From: ootiib@hot.ee   
      
   On Tuesday, 17 September 2013 07:24:09 UTC+3, fmatthew5876  wrote:   
   > >    Foo a;   
   > >    Foo b;   
   > >    printf( "%s %s", a.toString(), b.toString() );   
   >   
   > Nope thread local would fail there. Even better with undefined order   
   > of function argument evaluation, sometimes you'll print a twice, and   
   > other times b twice.   
   >   
   > Thread local or not, using a global to convert instances of an object   
   > to strings is rather ridiculous, as your example points out.   
      
   I proposed 'thread_local' for supporting legacy idiom ...   
    On Thursday, 12 September 2013 03:30:07 UTC+3, fmatthew5876 wrote:   
   > C had a lot of old style functions like this:   
   >   
   > char* foo(/*some_args*/);   
   >   
   > where the returned pointer was a function local static.   
   > Of course this is not thread safe so we never do it anymore.   
      
   I even pointed out that "If that [this is not thread safe] is the only   
   problem for you" then use 'thread_local'. It was actually surprise   
   (that this is the only problem for you) since talking of 'printf'   
   in multi-threaded usage usually means garbled nonsense on terminal   
   screen.   
      
   If I need 'toString()' member function then it returns 'std::string'   
   by value. It can be used with 'c_str()' in 'printf' or wherever else that   
   needs 'char const*'. Typical text exchange is most limited by latency   
   and throughput of channel of exchange and absence of dynamic strings   
   does not affect its performance by percentage that matters. 'std::string'   
   you banned so probably it matters on your case.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)