petergo@microsoft.UUCP (Peter GOLDE) (11/10/90)
In section 8.4.2, the C++ standard disallows the legal ANSI C initialization: char cv[4] = "asdf"; Since C++ is supposed to be as close as possible to ANSI C without compromising its features, I don't see what purpose this restriction serves. This is a useful feature which ANSI C very deliberately put into the standard; having C++ not allow it is a plain nuisance. Now I have to recode my strings using brace notation: what a pain! Peter Golde petergo%microsoft@uunet.uu.net
steve@taumet.com (Stephen Clamage) (11/11/90)
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
jbuck@galileo.berkeley.edu (Joe Buck) (11/11/90)
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
jimad@microsoft.UUCP (Jim ADCOCK) (11/13/90)
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.
jbuck@galileo.berkeley.edu (Joe Buck) (11/13/90)
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
jamiller@hpcupt1.cup.hp.com (Jim Miller) (11/13/90)
>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 I second that emotion. jim miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
petergo@microsoft.UUCP (Peter GOLDE) (11/16/90)
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
jimad@microsoft.UUCP (Jim ADCOCK) (11/17/90)
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.
steve@taumet.com (Stephen Clamage) (11/18/90)
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
davidm@uunet.UU.NET (David S. Masterson) (11/18/90)
>>>>> 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!"jamiller@hpcupt1.cup.hp.com (Jim Miller) (11/21/90)
>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. Because C code is being brought into C++ wholesale in some cases. An earlier thread *seemed* to complain about ANY divergence from ANSI C or maybe even K&R I C (at least that's what I felt some comments said). IMO, anything that would give people (managers or programmers) reasons NOT to adopt C++ should be avoided. These reasons, mind you, need not be valid, just there. One big reason is/would be the dreaded "incompatability", just there being such things (never mind they might not happen) keeps people away. The reason I supported the char x[4]="abcd"; incompatability is because is is *usally* an error. If it were not, I'd be against it. Even so I would be willing to support not making the change if it seems that anyone is really bothered about it (by "really" I mean code is affected). I would also be forced to back off by anyone pushing the "no incompatability" banner in the interest of acceptance. jim - do I have to be consistant in my arguments? - miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
daves@ex.heurikon.com (Dave Scidmore) (11/22/90)
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