James Kanze <james.kanze@[EMAIL PROTECTED]
> wrote in news:9b653ea1-eadb-464e-
abc7-11c9ee293746@[EMAIL PROTECTED]
> On May 7, 9:47 pm, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
>> meh...@[EMAIL PROTECTED]
wrote in news:b1ee3325-348a-41ec-88bd-d3aea0a2c784
>> @[EMAIL PROTECTED]
>
>> Besides, I recommend to get familiar with std::string and
>> forget the string lifetime issues forever.
>
> I can't let that pass. The only times I use C style strings is
> when lifetime is an issue; a static char[] with a constant
> initializer is static initialized, and effectively has an
> infinite lifetime.
And not much of use in a multithreaded application (presumably, char[]
array is used for changing the content, otherwise one should just use
string literals).
Any global mutable object will create problems in multithreaded
environment (and if you are writing a library you don't know if it is
going to be used in singlethreaded or multithreaded fa****on).
A static char[] has to be externally locked by each access. This should
better be encapsulated in a class managing this string - and voila, we
are back to the statics initialization order problem. One needs singleton
pattern or something similar here. And in a singleton one could easily
use std::string as well.
> A static std::string can easily be accessed
> before it is constructed, or after it is destructed.
>
Yes, avoid namespace-level statics, these are evil ;-) (no pun
intended!).
Note also that a static char[] array is of limited size. The size should
be checked explicitly by every mutating operation, which does not sound
very reliable. I would argue this solution has problems even in single-
threaded code.
Best regards
Paavo
|
