Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #5356

Re: Rationale behind user provided ctor requirement for const objects of non-POD class types

From "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com>
Newsgroups comp.lang.c++
Subject Re: Rationale behind user provided ctor requirement for const objects of non-POD class types
Date 2011-05-23 12:11 +0200
Organization A noiseless patient Spider
Message-ID <irdbge$8da$1@dont-email.me> (permalink)
References <ird841$112$1@news.grnet.gr>

Show all headers | View raw


* Nikos Chantziaras, on 23.05.2011 11:07:
> (Originally posted to comp.std.c++, but that newsgroup is dead.)
>
> Recently, I've seen a compiler (clang) that will not compile code like this:
>
>    struct A {
>          A() {}
>    };
>
>    class B {
>          A a_;
>    };
>
>    int foo()
>    {
>          const B b;
>          return 0;
>    }
>
> It will not compile it because 'b' is const B, which does not have a user
> defined ctor.  C++'03 [dcl.init] p9 says:
>
>    If no initializer is specified for an object, and the object
>    is of (possibly cv-qualified) non-POD class type (or array
>    thereof), the object shall be default-initialized; if the
>    object is of const-qualified type, the underlying class type
>    shall have a user-declared default constructor.
>
> Why is that?  Why can't a const B constructed the same way as a non-const B,
> using the implicitly defined default constructor?

Bjarne Stroustrup's "The Design & Evolution of C++" is a good source of answers 
to such questions.

Unfortunately I don't have it.

But often these rationales are nothing but common sense. So I guess if you check 
out D&E, and if it gives a rationale, it will be that

this unchanging "value" shall have been explicitly defined by the source code, 
because generally it makes no sense to /name a value/ and not define that value 
explicitly.

There are times where it might makes sense (if had been allowed) to write e.g.

   int const  someIntValue;

but from the compiler's point of view this seems like the programmer had 
forgotten to supplyh the value to be named, and anyway in such cases it's no big 
hardship to explicitly state what that value is,

   int const  someIntValue = int();

And likewise in your example.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Rationale behind user provided ctor requirement for const objects of non-POD class types Nikos Chantziaras <realnc@arcor.de> - 2011-05-23 12:07 +0300
  Re: Rationale behind user provided ctor requirement for const objects of non-POD class types "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-23 12:11 +0200
    Re: Rationale behind user provided ctor requirement for const objects of non-POD class types Nikos Chantziaras <realnc@arcor.de> - 2011-05-23 13:32 +0300
      Re: Rationale behind user provided ctor requirement for const objects of non-POD class types "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-23 13:36 +0200
        Re: Rationale behind user provided ctor requirement for const objects of non-POD class types "Balog Pal" <pasa@lib.hu> - 2011-05-23 14:44 +0200
          Re: Rationale behind user provided ctor requirement for const objects of non-POD class types Öö Tiib <ootiib@hot.ee> - 2011-05-24 16:04 -0700
            Re: Rationale behind user provided ctor requirement for const objects of non-POD class types "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-25 02:37 +0200

csiph-web