Safe thread to talk about const

Kian

Continuing the discussion from Enlightened:

@Kian said:
Do you know how to prevent it being used by library code? Because if not, the moment someone uses your custom type as a parameter for a templated library function you've violated the standard.

I get that argument (which is what Sutter is saying). Still, mutable members without synchronization seem useful enough to me (especially if you through other means guarantee that they will "never" be used in a multi-threaded context). Synchronization overhead is not free...

Well, as long as you don't use a class in a threaded context, it doesn't matter if it's thread safe. However, if you are choosing performance over safety, make sure you actually measured that you needed the performance and remember you'll need to teach peopler to never use it in an unsafe manner.

Kuro

This topic isn't even const!

Filed Under: until it's archived

Kian

Considering the speed at which threads get derailed, the best way to kill a topic is possibly to create a new thread for it :)

cvi

Well, yeah, but that applies equally to const and non-const methods.

Requiring const-methods to be thread safe (for reading) is a good goal. Making const-methods that are not thread-safe for reading illegal (which people seemingly were suggesting in the other thread) seems a bit overreaching to me, especially considering this is C++ (where shooting your feet is solely your own business).

NeighborhoodButcher

I approve the title of this topic.

Bulb

@Kian said:

Do you know how to prevent it being used by library code? Because if not, the moment someone uses your custom type as a parameter for a templated library function you've violated the standard.

Not me, them.

What I am saying is that the violation comes from using such object in context that assumes const methods are thread-safe (against other const methods), not from creating it.

It does not make creating such object good idea and the convention is definitely reasonable. But it is not a rule, just a (very reasonable) best practice.

@cvi said:

Requiring const-methods to be thread safe (for reading) is a good goal. Making const-methods that are not thread-safe for reading illegal (which people seemingly were suggesting in the other thread) seems a bit overreaching to me, especially considering this is C++ (where shooting your feet is solely your own business).

That's exactly why it isn't illegal.

In C++, that is. In Rust there is the borrow checker that does not allow multiple mutable references at the same time and the Sync trait that defines which types can be shared between threads at all and the Mutex that is a container for the locked value and only allows access to it when it is locked.

Kian

@cvi said:

Requiring const-methods to be thread safe (for reading) is a good goal. Making const-methods that are not thread-safe for reading illegal (which people seemingly were suggesting in the other thread) seems a bit overreaching to me, especially considering this is C++

The standard mandates that using the standard library on const parameters must not cause a data race. How you achieve this is up to you. Not having threads is one solution, but you are then making your object more limited. If someone uses your object in a threaded context, though, the one who violated the standard was the one who wrote the const method.

For different reasons, it may be preferable to write such code. There's a lot of code that is only defined when called with certain arguments.

@Bulb said:

What I am saying is that the violation comes from using such object in context that assumes const methods are thread-safe (against other const methods), not from creating it.

If I am cut-off from features of the language because someone else wrote a class that isn't well behaved, the one who wrote the class is the one that wrote non-conforming code. Not the person trying to write code according to the standard.

Correct code doesn't need disclaimers, it "just works" with other correct code. Incorrect code may be necessary or desirable, but it is still incorrect. C++ lets you bypass any and all security features, because sometimes it is the right thing to do and it had to make compromises to get other features.

CHUDbert

Quick! Someone Jeff all the replies to new topics!