🚀 go-pugleaf

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).
>[..]
>|> That is not relevant in this example, since despite the declaration,
>|> `v' is not an array.
>[..]
>|> values.  It is a special "adjustment" that is specified in 8.3.5/3,
>|> not a conversion in the usual C++ sense of the word.
>
>I'd prefere this "adjustment" to be DEPRECATED.
>
>Treating a name different to its declaration (without saying a word)
>is errorprone and leads users to confusion, like Theo Vosse.
>
>> void Add(DataPoint* dp, char v[N])
>
>Contratry to the intention, the compiler does NOT check, that Add
>is called with a char-array of size N. The fact that C/C++ allows it,
>while trating it as a simple (... char * v) leads to a dangerous feeling
>of security.
>
>(... char v[N]) is nothing more than a comment. For honesty this
>information should be given that way (as comment) and not as a type.
>
>As array-type-params widespread used, the most I'm hoping to get
>is deprecation.
>
>
>Ulf Schuenemann
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.

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 developed the habit of having bells ringing in my head, whenever I have
to deal with "low-level" code (ie straight C, not C++), and use a lot of
ASSERT on invariants and the like, and I try to encapsulate such code as
much as I can.

C arrays are just the fully efficient, highly dangerous counterpart of
more "programmer friendly" C++ containers, and provided the very limited
support C offers when dealing with them (in fact C only provides a syntax
for element access; element/array (dynamic) allocation, freeing, resizing
must be done with *user* code), there are very few reasons to stick with
them. In fact, the only advocated use is the access speed, but I'm always
amazed by the so called "optimized" code which, in practice, only saves a
few cycles in rarely used portions of a program...
Jean-Frangois Brouillet
Macintosh Software Developer
verec@micronet.fr      (preferred)
verecundus@eworld.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. ]