Subject: Re: Bug#195468: g++-3.3: default construction fails when no explicit default constructor defined

From: Herbert Valerio Riedel <[email-masked]>
Date: 31 May 2003 02:00:28 +0200

On Fri, 2003-05-30 at 22:08, Phil Edwards wrote:
> On Fri, May 30, 2003 at 09:26:32PM +0200, Herbert Valerio Riedel wrote:
> > $ cat static_var.cc
> > 
> > class bar {
> > public:
> >   int operator()(int i) { return i; }
> >   //bar (void) {} // default constructor
> > };
> > 
> > const bar b = bar (); // works always...
> > const bar b2; // fails if there is no explicit default constructor
> > $ g++ -c -O0 -Wall static_var.cc
> > static_var.cc:9: uninitialized const `b2'
> > $
> > 
> > if the commented out default constructor is enabled, compilation
> > succeeds...

> Or if you declare b2 as non-const.  This is not a bug.

I've reconsidered the problem;

now to me it looks, as if g++ behaves as if bar was a POD type (actually
the class defined above seems to qualify as POD type) since for those
cases, "const bar b2;" would really be uninitialized, since:

>A non-const POD object declared with no initializer has an
>"indeterminate initial value" [§8.5, ¶9].

thus compiling "const <POD-type> foo;" is sensible to fail...
but on the other hand, what 'indeterminate initial value' can there be,
if the struct doesn't contain any data member at all?!?
(fyi, 3 other c++ compilers I've tried compiled the code above
successfully...)

but, according to http://home.fnal.gov/~wb/POD.html, the following would
definitely not be a POD type:

class bar {}; // base class

class foo: public bar { // foo has a base class...
  int m_int; // "protected non-static data member"
protected:
  int m_int2; // "protected non-static data member"
public:
  foo operator=(const foo &f) { return *this; } // "user-defined copy
//assignment operator"
  ~foo () {} // "user-defined destructor"
};

const foo b; // "error: uninitialized const `b'"

...and yet g++-3.[23] fails to compile this... 

(btw...if I'd add a virtual function, or a user declared default
constructor, or some non-POD non-static data member, then the code would
compile...)

...so... is _still_ not a buggy behaviour??

regards,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: [email-masked]       /    Finger [email-masked] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142