Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: character array initialization
Message-ID: <59022@microsoft.UUCP>
Date: 12 Nov 90 19:47:30 GMT
References: <58962@microsoft.UUCP> <39503@ucbvax.BERKELEY.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 40

In article <39503@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:
|In article <58962@microsoft.UUCP>, petergo@microsoft.UUCP (Peter GOLDE) writes:
|> In section 8.4.2, the C++ standard disallows the legal ANSI C
|> initialization:
|> 
|> char cv[4] = "asdf";
|
|I just checked out that section.  Gack!  Why the hell did Stroustrup
|do that?  The rationale is that the string "asdf" really has five
|characters (trailing null), but the meaning is obvious and ANSI C
|allows it.
|
|Ellis and Stroustrup's commentary says (p. 153):
|
|	In this, C++ differs from ANSI C, where the example is allowed
|	and is intended to be a convenience to the programmer.
|
|What possible rationale is there for this change?

A possible rational would be if C++ were attempting to move towards 
stricter type checking of array types than ANSI-C.  In that regard,
however, C++ seems to be promulgating the confusion about whether arrays
are exact types or inexact in their first dimension.  Note in the above
example, the first dimension of an array is required to match exactly.
However, in function parameters, the first dimension is ignored -- 
a parameter char[10] is considered analogous to a char*.

I'd vote for cleaning this up by making arrays exact types everywhere
including their first dimension, retaining [sigh] implicit conversions
of arrays to pointers to their first members -- but only when assigning
an array to a pointer. To retain historical behavior then, people would 
have to declare parameters as char*'s and not char[10]'s.

An alternate approach would be to always consider arrays inexact in their
first parameter, except when allocating storage.  This weakens type
safety considerably.

Either way, choose one or the other!  Let's not have rules implying
inexact array types in some schenerios, and rules implying exact array types 
in other schenerios.