🚀 go-pugleaf

In article EAA05095@logatome.micronet.fr,
verec@micronet.fr (Jean-Frangois Brouillet) writes:
>In article <48804v$eu9@sunsystem5.informatik.tu-muenchen.de>,
>schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) wrote:
>
>>In article <9531505.20142@mulga.cs.mu.OZ.AU>,
>>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>[..]
>>|> The reason is that the type of `v' is converted from `char [N]' to
>>|> `char *' (see 8.3.5/3 in the April draft working paper).
>>[..]
>>
>>I'd prefere this "adjustment" to be DEPRECATED.
>>
>I can't exactly quote BS from memory, but I think he said something like
>"C arrays are weak and beyond repair". The point is that C semantic
>couldn't be preserved, were sizeof(v) allowed to return the actual size of
>the array in bytes.

Early in the C++ standardization process we had a nice proposal to
change built-in arrays in C++ to behave "properly". The size of the
array would be part of the type in function parameters, for example.
A lot of people (including me) liked the proposal on language-design
grounds, but the consensus was (including me) that it would seriously
break C compatibility, and so it was not adopted. Some breaks are
tolerated, but this one was considered too fundamental.

>The "quasy religious" approach BS followed regarding C compatibility when
>designing C++ may be questionable, but the fact is that C++ is near 100
>percent C compatible, and we have to live with that, wether we agree or
>not.

I think that is a fair assessment.

If you want arrays with nice properties, consider using an array class
such as vector or valarray instead of C-like built-in arrays. I don't
see how built-in arrays can be deprecated given their widespread use
in the portion of the standard library inherited from C. To pick one
example, what do you do about all the <string.h> functions?

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]