Greg Brewer wrote in message <7qk26r$22je$1@news.hal-pc.org>...
>No valid reason was
>presented as to why a data constructor could not call other, overloaded
>constructors of the same class.  A vocal and obstructionistic minority
>opposed this -- and any other -- change; however, most individuals
>responding were favorable.  Allowing a constructor to call other overloaded
>constructors will not break any existing code.
>
So how do you think the base class should be constructed if you allow
"nested" constructors?
E.g.
struct A{};
struct B:A

  int i;
  B();
  B(int i): i(i), B(){} // who calls A() ?
  B(int* i): B(), i(*i) {} // does the order matter ?
  B(char c):i(0) {if(c>0) B(); } // will you allow this also?
};

How does compiler know which constructor should initialize subclass A. How
would you distinguish constructor call from the temporary creation ( B() )?

Gene Bushuyev




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a good spot for posting disagreements with my summary.  If you have
additional comments on the original posts, please take it to the appropriate
topic area.

Greg Brewer





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev <gbush@synopsys.com> wrote in message
news:rstfc0jjj7154@corp.supernews.com...
>
> Greg Brewer wrote in message <7qk26r$22je$1@news.hal-pc.org>...
> So how do you think the base class should be constructed if you allow
> "nested" constructors?
> E.g.
> struct A{};
> struct B:A
>
>   int i;
>   B();
>   B(int i): i(i), B(){} // who calls A() ?
>   B(int* i): B(), i(*i) {} // does the order matter ?
>   B(char c):i(0) {if(c>0) B(); } // will you allow this also?
> };
>
> How does compiler know which constructor should initialize subclass A. How
> would you distinguish constructor call from the temporary creation
( B() )?

Well, I thought these topics had been thoroughly discussed; guess I was
wrong.  I don't have definitive answers; however, I do like Dave Harris'
idea that would disallow any other initializers when recursively calling an
initializer.

Greg Brewer
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I've been quite pleased that my discussion topics have generated so many
responses.  I thought I would take time to summarize.

Part 1) NULL discussion -- Initially, only labeled as Part 1
The consensus seems to be the C++ implementation is broke and little beyond
that.  I personally rather liked my idea of &0 is the null pointer; however,
noone else cared for it.  The 2nd best idea, IMHO, was to make ((void *)0) a
special case that could be universally promoted.  The main difficulty was
that any change necessary to fix the problems associated with the current
definition would result in some previously legal code becoming illegal.

Part 2) null declaration  discussion --  incorrectly labeled Part 1
In C, there was one good reason for not allowing a null declaration given:
because it would be difficult to distinguish a null declaration from a null
statement.  I found this to be somewhat lame in that it would easy enough to
consider it a null data declaration until the first executable statement has
been parsed.  No one presented any reasonable argument for disallowing a
null data declaration.  The only argument presented for continuing to
disallow a null data declaration was to preserve the status quo.  Allowing a
null declaration will not break any existing code.

Part 3) constructor discussion
There were two parts to this discussion.  I don't remember for sure;
however, I think the reason for requiring a data declaration for const
members of a class/structure was adequately addressed.  No valid reason was
presented as to why a data constructor could not call other, overloaded
constructors of the same class.  A vocal and obstructionistic minority
opposed this -- and any other -- change; however, most individuals
responding were favorable.  Allowing a constructor to call other overloaded
constructors will not break any existing code.

Part 4) string discussion  -- incorrectly labeled Part 3
There were two parts to this discussion.  The idea of having functions that
could translate a string to/from its source code equivalent received too few
responses to generate a summary of opinion.  The idea of adding an new
string sequence of '\e' for escape received much more commentary.  The only
reasonable argument against was that an escape character is not necessarily
defined in all codesets.  It was argued that sequence is useful to a
significant number of people.  Personally, I could go either way.  I no
longer have any need for the character; however, it would have been
convenient to have it in the past.  Defining '\e' as a valid character will
not break any existing code.

Part 5)  time function discussion -- actually posted in C forum
Like NULL, I think there was a strong consensus that the current standard
functions are inadequate.  All inadequacies identified dealt with timezones.
It was noted that a big problem with the current implementations is that
they assume US rules for daylight savings.  Adding new functions to handle
time conversions will break no existing code.

Part 5) implied member function discussion
Relatively little discussion was generated on this topic.  It was pointed
out that boolean operators defined in utility.h would cover the implied
cases given as suggestion.  That point was countered by someone who pointed
out that including utility.h can have adverse side effects.  I should have
been noted that the template boolean operators defined in utility.h are
limited to comparisons between like objects.  There would be no implied
boolean operators for classes that were otherwise independent of each other.
Providing default implied boolean operators will break no existing code.

Part 6) packed discussion
I didn't see much support for this idea.  The need for a modifier to specify
a packed data structure comes for the need on some platforms to align some
data types on certain boundaries.  On platforms that have no boundary
requirements at all, a packed modifier has no effect at all.  On platforms
that have strict boundary requirements, the value of a packed modifier is
debatable:  there is a strong probability to seperately compiled modules
agree on a simple structure definition and a packed structure would likely
be a liability since accessing members that are supposed to be aligned would
either generate an error condition or require special coding.  Personally,
the intel platform is the only one I know of that can go either way.  Iff
that is the case, then a packed modifier would only be beneficial on that
platform.  The usual cast of characters opposed this on the grounds that
#pragmas could handle the situation.  While I accept that this may have to
do, I wish I had been able to adequately demonstrate the inadequacies of
this solution.   Personally, I would favor adding the modifier and leaving
it totally undefined what it means.  Adding a modifier for packing
structures could break existing code -- requires new keyword that may be in
use as identifier.


Well, that's it for now.  I can't really think of anything new I would like
to see discussed.  I had thought to post a discussion on a "typeof" modifier
that I have found occassion to need; however, someone else posted a
discussion on that about the same time I started my discussions so I skipped
it.

I would like to think everyone that contributed.

Greg Brewer

P.S.  Now watch me think of something I forgot all about.  :-)




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> I've been quite pleased that my discussion topics have generated so many
> responses.  I thought I would take time to summarize.

[...]

> Part 3) constructor discussion
> There were two parts to this discussion.  I don't remember for sure;
> however, I think the reason for requiring a data declaration for const
> members of a class/structure was adequately addressed.  No valid reason was
> presented as to why a data constructor could not call other, overloaded
> constructors of the same class.  A vocal and obstructionistic minority
> opposed this -- and any other -- change; however, most individuals
> responding were favorable.  Allowing a constructor to call other overloaded
> constructors will not break any existing code.

I remember a perfect solution in terms of the current
language was posted: Just use a base class for the common
part.

[...]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]