Re: Please help with testing & improving a StringValue class
* Gianni Mariani:
Alf P. Steinbach wrote:
...
Comments, ideas, criticism etc. welcome!
Is it thread safe?
As much as any general class. ;-)
I don't believe in adding mutual exclusion to basic operations for a
general purpose class, but I understand the question: with non-mutable
values, it's natural to wonder whether that's in support of threading.
As I see it, adding mutual exclusion everywhere is inefficient, drags in
a lot of threading support code not otherwise needed, and leads to
spaghetti design when people feel "safe" doing anything whatsoever in
threads: IMHO threading code needs to be designed with care, not
accessing variables in other threads willy-nilly.
Cheers,
- Alf
PS: A more serious question: is it slicing safe? Version 01 is not, in
the sense that it's possible to use references or pointers so that one
ends up with a StringValue that's null (with value copied from a
StringValueOrNull). But I'm working on that, namely having
StringValueOrNull and StringValue derive from a common abstract base,
instead of having StringValue derive from StringValueOrNull. Now if
only I could make SFINAE & boost::disable_if work properly! :-)