🚀 go-pugleaf

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.