John Nagle wrote:

> [...]
>    I tend to think that if you need leading or trailing
> underscores for something, the namespace system is too weak.

How would you strengthen the namespace system to eliminate trailing
underscores here:

class my_class
{
public:
     my_class(int useful_name) : useful_name_(useful_name) { }

     int useful_name(void) const { return useful_name_; }
private:
     int useful_name_;
};

Dave

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dheld@codelogicconsulting.com ("David B. Held") wrote in message news:<utmg10s0r9po1d@corp.supernews.com>...

> How would you strengthen the namespace system to eliminate trailing
> underscores here:
>
> class my_class
> {
> public:
>      my_class(int useful_name) : useful_name_(useful_name) { }
>
>      int useful_name(void) const { return useful_name_; }
> private:
>      int useful_name_;
> };

Obvious:

class my_class
{
  public:
     my_class(int useful_name) : useful_name(useful_name) { }

     int get_useful_name( ) const { return useful_name; }
  private:
     int useful_name;
};

Methods are verbs/sentences, data members are nouns.

regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel Salters wrote:
>
> dheld@codelogicconsulting.com ("David B. Held") wrote in message news:<utmg10s0r9po1d@corp.supernews.com>...
>
> > How would you strengthen the namespace system to eliminate trailing
> > underscores here:
> >
> > class my_class
> > {
> > public:
> >      my_class(int useful_name) : useful_name_(useful_name) { }
> >
> >      int useful_name(void) const { return useful_name_; }
> > private:
> >      int useful_name_;
> > };
>
> Obvious:
>
> class my_class
> {
>   public:
>      my_class(int useful_name) : useful_name(useful_name) { }
>
>      int get_useful_name( ) const { return useful_name; }
>   private:
>      int useful_name;
> };
>
> Methods are verbs/sentences, data members are nouns.

However, the Standard Library has set up a convention by which
many member function names are nouns: size() instead of get_size(),
empty() instead of is_empty(), and so on.
Do you think it is worthy of following, or do you think it should be
reserved as an exception to the Standard Library only?

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dheld@codelogicconsulting.com ("David B. Held") wrote
> How would you strengthen the namespace system to eliminate trailing
> underscores here:
>
> class my_class
> {
> public:
>      my_class(int useful_name) : useful_name_(useful_name) { }
>
>      int useful_name(void) const { return useful_name_; }
> private:
>      int useful_name_;
> };

Without changing the external interface:

    class my_class {
        int m_useful_name;
    public:
        my_class(int useful_name) : m_useful_name(useful_name) { }
        int useful_name(void) const { return m_useful_name; }
    };

Changing "my_class" and "useful_name" into something more meaningful:

    class color {
        unsigned char m_red, m_green, m_blue;
    public:
        explicit color(unsigned long rgb)
            : m_red((rgb & 0xFF0000)>>16)
            , m_green((rgb & 0xFF00)>>8)
            , m_blue(rgb & 0xFF) { }
        color(unsigned char red, unsigned char green, unsigned char blue)
            : m_red(red)
            , m_green(green)
            , m_blue(blue) { }
        color(const color&c)
            : m_red(c.m_red), m_green(c.m_green), m_blue(c.m_blue) { }
        // No need for operator= or destructor -- compiler version is OK

        // Accessor functions
        unsigned char red()   const { return m_red; }
        unsigned char green() const { return m_green; }
        unsigned char blue()  const { return m_blue; }
        unsigned long rgb()   const { return (unsigned long(m_red)<<16) |
            (unsigned long(m_green)<<8) | unsigned long(m_blue); }

        // et. cetera
    };

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> dheld@codelogicconsulting.com ("David B. Held") wrote
>
> >How would you strengthen the namespace system to eliminate trailing
> >underscores here:
> >[...]
>
> Without changing the external interface:
>
>     class my_class {
>         int m_useful_name;
>     public:
>         my_class(int useful_name) : m_useful_name(useful_name) { }
>         int useful_name(void) const { return m_useful_name; }
>     };

Well, consider the original comment:

[John Nagle wrote:]
 >   I tend to think that if you need leading or trailing
 > underscores for something, the namespace system is too weak.

All you did was replace trailing underscores with m_ prefixes.  To which
I'd like to ask: does m_ mean "member", or "Micro$oft"? ;)  Not to
mention that your solution doesn't change the namespace system at all.
I think it's useful to have a "member wart" of some kind, whether it is
a trailing underscore or an m_ prefix, which was simply my point.  Or,
to directly address John's comment, I don't think member warts are all
that evil, or an indication that the naming system is broken.  I can't
imagine a better alternative that would allow one to use the same names
for private members, accessors, and parameters.

Dave

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dheld@codelogicconsulting.com ("David B. Held") wrote (abridged):
> How would you strengthen the namespace system to eliminate trailing
> underscores here:
>
> class my_class
> {
> public:
>      my_class(int useful_name) : useful_name_(useful_name) { }
>
>      int useful_name(void) const { return useful_name_; }
> private:
>      int useful_name_;
> };

The first part can be written:
   my_class::my_class(int useful_name) : useful_name(useful_name) { }

or:
   my_class::my_class(int useful_name) {
       this->useful_name = useful_name;
   }

already. The second part needs a language change. One approach would be to
put member functions and member variables into different scopes. The
compiler would need to look for useful_name() in a different scope to
useful_name - adding the brackets would make it a different kind of name.

If I recall correctly, that's what Java does. It is easier in Java because
there is no address-of operator. In C++ we might need some extra syntax to
say whether we want the address of the function or the variable. It's
doable.

Eiffel has another approach. It does not really allow public instance
variables. Declaring one actually declares an implicit accessor function.
I like this approach but it would be difficult to retrofit into C++.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer <andys@evo6.com.nospam> wrote:

> Historically, C compilers used to prefix global identifiers emitted to
> the linker with '_'.

Historically, C compilers used to prefix all identifiers emitted to the
assembler with '_', lest they clash with instruction opcodes or other
alphanumericals having special meaning to the assembler, thereby producing
an illegal assembly file.  The fact that the linking issues
(e.g. "start" in crt0 vs. "_start" from C)
are resolved by the underscore trick as well, is coincidental. It was always
possible to use other characters that were legal in the assembly identifiers,
but not in the C ones.

 Leo

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0211050744.57171a1@posting.google.com>, James Kanze
<kanze@gabi-soft.de> writes
>I don't know how this red-herring slipped in.  The necessity of the
>alternative tokens has nothing to do with any possible confusion between
>bitwise and logical operations.

I slipped it in to explain why I actually prefer the alternatives.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrea Griffini wrote:
 > On Mon, 4 Nov 2002 15:52:39 +0000 (UTC),
 > francis.glassborow@ntlworld.com (Francis Glassborow) wrote:
....
 > Sure I know there are STL replacements (I've even considered
 > adopting one) but I always supposed that using them is (from
 > a standard point of view) jumping in UB with both feet.
 > Is UB to use a name with two underscores and is ok to kick
 > away the system libraries ?

If either of the two vendors involved claims that the combination of
particular STL replacement with a particular compiler constitutes a
conforming implementation of C++, and if you feel you can trust that
claim, then it's OK. If there's no such trustworthy claim, it isn't.
Which really is no different from the case where both components come
from the same vendor.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote
> Allan W <allan_w@my-dejanews.com> writes
> >I said you can't use it because the compiler or library might.
> >I didn't say it would always fail -- just that these names are reserved.
> >"Be careful -- those things can hurt somebody."
> >
> >You said you CAN use it, but you go on to say that doing so might
> >cause undefined behavior. "You can point that at your foot and pull
> >the trigger if you want. However, you might lose a toe if you do so."
> >
> >Which one of us is silly?
>
> I think that your not being a native English speaker may be the problem.
> In English we distinguish between 'cannot' and 'should not'.

I am in fact an English speaker, born and raised in the United States.
Perhaps the distinction is between English as spoken in the United States,
and "The Queen's English" as spoken in England and Europe?

> 'I cannot fly' depending on context has two meanings in English (well at
> least two) 1) Flying is not one of my innate abilities. 2) I have not
> learned to fly an aircraft.
>
> 'I cannot drive a car' can mean that I like the physical ability to do
> so (e.g. being a paraplegic) or that I have not learnt how to. However
> if I have had my licence removed I can still drive a car, but I should
> not do so.

That is certainly true in some contexts, such as legalese. But informal
speech is not always so precise. "I can't drive now -- I don't have my
license!" does not mean "I am incapable of driving," but is rather an
emphatic way of saying "I really should not drive now!"

BTW, in the United States we would say "have not learned how to"
rather than "have not learnt how to." Another difference that might or
might not be interesting is the way we pronounce very large numbers.

                     United States   Europe
One million          1E6             1E6
One thousand million "Bad English"   1E9
One billion          1E9             1E12
One million billion  "Bad English"   1E18
One trillion         1E12            1E21

> You will find that because of the ambiguities inherent in the sue of
> 'may', 'can' and 'should' Standardese uses the directive terms 'Shall'
> and 'Shall not' where a language  requirement is specified. However even
> there some breaches are classified as undefined behaviour. Please note
> that implementations are allowed to make UB defined so UB is a
> portability issue (it specifies such code as inherently non-portable)

I wasn't using language meant for the standard, and I didn't think
that you were either. Nowhere in either of our messages did either one
of us use any variation on "should."

In my comments, when I said you can't use reserved names, I meant that
you cannot do so in a portable fully-compliant program.

I now understand that what you meant was "Of course you can use it, even
though you should not." I (mistakenly) interpreted your remarks
somewhat differently -- as I stated (quoted above). If this caused any
offense, I sincerely and publicly apologize.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> francis.glassborow@ntlworld.com (Francis Glassborow) wrote
>
>>Allan W <allan_w@my-dejanews.com> writes
....
>>I think that your not being a native English speaker may be the problem.
>>In English we distinguish between 'cannot' and 'should not'.
>
>
> I am in fact an English speaker, born and raised in the United States.
> Perhaps the distinction is between English as spoken in the United States,
> and "The Queen's English" as spoken in England and Europe?

I don't think so.

>>'I cannot drive a car' can mean that I like the physical ability to do
>>so (e.g. being a paraplegic) or that I have not learnt how to. However
>>if I have had my licence removed I can still drive a car, but I should
>>not do so.
>
>
> That is certainly true in some contexts, such as legalese. But informal
> speech is not always so precise. "I can't drive now -- I don't have my
> license!" does not mean "I am incapable of driving," but is rather an
> emphatic way of saying "I really should not drive now!"

In informal American usage, the meaning of "I can't drive" depends upon
the context (in this case, the phrase "I don't have my license" provides
that context). It could carry either meaning.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

alec@arlross.demon.co.uk (Alec Ross) wrote
> Can someone please give me some advice as to the interpretation of
> 17.4.3.1.2 wrt the use of leading underscores in names.
>
> (A reminder: "
>         -  ... contains a double underscore (__) or begins with an
> underscore followed by an upper case letter (2.11) is reserved to the
> implementation for any use.
>         - Each name that begins with an underscore is reserved to the
> implementation for use as a name in the global namespace."  (plus a
> footnote extending the reservation to namespace ::std.)
> )
>
> My queries mainly centre on the interpretation of "reserved" in the
> context above.

"Reserved" in this context means that you can't use it, because the
compiler or library MIGHT need it. Even if you know for a fact that
neither the compiler nor library DO use it, it's still reserved for
them and you can't use it.

Compare this to a reservation at a hotel. Mr. Jones wishes to check in,
but all the rooms are rented except for room 101, which is reserved for
Mr. Ross. Even though Ross isn't here yet, Jones can't use that room.

> Looking at 17.4.3.1, I think I know the intention, and
> how to interpret the text on underscores - but I am not certain.
>
> My interpretation is such that, inter alia, a name beginning with a
> single underscore and not followed by an upper case letter, nor
> including a double underscore, would be satisfactory (wrt underscores)
> in an application provided it were not declared in either the global or
> standard namespace.  In particular, a name consisting of a single
> underscore (only) would be OK provided that it were in some user-defined
> namespace, or class.
>
> Is this correct?

That's my understanding exactly. You're supposed to be able to use
names that start with underscores, provided the second letter isn't
an underscore or capital letter, and provided it's within a namespace.

However, I think there are some compilers (not 100% compliant) that
might have problems with names starting with underscores, even though
the standard says that shouldn't happen. For instance, Microsoft
probably has problems with the name "_far" even in class declarations.
('Course, they have problems with the name "far" too -- clearly non-
compliant.)

You're right about what the standard says, but if you want to remain
maximally portable, you should forget about any identifiers that
start with an underscore.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <j465vi3osh.fsf@informatik.hu-berlin.de>, Martin v. L   wis
<loewis@informatik.hu-berlin.de> writes
>alec@arlross.demon.co.uk (Alec Ross) writes:
>
>> My interpretation is such that, inter alia, a name beginning with a
>> single underscore and not followed by an upper case letter, nor
>> including a double underscore, would be satisfactory (wrt underscores)
>> in an application provided it were not declared in either the global or
>> standard namespace.
>
>What do you mean by "satisfactory (wrt underscores)".

I meant that such a name would be not be invalid - syntactically, or
semantically - on the basis of its use of underscore(s).

> An application
>must not add any names to namespace std, see 17.4.3.1/1.

I know.  The sentence at the top of this mail was addressing different
cases.  Sorry if this was insufficiently clear.

>
>Using such names in the global namespace is well-defined.
>
>> In particular, a name consisting of a single underscore (only) would
>> be OK provided that it were in some user-defined namespace, or
>> class.
>>
>> Is this correct?
>
>Yes, although you could remove the restriction that it must be in a
>user-defined namespace: The name '_' is not reserved at all, so you
>can use it as a global name as well (it is, indeed, common to use it
>as a macro name).

Yes, I have seen some macro uses too.  However I was wanting a sanity
check on my understanding of these things.  For example, the text
"begins with an underscore is reserved to the implementation for use as
a name in the global namespace" could be considered to apply to a single
'_'.  I.e it begins with an underscore, and has nothing thereafter.  Or
is a strong interpretation wanted for "begins"? If not, and single
underscore were left as a name after preprocessing, then either I'm
missing something, or, ISTM, the name would conflict with that reserved
for the global namespace.

I'm not principally concerned with global names as such, and even less
with introducing any user-defined global names in my code.  I am
concerned with issues of interpretation of the standard here.
Specifically I wish to use a single '_' as a name within a class or
namespace.  Given that the implementation could use this name globally,
I would be content that the local name hid the global one, if this could
be guaranteed to be legal and safe.
--
Alec Ross

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0210311313.3cfbe3b8@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
...
>> My queries mainly centre on the interpretation of "reserved" in the
>> context above.
>
>"Reserved" in this context means that you can't use it, because the
>compiler or library MIGHT need it. Even if you know for a fact that
>neither the compiler nor library DO use it, it's still reserved for
>them and you can't use it.

[snip analogy]

Thanks, that was my understanding, and I am clear on that.  However,
ISTM that the sense of "reserved to the implementation for use as a name
in the global namespace" could be interpreted as implying its
reservation in the global namespace, as above, _and disallowing of its
use elsewhere_.  I do not believe that that is a correct interpretation,
but would like to be quite clear about how to interpret the Standard
here.


>> Is this correct?
>
>That's my understanding exactly. You're supposed to be able to use
>names that start with underscores, provided the second letter isn't
>an underscore or capital letter, and provided it's within a namespace.

[snip potential platform issues]

>You're right about what the standard says, but if you want to remain
>maximally portable, you should forget about any identifiers that
>start with an underscore.


Thanks.  That is what I have generally done.  However, I have a case now
where it would be very convenient to use such a name.  If I do, I'd like
to confirm my understanding of how the Standard should be interpreted -
as well as see what my compilers do in this respect.  (That is, I could
sacrifice some current portability, as long as the code is well-formed,
and is treated correctly by at least one or two compilers.)
--
Alec Ross

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0210311313.3cfbe3b8@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>"Reserved" in this context means that you can't use it, because the
>compiler or library MIGHT need it. Even if you know for a fact that
>neither the compiler nor library DO use it, it's still reserved for
>them and you can't use it.

That is silly. Of course you can use any name you like, however if you
elect to use names that are reserved to the implementation the
consequences are your responsibility, and your code effectively has
undefined behaviour.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri,  1 Nov 2002 17:08:57 CST, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

>That is silly. Of course you can use any name you like, however if you
>elect to use names that are reserved to the implementation the
>consequences are your responsibility, and your code effectively has
>undefined behaviour.

I never found a compiler helping the programmer on this
front. For example once I had to help a friend to debug
some code that was crashing before the first instruction
of main even if there were no objects defined by him
instantiated before that (it was actually a C program
compiled with a C++ compiler) and the problem was in
the name of a global data variable with a leading
underscore that was clashing with the name of an internal
function and that was creating confusion to the linker...

I wouldn't be simple to just add checks in the compiler
to emit warnings ? May be the check could be implictly
disabled for source files coming from specific system
directories (system includes often need black magic) or
using a #pragma ...

That would help also improving portability and there
are so many reserved names that it's easy to step
also involuntarely on them.

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc392f5.3789663@news.tin.it>,
 on Sat,  2 Nov 2002 16:45:46 CST,
 agriff@tin.it (Andrea Griffini) wrote:

> On Fri,  1 Nov 2002 17:08:57 CST, Francis Glassborow
> <francis.glassborow@ntlworld.com> wrote:
>
> >That is silly. Of course you can use any name you like, however if you
> >elect to use names that are reserved to the implementation the
> >consequences are your responsibility, and your code effectively has
> >undefined behaviour.
>
> I never found a compiler helping the programmer on this
> front.

Compiler's aren't obliged to "help the programmer on this front" -
it is (AIUI) undefined behaviour.

> For example once I had to help a friend to debug some code that was
> crashing before the first instruction of main even if there were no
> objects defined by him instantiated before that (it was actually a C
> program compiled with a C++ compiler) and the problem was in the
> name of a global data variable with a leading underscore that was
> clashing with the name of an internal function and that was creating
> confusion to the linker...

Historically, C compilers used to prefix global identifiers emitted to
the linker with '_'. As a consequence, using a leading '_' on an
identifier is probably bad news. That's (part of) the reason they're
reserved for use by the implementation. There are times when - if you
really, really, _really_ know what you're doing - you may want to do
it. But as a general rule, there's no advantage from a user's point of
view (_why_ would you want to prefix a global identifier with '_'?
Other than to generate undefined behaviour?)

> I wouldn't be simple to just add checks in the compiler to emit
> warnings ? May be the check could be implictly disabled for source
> files coming from specific system directories

The standard places no requirements on the emission of warnings. If
(as it seems) you think this would improve the quality of
implementation, then perhaps you should ask you compiler vendor to do
so. Personally, I find it simple to just avoid using those
identifiers.

> (system includes often need black magic) or using a #pragma ...

"system includes" often use the identifiers reserved for the
implementation because the _have_ to use identifiers reserved for the
implementations use. (That's the reason so many people moan about not
being able to read the code in standard library headers).

> That would help also improving portability

Not using reserved names would help improve portability.

> and there are so many reserved names that it's easy to step also
> involuntarely on them.

It's also very easy to voluntarily avoid them:

Avoid identifiers with either a leading _ or containing a double __.
Place all of your code inside a namespace (other than std).

That covers pretty much everything you need to avoid (and some that
you don't), in two easy to read (and remember) sentences.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun,  3 Nov 2002 00:09:04 CST, Andy Sawyer <andys@evo6.com.NoSpam>
wrote:

>Compiler's aren't obliged to "help the programmer on this front" -
>it is (AIUI) undefined behaviour.

Yeah... and a conforming compiler may have as its only
diagnostic message "your program has an error somewhere"
without losing being conformant for that. So ?

While it's true we're not that far from this situation
when talking about errors done when using the standard
template library, still I see that as a problem of young
technology... that it's hoped to change in the future.
There are formal issues and pratical issues; saying "you
must not use any of the name that are reserved to me"
solves the formal one, but there's a pratical one when
the exact list of all those names is strange, long and
hard to remember and if a compiler is not required to
inform you when you're violating the rule.

>Historically, C compilers used to prefix global identifiers emitted to
>the linker with '_'. As a consequence, using a leading '_' on an
>identifier is probably bad news.
>That's (part of) the reason they're reserved for use by the
>implementation.

I don't see that as being a problem. Just the linker will
get double leading underscores on names to which you added
a leading underscore at the C level.

>> I wouldn't be simple to just add checks in the compiler to emit
>> warnings ? May be the check could be implictly disabled for source
>> files coming from specific system directories
>
>The standard places no requirements on the emission of warnings. If
>(as it seems) you think this would improve the quality of
>implementation, then perhaps you should ask you compiler vendor to do
>so. Personally, I find it simple to just avoid using those
>identifiers.

Do you think this is this a valid C++ program ?

  #include <iostream>

  int main()
  {
    int HUGE_VAL = 1001;
    std::cout << "Hello, world. "
              << " The value " << HUGE_VAL
              << " is huge, isn't it ?\n";
  }

>> That would help also improving portability
>
>Not using reserved names would help improve portability.

I think having a little help in remembering what those
reserved names are would be better.

>That covers pretty much everything you need to avoid (and some that
>you don't), in two easy to read (and remember) sentences.

Try to write down the list of all identifiers you can't
have for your use in a program that includes any
standard header. Then check for example with the first
table in [diff.library] to see how many you forgot just
from that table.

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc4e3b4.2553911@news.tin.it>,
 agriff@tin.it (Andrea Griffini) wrote:

> On Sun, 3 Nov 2002 00:09:04 CST, Andy Sawyer <andys@evo6.com.NoSpam>
> wrote:
>
> >Compiler's aren't obliged to "help the programmer on this front" -
> >it is (AIUI) undefined behaviour.
>
> Yeah... and a conforming compiler may have as its only
> diagnostic message "your program has an error somewhere"
> without losing being conformant for that. So ?

If it's so important to you, why not use a compiler that gives you the
diagnostics you want? If there isn't such a compiler, why not go
implement one? Or implement your set of diagnostics in (e.g.) g++ so
that everyone can benefit?

> While it's true we're not that far from this situation
> when talking about errors done when using the standard
> template library,

That rather depends on how the QoI of your chosen compiler. My
preferred compiler (Comeau) gives very helpful messages in that
context, but I must infer from your comment that your compiler
doesn't. Go tell that vendor that their QoI sucks.

> still I see that as a problem of young technology...

Or poor QoI.

> >Historically, C compilers used to prefix global identifiers emitted
> >to the linker with '_'. As a consequence, using a leading '_' on an
> >identifier is probably bad news.  That's (part of) the reason
> >they're reserved for use by the implementation.
>
> I don't see that as being a problem.

s/see/understand/ and you may be getting closer.

> Just the linker will get double leading underscores on names to
> which you added a leading underscore at the C level.

Not necessarily - a compiler might, for instance, only apply the
prefix to function names (rather than data). (Which sounds
suspiciously like the situation you described which afflicted your
colleague who made the decision to use explicitly reserved identifiers
in his code). It's also possible (indeed, probable) that the
compiler's runtime system contains functions and data whose name may
clash with the use of such symbols. (But then, you already know that,
don't you?). PLEASE tell me what is difficult about "don't use
identifiers containing leading or double underscores"?.

> Do you think this is this a valid C++ program ?
>
>   #include <iostream>
>
>   int main()
>   {
>     int HUGE_VAL = 1001;
>     std::cout << "Hello, world. "
>               << " The value " << HUGE_VAL
>               << " is huge, isn't it ?\n";
>   }

I assume you're trying to find out if I'm aware that HUGE_VAL is a
symbol reserved for use by the library? Yes, I am aware of the fact
that it's reserved. I'll even stick my neck out and go so far as to
say I think it's specifically reserved for use as a macro.

> >Not using reserved names would help improve portability.
>
> I think having a little help in remembering what those reserved
> names are would be better.

Then go and tell your vendor that their QoI sucks.

> >That covers pretty much everything you need to avoid (and some that
> >you don't), in two easy to read (and remember) sentences.
>
> Try to write down the list of all identifiers you can't have for
> your use in a program that includes any standard header.

I'd rather not, since (as you are clearly unaware) it's an infinitely
long list. You may be expecting to live forever (where "forever" is
a period of time longer than the lifetime of the universe); I
don't. Why don't you write out a list of all the reserved identifers
that my rules of thumb don't cover, and I'll give you the rest of my
rules of thumb.

> Then check for example with the first table in [diff.library] to see
> how many you forgot just from that table.

I went and checked the table you refer to, and guess what? None of
those were idenitifiers I'd ever have attempted to define in a
program). Not because I've memorized every possible reserved identifer
(life is, as I've pointed out, way too short), but because I have a
few rules of thumb regarding the naming of identifers which avoid such
issues.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Can someone please give me some advice as to the interpretation of
17.4.3.1.2 wrt the use of leading underscores in names.

(A reminder: "
        -  ... contains a double underscore (__) or begins with an
underscore followed by an upper case letter (2.11) is reserved to the
implementation for any use.
        - Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace."  (plus a
footnote extending the reservation to namespace ::std.)
)

My queries mainly centre on the interpretation of "reserved" in the
context above.  Looking at 17.4.3.1, I think I know the intention, and
how to interpret the text on underscores - but I am not certain.

My interpretation is such that, inter alia, a name beginning with a
single underscore and not followed by an upper case letter, nor
including a double underscore, would be satisfactory (wrt underscores)
in an application provided it were not declared in either the global or
standard namespace.  In particular, a name consisting of a single
underscore (only) would be OK provided that it were in some user-defined
namespace, or class.

Is this correct?

TIA.
--
Alec Ross

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

alec@arlross.demon.co.uk (Alec Ross) writes:

> My interpretation is such that, inter alia, a name beginning with a
> single underscore and not followed by an upper case letter, nor
> including a double underscore, would be satisfactory (wrt underscores)
> in an application provided it were not declared in either the global or
> standard namespace.

What do you mean by "satisfactory (wrt underscores)". An application
must not add any names to namespace std, see 17.4.3.1/1.

Using such names in the global namespace is well-defined.

> In particular, a name consisting of a single underscore (only) would
> be OK provided that it were in some user-defined namespace, or
> class.
>
> Is this correct?

Yes, although you could remove the restriction that it must be in a
user-defined namespace: The name '_' is not reserved at all, so you
can use it as a global name as well (it is, indeed, common to use it
as a macro name).

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 4 Nov 2002 05:14:57 +0000 (UTC), andys@evo6.com.NoSpam (Andy
Sawyer) wrote:

>Not necessarily - a compiler might, for instance, only apply the
>prefix to function names (rather than data). (Which sounds
>suspiciously like the situation you described which afflicted your
>colleague who made the decision to use explicitly reserved identifiers
>in his code).

Nope. The problem is that if you define even a function of
yours with name "_foo" you can't be sure there isn't an
internal library function with that name. Being in a library
the linker won't complain about duplication... but calling
yours instead will imply a disaster.
In that case it was data and not code... but the problem
can be the very same with code too.

>PLEASE tell me what is difficult about "don't use
>identifiers containing leading or double underscores"?.

Its absolutely trivial :) ... I never ran in that problem
in my life. Those leading underscore are even ugly.

Sure there are out there "leading underscore fanatics"
that just can't live without things like

   #if !defined(__MYCLASS_H_INCLUDED__)
   #define(__MYCLASS_H_INLUDED__)
   ...
   #endif

and once I actually tried to explain to one of them that
using the double underscore at the begining was adding
nothing but troubles... but hey... make all look so
"system stuff" ... I didn't succeed in convincing him.

>I assume you're trying to find out if I'm aware that HUGE_VAL is a
>symbol reserved for use by the library? Yes, I am aware of the fact
>that it's reserved. I'll even stick my neck out and go so far as to
>say I think it's specifically reserved for use as a macro.

No... I'm telling that just the leading underscore rule
doesn't say it all.

>> >Not using reserved names would help improve portability.
>>
>> I think having a little help in remembering what those reserved
>> names are would be better.
>
>Then go and tell your vendor that their QoI sucks.

Hey ... I'm telling exactly this. I never found a compiler
that added the trivial check with a stopword list where
a symbol is used to inform the programmer that it's violating
the standard. It's something that doesn't seem too hard
but strangely enough no one implements it.
And it would help somewhat distract people using HUGE_VAL
(and it would kill all those "leading underscore fanatics").
By the way... with the borland compiler that program compiles
fine as HUGE_VAL is defined as "_huge_double" or something
similar. What is going to happen if i declare a global
variable with that name is something interesting to discover.

>> >That covers pretty much everything you need to avoid (and some that
>> >you don't), in two easy to read (and remember) sentences.
>>
>> Try to write down the list of all identifiers you can't have for
>> your use in a program that includes any standard header.
>
>I'd rather not, since (as you are clearly unaware) it's an infinitely
>long list.

I thought it was pretty obvious that you were allowed to use
wildcards in your list :) ... sorry for not being so specific
(what is obvious is quite subjective).
Even with wildcards I bet you would forget a *lot* of forbidden
identifiers... don't you think you would ?

>Why don't you write out a list of all the reserved identifers
>that my rules of thumb don't cover, and I'll give you the rest of my
>rules of thumb.

HAHAHA... nice try. What is the rule you're going to explain
to a C++ class student ? "Tell me your identifier and I'll tell
you if you can use it" ? Then remember to add "(but hey... don't
expect your compiler to tell you if you can use it... that's
not required nor IMO useful)"; that's the full story.

>I went and checked the table you refer to, and guess what? None of
>those were idenitifiers I'd ever have attempted to define in a
>program).

You were lucky. I see nothing particularly bad in HUGE_VAL, do
you ? What about calling a struct "tm" ?

>Not because I've memorized every possible reserved identifer
>(life is, as I've pointed out, way too short), but because I have a
>few rules of thumb regarding the naming of identifers which avoid such
>issues.

That helps you avoiding HUGE_VAL ? It would be nice to know
it... it's avoiding all uppercase letters ? Prefixing all
names with "Andy" ?

I myself even stepped on those really useless alternate
keywords (still I'm trying to understand what was people
smoking at the commitee reunion when that - IMO - nonsense
was ratified).

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc61cf9.4471525@news.tin.it>, Andrea Griffini
<agriff@tin.it> writes
>I myself even stepped on those really useless alternate
>keywords (still I'm trying to understand what was people
>smoking at the commitee reunion when that - IMO - nonsense
>was ratified).

1) What was the place of birth of the designer of C++?
2) Which countries keyboards were problematic?

And almost everyone hated the last minute C fix of trigraphs.

Actually I rather like the alternatives, I have never known anyone using
them confuse logical and bit-wise operators while I have seen such
confusion in almost all code using the traditional symbols.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc61cf9.4471525@news.tin.it>,
 on Mon, 4 Nov 2002 09:44:38 +0000 (UTC),
 agriff@tin.it (Andrea Griffini) wrote:

> On Mon, 4 Nov 2002 05:14:57 +0000 (UTC), andys@evo6.com.NoSpam (Andy
> Sawyer) wrote:
>
> >Not necessarily - a compiler might, for instance, only apply the
> >prefix to function names (rather than data). (Which sounds
> >suspiciously like the situation you described which afflicted your
> >colleague who made the decision to use explicitly reserved identifiers
> >in his code).
>
> Nope. The problem is that if you define even a function of
> yours with name "_foo" you can't be sure there isn't an
> internal library function with that name.

Or, to restate your last sentence, if you use a reserved name you get
undefined behaviour. My point entirely - thank you.

> >I assume you're trying to find out if I'm aware that HUGE_VAL is a
> >symbol reserved for use by the library? Yes, I am aware of the fact
> >that it's reserved. I'll even stick my neck out and go so far as to
> >say I think it's specifically reserved for use as a macro.
>
> No... I'm telling that just the leading underscore rule
> doesn't say it all.

I'm perfectly well aware of that fact. I never, ever, claimed that it
did.

> >> >Not using reserved names would help improve portability.
> >>
> >> I think having a little help in remembering what those reserved
> >> names are would be better.
> >
> >Then go and tell your vendor that their QoI sucks.
>
> Hey ... I'm telling exactly this. I never found a compiler
> that added the trivial check with a stopword list where
> a symbol is used to inform the programmer that it's violating
> the standard. It's something that doesn't seem too hard
> but strangely enough no one implements it.

"No one", here, includes you. If you think it's such a huge
improvement and not too hard to implement, then why not go and
implement it in g++? If it's such a huge improvement, then a lot of
people will see it, and start applying pressure to other compiler
vendors to implement it.

> And it would help somewhat distract people using HUGE_VAL
> (and it would kill all those "leading underscore fanatics").
> By the way... with the borland compiler that program compiles
> fine as HUGE_VAL is defined as "_huge_double" or something
> similar.

Which is a valid implementation of HUGE_VAL.

> What is going to happen if i declare a global variable with that
> name is something interesting to discover.

You'll get undefined behaviour, because you're using a reserved name.

> >> >That covers pretty much everything you need to avoid (and some
> >> >that you don't), in two easy to read (and remember) sentences.
> >>
> >> Try to write down the list of all identifiers you can't have for
> >> your use in a program that includes any standard header.
> >
> >I'd rather not, since (as you are clearly unaware) it's an
> >infinitely long list.
>
> I thought it was pretty obvious that you were allowed to use
> wildcards in your list :)

You specifically asked for a list of "all identifiers", not a list of
wildcards. It was "obvious" that "wildcards" were explicitly
disallowed.

> (what is obvious is quite subjective).

Not in that case.

> Even with wildcards I bet you would forget a *lot* of forbidden
> identifiers... don't you think you would ?

Precisely how *much* are you prepared to "bet"? Or is that just
posturing? Define "a *lot*".

> >Why don't you write out a list of all the reserved identifers
> >that my rules of thumb don't cover, and I'll give you the rest of my
> >rules of thumb.
>
> HAHAHA... nice try.

So you're not prepared to write out the list of all reserved
identifiers? You challenged me to do so.

> What is the rule you're going to explain to a C++ class student ?

That's a problem for teachers, and I'm not a teacher.

> "Tell me your identifier and I'll tell you if you can use it" ?

Only an idiot works that way.

> Then remember to add "(but hey... don't expect your compiler to tell
> you if you can use it... that's not required nor IMO useful)";

Please tell me _exactly_ when I said it was not useful? Do you think
making misleading statments about my position will help your case?

> >I went and checked the table you refer to, and guess what? None of
> >those were idenitifiers I'd ever have attempted to define in a
> >program).
>
> You were lucky.

There was no luck involved.

> I see nothing particularly bad in HUGE_VAL, do you ?

Define "bad". I happen to know that HUGE_VAL is reserved in the C
library, and I even know what it's used for. How do I know that?
Because I've taken the time to learn a little about the languages
which I use, and I've used HUGE_VAL in the past (and will probably do
so again in the future).

> What about calling a struct "tm" ?

What about it? Was I supposed to be surprised that there's a struct
called tm in the standard library? What is in the least surprising
about that? I've used it many, many times over the last 20-odd years.

>
> >Not because I've memorized every possible reserved identifer
> >(life is, as I've pointed out, way too short), but because I have a
> >few rules of thumb regarding the naming of identifers which avoid such
> >issues.
>
> That helps you avoiding HUGE_VAL ? It would be nice to know
> it...

You've made it clear that all you're interested in doing is making
negative comments on what I say on the subject, and ascribing opinions
to me which I do not hold.

> it's avoiding all uppercase letters ?

I avoid uppercase letters in variable, function, class and namespace
names, period.

> Prefixing all names with "Andy" ?

No.

> I myself even stepped on those really useless alternate keywords

The keywords in question are not useless. They may strike /you/ as
being useless, but there are, in fact, other people that write C++.

> (still I'm trying to understand what was people smoking at the
> commitee reunion when that - IMO - nonsense was ratified).

That comment is offensive in the extreme. I suggest you aplogise,
publically, to all of the commitee members. At least they were doing
something positive, whilst all you seem to be interested in is
complaining and insulting people.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc4e3b4.2553911@news.tin.it>, Andrea Griffini
<agriff@tin.it> writes
>Yeah... and a conforming compiler may have as its only
>diagnostic message "your program has an error somewhere"
>without losing being conformant for that. So ?
>
>While it's true we're not that far from this situation
>when talking about errors done when using the standard
>template library, still I see that as a problem of young
>technology... that it's hoped to change in the future.
>There are formal issues and pratical issues; saying "you
>must not use any of the name that are reserved to me"
>solves the formal one, but there's a pratical one when
>the exact list of all those names is strange, long and
>hard to remember and if a compiler is not required to
>inform you when you're violating the rule.

And exactly how is a compiler supposed to know which identifiers are
provided by the user and which by an implementor of the Standard Library
(remember that some identifiers are necessarily global ones) ? Even
harder when you remember that the user does have a licence to add some
items to namespace std.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer wrote:
....
>>Just the linker will get double leading underscores on names to
>>which you added a leading underscore at the C level.
>
>
> Not necessarily - a compiler might, for instance, only apply the
> prefix to function names (rather than data). (Which sounds

Well, there's not too much use in worrying about compilers that don't
conform to the C++ standard. There's no upper limit on how disfunctional
they can be. I'm not saying that the C++ standard specifies how global
names are to be represented in object files; simply that the particular
representation you describe is going to break well-formed code. A
compiler must either pre-pend an '_' to every name, or to none, or use
some other scheme that preserves both the identities and distinctions
between them. It would be different if the standard said that data and
functions had two distinct name spaces that don't interact with each
other; then such a scheme could be made to work.

>>>Not using reserved names would help improve portability.
>>
>>I think having a little help in remembering what those reserved
>>names are would be better.
>
>
> Then go and tell your vendor that their QoI sucks.

It's not just a matter of the vendor. If C, and then C++, had been
designed from the beginning to ensure that reserved names were
completely and simply distinguishable from unreserved ones, it would
have been far easier to provide that QoI. It's probably too late now,
but it's something that should be kept in mind for future languages, and
something to keep in mind when adding new reserved names to C++.

>>Try to write down the list of all identifiers you can't have for
>>your use in a program that includes any standard header.
>
>
> I'd rather not, since (as you are clearly unaware) it's an infinitely
> long list.  ...

That was his point! So he's certainly aware of it. Of course, it can be
made of finite length through the use of regular expression, such as are
used by vi or regex(). However, even then, it's a rather long list to
memorize.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 4 Nov 2002 13:03:04 +0000 (UTC),
francis.glassborow@ntlworld.com (Francis Glassborow) wrote:

>In article <3dc61cf9.4471525@news.tin.it>, Andrea Griffini
><agriff@tin.it> writes
>>I myself even stepped on those really useless alternate
>>keywords (still I'm trying to understand what was people
>>smoking at the commitee reunion when that - IMO - nonsense
>>was ratified).
>
>1) What was the place of birth of the designer of C++?
>2) Which countries keyboards were problematic?

Hmmm... not very edifying for the committee :-(

>And almost everyone hated the last minute C fix of trigraphs.
>
>Actually I rather like the alternatives, I have never known anyone using
>them confuse logical and bit-wise operators while I have seen such
>confusion in almost all code using the traditional symbols.

FWIW, I have never seen them confused. However you should admit that
the alternative spellings are quite contrary to the spirit of C++ (if
nothing else, I think one who doesn't program with enough attention to
distinguish logical from bitwise operations CANNOT ever program in C
or C++, even with the alternate spellings) and that they are a whole
bunch of reserved words, whereas almost every day on this group we see
objections to the introduction of a new keyword for much more
judicious reasons than preventing confusion between symbols.

Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 4 Nov 2002 13:03:04 +0000 (UTC),
francis.glassborow@ntlworld.com (Francis Glassborow) wrote:

>In article <3dc61cf9.4471525@news.tin.it>, Andrea Griffini
><agriff@tin.it> writes
>>I myself even stepped on those really useless alternate
>>keywords (still I'm trying to understand what was people
>>smoking at the commitee reunion when that - IMO - nonsense
>>was ratified).
>
>1) What was the place of birth of the designer of C++?
>2) Which countries keyboards were problematic?

Yeah... indeed this was my first suspect. Also it's
my suspect about this other huge IMO questionable
weight given to the wide-char stuff.

Well I'm italian, and we have a few strange characters
too, but I never felt that being a big missing from
the C language. Of course we're somewhat lucky compared
to for example asians to which english characters are
just nonsensical symbols. But alternatives don't buy
much in that context ("and" is probably just as confusing
as "&&" if not worse).

We're also probably luckier than other european
populations as even using an english keyboard you can
type painlessy in italian, just adding a few single
quotes where accents are needed.

My idea is that the problem should be approached the
opposite way... like trying to get a common language
more common. English isn't perfect (and mine especially)
but it's there. I think programmers should try to
jump on this wagon instead of splitting knowledge and
multiply efforts.

Also in italy it's pretty hard to be a programmer (or
system administrator or just an heavy internet user)
unless you have an US keyboard anyway.
There is generally no tilde at all (you've to use
ALT+0126), no backquote (ALT+096), and symbols like
braces, pipe, at-sign or the pound sign are not
standard and sometimes so hard to type that you see
messages in newsgroups asking for help with that
(no, i'm NOT kidding on this).

But instead of having the language modified (and having
US programmers fainting at the sight of that source code)
I think it's best to just use an US keyboard.

I also think it's best to avoid using non-ASCII characters
when posting in newsgroups too... but that's another story.

>And almost everyone hated the last minute C fix of trigraphs.
>
>Actually I rather like the alternatives, I have never known anyone using
>them confuse logical and bit-wise operators while I have seen such
>confusion in almost all code using the traditional symbols.

I've never seen anyone using them making confusion either,
as I've never seen anyone using them at all.

And I've not dedicated any serious time in this statistic
study... but confusion between bit-wise and logical
operations is not in my opinion a serious problem with C
and didn't know it ever has been. There's a problem with
the somewhat surprising precedence of bitwise operations...
but that's another question.

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 4 Nov 2002 15:52:34 +0000 (UTC), andys@evo6.com.NoSpam (Andy
Sawyer) wrote:

>Or, to restate your last sentence, if you use a reserved name you get
>undefined behaviour. My point entirely - thank you.

Hmmm... this discussion is taking a strange
direction. I never said that using a reserved name
is Ok. I was just noticing that no help is given
from compilers for avoiding this mistake.
Not even the very simple one of giving warnings for
identifiers badly introduced by underscores that
don't come from the implementation itself.

>> No... I'm telling that just the leading underscore rule
>> doesn't say it all.
>
>I'm perfectly well aware of that fact. I never, ever, claimed that it
>did.

Sorry... I thought you hoped to grab everything
with a couple of rules. You need more than that.

>You'll get undefined behaviour, because you're using a reserved name.

It's undefined in general. I was curious about what
can happen with this very specific implementation...
will the program crash ? Will other parts find a
strange value of HUGE_VAL and behave accordingly ?
Will just nothing happen because <iostream> didn't
happen to define that macro ?

Lots of surprises because a reserved name
rarely used and not specifically ugly was used.
All this with zero warnings and zero errors...
isn't C++ an amazing environment sometimes ?

>You specifically asked for a list of "all identifiers", not a list of
>wildcards. It was "obvious" that "wildcards" were explicitly
>disallowed.

Geesh. I was trying to raise the level of the
discussion. There are a lot of words that are
not caught by those nice underscore-based rules.

>> (what is obvious is quite subjective).
>
>Not in that case.

Especially in that case. I wonder how many here
actually understood it the way you did.
Now I'm in doubt if you're just trolling here
for some reason I don't know or if you really
can't understand that point.

>> What about calling a struct "tm" ?
>
>What about it? Was I supposed to be surprised that there's a struct
>called tm in the standard library? What is in the least surprising
>about that? I've used it many, many times over the last 20-odd years.

Sure I did use it too. However I think it may be
surprising that someone experimenting with C++
and including just <iostream> (even not that ?)
in a toy program and defining a class in the
global namespace with that name is stepping in
the UB land (I'm actually not sure about this...
it's really true even for PODs ?).

>> That helps you avoiding HUGE_VAL ? It would be nice to know
>> it...
>
>You've made it clear that all you're interested in doing is making
>negative comments on what I say on the subject, and ascribing opinions
>to me which I do not hold.

If you're trying to avoid reserved names you have
to avoid HUGE_VAL too. And I didn't see your rules
working in that case.

>> I myself even stepped on those really useless alternate keywords
>
>The keywords in question are not useless. They may strike /you/ as
>being useless, but there are, in fact, other people that write C++.

Seems so. I'm sure however that I'm not alone in finding
those reserved words useless (or to put it differently WAY
less useful than other ones ... null keyword, anyone ?).

Being C++ a perfect democracy would be nice to see what
is the majiority of consensus about those alternative
keywords (first however it would be necessary to actually
inform a big percentage of C++ programmers that those
reserved words actually exist at all... my bet is that
the percentage of self defining C++ programmers that know
that "compl" is a reserved word is in one digit.

But C++ is not a perfect democracy (and I'm not saying it
should) and so here we are with those alternative keywords.

>> (still I'm trying to understand what was people smoking at the
>> commitee reunion when that - IMO - nonsense was ratified).
>
>That comment is offensive in the extreme. I suggest you aplogise,
>publically, to all of the commitee members. At least they were doing
>something positive, whilst all you seem to be interested in is
>complaining and insulting people.

Actually I agree that re-reading that phrase it sounds
really harsh. Sorry for that, honestly. I hope my rude
manners don't succeed in hiding what i'm trying to say
when I post in this newsgroup.

I really appreciate all the work done for C++ from who
is investing in it a lot of effort. I can just hope
there is a reasonable payoff for that for all that do.

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> Allan W <allan_w@my-dejanews.com> writes

> >"Reserved" in this context means that you can't use it, because the
> >compiler or library MIGHT need it. Even if you know for a fact that
> >neither the compiler nor library DO use it, it's still reserved for
> >them and you can't use it.
>
> That is silly. Of course you can use any name you like, however if you
> elect to use names that are reserved to the implementation the
> consequences are your responsibility, and your code effectively has
> undefined behaviour.

I said you can't use it because the compiler or library might.
I didn't say it would always fail -- just that these names are reserved.
"Be careful -- those things can hurt somebody."

You said you CAN use it, but you go on to say that doing so might
cause undefined behavior. "You can point that at your foot and pull
the trigger if you want. However, you might lose a toe if you do so."

Which one of us is silly?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>  agriff@tin.it (Andrea Griffini) wrote:
> > Try to write down the list of all identifiers you can't have for
> > your use in a program that includes any standard header.

andys@evo6.com.NoSpam (Andy Sawyer) wrote
> I'd rather not, since (as you are clearly unaware) it's an infinitely
> long list. You may be expecting to live forever (where "forever" is
> a period of time longer than the lifetime of the universe); I
> don't. Why don't you write out a list of all the reserved identifers
> that my rules of thumb don't cover, and I'll give you the rest of my
> rules of thumb.

It's a very long list.

It's not an infinite list (unless you count __a, __b, __c individually
rather than saying "anything that starts with __"). That would make it
much much longer, but not particularly useful.

Come to think of it, a compliant compiler is required to document it's
maximum identifier length, and encouraged to accept at least 1024
characters (before ignoring additional characters). So it's still not
infinite -- for compilers with 1024 significant characters, the number
of identifiers that start with __ is (63 + 63**2 + 63**3 + ... + 63**1022).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 4 Nov 2002 15:52:39 +0000 (UTC),
francis.glassborow@ntlworld.com (Francis Glassborow) wrote:

>And exactly how is a compiler supposed to know which identifiers are
>provided by the user and which by an implementor of the Standard Library
>(remember that some identifiers are necessarily global ones) ?

I always thought the implementation of the standard library
being actually 100% part of the compiler. I know this is not
technically true, as often the library is actually bought
from companies even specializing in that. But for me, the
buyer of the compiler, there should be IMO no distincion.

Sure I know there are STL replacements (I've even considered
adopting one) but I always supposed that using them is (from
a standard point of view) jumping in UB with both feet.
Is UB to use a name with two underscores and is ok to kick
away the system libraries ?

So implementers of the standard library are IMO implementers
of the compiler... they can use all the reserved identifier
they want. Those identifiers have been actually reserved
especially for them.

If a source file is from the implementation or from the
user I think could be detected from the directory o just
having a special "unlocking" pragma doing the magic.

>Even harder when you remember that the user does have a
>licence to add some items to namespace std.

Not using reserved names, I suppose.

Andrea

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bgbdsu4sa9hd1bdanpf5ru7neqnh5l932a@4ax.com>, Gennaro Prota
<gennaro_prota@yahoo.com> writes
>FWIW, I have never seen them confused. However you should admit that
>the alternative spellings are quite contrary to the spirit of C++ (if
>nothing else, I think one who doesn't program with enough attention to
>distinguish logical from bitwise operations CANNOT ever program in C
>or C++, even with the alternate spellings)

Then I think you would eliminate well over 90% of those using C++
compilers. And I have extensive experience of presenting advanced C++
courses to commercial programmers.

> and that they are a whole
>bunch of reserved words, whereas almost every day on this group we see
>objections to the introduction of a new keyword for much more
>judicious reasons than preventing confusion between symbols.

But additional keywords that were introduced over a decade ago, they
were one of the earliest extensions added by WG21 & J16



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0211041630.14574a50@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>I said you can't use it because the compiler or library might.
>I didn't say it would always fail -- just that these names are reserved.
>"Be careful -- those things can hurt somebody."
>
>You said you CAN use it, but you go on to say that doing so might
>cause undefined behavior. "You can point that at your foot and pull
>the trigger if you want. However, you might lose a toe if you do so."
>
>Which one of us is silly?

I think that your not being a native English speaker may be the problem.
In English we distinguish between 'cannot' and 'should not'.

'I cannot fly' depending on context has two meanings in English (well at
least two) 1) Flying is not one of my innate abilities. 2) I have not
learned to fly an aircraft.

'I cannot drive a car' can mean that I like the physical ability to do
so (e.g. being a paraplegic) or that I have not learnt how to. However
if I have had my licence removed I can still drive a car, but I should
not do so.

You will find that because of the ambiguities inherent in the sue of
'may', 'can' and 'should' Standardese uses the directive terms 'Shall'
and 'Shall not' where a language  requirement is specified. However even
there some breaches are classified as undefined behaviour. Please note
that implementations are allowed to make UB defined so UB is a
portability issue (it specifies such code as inherently non-portable)



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:

> Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> Which one of us is silly?


    I tend to think that if you need leading or trailing
underscores for something, the namespace system is too weak.

     John Nagle
     Animats


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote in message
news:<35GsoPB68lx9EwRW@robinton.demon.co.uk>...

> And exactly how is a compiler supposed to know which identifiers are
> provided by the user and which by an implementor of the Standard
> Library (remember that some identifiers are necessarily global ones) ?

Well, the authors of the compiler could read the standard.  It may
surprise you, but the people I know who actually work on C++ compilers
DO know which identifiers are defined by the standard.  They have
various reasons for not embedding this knowledge in the compiler (at
least not at present), but that is an implementation decision.
Technically, it would be easy, and I have actually used a C compiler
which did this; it knew, for example, that the external function printf
didn't read nor modify any user defined global variables, and so didn't
bother spilling them if they happened to be in a register.  (I'm not
convinced that this is a worthwhile optimization, but apparently, it
gained enough in some simple benchmark to please marketing.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

agriff@tin.it (Andrea Griffini) wrote in message
news:<3dc6c7ae.2182223@news.tin.it>...
> On Mon, 4 Nov 2002 13:03:04 +0000 (UTC),
> francis.glassborow@ntlworld.com (Francis Glassborow) wrote:

> >In article <3dc61cf9.4471525@news.tin.it>, Andrea Griffini
> ><agriff@tin.it> writes
> >>I myself even stepped on those really useless alternate keywords
> >>(still I'm trying to understand what was people smoking at the
> >>commitee reunion when that - IMO - nonsense was ratified).

> >1) What was the place of birth of the designer of C++?
> >2) Which countries keyboards were problematic?

> Yeah... indeed this was my first suspect. Also it's my suspect about
> this other huge IMO questionable weight given to the wide-char stuff.

> Well I'm italian, and we have a few strange characters too, but I
> never felt that being a big missing from the C language. Of course
> we're somewhat lucky compared to for example asians to which english
> characters are just nonsensical symbols. But alternatives don't buy
> much in that context ("and" is probably just as confusing as "&&" if
> not worse).

That's not the problem.  The problem is typing C++ on a keyboard which
doesn't have &.

> We're also probably luckier than other european populations as even
> using an english keyboard you can type painlessy in italian, just
> adding a few single quotes where accents are needed.

I'm not sure what you mean by "painlessly".  I type both French and
German painlessly in emacs using a US keyboard, because emacs has
special commands to allow entering ISO 8859-1 characters.  (But I still
can't get the Euro character or an oe ligature.)  When I choose, my
documentation is in LaTeX or HTML, written with emacs.

The problem is that I don't always choose, and that the world hasn't
always been like this.  When I started at Siemens, for example, we had 7
bit terminals, and a requirement that the documentation be in German,
with Umlauts.  That meant using the German national variant of ISO 646.
Without [, ], {, }, and | (and one or two others that I've forgotten).
Frankly, I wish we'd have had the alternative symbols back then.

> My idea is that the problem should be approached the opposite
> way... like trying to get a common language more common. English isn't
> perfect (and mine especially) but it's there. I think programmers
> should try to jump on this wagon instead of splitting knowledge and
> multiply efforts.

Programmers are only part of the problem.  I can't do everything in
English, because my customers are all computer scientists, and even some
of the computer scientists insist on the local language.

> Also in italy it's pretty hard to be a programmer (or system
> administrator or just an heavy internet user) unless you have an US
> keyboard anyway.

Guess what?  My users aren't system administrators or programmers (and
if they are heavy internet users, they are careful not to let their
bosses know).

But I agree that the problem isn't very important today.

> There is generally no tilde at all (you've to use ALT+0126), no
> backquote (ALT+096), and symbols like braces, pipe, at-sign or the
> pound sign are not standard and sometimes so hard to type that you see
> messages in newsgroups asking for help with that (no, i'm NOT kidding
> on this).

> But instead of having the language modified (and having US programmers
> fainting at the sight of that source code) I think it's best to just
> use an US keyboard.

I do.  Which doesn't prevent my comments from being in French, with
accents.  In the code I'm currently maintaining, the indentifiers are
also in French.  Without accents.  And I can assure you that leaving the
accents out of French doesn't help readability at all -- the only
difference between the imperative form and the past participle of most
verbs is an accent.

I know that this isn't the case in Italian, where accented characters
are fairly rare, always the last in the word, and where it is pretty
much standard practice to replace the accent by a left or right single
quote.  It's not a great problem in German, where there exists an
alternate way of writing accented characters -- ugly enough not to be
acceptable in running text, but quite adequate for identifiers in a
program.

So you're lucky.  It's not the case is French.  It's also not the case
in Scandinavian languages, nor from what I've been led to believe, in
eastern European languages.  (There exist official transcriptions to the
latin alphabet for Chinese and Japanese, so they might actually have it
easier than some of us Europeans.  But I really couldn't say whether
these transcriptions are in any way readable to a native speaker.)

> I also think it's best to avoid using non-ASCII characters when
> posting in newsgroups too... but that's another story.

It depends on the newsgroup:-).

Formally, you are right, and the relevant RFC specifies seven bit ASCII.
In practice, the fr.* hierarchy has extended the RFC to allow 8859-1,
and more recently, I think that they've allowed 8859-15 as well, as long
as the encoding is specified in the header.

The fact that the newgroups get it wrong doesn't mean that C++ has to
follow.

> >And almost everyone hated the last minute C fix of trigraphs.

Probably because the promissed tools were never made available.

> >Actually I rather like the alternatives, I have never known anyone
> >using them confuse logical and bit-wise operators while I have seen
> >such confusion in almost all code using the traditional symbols.

> I've never seen anyone using them making confusion either, as I've
> never seen anyone using them at all.

I've used them.  But I don't think I've ever confused them.

On the other hand, I suspect that I'm not a typical C++ programmer.

> And I've not dedicated any serious time in this statistic study... but
> confusion between bit-wise and logical operations is not in my opinion
> a serious problem with C and didn't know it ever has been. There's a
> problem with the somewhat surprising precedence of bitwise
> operations...  but that's another question.

I don't know how this red-herring slipped in.  The necessity of the
alternative tokens has nothing to do with any possible confusion between
bitwise and logical operations.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc6c7ae.2182223@news.tin.it>, Andrea Griffini
<agriff@tin.it> writes
>On Mon, 4 Nov 2002 13:03:04 +0000 (UTC),
>francis.glassborow@ntlworld.com (Francis Glassborow) wrote:
>
>>In article <3dc61cf9.4471525@news.tin.it>, Andrea Griffini
>><agriff@tin.it> writes
>>>I myself even stepped on those really useless alternate
>>>keywords (still I'm trying to understand what was people
>>>smoking at the commitee reunion when that - IMO - nonsense
>>>was ratified).
>>
>>1) What was the place of birth of the designer of C++?
>>2) Which countries keyboards were problematic?
>
>Yeah... indeed this was my first suspect. Also it's
>my suspect about this other huge IMO questionable
>weight given to the wide-char stuff.
>
>Well I'm italian, and we have a few strange characters
>too, but I never felt that being a big missing from
>the C language. Of course we're somewhat lucky compared
>to for example asians to which english characters are
>just nonsensical symbols. But alternatives don't buy
>much in that context ("and" is probably just as confusing
>as "&&" if not worse).
>
>We're also probably luckier than other european
>populations as even using an english keyboard you can
>type painlessy in italian, just adding a few single
>quotes where accents are needed.

That was not the problem, the problem stemmed from some symbols used in
C not being part of the then standard ISO character set (646, I think).
Accented letters etc. are an entirely different issue.

>
>My idea is that the problem should be approached the
>opposite way... like trying to get a common language
>more common. English isn't perfect (and mine especially)
>but it's there. I think programmers should try to
>jump on this wagon instead of splitting knowledge and
>multiply efforts.

Try that argument with the Japanese, I can see smoke rising even from
here :-)

>
>Also in italy it's pretty hard to be a programmer (or
>system administrator or just an heavy internet user)
>unless you have an US keyboard anyway.
>There is generally no tilde at all (you've to use
>ALT+0126), no backquote (ALT+096), and symbols like
>braces, pipe, at-sign or the pound sign are not
>standard and sometimes so hard to type that you see
>messages in newsgroups asking for help with that
>(no, i'm NOT kidding on this).

>
>But instead of having the language modified (and having
>US programmers fainting at the sight of that source code)
>I think it's best to just use an US keyboard.

And English speaking non-US countries would be very unhappy. Why should
I have to use two keyboards, one for English and one for programming.
The important issue is that some characters in the C source character
set were no among those required to be representable on all standard
consoles.

>
>I also think it's best to avoid using non-ASCII characters
>when posting in newsgroups too... but that's another story.

Indeed, but part of the problem there is related to codesets. The
Sterling pound sign happened to map on to a code that suppressed a
display line on some systems using a different code set.

>
>>And almost everyone hated the last minute C fix of trigraphs.
>>
>>Actually I rather like the alternatives, I have never known anyone using
>>them confuse logical and bit-wise operators while I have seen such
>>confusion in almost all code using the traditional symbols.
>
>I've never seen anyone using them making confusion either,
>as I've never seen anyone using them at all.

Because they are so little known, but that might change:-)

>
>And I've not dedicated any serious time in this statistic
>study... but confusion between bit-wise and logical
>operations is not in my opinion a serious problem with C
>and didn't know it ever has been.

Because in many cases the confusion (using bit-wise when logicical was
intended) does not bite except very rarely. For example:

(a==b) & (c==d)

is 'wrong' but works on all systems I have used. That makes it
particularly difficult to get programmers to realise that:
a & (c==d)

is very different from

a && (c==d)

even though in many contexts it also provides the desired result.

> There's a problem with
>the somewhat surprising precedence of bitwise operations...
>but that's another question.

Yes, further source of mistakes, but I think you have to look at the
history of early C to understand how we got where we did.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dc6c7ae.2182223@news.tin.it>, Andrea Griffini
<agriff@tin.it> writes
  <snip>
>But instead of having the language modified (and having
>US programmers fainting at the sight of that source code)
>I think it's best to just use an US keyboard.
  <snip>

How do you persuade an accountant to let you have two PCs - one for
writing C++ code, the other for writing budget proposals :-)

  John
--
John Harris
  mailto:john@jgharris.demon.co.uk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]