3 ms·
> 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 un
by 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 agoI 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 agoFair enough! Although obviously having to copy the data out (especially if it has a destructor) is a bit nasty.
- robotresearcher 11y agoYes, 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.