Private constructor

[Alf P. Steinbach]

And if you would bother reading Chapter 12 about
special member functions, you will find almost word for word the description
I gave you about the constructor NOT HAVING A NAME.

The standard uses the word "call" about calling a constructor.

 

[Ron Natalie]

The standard uses the word "call" about calling a constructor.

It doesn't say that T() is a call of a constructor nor does it say anywhere
that
a program can call the constructor directly. It specifically states
otherwise.

You were the one who started this inane subthread by inserting the blatantly
false statement in response to my attempt to help another user. Grow up.

 

[Alf P. Steinbach]

It doesn't say that T() is a call of a constructor

See e.g. §12.1/5: "A default constructor for a class X is a constructor
of class X that can be called without an argument".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Also many other paragraphs that concern constructor _calls_.

nor does it say anywhere that
a program can call the constructor directly. It specifically states
otherwise.

If you think so, submit a defect report.

What you cannot do, however, is to call a constructor without
constructing an object (or at least, attempting to do so).

On the third hand, you can specify the storage in which to
construct the object.

You were the one who started this inane subthread by inserting the blatantly
false statement in response to my attempt to help another user. Grow up.

Ron, Ron, it's almost Christmas, and this is only _terminology_, for
Crissake!

If that's what's needed to please you I'll renounce the standard once
and for all: it's false, utterly false, and in contrast to what §12.1/5
falsely asserts, you cannot _call_ a default constructor (or any
constructor, for that matter), with or without an argument. There! OK?

PS: I'm leaving for my Christmas Holiday in a few hours, so I may not be
able to reply to any response from you. But hopefully the standard is
good enough? If not, whoa, we'll have to fix it! ;-)

Happy Christmas, and Merry New Year to you, and all other participants
in this group!

Cheers!

 

[Ron Natalie]

See e.g. §12.1/5: "A default constructor for a class X is a constructor
of class X that can be called without an argument".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes but it doesn't say anything about the programmer being able to call it.

You are ignoring the rest of 12.1.

Also many other paragraphs that concern constructor _calls_.




If you think so, submit a defect report.

The only defect is your insistance on reading things into the standard
which are not there.

What you cannot do, however, is to call a constructor without
constructing an object (or at least, attempting to do so).

No, what you can not do is call the constructor. You can only create
objects, and in that case the implementation invokes the constructors
at the appropriate time.

Ron, Ron, it's almost Christmas, and this is only _terminology_, for
Crissake!

It is not just terminology. The original poster was quite confused (and
further confused by your misinformation). The syntax presented is not
a call of a constructor, it is the creation of the object. If it were a
member function call to the constructor, it would be invoked on the
"this" object, which it is not. This is a common confusion newbies
make. There is no syntax to directly call constructors.

If that's what's needed to please you I'll renounce the standard once
and for all: it's false, utterly false, and in contrast to what §12.1/5
falsely asserts, you cannot _call_ a default constructor (or any
constructor, for that matter), with or without an argument. There! OK?

Correct, you can not call constructors, NOTHING THE STANDARD SAYS
IS IN CONFLICT WITH THIS.

You seem to refuse to understand the difference between a program calling
a constuctor and it being called by the implementation.

 

[Andy]

I have no clue what you are talking about. Constructors are non-static
member functions. You can't call them. They do have this pointers.

The constructor can indeed not be called. Of course the CRT Startup
code calls the constructor on behalf of the instantiator.

Constructors do have this pointers. Got that corrected. "This" can be
accessed inside the constructor body, not the initializer list ...
which is absolutely logical. In the initializer list, the object is
still to be completely constructed.

You're confusing access with instantiation. A static member function
has access to the private members of other objects of the same class
just like non-static members of one object can access private
members of other instances of the class.

Can static members access any non-static data members of an object of
a class? Don't think so. They can of course call non-static member
functions.

//// try compiling this code
//// It does not compile
#include <iostream>

class Cabc
{
private:
int abc;
int d;

public:
Cabc(int a) : abc(a)
{
std::cout<<this->abc<<std::endl;
}

static int getValue()
{
return abc;
}
};

int main()
{
Cabc(19);
return 0;
}

/////////////////////////////////////////////////////////////////////////

Cheers,
Andy

 

[Andy]

A static member function

has access to the private members of other objects of the same class
just like non-static members of one object can access private
members of other instances of the class.

I think the following is true:

1) Static member functions cannot access any non-static data members
of a class.
2) Static member functions cannot call any non-static member functions
of a class as a logical corollary to 1). Because these non-static
member functions themselves might be accessing non-static data
members.

Am I missing anything?

With constructors, this is different although they are non-static. The
static member function can instantiate an object of the class it
belongs to. This is what I found out.

 

[Rob Williscroft]

Andy wrote in

Can static members access any non-static data members of an object of
a class? Don't think so. They can of course call non-static member
functions.

//// try compiling this code
//// It does not compile
#include <iostream>

class Cabc
{
private:
int abc;
int d;

public:
Cabc(int a) : abc(a)
{
std::cout<<this->abc<<std::endl;
}

static int getValue( Cabc const &c )
{
return c.abc;
}

};

int main()
{

Cabc c(19);
std::cout << Cabc::getValue( c ) << std::endl;

}

The problem wasn't member access, it was the lack of an object.

Rob.

 

[Andy]

You said that already. I don't follow. One more time: Where should I
look for an explanation?

I feel sorry I started a thread which gave rise to this (otherwise
increasingly colourful) sub-thread.

The constructor of an object _cannot_ be called by a code creating the
object. This might make for a good war on terminology ... but calling
a member function and calling a constructor are not the same thing.
The constructor of all objects will be invoked by the C++ Runtime
startup code.

For one, you cannot keep "calling" the constructor of an instance
because it makes no sense. You can do so with member functions (I know
that was not needed to be mentioned).

Also please refer to Scott Meyers'** discussion on overloading
"operator new" and "operator delete". He mentions that you cannot
overload the "new operator" which is meant to construct the object ...
bring it to life. He distinguishes it from the "operator new" (a
convenient terminology) which can be overloaded to take care of your
memory allocation scheme.

----
** Don't remember which of the two books: Effective or More Effective
C++.

Cheers,
Andy

 

[Ron Natalie]

Can static members access any non-static data members of an object of
a class? Don't think so. They can of course call non-static member
functions.

//// try compiling this code
//// It does not compile

It has different problems. You're confusing non-static and static with
public versus private.

Consider this:

class A {
int i; // private

public:
A(int i) : i(i) { }
static int StaticGetA(A& ar) { return ar.i; } // legal!
};

int NonMemberGetA(A& ar) { return ar.i; } // not legal, doesn't compile

A a(5);

cout << a.i; // Illegal, doesn't compile.
cout << StaticGetA(a); // returns 5

See the StaticGetA has access to A::i where none of the external fucntions do.

 

[Ron Natalie]

1) Static member functions cannot access any non-static data members
of a class.

They can if they access it through a pointer or a reference. You are right, they
can't without as they have no "this" object to get the member from. However, given
an object pointer they can get access to the private non-static members on the object.

With constructors, this is different although they are non-static. The
static member function can instantiate an object of the class it
belongs to. This is what I found out.

It's not really that different. The static member can create an object of the
type because the constructor is ACCESSIBLE (i.e., the private/protected/public
rules).

You see there are two different principles here:

static versus non-static (I don't know what to call this distinction in general).
Access control (which is the public/private/static protected rules).

 

[Jeff Schwab]

Constructors do have this pointers. Got that corrected. "This" can be
accessed inside the constructor body, not the initializer list ...
which is absolutely logical. In the initializer list, the object is
still to be completely constructed.

The same may be said of the entire constructor, if the class has virtual
methods.

Thanks for helping explain why constructors cannot be called.

-Jeff

 

[Mike Hewson]

<snip>

So, *evidently* it is the difference between implicit and explicit uses of
the constructor ie. can I name it ( no choice really ) and call it by that
name in the source code outside it's definition in the class ( no ), or will
the implementation of the abstract/virtual machine invoke the constructor's
code ( well, 'as if' anyway ) upon any given instantiation ( including
temporaries, classes composing classes etc ... ) ?

Cheers

 

[Ron Natalie]

So, *evidently* it is the difference between implicit and explicit uses of
the constructor ie. can I name it ( no choice really ) and call it by that
name in the source code outside it's definition in the class ( no )

You can't name it. The standard says they don't have names just a
convention for declaring/defining them. This is important as it resolves
an ambiguity between whether it is a type name or the consturctor
name (by eliminating the latter).

Frankly, it's C++'s terseness and eschewing of additional reserved
words.

Since constructors NEVER participate in name resolution, there is
NO way to reference it so it can be called. You always get a class
name when you try so it always thinks that you are doing a cast.

or will
the implementation of the abstract/virtual machine invoke the constructor's
code ( well, 'as if' anyway ) upon any given instantiation ( including
temporaries, classes composing classes etc ... ) ?

That is true. Any time you create an object either by invocation of new,
defining a variable of that type, creation of a temporary, function arguments,
subobjects of a larger object, etc... the compiler invokes the defined initialization
on the object and all of its subobjects. For (most) classes this means invoking the constructor.
So it is more than just one constructor being run in most cases.

 

[Mike Hewson]

You can't name it. The standard says they don't have names just a
convention for declaring/defining them. This is important as it resolves
an ambiguity between whether it is a type name or the consturctor
name (by eliminating the latter). Frankly, it's C++'s terseness and eschewing
of additional reserved words. Since constructors NEVER participate in name
resolution, there is NO way to reference it so it can be called. You always get
a class name when you try so it always thinks that you are doing a cast.

Bingo! That makes perfect sense, 'of course' .... I say in retrospect.

Thanks.

Cheers

 

[Ron Natalie]

The same may be said of the entire constructor, if the class has virtual
methods.

Virtualness is hotwired to the type of the constructor's class while the constructor
body is running. It's no more or less of a problem with virtual methods than
anything else. It's always incumbent on code executing during construction
to be aware of what has and has not been initialized so far.

The only issue is that passing "this" outside the constructor context is a warning
sign that someone ignorant of the fact that the object is still under construction
may do something inappropriate. The compiler is just warning you to look
further.