On Wed, 24 Oct 2001, Matthias Klose 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?
After analyzing the problem it became clear
On Sat, 27 Oct 2001, Nathan Myers wrote:
[...]
> > 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 TYPE obj = INITIALIZER; return obj; }
> >
> > T
On Wed, Oct 24, 2001 at 11:48:02PM +0200, Martin v. Loewis wrote:
> > 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
Hi,
On Thu, 25 Oct 2001, Martin v. Loewis wrote:
> > I don't like this `construct on first use' idiom at all, aesthetically.
>
> Isn't this exactly what you want, and what modules.h does? If module A
> uses module B, construction of A first constructs B.
Sure it is.
> > I find it disgusting t
> I don't like this `construct on first use' idiom at all, aesthetically.
Isn't this exactly what you want, and what modules.h does? If module A
uses module B, construction of A first constructs B.
> I find it disgusting to use a function call for that and a
> preprocessor symbol.
Well, you do
On Wed, 24 Oct 2001, Martin v. Loewis wrote:
> 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 TYPE obj = INITIALIZER;
> return obj;
> }
>
> Then use
> 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
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 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
> > 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
On Wed, Oct 24, 2001 at 01:11:02AM +0200, Matthias Klose wrote:
> Richard B. Kreckel writes:
> > Package: g++-3.0
> > Version: 1:3.0.2-0pre011014
> > Severity: important
> >
> > Summary: It seems like some bug crept into Debian's gcc-3.0. The bug does
> > not seem to be present upstream. This bu
Richard B. Kreckel writes:
> Package: g++-3.0
> Version: 1:3.0.2-0pre011014
> Severity: important
>
> Summary: It seems like some bug crept into Debian's gcc-3.0. The bug does
> not seem to be present upstream. This bug renders the CLN package
> unlinkable with our compiler.
>
> The following p
Package: g++-3.0
Version: 1:3.0.2-0pre011014
Severity: important
Summary: It seems like some bug crept into Debian's gcc-3.0. The bug does
not seem to be present upstream. This bug renders the CLN package
unlinkable with our compiler.
The following piece of code is extracted from CLN's PROVIDE/
16 matches
Mail list logo
