[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC, problem with g++4



On Fri, 2005-07-29 at 10:55 +0300, Jaakko Niemi wrote:
>  Hello,
> 
>  /usr/include/sys/socket.h has this:
> 
> -------------
> /* The following constants should be used for the second parameter of
>    `shutdown'.  */
> enum
> {
>   SHUT_RD = 0,          /* No more receptions.  */
> #define SHUT_RD         SHUT_RD
>   SHUT_WR,              /* No more transmissions.  */
> #define SHUT_WR         SHUT_WR
>   SHUT_RDWR             /* No more receptions or transmissions.  */
> #define SHUT_RDWR       SHUT_RDWR
> };
> -------------
> 
>  which results into error when compiling sfs with g++ 4.x:
> 
> rexchan.C: In member function 'virtual void unixfd::data(svccb*)':
> rexchan.C:254: error: '<anonymous enum>' is/uses anonymous type
> rexchan.C:254: error:   trying to instantiate 'template<class C, class
> R, class B1, class A1, class AA1> refcounted<callback_c_1_1<C*, C, R,
> B1, A1>, scalar>* wrap(C*, R (C::*)(A1, B1), const AA1&)'
> rexchan.C:254: error: no matching function for call to 'wrap(unixfd*
> const, void (unixfd::*)(int, int), <anonymous enum>)'
> 
>  rexchan.C:254 is:
> 
> paios_out->setwcb (wrap (this, &unixfd::update_connstate, SHUT_WR));
> 
>  Now, should libc name that enumeration, g++ generate warning instead
> of error or moon be mined for cheese snacks?

I think the moon should be mined for cheese snacks.  No, just kidding.

libc6 should not name an enumeration except either in the implementation
namespace or as required by POSIX.

What I think it should do, and this is JMHO, is just:
#define SHUT_RD 0
#define SHUT_WR 1
#define SHUT_RDWR 2

and leave the enumeration out of it, since it's not required, and can
actually break things, if the values are not within the value of an int.
For example, the Sparc/UltraSparc fpu_control.h.

I definitely like gcc's strictness, so it should definitely be an error.
I think the reason that g++ is so strict on anonymous enums is that it
had problems with mangling their names (since they don't have any name,
it's sort of hard to mangle them).  Also, I believe it violates the C++
standard for that very reason.

Of course, I could be persuaded that the enumeration is a good idea, but
I don't see what problem it solves, and it only seems to cause them.
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_}<DATA>;eval$a;print;__DATA__
M961H<F$@8FAM;"!U<F%O<G-U(#QU<F%O<G-U0&=D:75M<&UC8VUL=G)U;6LN
M<FUL+F=Y/@H)>2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: