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

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

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

Show all headers | View raw

On 05/23/2011 01:11 PM, Alf P. Steinbach /Usenet wrote:
> * Nikos Chantziaras, on 23.05.2011 11:07:
>> [...]
>> 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?
>[...]
> 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.

Good thinking, but it doesn't seem to apply.  Consider this:

   #include <iostream>

   class A {
       int x_;
   public:
       A() : x_(5) { }
       int x() const { return x_; }
   };

   class B: public A { };

   int main()
   {
       const B b;
       std::cout << b.x() << "\n";
   }

With compilers that accept this, the output of the program is "5".  But 
the C++ standard says that it should not be compilable.  In this case 
however, 'b' has a perfectly fine initial state.

Also, let's not forget that an object can have mutable members, so the 
requirement for a user defined ctor for const B makes even less sense.

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