🚀 go-pugleaf

In article <4j5b26$1e7a@mule1.mindspring.com> abell@mindspring.com
(Andrew Bell) writes:

|> Hopefully these will have short answers, and aren't inappropriate for
|> the newsgroup.

|> 1) Is there any way to catch an exception thrown in the constructor of
|> a statically constructed object?  Does it call unexpected() or
|> terminate() even?

Exactly.  There is no way to catch the exception, so terminate will be
called.

|> 2) From a previous post on this group, it looks like the standard will
|> allow one to define conversion operators for pre-existing, source code
|> untouchable data types.  Yes? No? What will this look like? I have the
|> May copy of the WP, and don't see any mention of this.

I'm not sure what you mean here.  You have always been able to define
conversion operators for pre-existing types to *NEW* types; such
operators are called constructors:-).  If you mean somehow change the
meaning of e.g.: int->long, then I don't think that there is the
slightest chance of this being supported.

|> 3) I often write what I call "pure wrapper" classes to give access
|> protection and data abstraction to pre-existing data types.  A pure
|> wrapper class is a class that adds no member variables or virtual
|> member functions to a class/struct that has no virtual functions of
|> its own, so their size and alignment should be the same and casting
|> between the two should be perfectly safe.  The new standard doesn't
|> have any special support (for example, allowing it automatically) for
|> this, does it?

I'd like something like this too.  I often derive for the sole purpose
of changing the default constructor.

The only place where this is really an issue, however, is in arrays.
And since vector uses the copy constructor (rather than the default
constructor) to initialize, IMHO, it is no longer an issue there,
either. 

So while some added guarantees might be nice, they really aren't worth
the effort it would take to define them.

|> 4) With RTTI, a derived class that doesn't change any virtual member
|> funcs or add any properties to a base class still evaluates to a
|> different object type, correct?

One would certainly hope so.  I cannot think of any reason why it would
be different.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]