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

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

In article <48d6cu$8pv@engnews1.eng.sun.com>,
clamage@Eng.Sun.COM (Steve Clamage) writes:
[..]
|> 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.

"Behaving properly" would be a severe change in the semantics of
array-params.  So IMO this decission is ok.

- The first step toward "behaving properly" would be DEPRECATION:
  a feature that might be removed in a next version of C++.
- The second step could be "remove array-params".
- And then, when there is no C++ code left with array-params
  one could do the third step:
  Reintroduction of array-params but now "behaving properly".

IMHO  deprecation is by itself an advantage  (without a future
second+third step) as it makes the problem of non-properly
behavior obvious to the programmer.
By not using array-params any more, new code will become less
errorprone and more honest, while old code will still compile
(with a 'diagnostic message').


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

Hi,

I've been wondering. Both the C++ compiler on my macintosh (CodeWarrior)
and GNU C++ (2.6.something) say that the size of an array passed as an
argument to a function is 4, which is the size of a pointer (or
reference).

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.

The ANSI paper also explicitly adds:

* [...] array-to-pointer [...] standard conversions are suppressed on the
operand of sizeof.

What's the verdict? 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?

I'm very interested in what the protagonists of (a) have to say...

--
        Theo Vosse
        ----------
        Unit for Experimental and Theoretical Psychology
        University of Leiden
        The Netherlands
---
[ 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. ]

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