By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,238 Members | 1,837 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,238 IT Pros & Developers. It's quick & easy.

Private constructor

P: n/a
1) Is there any use of defining a class with a single constructor
declared in private scope? I am not asking a about private copy
constructors to always force pass/return by reference.

2) Is this in any way used to create singletons. Can someone say how?

Cheers,
Andy
Jul 22 '05 #1
Share this Question
Share on Google+
34 Replies


P: n/a
Andy wrote:
1) Is there any use of defining a class with a single constructor
declared in private scope? I am not asking a about private copy
constructors to always force pass/return by reference.

2) Is this in any way used to create singletons. Can someone say how?


If you want to create singletons, you have to declare all your constructors
(and operator=, too) as private.

Then you create a public function that checks if singleton was created
(through some static bool member) and then calls (private) constructor.

Then (if check passed) your function returns refernece (or pointer) on your
singleton and set true flag to static member -- singleton was created.

--
mP

http://pivoluska.matfyz.cz/
Jul 22 '05 #2

P: n/a

"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
1) Is there any use of defining a class with a single constructor
declared in private scope? I am not asking a about private copy
constructors to always force pass/return by reference.

2) Is this in any way used to create singletons. Can someone say how?


The point of making a constructor private is usually to NOT allow anyone to
use it. (Imagine that instead of the "private" keyword it was
"inaccessible".) That allows you to have a class available for use, but not
for anyone to just create one with a plain constructor. Normally you'd
provide some other means for creating one, where you can control whether it
gets created or not. For example, you could have a static function called
"create", and that would have to be called to get a new object. In the
create function, you can first check to see if you've created one before, by
keeping a flag or counter. If so, you don't create one. If not, you create
one and return one. That way no more than one can ever exist.
Jul 22 '05 #3

P: n/a
"jeffc" <no****@nowhere.com> wrote in message news:<3f********@news1.prserv.net>...
"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
1) Is there any use of defining a class with a single constructor
declared in private scope? I am not asking a about private copy
constructors to always force pass/return by reference.

2) Is this in any way used to create singletons. Can someone say how?


The point of making a constructor private is usually to NOT allow anyone to
use it. (Imagine that instead of the "private" keyword it was
"inaccessible".) That allows you to have a class available for use, but not
for anyone to just create one with a plain constructor. Normally you'd
provide some other means for creating one, where you can control whether it
gets created or not. For example, you could have a static function called
"create", and that would have to be called to get a new object. In the
create function, you can first check to see if you've created one before, by
keeping a flag or counter. If so, you don't create one. If not, you create
one and return one. That way no more than one can ever exist.


Just one question - even the static creator function needs to create
an instance of the class on the heap or stack. Without a constructor
how can that be made possible. Or is it that everything is static and
the singleton is stateless? So we never need an instance. I think I am
missing something.
Jul 22 '05 #4

P: n/a
Andy wrote:

"jeffc" <no****@nowhere.com> wrote in message news:<3f********@news1.prserv.net>...
"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
1) Is there any use of defining a class with a single constructor
declared in private scope? I am not asking a about private copy
constructors to always force pass/return by reference.

2) Is this in any way used to create singletons. Can someone say how?


The point of making a constructor private is usually to NOT allow anyone to
use it. (Imagine that instead of the "private" keyword it was
"inaccessible".) That allows you to have a class available for use, but not
for anyone to just create one with a plain constructor. Normally you'd
provide some other means for creating one, where you can control whether it
gets created or not. For example, you could have a static function called
"create", and that would have to be called to get a new object. In the
create function, you can first check to see if you've created one before, by
keeping a flag or counter. If so, you don't create one. If not, you create
one and return one. That way no more than one can ever exist.


Just one question - even the static creator function needs to create
an instance of the class on the heap or stack. Without a constructor
how can that be made possible. Or is it that everything is static and
the singleton is stateless? So we never need an instance. I think I am
missing something.


Detail!
He didn't say that the class dosn't have a constructor (which by the
way is impossible). He said that the constructor is private! And
like an other private class member it can be used from a class member
function only. Since the static creator function is a member function,
it can use the constructor.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #5

P: n/a
Karl Heinz Buchegger wrote:

Andy wrote:

"jeffc" <no****@nowhere.com> wrote in message news:<3f********@news1.prserv.net>...
"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
> 1) Is there any use of defining a class with a single constructor
> declared in private scope? I am not asking a about private copy
> constructors to always force pass/return by reference.
>
> 2) Is this in any way used to create singletons. Can someone say how?

The point of making a constructor private is usually to NOT allow anyone to
use it. (Imagine that instead of the "private" keyword it was
"inaccessible".) That allows you to have a class available for use, but not
for anyone to just create one with a plain constructor. Normally you'd
provide some other means for creating one, where you can control whether it
gets created or not. For example, you could have a static function called
"create", and that would have to be called to get a new object. In the
create function, you can first check to see if you've created one before, by
keeping a flag or counter. If so, you don't create one. If not, you create
one and return one. That way no more than one can ever exist.
Just one question - even the static creator function needs to create
an instance of the class on the heap or stack. Without a constructor
how can that be made possible. Or is it that everything is static and
the singleton is stateless? So we never need an instance. I think I am
missing something.


Detail!
He didn't say that the class dosn't have a constructor (which by the
way is impossible).


Sorry. POD's indeed don't have a constructor.
He said that the constructor is private! And
like an other private class member it can be used from a class member
function only. Since the static creator function is a member function,
it can use the constructor.


--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #6

P: n/a

"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...

The point of making a constructor private is usually to NOT allow anyone to use it. (Imagine that instead of the "private" keyword it was
"inaccessible".) ....


Just one question - even the static creator function needs to create
an instance of the class on the heap or stack. Without a constructor
how can that be made possible. Or is it that everything is static and
the singleton is stateless? So we never need an instance. I think I am
missing something.


What I wrote was a little misleading. When I said "NOT allow anyone to use
it", I didn't mean literally anyone. I mean anyone *else* outside the
class. The class itself can access its own private constructor. See Karl's
answer. e.g.

class A
{
private:
A() {}
public:
static A* createAnA();
};

A* A::createAnA()
{
return new A;
}

int main()
{
A* pA = A::createAnA();
}
Jul 22 '05 #7

P: n/a
"jeffc" <no****@nowhere.com> wrote in message news:<3f********@news1.prserv.net>...
"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...

The point of making a constructor private is usually to NOT allow anyone to use it. (Imagine that instead of the "private" keyword it was
"inaccessible".) ....
Just one question - even the static creator function needs to create
an instance of the class on the heap or stack. Without a constructor
how can that be made possible. Or is it that everything is static and
the singleton is stateless? So we never need an instance. I think I am
missing something.


What I wrote was a little misleading. When I said "NOT allow anyone to use
it", I didn't mean literally anyone. I mean anyone *else* outside the
class. The class itself can access its own private constructor. See Karl's
answer. e.g.


I am sorry I made a stupid mistake. I was under the impression that
just as static functions cannot access instance data members of a
class, they also cannot call non-static member functions. Of course
member functions are not per instance even if they are made to look
that way. Constructor being a special kind of such a function should
be accessible from static member functions.

class A
{
private:
A() {}
public:
static A* createAnA();
};

A* A::createAnA()
{
return new A;
}

int main()
{
A* pA = A::createAnA();
}


I was just wondering, though this is purely a design issue, what
happens to the pointer that we get from the CreateAnA creator
function. The client code will need to explicitly call "delete" on
this pointer -- not a good thing. We would perhaps need a manager
class in between which takes care of calling delete in its destructor
.... or may be something like an auto_ptr type smart and cocky pointer
pretenders.

The singleton
--------------

The code snippet that you gave does not serve a singleton though. How
do we do that. I tried doing it this way:

----->

#include <iostream>

class CPrivCons
{
private:
CPrivCons(int n) : m_nInt(n)
{
s_cRefCnt=0;
s_This = NULL;
}

int m_nInt;
static int s_cRefCnt;
static CPrivCons *s_This;

public:
static CPrivCons& CreateObj(int n)
{
if(s_cRefCnt==0){
std::cout<<"NewInstanceCreated"<<std::endl;

s_This = new CPrivCons(n);
}

s_cRefCnt++;

return *s_This;
}

static void DestroyObj()
{
if(--s_cRefCnt == 0){
std::cout<<"ObjectDestroyed"<<std::endl;

delete s_This;
}
}

int get_IntVal()
{
int n = m_nInt;

return n;
}

void set_IntVal(int n)
{
m_nInt = n;
}
};

int CPrivCons::s_cRefCnt = 0;
CPrivCons *CPrivCons::s_This = NULL;
int main()
{
CPrivCons& p = CPrivCons::CreateObj(10);

CPrivCons& p1 = CPrivCons::CreateObj(12);

std::cout<<p.get_IntVal()<<std::endl;

std::cout<<p1.get_IntVal()<<std::endl;;

p1.set_IntVal(19);

std::cout<<p.get_IntVal()<<std::endl;

CPrivCons::DestroyObj();
CPrivCons::DestroyObj();

return 0;
}
<-----
The above code can of course not be used in a multi-threaded
situation. Besides, I feel there should be a separate manager
interface interposed between the singleton and the client.

Cheers,
Andy
Jul 22 '05 #8

P: n/a
<
I am sorry I made a stupid mistake. I was under the impression that
just as static functions cannot access instance data members of a
class, they also cannot call non-static member functions. Of course
member functions are not per instance even if they are made to look
that way. Constructor being a special kind of such a function should
be accessible from static member functions.


That was stupider on second thoughts. A constructor does not get a
this pointer secretly. So it's not a special kind of the others ... it
is special and different from the rest. Nevertheless, I think I am
right in assuming that neither the member functions nor the
constructor or destructor constitute the state of an instantiated
object - therefore static member functions should be able to access
them.
Jul 22 '05 #9

P: n/a

"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
<
I am sorry I made a stupid mistake. I was under the impression that
just as static functions cannot access instance data members of a
class, they also cannot call non-static member functions. Of course
member functions are not per instance even if they are made to look
that way. Constructor being a special kind of such a function should
be accessible from static member functions.


That was stupider on second thoughts. A constructor does not get a
this pointer secretly. So it's not a special kind of the others ... it
is special and different from the rest. Nevertheless, I think I am
right in assuming that neither the member functions nor the
constructor or destructor constitute the state of an instantiated
object - therefore static member functions should be able to access
them


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.
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.
Jul 22 '05 #10

P: n/a
Ron Natalie wrote:
"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
<
I am sorry I made a stupid mistake. I was under the impression that
just as static functions cannot access instance data members of a
class, they also cannot call non-static member functions. Of course
member functions are not per instance even if they are made to look
that way. Constructor being a special kind of such a function should
be accessible from static member functions.

That was stupider on second thoughts. A constructor does not get a
this pointer secretly. So it's not a special kind of the others ... it
is special and different from the rest. Nevertheless, I think I am
right in assuming that neither the member functions nor the
constructor or destructor constitute the state of an instantiated
object - therefore static member functions should be able to access
them

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


<nit> Yes, you can. Allocators do it all the time. </nit>
They do have this pointers.
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.


Right on.

Jul 22 '05 #11

P: n/a

"Jeff Schwab" <je******@comcast.net> wrote in message
news:Lc********************@comcast.com...

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


<nit> Yes, you can. Allocators do it all the time. </nit>


Sorry, totally wrong. They do not participate in name resolution, they
can't
be called. Allocators don't do it.
Jul 22 '05 #12

P: n/a
On Sat, 20 Dec 2003 10:59:24 -0500, "Ron Natalie" <ro*@sensor.com> wrote:

"Jeff Schwab" <je******@comcast.net> wrote in message
news:Lc********************@comcast.com...
>
> I have no clue what you are talking about. Constructors are non-static
> member functions. You can't call them.


<nit> Yes, you can. Allocators do it all the time. </nit>


Sorry, totally wrong. They do not participate in name resolution, they
can't
be called. Allocators don't do it.


Perhaps it's just a question of terminology.

I find it more useful to use the word "call" about any statement that
causes a function to be executed, with control returning to the next
statement.

T();

is a simple example of executing the default constructor of type T,
here on a temporary object.

new(place) T();

is a simple example of executing the default constructor of type T on
a given area of memory 'place'.

In pure C++ terminology one might elect to call the latter a placement
new, and have no problems with multiple meanings of words.

But how would you then describe it to, say, an Ada programmer?

Jul 22 '05 #13

P: n/a
Ron Natalie wrote:
"Jeff Schwab" <je******@comcast.net> wrote in message
news:Lc********************@comcast.com...

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


<nit> Yes, you can. Allocators do it all the time. </nit>

Sorry, totally wrong. They do not participate in name resolution, they
can't be called. Allocators don't do it.


I don't know what you mean. Is there a technicality that makes my use
of "call" incorrect? Where should I look for an explanation?

Thanks,
Jeff

Jul 22 '05 #14

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...
Perhaps it's just a question of terminology.
Perhaps, but it appears yours is not accureate.
I find it more useful to use the word "call" about any statement that
causes a function to be executed, with control returning to the next
statement.

T();
If T is a type name, this is not a fucntion call. It is only a function
call, when
T has function type.

When T is a type name, you have just created a default rvalue of that type.
is a simple example of executing the default constructor of type T,
here on a temporary object.
No, it creates a temporary object. The constructor is invoked when ever an
object
that has one is created
new(place) T();

is a simple example of executing the default constructor of type T on
a given area of memory 'place'.
No, it creates an object using the placement new syntax, which means that
the
placement allocation function is called and then the constructor is invoked
on that.

In neither case are you calling the constructor, you are causing objects to
be created
and the constructor is called by the environment as a side effect.
In pure C++ terminology one might elect to call the latter a placement
new, and have no problems with multiple meanings of words.
The meaning of the words is quite well defined by the standard. The
constructor
doesn't have a name. It does not participate in name resolution. You can't
call
it, you can't get a pointer to it, you can't do anything with it other than
define it
and let the the implementation call it at the appropriate times.
But how would you then describe it to, say, an Ada programmer?


Like I just did.

Jul 22 '05 #15

P: n/a

"Jeff Schwab" <je******@comcast.net> wrote in message
news:j9********************@comcast.com...
Ron Natalie wrote:
"Jeff Schwab" <je******@comcast.net> wrote in message
news:Lc********************@comcast.com...

I have no clue what you are talking about. Constructors are non-staticmember functions. You can't call them.

<nit> Yes, you can. Allocators do it all the time. </nit>

Sorry, totally wrong. They do not participate in name resolution, they
can't be called. Allocators don't do it.


I don't know what you mean. Is there a technicality that makes my use
of "call" incorrect? Where should I look for an explanation?

Yes, there is no way to call a constructor. They don't have names, the do
not
participate in name resolution. You can NOT call them. They are called
by
the implementation as a side effect of creating an object.
Jul 22 '05 #16

P: n/a
On Sat, 20 Dec 2003 15:09:45 -0500, "Ron Natalie" <ro*@sensor.com> wrote:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...
Perhaps it's just a question of terminology.
Perhaps, but it appears yours is not accureate.

I find it more useful to use the word "call" about any statement that
causes a function to be executed, with control returning to the next
statement.

T();


If T is a type name, this is not a fucntion call. It is only a function
call, when T has function type.


If you don't think a constructor is a member function, then consult the
standard. Chapter 12 is about special member functions. Do you think
something can be a member function and not a function?
When T is a type name, you have just created a default rvalue of that type.
That's what I wrote, yes. In this you are correct.
is a simple example of executing the default constructor of type T,
here on a temporary object.


No, it creates a temporary object.


Where did you get the idea that there is any conflict between
calling a constructor and creating an object?

The main purpose of a constructor is exactly to _strongly couple_
those two actions.
The constructor is invoked when ever an object that has one is created
What is, in your opinion, the difference between "invoked", "executed"
and "called"?


new(place) T();

is a simple example of executing the default constructor of type T on
a given area of memory 'place'.


No,


Oh yes.

it creates an object using the placement new syntax,
Yes, it does.

which means that the placement allocation function is called
There isn't necessarily a placement allocation function.
and then the constructor is invoked on that.
Is called, yes. ;-)


In neither case are you calling the constructor,
Oh yes I am.

you are causing objects to be created
Yes I am.

and the constructor is called by the environment as a side effect.
That is not meaningful in any way.
In pure C++ terminology one might elect to call the latter a placement
new, and have no problems with multiple meanings of words.


The meaning of the words is quite well defined by the standard. The
constructor doesn't have a name. It does not participate in name
resolution. You can't call it,


Oh yes I can, as demonstrated.

you can't get a pointer to it, you can't do anything with it
other than define it and let the the implementation call it at
the appropriate times.


Oh yes I can, and it's very simple: placement new is in the language
exactly for that purpose.
But how would you then describe it to, say, an Ada programmer?


Like I just did.


You haven't.

Jul 22 '05 #17

P: n/a
Ron Natalie wrote:
"Jeff Schwab" <je******@comcast.net> wrote in message
news:j9********************@comcast.com...
Ron Natalie wrote:
"Jeff Schwab" <je******@comcast.net> wrote in message
news:Lc********************@comcast.com...

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

<nit> Yes, you can. Allocators do it all the time. </nit>
Sorry, totally wrong. They do not participate in name resolution, they
can't be called. Allocators don't do it.


I don't know what you mean. Is there a technicality that makes my use
of "call" incorrect? Where should I look for an explanation?


Yes, there is no way to call a constructor. They don't have names, the do
not
participate in name resolution. You can NOT call them. They are called
by
the implementation as a side effect of creating an object.


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

Jul 22 '05 #18

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...
On Sat, 20 Dec 2003 15:09:45 -0500, "Ron Natalie" <ro*@sensor.com> wrote:

If T is a type name, this is not a fucntion call. It is only a function
call, when T has function type.
If you don't think a constructor is a member function, then consult the
standard. Chapter 12 is about special member functions. Do you think
something can be a member function and not a function?


I never said the constructor wasn't a member function. I said if T in your
example was a TYPE NAME then it is not a function call. It's not the
syntax for a function call. 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.
Where did you get the idea that there is any conflict between

calling a constructor and creating an object?


What conflict. They are two different concepts. The constructor invocation
is part of the object creation, but you are not "calling" it with the syntax
you
gave. You need to look at the syntax for expressions.
TYPEID ( )
is an explicit type conversion (5.2.3 of the standard).
It is NOT a function call (5.2.2 of the standard),.
>The constructor is invoked when ever an object that has one is created
What is, in your opinion, the difference between "invoked", "executed">


It is called by the implemenation, not by the programmer. I specifically
said
that, but you consider to ignore it in your refusal to admit that you can't
understand
the first sentence of 12.1
which means that the placement allocation function is called
There isn't necessarily a placement allocation function.


Then the program is ill-formed. In order for the syntax you wrote
to work, you must define the placement allocation function (or #include
<new>
which does it for you).
In neither case are you calling the constructor,


Oh yes I am.

Please go back and read 5.2.2, 5.2.3, and 12.1.
you can't get a pointer to it, you can't do anything with it
other than define it and let the the implementation call it at
the appropriate times.


Oh yes I can, and it's very simple: placement new is in the language
exactly for that purpose.


??? How do you get a potiner to the constructor.

Jul 22 '05 #19

P: n/a

"Jeff Schwab" <je******@comcast.net> wrote in message
news:7o********************@comcast.com...
You said that already. I don't follow. One more time: Where should I
look for an explanation?

5.2.2 and 5.2.3 show the syntax for function calls versus type conversion.

Given the statement :
T();

If T is a type id, then the expression is a type conversion (5.2.3),
otherwise
it has to be function name (5.2.2) to be a function call.

12.1 in the very first sentence details that constructors do not have names
and can not be called.
Jul 22 '05 #20

P: n/a
On Sat, 20 Dec 2003 15:34:07 -0500, "Ron Natalie" <ro*@sensor.com> wrote:
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.

Jul 22 '05 #21

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...
On Sat, 20 Dec 2003 15:34:07 -0500, "Ron Natalie" <ro*@sensor.com> wrote:
And if you would bother reading Chapter 12 about
special member functions, you will find almost word for word the descriptionI gave you about the constructor NOT HAVING A NAME.


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.
Jul 22 '05 #22

P: n/a
On Sat, 20 Dec 2003 21:52:17 -0500, "Ron Natalie" <ro*@sensor.com> wrote:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...
On Sat, 20 Dec 2003 15:34:07 -0500, "Ron Natalie" <ro*@sensor.com> wrote:
>And if you would bother reading Chapter 12 about
>special member functions, you will find almost word for word thedescription >I gave you about the constructor NOT HAVING A NAME.
The standard uses the word "call" about calling a constructor.


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!

Jul 22 '05 #23

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...

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_.
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.


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.
Jul 22 '05 #24

P: n/a
"Ron Natalie" <ro*@sensor.com> wrote in message news:<3f***********************@news.newshosting.c om>...
"Andy" <ga***********@yahoo.com> wrote in message
news:96**************************@posting.google.c om...
<
I am sorry I made a stupid mistake. I was under the impression that
just as static functions cannot access instance data members of a
class, they also cannot call non-static member functions. Of course
member functions are not per instance even if they are made to look
that way. Constructor being a special kind of such a function should
be accessible from static member functions.

That was stupider on second thoughts. A constructor does not get a
this pointer secretly. So it's not a special kind of the others ... it
is special and different from the rest. Nevertheless, I think I am
right in assuming that neither the member functions nor the
constructor or destructor constitute the state of an instantiated
object - therefore static member functions should be able to access
them


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
Jul 22 '05 #25

P: n/a
> 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.
Jul 22 '05 #26

P: n/a
Andy wrote in news:96**************************@posting.google.c om:
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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #27

P: n/a
Jeff Schwab <je******@comcast.net> wrote in message news:<7o********************@comcast.com>...
Ron Natalie wrote:
"Jeff Schwab" <je******@comcast.net> wrote in message
news:j9********************@comcast.com...
Ron Natalie wrote:

"Jeff Schwab" <je******@comcast.net> wrote in message
news:Lc********************@comcast.com...

>>I have no clue what you are talking about. Constructors are


non-static
>>member functions. You can't call them.
>
><nit> Yes, you can. Allocators do it all the time. </nit>
Sorry, totally wrong. They do not participate in name resolution, they
can't be called. Allocators don't do it.

I don't know what you mean. Is there a technicality that makes my use
of "call" incorrect? Where should I look for an explanation?


Yes, there is no way to call a constructor. They don't have names, the do
not
participate in name resolution. You can NOT call them. They are called
by
the implementation as a side effect of creating an object.


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
Jul 22 '05 #28

P: n/a

"Andy" <ga***********@yahoo.com> wrote in message news:96**************************@posting.google.c om...
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


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.

Jul 22 '05 #29

P: n/a

"Andy" <ga***********@yahoo.com> wrote in message news:96**************************@posting.google.c om...
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).
Jul 22 '05 #30

P: n/a
Andy wrote:
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

Jul 22 '05 #31

P: n/a
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..
<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
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #32

P: n/a

"Mike Hewson" <he******@austarnet.com.au> wrote in message news:bs**********@austar-news.austar.net.au...
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.
Jul 22 '05 #33

P: n/a
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..
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
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal
Jul 22 '05 #34

P: n/a

"Jeff Schwab" <je******@comcast.net> wrote in message news:q-********************@comcast.com...
Andy wrote:
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.

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.

Jul 22 '05 #35

This discussion thread is closed

Replies have been disabled for this discussion.