🚀 go-pugleaf

vosse@ruls41.fsw.LeidenUniv.nl (Theo Vosse) writes:

>[...] If I have a function
>
>void Add(DataPoint* dp, char v[N])
>{
>    ... sizeof(v) ...
>}
>
>Should sizeof(v) be
>
>a) 4
>b) N
>c) Another value?

`sizeof(v)' should be equal to `sizeof(char *)' (i.e. 4 on typical 32-bit
implementations).

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).
You cannot pass arrays by value in C or C++ (at least not
unless you wrap them up in a struct or class).

>However, both ARM and some ANSI proposal on the net (the September working
>paper?) state:
>
>* When applied to an array, the result is the total number of bytes in the
>array.

That is not relevant in this example, since despite the declaration,
`v' is not an array.

>The ANSI paper also explicitly adds:
>
>* [...] array-to-pointer [...] standard conversions are suppressed on the
>operand of sizeof.

Again, this does not apply - `v' is not an array, so of course the
array-to-pointer standard conversion cannot be applied.  The change
of the type of `v' from array to pointer (since the declaration of
`v' is in a function parameter) is not an instance of the
array-to-pointer standard conversion described in 4.2 which applies to
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.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ 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. ]

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

--------------------------------------------------------------------
 ,_.   Ulf Schuenemann
#,  \  Fakultaet fuer Informatik, Technische Universitaet Muenchen, Germany.
 |   > email: schuenem@informatik.tu-muenchen.de
 v=-<  WWW:   http://hphalle2.informatik.tu-muenchen.de/~schuenem/
---
[ 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. ]

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. ]