🚀 go-pugleaf

petergo@microsoft.UUCP (Peter GOLDE) writes:

>In section 8.4.2, the C++ standard disallows the legal ANSI C
>initialization:
>char cv[4] = "asdf";

First of all, there is no C++ standard yet.  Mr Golde seems to be referring
to E&S, a reference book which at the moment does not correspond entirely
to any commercial C++ compiler.  The ANSI C++ X3J16 standards committee
will eventually produce a C++ standard, and it will look at lot like E&S
without the annotations.  But E&S is not the C++ standard.

>Now I have to recode my strings using brace notation: what a pain!

I agree that this restriction will break some existing code.  But how
often is it essential to use a fixed-size array of characters without
the terminating null?  To cater to those special cases, IMHO very rare,
C introduces weird semantics for array initialization.  In addition, it
seems to me that 
	char cv[4] = "asdf";
is more likely to be an error than a deliberate attempt to save one byte.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

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?

--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck	

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.

petergo@microsoft.UUCP (Peter GOLDE) writes:
>In section 8.4.2, the C++ standard disallows the legal ANSI C
>initialization:
>char cv[4] = "asdf";
In article <513@taumet.com>, steve@taumet.com (Stephen Clamage) writes:
> First of all, there is no C++ standard yet.  Mr Golde seems to be referring
> to E&S, a reference book which at the moment does not correspond entirely
> to any commercial C++ compiler.  The ANSI C++ X3J16 standards committee
> will eventually produce a C++ standard, and it will look at lot like E&S
> without the annotations.  But E&S is not the C++ standard.

True; however, the standards committee has adopted E&S as the base document
for the standard.  This probably means that any nit in E&S that is not
screamed about by the user community will wind up in the standard.

> To cater to those special cases, IMHO very rare,
> C introduces weird semantics for array initialization.  In addition, it
> seems to me that 
> 	char cv[4] = "asdf";
> is more likely to be an error than a deliberate attempt to save one byte.

The same argument could have been made against this construct in ANSI C;
however, it is permitted there.  Gratuitous incompatibilities with ANSI
C which yield no significant advantage should be avoided; they only make
it harder for people to convert from C to C++.

--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck	

In article <513@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>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 agree that this restriction will break some existing code.  But how
>often is it essential to use a fixed-size array of characters without
>the terminating null?  To cater to those special cases, IMHO very rare,
>C introduces weird semantics for array initialization.  In addition, it
>seems to me that 
>	char cv[4] = "asdf";
>is more likely to be an error than a deliberate attempt to save one byte.

A good argument.  I might even accept it, were I designing a language
myself.  But many of the best C language experts in the country
(the ANSI C committee) considered this argument, and rejected it.
The issue should be closed now.

BTW, just because string initialization of the type mentioned
is "very rare" in YOUR code, don't think that it's very rare
in other peoples code.  0 termination is not the best string 
representation for many applications.

---
Peter Golde        petergo%microsoft@uunet.uu.net

In article <59110@microsoft.UUCP> petergo@microsoft.UUCP (Peter GOLDE) writes:
|In article <513@taumet.com> steve@taumet.com (Stephen Clamage) writes:
|>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 agree that this restriction will break some existing code.  But how
|>often is it essential to use a fixed-size array of characters without
|>the terminating null?  To cater to those special cases, IMHO very rare,
|>C introduces weird semantics for array initialization.  In addition, it
|>seems to me that 
|>	char cv[4] = "asdf";
|>is more likely to be an error than a deliberate attempt to save one byte.
|
|A good argument.  I might even accept it, were I designing a language
|myself.  But many of the best C language experts in the country
|(the ANSI C committee) considered this argument, and rejected it.
|The issue should be closed now.
|
|BTW, just because string initialization of the type mentioned
|is "very rare" in YOUR code, don't think that it's very rare
|in other peoples code.  0 termination is not the best string 
|representation for many applications.

In this and in other areas where C has muddled type rules,
perhaps backwards compatibility and other "special" needs can be
met via the extern "C" construct?  In particular strings could be
interpreted according to the rules of the language requested?

extern "Pascal" { char cv[] = "asdf"; }

for example?

I'd put my vote in for C++ trying to clean up type rules somewhat,
rather than trying to maintain the last iota of backwards compatibility
[with K&R C, ANSI C, C++ 1.2, C++ 2.0, ....????]  The drive to maintain 
backwards compatibility has made some of the type inference rules so
obtuse that compiler writers can't figure them out, let alone programmers
actually use them intelligently.

In my opinion C++ is not C, and the needs of object oriented programmers
are sufficiently different than the needs of C programmers that fine
grained details of ANSI-C ought to be considered again, rather than
accepted unthinkingly as "THE" answer.  Let's try to clean things up a 
little bit around the edges.

petergo@microsoft.UUCP (Peter GOLDE) writes:

>BTW, just because string initialization of the type mentioned
>is "very rare" in YOUR code, don't think that it's very rare
>in other peoples code.  0 termination is not the best string 
>representation for many applications.

A good point.  Nonetheless, 0 termination is the standard in C.
There is no support anywhere else in the language for strings
which are not 0-terminated.  You have to write special code to
handle them wherever such are used.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

>>>>> On 16 Nov 90 20:19:51 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said:

Jim> In my opinion C++ is not C, and the needs of object oriented programmers
Jim> are sufficiently different than the needs of C programmers that fine
Jim> grained details of ANSI-C ought to be considered again, rather than
Jim> accepted unthinkingly as "THE" answer.  Let's try to clean things up a 
Jim> little bit around the edges.

I think I'd agree with this, but let's make it a question instead.  Is there
anyone out there doing something with C++ where they need absolute ANSI-C
compatibility at compile time?  What are the benefits of taking this draconian
an approach to a language that's still growing?  To me, the ability to link
ANSI-C functions with C++ code is more than sufficient and, in some cases,
helps improve the code by separating programming styles.  Its nice for
programmer learning curve for there to be a significant overlap in ANSI-C and
C++, but there is already divergence, so why not attempt to improve things?
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
uunet!cimshop!davidm				Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <59110@microsoft.UUCP> petergo@microsoft.UUCP (Peter GOLDE) writes:
|In article <513@taumet.com> steve@taumet.com (Stephen Clamage) writes:
|>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 agree that this restriction will break some existing code.  But how
|>often is it essential to use a fixed-size array of characters without
|>the terminating null?  To cater to those special cases, IMHO very rare,
|>C introduces weird semantics for array initialization.  In addition, it
|>seems to me that 
|>	char cv[4] = "asdf";
|>is more likely to be an error than a deliberate attempt to save one byte.
|
|A good argument.  I might even accept it, were I designing a language
|myself.  But many of the best C language experts in the country
|(the ANSI C committee) considered this argument, and rejected it.
|The issue should be closed now.

This argument is based on the false assumption that the ANSI C committie
was trying to adopt the ideal set of 'C' language features as a standard.
It was not, in fact the ANSI 'C' specification specificaly states that the
ANSI 'C' committies charter was to CODEFY EXISTING PRACTICE. It would be
far more correct to say "many of the best C language experts in the country
(the ANSI C committee) considered this argument and found it did not correspond
to existing practice".
    The ANSI committie did not set out to enhance or correct language features.
The goals for the development of C++ are far different. Since the existing
practice criteria for development was invalid, the goal was primarily to
enhance the language and correct percieved problems with the original 'C'
language.
	Because of stronger type checking and other changes in the language
it is nearly impossible to port 'C' code to 'C++' anyway, this is just another
area of incompatibility to deal with.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com