On May 18, 10:55 pm, Jo Vendt <jove...@gmail.com> wrote:
> On 12 Mai, 20:10, Magnus F <ma...@lysator.liu.se> wrote:
>
>
>
> > Hello.
>
> > I recently found that the following code is non-standard due to
> > [decl.init] =A75 (FCD [decl.init] =A76) and would like to know why that
is
> > as I have a hard time understanding what the gains from it is.
>
> > struct State {
> >  virtual ~State() { }
> >  virtual const State* nextState() const = 0;
>
> > };
>
> > struct StateA : state {
> >  const State* nextState() const;
>
> > };
>
> > const StateA stateA;
>
> > I would also like to know if it is way to light to lift that
> > restriction but I fear it is to late for the current standard.
>
> I think the restriction is in place to prevent any of the member
> subobjects from ending up with indeterminate values, the assumption
> being that if a user-defined constructor is provided, it will properly
> initialize the object. Of course, when the class has no subobjects
> that need initialization, it may seem like a pointless requirement.

I think it is pointless if the object is default constructible.
Sure, forbidding indeterminate values is a nice idea but then I think
it would be better to do that than to disallow default constructed
const objects.

> However, the new list-initialization syntax makes it very easy to
> value-initialize the object.
>
> const StateA stateA {}; // OK, object is value-initialized, no user-
> defined constructor required

Yes - it seems that way. This only makes the whole restriction more
weird even if it is nice to know that there is a way around it.

/MF


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 12, 8:10 pm, Magnus F <ma...@lysator.liu.se> wrote:
> I recently found that the following code is non-standard due to
> [decl.init] =A75 (FCD [decl.init] =A76) and would like to know why that is
> as I have a hard time understanding what the gains from it is.
>
> struct State {
>  virtual ~State() { }
>  virtual const State* nextState() const = 0;
> };
>
> struct StateA : state {
>  const State* nextState() const;
> };
>
> const StateA stateA;
>
> I would also like to know if it is way to light to lift that
> restriction but I fear it is to late for the current standard.

Note that there exists already a corresponding core issue
for this situation:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#253

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hello.

I recently found that the following code is non-standard due to
[decl.init] =A75 (FCD [decl.init] =A76) and would like to know why that is
as I have a hard time understanding what the gains from it is.

struct State {
 virtual ~State() { }
 virtual const State* nextState() const = 0;
};

struct StateA : state {
 const State* nextState() const;
};

const StateA stateA;

I would also like to know if it is way to light to lift that
restriction but I fear it is to late for the current standard.

/MF


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Magnus F <magfr@lysator.liu.se> writes:

> Hello.
>
> I recently found that the following code is non-standard due to
> [decl.init] =A75 (FCD [decl.init] =A76) and would like to know why that is
> as I have a hard time understanding what the gains from it is.
>
> struct State {
>  virtual ~State() { }
>  virtual const State* nextState() const = 0;
> };
>
> struct StateA : state {
>  const State* nextState() const;
> };
>
> const StateA stateA;

Just to clarify this for myself, since you don't present the detail of
[dcl.init] that you are wanting to refer to...  Are you intending
something along the lines of what arises from:

      [dcl.init]/11
  "If no initializer is specified for an object, the object is default
  initialized."

coupled with:

      [dcl.init]/6
  "If a program calls for the default initialization of an object of a
  const-qualified type T, T shall be a class type with a user-provided
  default constructor."

If this is the case then a simpler example suffices:

  struct State { };
  const State state;

  Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for
  ONLINE_EVALUATION_BETA2
  Copyright 1988-2008 Comeau Computing.  All rights reserved.
  MODE:strict errors C++ noC++0x_extensions

  "ComeauTest.c", line 3: error: const variable "state" requires an
         initializer --
      class "State" has no explicitly declared default constructor
    const State state;
                     ^

unless you are referring to some other aspect of your code relating,
perhaps, to the inclusion of a polymorphic inheritance relationship
specifically.

What's interesting about the above, however, is that, whilst GCC (4.4.3)
rejects the simpler example given, agreeing with Comeau:

  21:49:03 Paul Bibbings@JIJOU
  /cygdrive/d/CPPProjects/CSCPP $gcc -ansi -pedantic -c
     const_objects.cpp
  const_objects.cpp:5: error: uninitialized const    state

  21:49:19 Paul Bibbings@JIJOU
  /cygdrive/d/CPPProjects/CSCPP $

it nevertheless *accepts* your code as given (with the correction of
`State' for `state' as the type inherited from), which Comeau does
*not*.

Regards

Paul Bibbings

<snip />


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 13, 7:30 pm, Paul Bibbings <paul.bibbi...@gmail.com> wrote:
> Magnus F <ma...@lysator.liu.se> writes:
> > Hello.
>
> > I recently found that the following code is non-standard due to
> > [decl.init] =A75 (FCD [decl.init] =A76) and would like to know why that
is
> > as I have a hard time understanding what the gains from it is.
>
> > struct State {
> >  virtual ~State() { }
> >  virtual const State* nextState() const = 0;
> > };
>
> > struct StateA : state {
> >  const State* nextState() const;
> > };
>
> > const StateA stateA;
>
> Just to clarify this for myself, since you don't present the detail of
> [dcl.init] that you are wanting to refer to...  Are you intending
> something along the lines of what arises from:
>
>       [dcl.init]/11
>   "If no initializer is specified for an object, the object is default
>   initialized."
>
> coupled with:
>
>       [dcl.init]/6
>   "If a program calls for the default initialization of an object of a
>   const-qualified type T, T shall be a class type with a user-provided
>   default constructor."

Yes. That is what I am referring to, sorry for being less than clear.
I just fail to see what the gain from the restriction is while I can
see valid use cases for const objects without a constructor.

> What's interesting about the above, however, is that, whilst GCC (4.4.3)
> rejects the simpler example given, agreeing with Comeau:
> ...
> it nevertheless *accepts* your code as given (with the correction of
> `State' for `state' as the type inherited from), which Comeau does
> *not*.

Yes - this is a known bug in GCC that is fixed for the next (4.6.0)
major release.

/MF


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 12 Mai, 20:10, Magnus F <ma...@lysator.liu.se> wrote:
> Hello.
>
> I recently found that the following code is non-standard due to
> [decl.init] =A75 (FCD [decl.init] =A76) and would like to know why that is
> as I have a hard time understanding what the gains from it is.
>
> struct State {
>  virtual ~State() { }
>  virtual const State* nextState() const = 0;
>
> };
>
> struct StateA : state {
>  const State* nextState() const;
>
> };
>
> const StateA stateA;
>
> I would also like to know if it is way to light to lift that
> restriction but I fear it is to late for the current standard.

I think the restriction is in place to prevent any of the member
subobjects from ending up with indeterminate values, the assumption
being that if a user-defined constructor is provided, it will properly
initialize the object. Of course, when the class has no subobjects
that need initialization, it may seem like a pointless requirement.
However, the new list-initialization syntax makes it very easy to
value-initialize the object.

const StateA stateA {}; // OK, object is value-initialized, no user-
defined constructor required


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]