4 ms·

The fundamental problem with this pattern in C++ is that you can always just keep around a pointer into it and then the "mutex guard" thing falls apart. There's

by Gankro 11y ago

The fundamental problem with this pattern in C++ is that you can always just keep around a pointer into it and then the "mutex guard" thing falls apart. There's no way to communicate to the language that this pointer can't hang around any longer than the mutex guard (because that's the only thing preventing the pointer from being racy). You basically can't write safe abstractions in C++ in the face of pointers.

robotresearcher 11y ago
> You basically can't write safe abstractions in C++ in the face of pointers. Sure you can, with accessor methods (get/set). Don't expose the address of the underlying data structure. Don't expose the lock object either.
- jacques_chester 11y ago
  I think you're talking past each other. In both cases you need discipline to correctly interact with shared data. The point is: some languages enforce discipline with compilers. Some rely on engineers to enforce it themselves. Of the two, compilers appear so far to be more consistent.
  - robotresearcher 11y ago
    > compilers appear so far to be more consistent. That's true. Which is why object membership is private by default in C++. You can't get the address of an object member unless the author expressly allows you. That's why I think the GP's complaints about pointers making safe shared data nigh-impossible in C++ was maybe overstated. The language/compiler has things to help you. Much more than C, anyway.
- Gankro 11y ago
  Fair enough! Although obviously having to copy the data out (especially if it has a destructor) is a bit nasty.
  - robotresearcher 11y ago
    Yes, for big things it's a drag. Even for small things it's verbose to use and awful boilerplate to write. And I totally agree with the spirit of your argument that pointers and pointer aliasing makes concurrency harder in C/C++. Was just pointing out the standard well-known idiom for avoiding the problem. Indeed C++'s 'private' language feature allows the compiler to help you with it.
deleted 11y ago
[deleted]

by Gankro 11y ago

robotresearcher 11y ago

> You basically can't write safe abstractions in C++ in the face of pointers. Sure you can, with accessor methods (get/set). Don't expose the address of the underlying data structure. Don't expose the lock object either.

jacques_chester 11y ago
I think you're talking past each other. In both cases you need discipline to correctly interact with shared data. The point is: some languages enforce discipline with compilers. Some rely on engineers to enforce it themselves. Of the two, compilers appear so far to be more consistent.
- robotresearcher 11y ago
  > compilers appear so far to be more consistent. That's true. Which is why object membership is private by default in C++. You can't get the address of an object member unless the author expressly allows you. That's why I think the GP's complaints about pointers making safe shared data nigh-impossible in C++ was maybe overstated. The language/compiler has things to help you. Much more than C, anyway.
Gankro 11y ago
Fair enough! Although obviously having to copy the data out (especially if it has a destructor) is a bit nasty.
- robotresearcher 11y ago
  Yes, for big things it's a drag. Even for small things it's verbose to use and awful boilerplate to write. And I totally agree with the spirit of your argument that pointers and pointer aliasing makes concurrency harder in C/C++. Was just pointing out the standard well-known idiom for avoiding the problem. Indeed C++'s 'private' language feature allows the compiler to help you with it.

deleted 11y ago

[deleted]