82ec33d1   
   From: crusader.mike@googlemail.com   
      
   On Oct 25, 2:53 am, trop...@googlemail.com wrote:   
   > Michael Kilburn  wrote:   
   > > Needed:   
   >   
   > > - to convert TAG from pointer to array, i.e. solution should look smth   
   > > like:   
   > >      // .h   
   > >      template class Value   
   > >      {   
   > >          ...   
   > >          static char const TAG[];   // note that array size is not   
   > >                                     // associated with variable yet   
   > >      };   
   >   
   > I still don't understand why you need that. A C string is not delimited   
   > by the length of the array but by the terminating 0.   
   > Smart compilers may even optimize away strlen if the string value is   
   > known at compile time.   
      
   Because in certain cases losing information (array size known at   
   compile-time) is unacceptable. You'll be surprised how much time   
   typical C++ program spends scanning memory for zero byte or similar   
   operations which could be avoided if array length was not lost   
   somewhere due to array-to-ptr decay (which C++ does so eagerly, that   
   you can't prevent it even if you wanted to). We probably burned half   
   of amazon forest in CPUs around the world scanning memory for   
   zeroes. :-)   
      
   C-stlye strings are evil legacy of C and their widespread and   
   unquestionable adoption is bad -- it is bad to the point that there is   
   no strtod() function that does not require string to be zero-   
   terminated. I've checked CORBA orb we use and found that string   
   returned by my method gets strlen'ed up to three times before being   
   sent over the wire -- only because CORBA standard decided to adopt C-   
   style strings instead of anything else... and etc, and etc.   
      
      
   > >      // strangely enough compiler treats these declarations as typical   
   > >      // "extern char const S[N]" and associates array length (e.g.   
   > >      // sizeof(S1)) with given variable instance (e.g. Value::TAG)   
   >   
   > Strange indeed, how is that supposed to work for other translation units?   
   > Or will it those just assume a pointer, like in a function parameter?   
      
   This code is in .h file -- it seem to work fine if related translation   
   unit includes it.   
      
      
   > > In any case code above does not work. After I've replaced array with a   
   > > reference to array, I've discovered that forward declarations used to   
   > > "add" array size info to variable stopped working -- compiler refuses   
   > > to accept them (same for stuff in .cpp -- now it complains about   
   > > difference between 'reference to array[]' vs 'reference to array[8]',   
   > > even though it was totally cool with 'array[]' vs 'array[8]').   
   >   
   > Well that's what I would expect and how it works for non-array types.   
   > So you complain about arrays not being first class citizens and on the   
   > other hand you also complain that they actually _do_ behave like first   
   > class citizens in the case of "reference to array"?   
      
   "First-class citizen" complaint was about compiler refusing to accept   
   code like this:   
   char const S1[] = "ABC";   
   char const S2[] = S1;   
   as well as few other things compiler refuses to do for me (like   
   returning arrays from functions & etc)   
      
   Wrt 'reference to array' problemmy complaint is that compiler behaves   
   in a not consistent manner, in particular this is fine:   
       extern char const S1[];   
       char const S1[4] = "ABC";   
      
   but this -- is not:   
       extern char const (&S1)[];   
       char const (&S1)[4] = "ABC";   
      
   silly compiler...   
      
   Regards,   
   Michael.   
      
      
   --   
         [ 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)