From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,d95b511473b3a931 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,d95b511473b3a931 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,d95b511473b3a931 X-Google-Attributes: gid1014db,public From: Mark Eichin Subject: Re: Language Choice and Coding style Date: 1996/07/03 Message-ID: #1/1 X-Deja-AN: 163603678 sender: eichin@maneki-neko.cygnus.com references: organization: Cygnus Support, Eastern USA newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1996-07-03T00:00:00+00:00 List-Id: Intriguing. > p one, p two: char const *; Interestingly enough, this eliminates the common mistake of using char const *p1, p2; /* A */ when char const *p1, *p2; /* B */ is what is intended. (Yes, I know you'll get a compiler error with A in most actual uses, but you can construct cases where you don't...) One obvious nit is the C bitfield specifier... but it turns out that it is easy to leave unchanged from context (by putting it in the type, not the variable... ie: int j1:1; becomes j one: int: 1; with no ambiguity.) The conclusion > it is not our *compiler technology* that forbids embedded blanks > in identifiers, it is our *programming language standards*. is interesting, because the C standard was explicitly an attempt to codify existing practice in what had begun as a low-level language design, and not redesign it. C++ is correspondingly limited to the same thing by it's C heritage. Ada doesn't have these particular constraints... so were spaces in identifiers simply not considered [since noone else had used them in 30 years] or where they deliberately omitted? _Mark_ Cygnus Support, Eastern USA