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

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

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

Show all headers | View raw

* Nikos Chantziaras, on 23.05.2011 12:32:
> 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";
>    }

I think this is completely like the `someIntValue` case. You want any value of 
class `B`, or perhaps the default value. Then for this special case it's no big 
deal to write

   B const b = B();

just as with the `someIntValue`.


> 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.

As I see it mutable members are pretty irrelevant, because their mutability 
should not affect the externally visible state. E.g., a mutable member might be 
used for caching for some costly-to-compute result, for example a matrix 
determinant, but the using code does not see any state change. Thus, declaring a 
`const` object of such a well-designed class is no different; it is conceptually 
to name an unchanging value, which "should" be specified.


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