> Lots of real C++ code is order-sensitive. This is a serious problem and
> there are a couple of ugly solutions to it.
I'd say that the best solution would be to get rid of globals. This is
actually very easy:
If you have
TYPE VAR = INITIALIZER;
replace that with
TYPE& getVAR(){
static T
Right, understood, finally. Thanks.
-Original Message-
From: Martin v. Loewis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2001 8:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
debian-gcc@lists.debian.org; [EMAIL PROTECTED]
Subject: Re:
> I can't disagree with your reading ("involve" doesn't mean "be"). However,
> searching for "integral constant expression" suggests to me that this
> outlaws the following code, all of which compiles without warning:
>
> enum {dim = 1};
> char a [dim]; // 8.3.4.1
Please note that only null poin
Installing:
gcc-3.0-base_3.0.2-1_all.deb
to pool/main/g/gcc-3.0/gcc-3.0-base_3.0.2-1_all.deb
libstdc++3-dbg_3.0.2-1_i386.deb
to pool/main/g/gcc-3.0/libstdc++3-dbg_3.0.2-1_i386.deb
gcc-3.0_3.0.2ds4-1.diff.gz
to pool/main/g/gcc-3.0/gcc-3.0_3.0.2ds4-1.diff.gz
g77-3.0_3.0.2-1_i386.deb
to pool/
On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
> If you're order-sensitive, you've got a problem.
Lots of real C++ code is order-sensitive. This is a serious problem and
there are a couple of ugly solutions to it. The best solution would be to
teach the linker about it. The solution we are talk
On Wed, Oct 24, 2001 at 05:59:24PM +0200, Richard B. Kreckel wrote:
> On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
> [...]
> > > Could you please provide a pointer or two to code samples or things that
> > > might be helpful implementing it the Right Way, since I intend to try and
> > > fix it? (
On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
[...]
> > Could you please provide a pointer or two to code samples or things that
> > might be helpful implementing it the Right Way, since I intend to try and
> > fix it? (Dunno if I'm old enough for this, though.)
> >
> > Thanks a lot for all the i
On Wed, Oct 24, 2001 at 01:06:48PM +0200, Richard B. Kreckel wrote:
>
> OOOoopsss
>
> Could you please provide a pointer or two to code samples or things that
> might be helpful implementing it the Right Way, since I intend to try an
On Wed, Oct 24, 2001 at 09:15:00AM +0200, Martin v. Loewis wrote:
> > I don't think you're arguing the right side. Look at my message - I
> > don't know what the poster did, but _MY_ installed g++ v3.0 declares it
> > invalid.
>
> And I assume everybody else's does so, as well: on my system, bo
On Tue, 23 Oct 2001, Daniel Jacobowitz wrote:
> [...]
> >
> > hmm, I was under the impression, that enabling -fuse-cxa-atexit as the
> > default on a glibc-2.2 based system, was safe.
> >
> > You get the code you want with -fno-use-cxa-atexit. Should we revert
> > this change?
>
> I don't think
I can't disagree with your reading ("involve" doesn't mean "be"). However,
searching for "integral constant expression" suggests to me that this
outlaws the following code, all of which compiles without warning:
enum {dim = 1};
char a [dim]; // 8.3.4.1
void* b = new char [1] [dim]; // 5.3.4.6
st
> > I'll take another attempt at declaring gcc behaviour to be correct.
> > According to 4.10/1, "success" is a null pointer constant:
> >
> > # A null pointer constant is an integral constant expression (5.19)
> > # rvalue of integer type that evaluates to zero. A null pointer
> > # constant can
>non-aggregate type `Foo ()(int (*)())'
> // This is the problematic line:
> Foo broken(int(returnLong()));
[...]
> The error message from g++ is:
> gcc-bug-constructor.cc:36: request for member `field' in `broken', which is
> of
>non-aggregate type `Foo ()(int (*)())'
Thank
> I'll take another attempt at declaring gcc behaviour to be correct.
> According to 4.10/1, "success" is a null pointer constant:
>
> # A null pointer constant is an integral constant expression (5.19)
> # rvalue of integer type that evaluates to zero. A null pointer
> # constant can be converted
> > You get the code you want with -fno-use-cxa-atexit. Should we revert
> > this change?
>
> I don't think so. I'm 90% positive that this is CLN's fault.
> Inserting labels in the body of a function is a somewhat disgusting way
> to do it!
I agree. There is no guarantee in the C++ language, or
> I don't think you're arguing the right side. Look at my message - I
> don't know what the poster did, but _MY_ installed g++ v3.0 declares it
> invalid.
And I assume everybody else's does so, as well: on my system, both g++
2.95 and 3.1 20011009 complain about your code (where the constant is
Package: g++-3.0
Version: 1:3.0.2-0pre010922
Severity: normal
File: /usr/bin/g++-3.0
The attached file demonstrates that g++ (in Debian/testing) barfs on a
nested int conversion of a static function in a constructor expecting
an int. (See the main local variable 'broken' in the example.) My
expe
On Tue, Oct 23, 2001 at 11:51:46PM +0200, Martin v. Loewis wrote:
> > On Tue, Oct 23, 2001 at 08:21:26PM +0200, Martin v. Loewis wrote:
> > > > The following code does not produce an error when one is
> > > > expected.
> > > > void stat ();
> > > >
> > > > static const int success = 0;
>
18 matches
Mail list logo
