|
Home > Archive > Debian Developers > July 2005 > RFC, problem with g++4
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
RFC, problem with g++4
|
|
| Jaakko Niemi 2005-07-29, 2:51 am |
| 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?
--j
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian M. Carlson 2005-07-29, 8:08 am |
| 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)
| |
| Petri Latvala 2005-07-29, 8:08 am |
| On Fri, Jul 29, 2005 at 10:55:36AM +0300, Jaakko Niemi wrote:
> Hello,
>
> /usr/include/sys/socket.h has this:
[anonymous enum def]
> 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?
Either the first or the third option. The C++ standard clearly says
you cannot use an anonymous type as a template argument.
One option would be to make wrap take an int always, if that's
feasible. Or long. Or unsigned versions of those.
--
Petri Latvala
| |
| Antti-Juhani Kaijanaho 2005-07-29, 8:08 am |
| On 20050729T083332+0000, Brian M. Carlson wrote:
> 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.
The anon enumeration trick has been an established C++ idom for years
(ISTR, but cannot check now, even Stroustrup himself advocating it).
It's a shame if it now suddenly stopped working and is somehow against
the standard, even.
The problem with #defines is that they're outside the language proper
and, for example, pay no attention to namespaces.
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
| |
| Goswin von Brederlow 2005-07-29, 8:08 am |
| Antti-Juhani Kaijanaho <ajk@debian.org> writes:
> On 20050729T083332+0000, Brian M. Carlson wrote:
>
> The anon enumeration trick has been an established C++ idom for years
> (ISTR, but cannot check now, even Stroustrup himself advocating it).
> It's a shame if it now suddenly stopped working and is somehow against
> the standard, even.
>
> The problem with #defines is that they're outside the language proper
> and, for example, pay no attention to namespaces.
> --
> Antti-Juhani Kaijanaho, Debian developer
>
> http://kaijanaho.info/antti-juhani/blog/en/debian
But that is C code and the defines are there anyway, but currently
they are save NOPs.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-07-29, 8:08 am |
| * Antti-Juhani Kaijanaho:
> The anon enumeration trick has been an established C++ idom for years
> (ISTR, but cannot check now, even Stroustrup himself advocating it).
This was once desirable because you couldn't declare real constants in
classes. Today,
template <typename T>
struct Foo
{
static const unsigned N = T::N;
char bar[N];
};
works and the enum trick lost its importance.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-29, 6:13 pm |
| Florian Weimer <fw@deneb.enyo.de> writes:
> * Antti-Juhani Kaijanaho:
>
>
> This was once desirable because you couldn't declare real constants in
> classes. Today,
>
> template <typename T>
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
Doesn't that still make N a real variable in memory and does not get
optimized away like enums?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-07-29, 6:13 pm |
| On 7/29/05, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wro=
te:
> Florian Weimer <fw@deneb.enyo.de> writes:
> Doesn't that still make N a real variable in memory and does not get
> optimized away like enums?
I think it's (only) required to have an address.
I don't see why the compiler can't optimize it away (if it's const).
| |
| Antti-Juhani Kaijanaho 2005-07-29, 6:13 pm |
| On 20050729T163333+0200, Olaf van der Spek wrote:
> On 7/29/05, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
>
> I think it's (only) required to have an address.
> I don't see why the compiler can't optimize it away (if it's const).
Only if the compiler knows all uses of that constant. With dynamic
linking, you can't know that very easily.
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
| |
| Florian Weimer 2005-07-29, 6:13 pm |
| * Goswin von Brederlow:
>
> Doesn't that still make N a real variable in memory and does not get
> optimized away like enums?
Only if you provide a definition, and not just a declaration, it
seems.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Antti-Juhani Kaijanaho 2005-07-29, 6:13 pm |
| On 20050729T151821+0200, Florian Weimer wrote:
> Today,
>
> template <typename T>
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
That is not a new trick, I'm fairly sure that was legal when I first
learned of the enum idiom. The problem is, your trick doesn't work
outside templates,
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
| |
| Florian Weimer 2005-07-29, 6:13 pm |
| * Antti-Juhani Kaijanaho:
> That is not a new trick, I'm fairly sure that was legal when I first
> learned of the enum idiom.
It's illegal according to The C++ programming Language, Second Edition
(which was published in 1991). I didn't claim the trick was new. 8-)
> The problem is, your trick doesn't work outside templates,
Huh?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thiemo Seufer 2005-07-29, 6:13 pm |
| Antti-Juhani Kaijanaho wrote:
> On 20050729T163333+0200, Olaf van der Spek wrote:
>
> Only if the compiler knows all uses of that constant.
The declared use is enough.
> With dynamic linking, you can't know that very easily.
The compiler knows nothing about dynamic linking, since this is outside
the compilation unit.
Thiemo
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-07-29, 6:13 pm |
| * Thiemo Seufer:
>
> The compiler knows nothing about dynamic linking, since this is outside
> the compilation unit.
Indeed, and the fact that you can use such a constant as a template
argument just stresses that it's a compile-time thing.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Olaf van der Spek 2005-07-29, 6:13 pm |
| On 7/29/05, Antti-Juhani Kaijanaho <ajk@debian.org> wrote:
> On 20050729T163333+0200, Olaf van der Spek wrote:
wrote:[vbcol=seagreen]
>=20
> Only if the compiler knows all uses of that constant. With dynamic
> linking, you can't know that very easily.
I thought you meant optimizing code that accesses it for performance.
I don't think the space optimization is important.
| |
| Florian Weimer 2005-07-29, 6:13 pm |
| * Olaf van der Spek:
>
> I thought you meant optimizing code that accesses it for performance.
> I don't think the space optimization is important.
The space optimization is crucial for some template code.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Antti-Juhani Kaijanaho 2005-07-29, 6:13 pm |
| On 20050729T171111+0200, Florian Weimer wrote:
>
> Huh?
[After testing it:] I'll be damned. I was sure I was right 
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
| |
| Jaakko Niemi 2005-07-29, 6:13 pm |
| On Fri, 29 Jul 2005, Florian Weimer wrote:
> This was once desirable because you couldn't declare real constants in
> classes. Today,
>
> template <typename T>
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
So, if I'm understanding this and the discussion
that followed correctly, we should change the
enum to constants. Unless anyone objects, I'll
file a bug against libc6-dev tomorrow asking for
it.
--j
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-07-29, 6:13 pm |
| * Jaakko Niemi:
> So, if I'm understanding this and the discussion
> that followed correctly, we should change the
> enum to constants.
Eh, no, sorry. This will almost certainly break things because this
is a C header, not C++.
Just use #defines, as suggested by Brian M. Carlson in
<1122626012.30217.37.camel@stonewall.crustytoothpaste.ath.cx>.
But I'd also ask upstream first. Maybe they have a strong opinion
about this matter, and it's probably not a good idea to diverge
needlessly because it might impact cross-distribution portability.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jaakko Niemi 2005-07-29, 6:13 pm |
| On Fri, 29 Jul 2005, Florian Weimer wrote:
> * Jaakko Niemi:
>
>
> Eh, no, sorry. This will almost certainly break things because this
> is a C header, not C++.
Sorry, just #defines instead of enum is what I meant.
Just had some rather strong cough medicine..
Now, to #define a const.. mmm, cheese..
--j
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-29, 8:51 pm |
| Florian Weimer <fw@deneb.enyo.de> writes:
> * Goswin von Brederlow:
>
>
> Only if you provide a definition, and not just a declaration, it
> seems.
The proper use of this construct seems to be:
template <typename T>
struct Foo {
static const unsigned N = T::N;
char bar[N];
};
struct Bla {
static const unsigned N;
};
const unsigned Bla::N = 10;
int main() {
Foo<Bla> foo;
}
Correct me if I'm wrong but doesn't that
1.) Only move the const declaration from the template into the
template parameter?
2.) Cause the template to have static member N in every file that uses
the template and for every type?
3.) Cause Bla to have a static member N in every file that uses
the template and for every type?
4.) Cause 2 extra indirections due to 2+3?
By the way,
template <typename T>
struct Foo {
static const unsigned N = 10;
char bar[N];
};
works just as well.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-07-30, 7:48 am |
| * Goswin von Brederlow:
> The proper use of this construct seems to be:
>
> template <typename T>
> struct Foo {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> struct Bla {
> static const unsigned N;
> };
>
> const unsigned Bla::N = 10;
>
> int main() {
> Foo<Bla> foo;
> }
This program is ill-formed.
Bla::N is not an integral constant expression (5.19/1) and thus does
not make Foo::N an integral constant expression, either (9.4.2/4).
I will file a couple of bug reports. Some of these things might
actually undocumented G++ extensions.
> Correct me if I'm wrong but doesn't that
>
> 1.) Only move the const declaration from the template into the
> template parameter?
>
> 2.) Cause the template to have static member N in every file that uses
> the template and for every type?
>
> 3.) Cause Bla to have a static member N in every file that uses
> the template and for every type?
I don't understand these questions.
If the definition of Bla::N appears in multiple translation units, the
one definition rule is violated and the program is ill-formed.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jaakko Niemi 2005-07-30, 8:47 pm |
| Xref: number1.nntp.dca.giganews.com linux.debian.devel:175080
Followups to #320630.
--j
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|