«

Alf P. Steinbach wrote:

> * Rolf Magnus:
>> Alf P. Steinbach wrote:
>>
>>> I guess it's time for the authority argument again (not thereby
>>> denigrating my own biggie authority, but ):
>>>
>>> Andrew Koenig & Bjarne Stroustrup
>>> "The explicit constructor call greater<int>() will serve the same
>>> purpose by creating an anonymous object:"
>>
>> Well, everyone makes an error now and then
>
> The languages' creator, the first secretary of the committee and the
> standard itself is in error about the terminology, yeah, right.
>
>
>>>> A constructor is always implicitly invoked as part of object creation.
>>> Not quite, e.g. ...
>>>
>>> int x;
>>>
>>> ... creates an object without calling a constructor, and so does (as I
>>> recall, but don't flog me if the standard defines by way of a default
>>> constructor) ...
>>
>> If every constructor call is done as part of object creation, that
>> doesn't mean that every object creation involves a constructor call. I
>> was rather talking about the former, not the latter. But I admit my last
>> posting could be misinterpreted.
>>
>>> struct Foo { int x; };
>>>
>>> int main()
>>> {
>>> Foo();
>>> }
>>>
>>> What you probably meant was that if a class has at least one declared
>>> constructor, then, without using very low level features to circumvent
>>> this guarantee, creating any instance of that class calls a constructor
>>> of that class,
>>
>> No. What I meant is that it's just the other way round.
>
> There is no "other way around": you can't have one without the other.
>
>
>> You cannot
>> circumvent it, since if the constructor hasn't been executed, it's not an
>> object of that type yet.
>
> This shows that you have some fundamental misunderstanding.
>
> It's not clear what you misunderstand but I think you should make an
> effort to find out.

I guess it must be the same fundamental misunderstanding that people had
when writing paragraph 3.8 of the C++ standard:

3.8 Object Lifetime [basic.life]

1 The lifetime of an object is a runtime property of the object. The
lifetime of an object of type T begins when:

— storage with the proper alignment and size for type T is obtained, and
— if T is a class type with a non-trivial constructor (12.1), the
constructor call has completed.

On Jul 2, 3:51*pm, Rolf Magnus <ramag...@t-online.de> wrote:
> Alf P. Steinbach wrote:
> > * Rolf Magnus:
> >> Alf P. Steinbach wrote:
>
> >>> I guess it's time for the authority argument again (not thereby
> >>> denigrating my own biggie authority, but ):
>
> >>> Andrew Koenig & Bjarne Stroustrup
> >>> "The explicit constructor call greater<int>() will serve the same
> >>> purpose by creating an anonymous object:"
>
> >> Well, everyone makes an error now and then
>
> > The languages' creator, the first secretary of the committee and the
> > standard itself is in error about the terminology, yeah, right.
>
> >>>> A constructor is always implicitly invoked as part of object creation.
> >>> Not quite, e.g. ...
>
> >>> * *int x;
>
> >>> ... creates an object without calling a constructor, and so does (as I
> >>> recall, but don't flog me if the standard defines by way of a default
> >>> constructor) ...
>
> >> If every constructor call is done as part of object creation, that
> >> doesn't mean that every object creation involves a constructor call. I
> >> was rather talking about the former, not the latter. But I admit my last
> >> posting could be misinterpreted.
>
> >>> * *struct Foo { int x; };
>
> >>> * *int main()
> >>> * *{
> >>> * * * *Foo();
> >>> * *}
>
> >>> What you probably meant was that if a class has at least one declared
> >>> constructor, then, without using very low level features to circumvent
> >>> this guarantee, creating any instance of that class calls a constructor
> >>> of that class,
>
> >> No. What I meant is that it's just the other way round.
>
> > There is no "other way around": you can't have one without the other.
>
> >> You cannot
> >> circumvent it, since if the constructor hasn't been executed, it's not an
> >> object of that type yet.
>
> > This shows that you have some fundamental misunderstanding.
>
> > It's not clear what you misunderstand but I think you should make an
> > effort to find out.
>
> I guess it must be the same fundamental misunderstanding that people had
> when writing paragraph 3.8 of the C++ standard:
>

> — storage with the proper alignment and size for type T is obtained, and
> — if T is a class type with a non-trivial constructor (12.1), the
> constructor call has completed.


I don't know what the problem with that. There is no doubt that the
constructor is called. The issue is whether or not you believe that
the programmer has written code that calls it. Count me in the "you
can't call constructors" crowd. You can create objects, but the
implementation calls the constructors for you as necessary. Any
syntax you think you are writing that is a constructor call, is in
fact,
a cast or temporary object creation.

* Ron:
> On Jul 2, 3:51 pm, Rolf Magnus <ramag...@t-online.de> wrote:
>> Alf P. Steinbach wrote:
>>> * Rolf Magnus:
>>>> Alf P. Steinbach wrote:
>>>>> I guess it's time for the authority argument again (not thereby
>>>>> denigrating my own biggie authority, but ):
>>>>> Andrew Koenig & Bjarne Stroustrup
>>>>> "The explicit constructor call greater<int>() will serve the same
>>>>> purpose by creating an anonymous object:"
>>>> Well, everyone makes an error now and then
>>> The languages' creator, the first secretary of the committee and the
>>> standard itself is in error about the terminology, yeah, right.
>>>>>> A constructor is always implicitly invoked as part of object creation.
>>>>> Not quite, e.g. ...
>>>>> int x;
>>>>> ... creates an object without calling a constructor, and so does (as I
>>>>> recall, but don't flog me if the standard defines by way of a default
>>>>> constructor) ...
>>>> If every constructor call is done as part of object creation, that
>>>> doesn't mean that every object creation involves a constructor call. I
>>>> was rather talking about the former, not the latter. But I admit my last
>>>> posting could be misinterpreted.
>>>>> struct Foo { int x; };
>>>>> int main()
>>>>> {
>>>>> Foo();
>>>>> }
>>>>> What you probably meant was that if a class has at least one declared
>>>>> constructor, then, without using very low level features to circumvent
>>>>> this guarantee, creating any instance of that class calls a constructor
>>>>> of that class,
>>>> No. What I meant is that it's just the other way round.
>>> There is no "other way around": you can't have one without the other.
>>>> You cannot
>>>> circumvent it, since if the constructor hasn't been executed, it's not an
>>>> object of that type yet.
>>> This shows that you have some fundamental misunderstanding.
>>> It's not clear what you misunderstand but I think you should make an
>>> effort to find out.
>> I guess it must be the same fundamental misunderstanding that people had
>> when writing paragraph 3.8 of the C++ standard:
>>
>
>> — storage with the proper alignment and size for type T is obtained, and
>> — if T is a class type with a non-trivial constructor (12.1), the
>> constructor call has completed.
>
>
> I don't know what the problem with that. There is no doubt that the
> constructor is called. The issue is whether or not you believe that
> the programmer has written code that calls it.

Well, It's OK, fine by me, when someone adopts the convention that a directory
is only "empty" when it contains no entries whatsoever, not even "." and "..".

It is a valid technical way of looking at it, but with unusual meanings for both
of the terms "directory" and "empty".

It can probably even help the confused person who is unable to understand that a
directory is "empty" when it contains "." and ".." (and it marks that person as
seriously confused, so anything that helps is welcome).

If I have to communicate with such a person about directories and their removal,
say, which involves considerations of whether directories are "empty", then,
after failing to convince him or her to use or even understand the usual meaning
of "empty directory", I just find some way of communicating anyway, perhaps by
agreeing on some completely new terms, some person-specific abra cadabra.

However, that person teaching his or her terminology to newbies is a problem.


Cheers & hth.,

- Alf

On Jul 2, 10:06 pm, Ron <ron.nata...@gmail.com> wrote:
> On Jul 2, 3:51 pm, Rolf Magnus <ramag...@t-online.de> wrote:
> > Alf P. Steinbach wrote:

[...]
> > >> You cannot circumvent it, since if the constructor hasn't
> > >> been executed, it's not an object of that type yet.

> > > This shows that you have some fundamental misunderstanding.

> > > It's not clear what you misunderstand but I think you
> > > should make an effort to find out.

> > I guess it must be the same fundamental misunderstanding
> > that people had when writing paragraph 3.8 of the C++
> > standard:

> > — storage with the proper alignment and size for type T is obtained, and
> > — if T is a class type with a non-trivial constructor (12.1), the
> > constructor call has completed.

> I don't know what the problem with that. There is no doubt
> that the constructor is called. The issue is whether or not
> you believe that the programmer has written code that calls
> it.

Not even. I don't think anyone would argue that the programmer
doesn't write code which calls the constructor. The only real
issue is what is meant by "explicit" when speaking of an
"explicit constructor call". If "explicit" is meant to say: the
programmer has written an expression which intentionally and
expressedly calls the constructor, and does nothing else, I'm
sure that even Alf would agree that C++ doesn't have this.

As Alf has pointed out, of course, the same thing can be said
for calling a function, since you can't write an expression
which calls a function without also evaluating it's arguments.
And although I don't really agree with Alf here, I think he
certainly has at least a partial point: the address of the raw
memory in which the object is to be constructed is in a very
real sense a necessary argument to a constructor (if for no
other reason than the this pointer must be allocated), and any
necessary memory allocation can certainly be considered part of
evaluating that argument; there is a very real sense in which
something like "MyClass()" and "functionReturningMyClass()" are
similar, with the first calling the constructor, and the second
the function. In the end, we're not arguing about what actually
takes place in any given expression (I think Alf and Rolf agree
about that), but about how to best describe it. And we're not
helped by the fact that the standard describes it as a type
conversion, since that's a perfectly horrible way to talk about
it, given that there is nothing to convert. My preference is to
speak of "explicitly creating a temporary object", because I
think that most clearly expresses what is happening, and the
intent when I write such an expression. But Alf is certainly
not alone in calling it "explicitly calling a constructor". And
while I definitely prefer "explicitly creating an obejct",
"explicitly calling a constructor" is still better that
"explicit type conversion (functional notation)". (IMHO, of
course).

FWIW: the problem with Alf's point of view, IMHO, is that when
people ask about explicitly calling the constructor, they're
usually asking about something similar to what Java calls
"explicit constructor invocations". In C++, this would be
citing the base class in the initialization list for base
classes, but the current version of C++ doesn't have any
equivalent for the "alternate constructor invocation" of Java.
(In the next version of the standard, it will be possible for a
constructor to delegate to another constructor of the object in
the initialization list.) I have no problems with Alf using
"explicitly calling the constructor" as he does, any more than I
have problems with Stroustrup doing it (and Alf's usage does
correspond to Stroustrup's). On the other hand, when someone
asks about how to explicitly call the constructor, and they are
obviously using the phrase as it is used in Java, then the
correct answer is "you can't explicitly call the constructor in
C++". Because the context has defined "explicitly call the
constructor" in a way different from that used by Alf (or
Stroustrup). And in the way the context has defined "explicitly
call the constructor", it doesn't exist in (current) C++.

> Count me in the "you can't call constructors" crowd.
> You can create objects, but the implementation calls the
> constructors for you as necessary. Any syntax you think you
> are writing that is a constructor call, is in fact, a cast or
> temporary object creation.

The problem, as I'm sure Alf would point out, is that the
standard doesn't define a syntax "temporary object creation",
any more than it defines a syntax "explicit constructor call".
And the people who start these threads aren't asking how to do
an "explicit type conversion", since they don't have anything to
convert.

All things considered: if I could find the time, I'd write up a
proposal to change the name of section §5.2.3 to "Explicit
creation of a temporary object". (It's not necessarily as
simple as it sounds. Remember that given:
struct A {} ;
struct B { operator A() ; } ;
, the expression "A( someB )" invokes B:perator A(). And not
directly the constructor of A. And that with:
typedef A* APtr ;
as well, "APtr( ptrToB )" is a reinterpret_cast.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jun 29, 9:55*pm, Prasoon <prasoonthegr...@gmail.com> wrote:
> Can constructors be explicitly called ...

IMHO the answer depends on the definition of 'explicitly called', but
if I am guessing right what you meant by it then the answer is 'no'

Constructors (according to the Standard, Chapter 12) are 'special
member functions' and don't have names. It is my understanding that
you can't 'explicitly' or 'directly' call something that doesn't have
a name, because it's by it's name that you call it.

Alf P. Steinbach wrote:

> * Rolf Magnus:
>> Alf P. Steinbach wrote:
>>
>>> struct Foo { int x; };
>>>
>>> int main()
>>> {
>>> Foo();
>>> }
>>>
>>> What you probably meant was that if a class has at least one
>>> declared constructor, then, without using very low level features to
>>> circumvent this guarantee, creating any instance of that class calls
>>> a constructor of that class,
>>
>> No. What I meant is that it's just the other way round.
>
> There is no "other way around": you can't have one without the other.

As far as I can see, you both are using different phrases to say the
same thing: If a type has a (non-trivial) constructor, creating an
object implies that a constructor gets invoked, and equivalently if a
constructor has been invoked, an object is being created.

>
>> You cannot
>> circumvent it, since if the constructor hasn't been executed, it's
>> not an object of that type yet.
>
> This shows that you have some fundamental misunderstanding.

I don't see a misunderstanding here.
Can you show how to create an object of the non-POD type std::string
without invoking one of its constructors?

>
> It's not clear what you misunderstand but I think you should make an
> effort to find out.
>
>
> Cheers & hth.,
>
> - Alf
>
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

* Bart van Ingen Schenau:
> Alf P. Steinbach wrote:
>
>> * Rolf Magnus:
>>> Alf P. Steinbach wrote:
>>>
>>>> struct Foo { int x; };
>>>>
>>>> int main()
>>>> {
>>>> Foo();
>>>> }
>>>>
>>>> What you probably meant was that if a class has at least one
>>>> declared constructor, then, without using very low level features to
>>>> circumvent this guarantee, creating any instance of that class calls
>>>> a constructor of that class,
>>> No. What I meant is that it's just the other way round.
>> There is no "other way around": you can't have one without the other.
>
> As far as I can see, you both are using different phrases to say the
> same thing: If a type has a (non-trivial) constructor, creating an
> object implies that a constructor gets invoked, and equivalently if a
> constructor has been invoked, an object is being created.
>
>>> You cannot
>>> circumvent it, since if the constructor hasn't been executed, it's
>>> not an object of that type yet.
>> This shows that you have some fundamental misunderstanding.
>
> I don't see a misunderstanding here.

That could possibly be because you're jumping into some debate and have no idea
of the context.


> Can you show how to create an object of the non-POD type std::string
> without invoking one of its constructors?

First, I don't think that this has anything to do with Rolf Magnus' mixup of
levels or context or whatever his very persistent confusion is or was about.

And second, since the question is practically meaningless (see below), it may be
that you have misunderstood something, different from Rolf Magnus though.

But, if you're referring to the low-level features I mentioned, the validity of
any solution depends on the particular implementation of std::string. Such code,
reproducing a memory layout, is not portable, and is "very low-level", and since
you're asking about std::string, for which such techniques would be wholly
inappropriate no matter the context (this is why the question is practically
meaningless), my advice is to not do it, and to not even think about it.

On the other hand, in contrast to std::string and a practitioner who doesn't
know that std::string isn't relevant, it can be trivial and useful for someone
who does have the requisite understanding and who controls the class.

E.g. such techniques are used in Microsoft's libraries (not sure if they do it
for binary serialization, but e.g. downcasting for access control is, as I
recall, used in ATL).


Cheers & hth.,

- Alf

Alf P. Steinbach wrote:

> * Bart van Ingen Schenau:
>
>> Can you show how to create an object of the non-POD type std::string
>> without invoking one of its constructors?
>
> First, I don't think that this has anything to do with Rolf Magnus'
> mixup of levels or context or whatever his very persistent confusion
> is or was about.

That is possible, but you seem to be rather quick in calling people
confused, when they seem (to me) to have the same understanding as you
but phrase it differently.

>
> And second, since the question is practically meaningless (see below),
> it may be that you have misunderstood something, different from Rolf
> Magnus though.

I don't think I have any misunderstanding, because you gave exactly the
answer I was expecting: it can not be done in portable code and should
not be done anyway without very special reasons.
And it probably relies on a particular form of UB.

>
> Cheers & hth.,
>
> - Alf

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/