"Alf P. Steinbach" wrote:
> * Victor Bazarov:
> > The paragraph 13 in 12.1 reads:
> >
> > "(...) [Note: The syntax looks like an explicit call of the constructor. ]
> > (...)[Note: explicit constructor calls do not yield lvalues, see 3.10. ]"
> >
> > I am wondering, the two 'Notes', the first and the third, seem to contradict
> > each other.  If the first, by saying "looks like", implies that the syntax
> > is _not_ an explicit call of the constructor, then why is the third using
> > the "explicit constructor calls" as if they are real.  Of course, if the
> > third note is correct, and there is such a thing as an explicit constructor
> > call, then why the first note saying "looks like", shouldn't it then say
> > "is"?
> >
> > I know that notes are not normative, but they are supposed to clear up some
> > stuff, not add to the confusion.  Or, so I thought, anyway...
>
> The two notes are contradictory (....)

If you are right that there are explicit constructor calls, Alf, I
don't think the two notes are necessarily contradictory. One could say,
"That guy over there looks like Victor. Is it him?", and the second
sentence could be answered either positively or negatively without
violating the sense of the first.

In the same way, if something "looks like" an explicit constructor
call, it might or might not actually be one, but of course, if such
calls don't exist, it certainly is not one.

The real question here is: Is that second note in error? It certainly
seems to indicate that constructors can be called explicitly, but is it
in harmony with the Standard proper on that point?

Cheers! --M

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

mlimber wrote:

> "Alf P. Steinbach" wrote:
>> * Victor Bazarov:
>> > The paragraph 13 in 12.1 reads:
>> >
>> > "(...) [Note: The syntax looks like an explicit call of the
>> > constructor. ] (...)[Note: explicit constructor calls do not yield
>> > lvalues, see 3.10. ]"
>> >
>> > I am wondering, the two 'Notes', the first and the third, seem to
>> > contradict
>> > each other.  If the first, by saying "looks like", implies that the
>> > syntax is _not_ an explicit call of the constructor, then why is the
>> > third using
>> > the "explicit constructor calls" as if they are real.  Of course, if
>> > the third note is correct, and there is such a thing as an explicit
>> > constructor call, then why the first note saying "looks like",
>> > shouldn't it then say "is"?
>> >
>> > I know that notes are not normative, but they are supposed to clear up
>> > some
>> > stuff, not add to the confusion.  Or, so I thought, anyway...
>>
>> The two notes are contradictory (....)
>
> If you are right that there are explicit constructor calls, Alf, I
> don't think the two notes are necessarily contradictory. One could say,
> "That guy over there looks like Victor. Is it him?", and the second
> sentence could be answered either positively or negatively without
> violating the sense of the first.
>
> In the same way, if something "looks like" an explicit constructor
> call, it might or might not actually be one, but of course, if such
> calls don't exist, it certainly is not one.
>
> The real question here is: Is that second note in error? It certainly
> seems to indicate that constructors can be called explicitly, but is it
> in harmony with the Standard proper on that point?

Well, the standard says in 12.1./8:

Default constructors are called implicitly to create class objects of static
or automatic storage duration (3.7.1, 3.7.2) defined without an initializer
(8.5), are called to create class objects of dynamic storage duration
(3.7.3) created by a new-expression in which the new-initializer is omitted
(5.3.4), or are called when the explicit type conversion syntax (5.2.3) is
used. A program is ill-formed if the default constructor for an object is
implicitly used and the constructor is not accessible (clause 11).


Note how the first kind of call to a default constructor is labelled
implicit whereas all other call are at least not explicitly marked as
implicit. That may or may not be an oversight, though.



Best

Kai-Uwe Bux

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

* mlimber:
> "Alf P. Steinbach" wrote:
>> The two notes are contradictory (....)
>
> If you are right that there are explicit constructor calls, Alf,

First of all, this is like you say "if you are right that cars do exist,
Alf".  That vaguely implies some very unusual meaning of "car", where
the existence of whatever it is, is in question.  So I can't really say
whether what /you/ mean by that term, has some objective existence.

Second, I've never maintained that even for the literal sequence of
letters "explicit constructor call".

I've never stated: "cars do exist", implying the possibility of
non-existence, like, when one isn't looking.  My position is, on the
contrary, that the existence of cars is completely unaffected by
anyone's choice of terms to refer to them, or refusal to refer to them,
or refusal to believe that "car" can refer to a car.  I.e., I have
maintained and maintain that subjective denial does not affect reality.


> I don't think the two notes are necessarily contradictory. One could say,
> "That guy over there looks like Victor. Is it him?", and the second
> sentence could be answered either positively or negatively without
> violating the sense of the first.

That's a logical possibility, yes.

Perhaps most of the standard is like that? ;-)


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Alf P. Steinbach wrote:
> * mlimber:
> > If you are right that there are explicit constructor calls, Alf,
>
> First of all, this is like you say "if you are right that cars do exist,
> Alf".  That vaguely implies some very unusual meaning of "car", where
> the existence of whatever it is, is in question.  So I can't really say
> whether what /you/ mean by that term, has some objective existence.
>
> Second, I've never maintained [existence] even for the literal sequence of
> letters "explicit constructor call".
>
> I've never stated: "cars do exist", implying the possibility of
> non-existence, like, when one isn't looking.

Is this purely a philosophical meandering on the meaning of
"existence"? If so, it's way off topic here. If not, this part of your
post seems to me to be nothing more than a logomachy. The "existence"
of explicit constructor calls merely means that the standard allows one
to invoke the constructor explicitly. If it does not, then all apparent
invocations are actually something else (e.g. creating a temporary
object, casts with functional notation, etc.). So, I would say the
existence of explicit constructor calls is less like that of cars and
more akin to that of, say, black holes, for which we have significant
indirect evidence but no certainty (insofar as observation can even
yield certainty... but that, too, is way off topic!).

> My position is, on the
> contrary, that the existence of cars is completely unaffected by
> anyone's choice of terms to refer to them, or refusal to refer to them,
> or refusal to believe that "car" can refer to a car.  I.e., I have
> maintained and maintain that subjective denial does not affect reality.

I agree wholeheartedly, but I would hasten to point out that the
opposite may also be true: if unicorns don't exist in reality, calling
something that resembles one "a unicorn" does not make it so.

Cheers! --M

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

The paragraph 13 in 12.1 reads:

"A functional notation type conversion (5.2.3) can be used to create
 new objects of its type. [Note: The syntax
looks like an explicit call of the constructor. ] [Example:
    complex zz = complex(1,2.3);
    cprint( complex(7.8,1.2) );
-end example] An object created in this way is unnamed. [Note: 12.2
 describes the lifetime of temporary
objects. ] [Note: explicit constructor calls do not yield lvalues, see
3.10. ]"

I am wondering, the two 'Notes', the first and the third, seem to contradict
each other.  If the first, by saying "looks like", implies that the syntax
is _not_ an explicit call of the constructor, then why is the third using
the "explicit constructor calls" as if they are real.  Of course, if the
third note is correct, and there is such a thing as an explicit constructor
call, then why the first note saying "looks like", shouldn't it then say
"is"?

I know that notes are not normative, but they are supposed to clear up some
stuff, not add to the confusion.  Or, so I thought, anyway...

Thank you.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Victor Bazarov wrote:
> The paragraph 13 in 12.1 reads:
>
> "A functional notation type conversion (5.2.3) can be used to create
> new objects of its type. [Note: The syntax
> looks like an explicit call of the constructor. ] [Example:
>    complex zz = complex(1,2.3);
>    cprint( complex(7.8,1.2) );
> -end example] An object created in this way is unnamed. [Note: 12.2
> describes the lifetime of temporary
> objects. ] [Note: explicit constructor calls do not yield lvalues, see
> 3.10. ]"
>
> I am wondering, the two 'Notes', the first and the third, seem to
> contradict each other.  If the first, by saying "looks like", implies
> that the syntax is _not_ an explicit call of the constructor, then
> why is the third using the "explicit constructor calls" as if they
> are real.  Of course, if the third note is correct, and there is such
> a thing as an explicit constructor call, then why the first note
> saying "looks like", shouldn't it then say "is"?
>
> I know that notes are not normative, but they are supposed to clear
> up some stuff, not add to the confusion.  Or, so I thought, anyway...

OK, adding to my own post, as yet another thread on "can we call a
constructor"
is winding down in comp.lang.c++...

A possible reading of this paragraph, as it was pointed to me, is that it
is not a contradiction, and the notes simply refer to "explicit constructor
calls" that do exist (generally speaking), and are defined elsewhere.

My question is then, "where are they defined"?

My apparent confusion comes from the fact that we cannot call a constructor
for a specific object.  Is that obvious?  Supposedly, there is no syntax
that allows that.  But constructors are members.  Are they static?  Or are
they impicitly static (like the overloaded 'new' and 'delete', for example)?

Constructors don't have names.  They are not found during name lookup.  But
the syntax "<type-id> ( [<expr>] )", which the paragraph 12.1/13 describes,
does exist, and the type will be looked up, right?  And they participate in
overload resolution, apparently.  Just like any other function.

I am asking mostly to try to either find the place in the Standard that is
already clear about all that, or if such place doesn't exist, perhaps to add
some kind of disambiguation (or at least understand why we don't want to do
that).

And, why don't we allow constructors to be called?  What if it would only
be allowed in the initialiser list of another constructor?  They are already
special...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

* Victor Bazarov:
>
> A possible reading of [pargraph 12.1/13], as it was pointed to me, is that it
> is not a contradiction, and the notes simply refer to "explicit constructor
> calls" that do exist (generally speaking), and are defined elsewhere.
>
> My question is then, "where are they defined"?

The functional cast notation is one example.

An "explicit" (C++ keyword) constructor means it generally must be
called via explicit constructor calls, functional cast notation.

Except for a default constructed variable, and except in the context of
a static_cast, which both are explicit expressions of intent  --  not
sure if there are more exceptions.


> My apparent confusion comes from the fact that we cannot call a constructor
> for a specific object.  Is that obvious?  Supposedly, there is no syntax
> that allows that.  But constructors are members.  Are they static?  Or are
> they impicitly static (like the overloaded 'new' and 'delete', for example)?

No, constructors are not static: a constructor has an implicit 'this'
argument.  Constructors are neither static nor non-static.  They're
/special/, what the standard calls "special member functions".


> Constructors don't have names.  They are not found during name lookup.  But
> the syntax "<type-id> ( [<expr>] )", which the paragraph 12.1/13 describes,
> does exist, and the type will be looked up, right?  And they participate in
> overload resolution, apparently.  Just like any other function.

It's complicated, I agree.  It would apparently be less complicated if
constructors formally had names, just like destructors, and the standard
simply disallowed the form o.T().  Perhaps the person who originally
wrote the "constructors do not have names" sentence could clarify?


> I am asking mostly to try to either find the place in the Standard that is
> already clear about all that, or if such place doesn't exist, perhaps to add
> some kind of disambiguation (or at least understand why we don't want to do
> that).
>
> And, why don't we allow constructors to be called?

We do.


> What if it would only
> be allowed in the initialiser list of another constructor?  They are already
> special...

Constructors are already special in general, not just when used in
initializer lists, and they are called in initializer lists.  Details:
one possibility mentioned in 12.6.1/3 is that a member is
direct-initialized.  And after some preamble 8.5/14 then states "the
constructor so selected is called to initialize the object".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

* Victor Bazarov:
> The paragraph 13 in 12.1 reads:
>
> "A functional notation type conversion (5.2.3) can be used to create
>  new objects of its type. [Note: The syntax
> looks like an explicit call of the constructor. ] [Example:
>     complex zz = complex(1,2.3);
>     cprint( complex(7.8,1.2) );
> -end example] An object created in this way is unnamed. [Note: 12.2
>  describes the lifetime of temporary
> objects. ] [Note: explicit constructor calls do not yield lvalues, see
> 3.10. ]"
>
> I am wondering, the two 'Notes', the first and the third, seem to contradict
> each other.  If the first, by saying "looks like", implies that the syntax
> is _not_ an explicit call of the constructor, then why is the third using
> the "explicit constructor calls" as if they are real.  Of course, if the
> third note is correct, and there is such a thing as an explicit constructor
> call, then why the first note saying "looks like", shouldn't it then say
> "is"?
>
> I know that notes are not normative, but they are supposed to clear up some
> stuff, not add to the confusion.  Or, so I thought, anyway...

The two notes are contradictory, and the first represents a bit of
confusion.

The second note refers to 3.10, which has a corresponding note about
"invocations of constructors" not being lvalues, in the same way as an
invocation of a function that returns a class type object is not an lvalue.

Note: the standard uses the words "call" and "invocation"
interchangeably, but with meanings that vary depending on the context.

In some cases, such as here (12.1/13, 3.10/2) and in the definition of a
default constructor (12.1/5), "call" or "invocation" wrt. a constructor
necessarily refers to a source code specification of an object creation;
let's call that a source code constructor call.

In some other cases (e.g. 12.1/2, 12.1/8), "call" or "invocation" wrt. a
constructor refers to actions taken by the abstract machine; let's call
that an abstract machine constructor call.

The first note of 12.1/13 probably represents an attempt to state that a
functional notation type conversion used to create an object, is not an
abstract machine constructor call.

Which is not meaningful because the context is already the source code,
namely the syntax.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Alf P. Steinbach wrote:
> * Victor Bazarov:
>>[..]
>> And, why don't we allow constructors to be called?
>
> We do.

I guess I ought to be more verbose.  Why don't we allow constructors
to be called [again] for a particular object, like Java does, for
example?

>> What if it would only
>> be allowed in the initialiser list of another constructor?  They are
>> already special...


Please consider that in light of my clarification.

V
--
Please remove capital As from my address when replying by mail


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Victor Bazarov posted:

> Alf P. Steinbach wrote:
>> * Victor Bazarov:
>>>[..]
>>> And, why don't we allow constructors to be called?
>>
>> We do.
>
> I guess I ought to be more verbose.  Why don't we allow constructors
> to be called [again] for a particular object, like Java does, for
> example?


I'm probably flogging a dead horse here, but we can:

new(some_memory) SomeClass(some arguments);


-Tom   s

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Tom   s wrote:
> Victor Bazarov posted:
>
>> Alf P. Steinbach wrote:
>>> * Victor Bazarov:
>>>> [..]
>>>> And, why don't we allow constructors to be called?
>>> We do.
>> I guess I ought to be more verbose.  Why don't we allow constructors
>> to be called [again] for a particular object, like Java does, for
>> example?
>
>
> I'm probably flogging a dead horse here, but we can:
>
> new(some_memory) SomeClass(some arguments);
>
>
Which is still way more than just calling the SomeClass consturctor.
It is what it says, creating a new SomeClass object on preallocated
memory.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

* Victor Bazarov:
> Alf P. Steinbach wrote:
>> * Victor Bazarov:
>>> [..]
>>> And, why don't we allow constructors to be called?
>> We do.
>
> I guess I ought to be more verbose.  Why don't we allow constructors
> to be called [again] for a particular object, like Java does, for
> example?

I assume you're referring to Java's constructor chaining, allowing one
class T constructor to defer the bulk of the work to another class T
constructor.

IMO that's highly desirable: the workarounds we have with the current
standard (default arguments, init-function, artificial base class) are
generally unsatisfactory, kludges.

One moment while I'm firing up FireFox...

OK, found some proposals:

"Class Defaults", Glassborow, 2003,
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1445.htm>

"Delegating Constructors", Sutter & Glassborow, 2004,
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1581.pdf>
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1618.pdf>

"Inheriting Constructors", Glassborow, 2004,
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1583.pdf>

"Forwarding and inherited constructors", Michaud & Wong, 2005,
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1898.pdf>

Perhaps someone on the standard committee could comment on the status of
this work, e.g., will we have constructor delegation in C++0x?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Ron Natalie wrote:
> Tom   s wrote:
>> Victor Bazarov posted:
>>
>>> Alf P. Steinbach wrote:
>>>> * Victor Bazarov:
>>>>> [..]
>>>>> And, why don't we allow constructors to be called?
>>>> We do.
>>> I guess I ought to be more verbose.  Why don't we allow constructors
>>> to be called [again] for a particular object, like Java does, for
>>> example?
>>
>>
>> I'm probably flogging a dead horse here, but we can:
>>
>> new(some_memory) SomeClass(some arguments);
>>
>>
> Which is still way more than just calling the SomeClass consturctor.
> It is what it says, creating a new SomeClass object on preallocated
> memory.

But a constructor is precisely that which converts preallocated
memory into an object; what difference do you see?  I would expect
the compiler to translate the placement new above, after inlining
of the relevant operator new, to a call to the constructor, and
nothing more.  My assumption is that by "the constructor" we include
the code that calls other constructors as required -- which requires
in some cases that the constructor be aware of whether it is "in
charge" (i.e., it should call ctors for virtual bases etc.) or not.

-- James

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

In article <4dsemvF1bj1orU1@individual.net>, Alf P. Steinbach
<alfps@start.no> writes
>Perhaps someone on the standard committee could comment on the status
>of this work, e.g., will we have constructor delegation in C++0x?

It is in the working draft.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

* Ron Natalie:
> Tom=E1s wrote:
>> Victor Bazarov posted:
>>
>>> Alf P. Steinbach wrote:
>>>> * Victor Bazarov:
>>>>> [..]
>>>>> And, why don't we allow constructors to be called?
>>>> We do.
>>> I guess I ought to be more verbose.  Why don't we allow constructors
>>> to be called [again] for a particular object, like Java does, for
>>> example?
>>
>>
>> I'm probably flogging a dead horse here, but we can:
>>
>> new(some_memory) SomeClass(some arguments);
>>
>>
> Which is still way more than just calling the SomeClass consturctor.
> It is what it says, creating a new SomeClass object on preallocated
> memory.

This seems to go to the terminology employed by the standard, that it=20
should be changed to replace all usage of the term "call" (and possibly=20
"invoke") for constructor calls, with some other unspecified term.

If I understand you correctly:

   * The word "call" should only be used where it would be appropriate
     to say "just call" instead.

   * "just call" excludes constructor calls, because a, uhm, "constructor
     call", would include more than execution of one constructor's body,
     or in general, in some sense more than execution of a freestanding
     function.

   * OTOH, "just call" includes virtual function calls, where the
     virtual function call includes more than a call of a freestanding
     function.

   * Still OTOH, "just call" includes explicit destructor calls, where
     the destructor call likewise includes more than a call of
     freestanding function.

   * Still OTOH., "just call" includes an operator() call on an object
     with an implicit conversion to function pointer, ..., and so on.

 From this list it seems that the notion of more going on than for a=20
call of a freestanding function, is not essential to the definition of=20
"just call".  Or else, that "just call" really means a call of a=20
freestanding function, nothing else.  So that "call" should only be used=20
for calls of freestanding functions: not for anything in the list above.

Assuming the first possibility, since the second is ridiculous, "just=20
call" seems to boil down to the definition that "just call" means any=20
call that is not a constructor call, and hence, that the requirement=20
that "call" should only be used for "just call" boils down to the=20
assertion that "call" should not be used for constructor calls; and=20
further, that a constructor call is not a "call" because the term "call"=20
arbitrarily excludes constructor calls  --  hey, that's not a dog,=20
because the term "dog" should not be used for border collies.

Why should the standard differentiate constructor calls in that way, and=20
what term should it, IYO., use instead of "call" and "invoke"?

--=20
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Ron Natalie wrote:
> Tom   s wrote:
> > Victor Bazarov posted:
> >
> >> Alf P. Steinbach wrote:
> >>> * Victor Bazarov:
> >>>> [..]
> >>>> And, why don't we allow constructors to be called?
> >>> We do.
> >> I guess I ought to be more verbose.  Why don't we allow constructors
> >> to be called [again] for a particular object, like Java does, for
> >> example?
> >
> >
> > I'm probably flogging a dead horse here, but we can:
> >
> > new(some_memory) SomeClass(some arguments);
> >
> >
> Which is still way more than just calling the SomeClass consturctor.
> It is what it says, creating a new SomeClass object on preallocated
> memory.

Well, yes. What else would you want a repeat call to a constructor to
do?


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]