Re: enums in C++

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Ulrich" == Ulrich Drepper <drepper@redhat.com> writes:

    Ulrich> Nathan Sidwell <nathan@codesourcery.com> writes:

    >> Remember, stuff inside `extern "C" { ... }' must still be valid
    >> C++. Also remember, the set of overloaded functions named `foo'
    >> must have distinct parameters, only one of the set can have C
    >> linkage.

    Ulrich> Yes, it must be valid C++ but the rules must be relaxed.

*Must* be relaxed?  Surely you mean "I wish the rules could be
relaxed?"

Then the compiler would not be a conforming C++ compiler.  G++ is
conforming to the C++ standard here.  Responding to your next
suggestion (be relaxed unless -pedantic is in use, or when
-fpermissive is in use), it's difficult to provide a compiler that is
more lenient when calling extern "C" functions than it is with
ordinary functions because of complex questions involving overloading.

Besides, it goes against a basic bit of philosophy about extern "C"
functions: that they are just C++ functions whose names are mangled
differently.  You're thinking about extern "C" in only one direction;
i.e., the direction of C libraries callable by C++ programs.  The
other usage is to provide C++ libraries callable by C programs.
There, the code in the function is written in C++, and programmers
expect C++ rules to apply.

And there's an easy work-around: use a cast.  Or declare the function
to take an `int'.  (By the way, that would be a clearer choice: you're
using the enums as flags, which is fine, but the resulting A | B is
not a member of the enumeration.  It's really just an integer.)  The
C++ committee made the decision for stronger type safety, and I see no
reason to overrule that decision here.

A disproportionate number of bugs and maintenance headaches in G++
have stemmed from "simple" extensions.  Adding additional ones should
require an extremely rigorous process, analagous to that used when the
C committee wants to add an extension to ANSI/ISO C.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com