constructor

[slurper]

i have the following

class sequence {
public:
sequence (const sequence& mysequence, const int newjob) {
job_sequence(mysequence.job_sequence)
job_sequence.push_back(newjob);
...
}

vector<int> job_sequence;
}

what i want is: if i have a sequence object, i want to be able to create a
new object that copies the job_sequence within it and adds another job to
the job_sequence vector.

question: i assume that when i call the constructor for sequence-class, that
first of all the constructor for "vector<int> job_sequence" will be called
( is this wrong? i assume that when i construct an object, the constructors
of all data-members will be called). next: is it ok to call
"job_sequence(mysequence.job_sequence)" in the constructor of sequence?
this last statement says that the constructor of vector<int> should be
called, right? can i call the constructor with the other vector as an
argument, even though the vector object was already constructed (with
default constructor, which i assume, is an empty vector?

tx

 

[Rolf Magnus]

i have the following

class sequence {
public:
sequence (const sequence& mysequence, const int newjob) {
job_sequence(mysequence.job_sequence)
job_sequence.push_back(newjob);
...
}

vector<int> job_sequence;
}
;

what i want is: if i have a sequence object, i want to be able to create a
new object that copies the job_sequence within it and adds another job to
the job_sequence vector.

question: i assume that when i call the constructor for sequence-class,
that first of all the constructor for "vector<int> job_sequence" will be
called ( is this wrong? i assume that when i construct an object, the
constructors of all data-members will be called).

That's correct.

next: is it ok to call "job_sequence(mysequence.job_sequence)" in the
constructor of sequence?
No.

this last statement says that the constructor of vector<int> should be
called, right?

No, it says that the class's operator() gets called. It doesn't have
anything to do with construction. Since AFAIK vector doesn't have
operator() defined, this should produce an error.

can i call the constructor with the other vector as an
argument, even though the vector object was already constructed (with
default constructor, which i assume, is an empty vector?

You cannot call constructors yourself. They are automatically called
whenever you create an object. What you can do is - for member variables -
specify which constructor gets called through the initializer list. If you
don't specify any, the default constructor gets called. So in your above
example, job_sequence will already be default-constructed before you enter
your sequence constructor.
Since you want the copy constructor instead, you'd have to write:

sequence (const sequence& mysequence, const int newjob)
: job_sequence(mysequence.job_sequence)
{
job_sequence.push_back(newjob);
...
}

 

[Matthias =?ISO-8859-1?Q?K=E4ppler?=]

i have the following

class sequence {
public:
sequence (const sequence& mysequence, const int newjob) {
job_sequence(mysequence.job_sequence)
job_sequence.push_back(newjob);
...
}

vector<int> job_sequence;
}

Firts of all:
Constructors are called when you -construct- an object, therefore the name
constructor. It's job is to set the object to an initial state.
Constructors are called implicitly, you shouldn't call them explicitly.
They shouldn't be misued as a means of changing the state of your object.
And maybe even can't, I'm not even sure if an explicit ctor call is legal
in standard C++.

Class names should always start with a capital letter by the way. And you're
missing a semicolon after the ctor call.

question: i assume that when i call the constructor for sequence-class,
that first of all the constructor for "vector<int> job_sequence" will be
called ( is this wrong? i assume that when i construct an object, the
constructors of all data-members will be called).

As far as I know, the order of constructor calls is undefined. Or at least
compiler dependent. But of course vector's ctor will be called before
sequence. Everything else wouldn't make sense.

next: is it ok to call
"job_sequence(mysequence.job_sequence)" in the constructor of sequence?

No, use the init list.

this last statement says that the constructor of vector<int> should be
called, right?

No, you're just saying that sequence has a vector of int. Of course, at some
time of construction, its ctor will be called.

Regards,
Matthias

 

[Alf P. Steinbach]

* Matthias:

As far as I know, the order of constructor calls is undefined. Or at least
compiler dependent.

No, it's generally well-defined.

For member variables it's the order of declaration.

I'm not quite sure with regard to multiple inheritance, but probably
even then (if or when it matters I'll look it up).

 

[Matthias =?ISO-8859-1?Q?K=E4ppler?=]

* Matthias:

No, it's generally well-defined.

For member variables it's the order of declaration.

I'm not quite sure with regard to multiple inheritance, but probably
even then (if or when it matters I'll look it up).

Oh, well, one less problem to worry about
You're right of course. This can be pretty confusing at times, because
regardless in which order we write objects in the init list, they will
always be constructed in the order of declaration.

Maybe I confused that with the construction of global objects? I think
that's when the order of construction is undefined (again, feel free to
correct me if I'm wrong).

Best regards,
Matthias

 

[Peter Koch Larsen]

Firts of all:
Constructors are called when you -construct- an object, therefore the name
constructor. It's job is to set the object to an initial state.
Constructors are called implicitly, you shouldn't call them explicitly.
They shouldn't be misued as a means of changing the state of your object.
And maybe even can't, I'm not even sure if an explicit ctor call is legal
in standard C++.

It is - but only rarely needed, and not something a novice should attempt to
do.

Class names should always start with a capital letter by the way. And
you're
missing a semicolon after the ctor call.

Well - there's no constructor call. And theres no need that class names
should start with a capital letter - imo, this is ugly.

[snip]

Regards,
Matthias

Kind regards
Peter

 

[Matthias =?ISO-8859-1?Q?K=E4ppler?=]

And theres no need that class names
should start with a capital letter - imo, this is ugly.

It's not enforced by the compiler, no. I know the standard library does not
follow this notation, but in all object oriented languages I have seen so
far it is common practice to note classes with the first letter being
uppercase (which would be Java, C# and Ada to name a few, and the major
part of C++ programmers do so as well).

 

[Howard]

It's not enforced by the compiler, no. I know the standard library does
not
follow this notation, but in all object oriented languages I have seen so
far it is common practice to note classes with the first letter being
uppercase (which would be Java, C# and Ada to name a few, and the major
part of C++ programmers do so as well).

Really? For example, the string class? Or the std template classes, such
as vector, list and map?

-Howard

 

[Matthias =?ISO-8859-1?Q?K=E4ppler?=]

Really? For example, the string class? Or the std template classes, such
as vector, list and map?

-Howard

Yep, I already said the standard template library does not follow this
convention. Only god knows why. And the developers. If this is good or bad
is in the eye of the beholder

Cheers,
Matthias

 

[Howard]

Yep, I already said the standard template library does not follow this
convention. Only god knows why. And the developers. If this is good or bad
is in the eye of the beholder

Ok...I must be blind! Not enough coffee. Or too much? Sorry. I'll slink
away now.
-Howard

 

[DaKoadMunky]

And maybe even can't, I'm not even sure if an explicit ctor call is legal

It is - but only rarely needed, and not something a novice should attempt to

do.

1: What is the syntax of an explicit ctor call?

2: Under what circumstance would such a call be appropriate?

3: Under what circumstances would it be safe to use such a call?

I have seen people attempt to use placement new within one constructor to
employ reuse of another constructor. Is that what you are referring to?

 

[Alf P. Steinbach]

* DaKoadMunky:

do.

1: What is the syntax of an explicit ctor call?

Several.

Terminology: "explicit" is something you specify directly, "implicit" is
something not directly specified (although I'm reasonably sure that's
not the meaning intended by Peter Koch Larsen here).

Adopting this usual set of meanings you have

string s; // Implicit constructor call.
string t( "x" ); // Explicit constructor call.

so "explicit" is not terribly useful, except perhaps to discuss the
syntactical problems with explicit calls of nullary constructors...

The syntax on the right side in

string u = string( "y" );

is technically a functional cast, IIRC; for the other forms please look
it up yourself (it's spread all over the standard, much work to find).

A more useful distinction is _source code_ level constructor call
(includes both examples above) versus _generated_ constructor call.

An explicit constructor call is always a source code level call, a
generated call is always an implicit one, and there are calls that are
source code level implicit calls, such as the first example above.

Every tree of constructor calls start with a source code level
constructor call, it's just a very common misconception that they're
never "explicit", or not "calls" (that last misconception is mentioned
in the FAQ, by ref to the definition of default constructor). The first
misconception probably stems from a passage in the standard where the
word "explicit" is used for disambiguation in a particular context, and
the last misconception probably stems from the desire to teach newbies
not to think of a constructor as a an ordinary callable member function,
but doing that by inventing a simple and incorrect explanation instead
of how things actually work.

What you can't do is to have a source code level constructor call on
pre-existing storage, except by using placement new (and except to the
degree that one might argue that a base class constructor argument
specification in an initializer list is such a call), and that's the
main purpose of a constructor: to strongly couple allocation with
initialization, at the source code level.

Generated constructor calls are, on the other hand, always made on
pre-existing storage.

Every successful source code level constructor call results in at least
one generated constructor call: to be precise, if your source code level
call is not placement new, but e.g. 'std::string s( "a" );', then it
results in an allocation (static, stack or heap) plus a tree of
generated constructor calls on that allocated storage.

Presumably Peter Koch Larsen is referring to placement new, just using
an unfortunate choice of terms.

2: Under what circumstance would such a call be appropriate?

Placement new is almost never appropriate, certainly not by novices, but
you can find it used in e.g. any implementation of std::vector --
instead of using placement new directly, use for example std::vector.

3: Under what circumstances would it be safe to use such a call?

I'm tempted to write "never", but: when you have full control... ;-)

I have seen people attempt to use placement new within one constructor to
employ reuse of another constructor.

That is extremely dangerous and totally unnecessary. Instead, factor
out the common initialization in a separate function. That's a FAQ.

 

[Victor Bazarov]

do.

1: What is the syntax of an explicit ctor call?

No such thing.

2: Under what circumstance would such a call be appropriate?

Had there been such a call possible, we might consider talking about
appropriateness. Since there is no such thing, why bother?

3: Under what circumstances would it be safe to use such a call?

Under what circumstances would it be safe to travel at the speed of
light?

I have seen people attempt to use placement new within one constructor to
employ reuse of another constructor. Is that what you are referring to?

Probably. It's still not "an explicit ctor call".

V

 

[Victor Bazarov]

[...]
Every tree of constructor calls start with a source code level
constructor call, it's just a very common misconception that they're
never "explicit", or not "calls" (that last misconception is mentioned
in the FAQ, by ref to the definition of default constructor). The first
misconception probably stems from a passage in the standard where the
word "explicit" is used for disambiguation in a particular context, and
the last misconception probably stems from the desire to teach newbies
not to think of a constructor as a an ordinary callable member function,
but doing that by inventing a simple and incorrect explanation instead
of how things actually work.

12.1/2 "Because the constructors do not have names, they are never found
during name lookup". Yes, you can _cause_ a constructor to be called.
You can never _call_ one, though. Where's the misconception? And how is
that "from the desire to teach newbies"? Is the Standard for newbies
only?

V

 

[Alf P. Steinbach]

* Victor Bazarov:

[...]
Every tree of constructor calls start with a source code level
constructor call, it's just a very common misconception that they're
never "explicit", or not "calls" (that last misconception is mentioned
in the FAQ, by ref to the definition of default constructor). The first
misconception probably stems from a passage in the standard where the
word "explicit" is used for disambiguation in a particular context, and
the last misconception probably stems from the desire to teach newbies
not to think of a constructor as a an ordinary callable member function,
but doing that by inventing a simple and incorrect explanation instead
of how things actually work.

12.1/2 "Because the constructors do not have names, they are never found
during name lookup". Yes, you can _cause_ a constructor to be called.

That's correct.

You can never _call_ one, though.

That's incorrect.

I seem to recall we have discussed that before, and so I simply direct
you again to the same place (definition of default constructor), "can be
called".

Where's the misconception?

In your mind... ;-)

 

[Victor Bazarov]

* Victor Bazarov:

[...]
Every tree of constructor calls start with a source code level
constructor call, it's just a very common misconception that they're
never "explicit", or not "calls" (that last misconception is mentioned
in the FAQ, by ref to the definition of default constructor). The
first
misconception probably stems from a passage in the standard where the
word "explicit" is used for disambiguation in a particular context, and
the last misconception probably stems from the desire to teach newbies
not to think of a constructor as a an ordinary callable member
function,
but doing that by inventing a simple and incorrect explanation instead
of how things actually work.

12.1/2 "Because the constructors do not have names, they are never found
during name lookup". Yes, you can _cause_ a constructor to be called.

That's correct.

You can never _call_ one, though.

That's incorrect.

I seem to recall we have discussed that before, and so I simply direct
you again to the same place (definition of default constructor), "can be
called".

Where's the misconception?

In your mind... ;-)

Do we always get hung up on the definition of "be"?

Can it be called? Of course it can, it's a function, the compiler makes
sure that a constructor is called when you create an object.

Can I call it? No, of course not. It's a special function that does not
have a name, you cannot call it directly.

So, Alf, when somebody asks the question "can a constructor be called?", do
you see it as "can a constructor be called at all?" or as "can a constructor
be called _by_ me _directly_ using some tricky syntax?", and which question
are you answering? Are you sure you're answering the question asked?

Whose misconception is it?

V

 

[Alf P. Steinbach]

* Victor Bazarov:

* Victor Bazarov:

[...]
Every tree of constructor calls start with a source code level
constructor call, it's just a very common misconception that they're
never "explicit", or not "calls" (that last misconception is mentioned
in the FAQ, by ref to the definition of default constructor). The
first
misconception probably stems from a passage in the standard where the
word "explicit" is used for disambiguation in a particular context, and
the last misconception probably stems from the desire to teach newbies
not to think of a constructor as a an ordinary callable member
function,
but doing that by inventing a simple and incorrect explanation instead
of how things actually work.

12.1/2 "Because the constructors do not have names, they are never found
during name lookup". Yes, you can _cause_ a constructor to be called.

That's correct.

You can never _call_ one, though.

That's incorrect.

I seem to recall we have discussed that before, and so I simply direct
you again to the same place (definition of default constructor), "can be
called".

Where's the misconception?

In your mind... ;-)

Do we always get hung up on the definition of "be"?

Can it be called? Of course it can, it's a function, the compiler makes
sure that a constructor is called when you create an object.

AFAICS that's correct assuming by "object" you mean "object of class
type", for any reasonable definition of "create".

Can I call it? No, of course not. It's a special function that does not
have a name, you cannot call it directly.

That's incorrect.

But I shouldn't just have referred you to the standard, which for once
is pretty explicit.

One logical fallacy is to assume, in spite of repeated clear
explanations that it is not so, that "call" in this context always means
"ordinary source code level function call used to call a constructor on
pre-existing storage"; starting from a such a false premise any
consequence can be derived.

 

[Victor Bazarov]

That's incorrect.
Huh?

But I shouldn't just have referred you to the standard, which for once
is pretty explicit.

Do please. I am curious where in the Standard there is evidence to your
"That's incorrect" response. Don't be shy. Give it to me as it is.

One logical fallacy is to assume, in spite of repeated clear
explanations that it is not so, that "call" in this context always means
"ordinary source code level function call used to call a constructor on
pre-existing storage"; starting from a such a false premise any
consequence can be derived.

So, it does not necessarily mean "ordinary source code level function
call", I get it. So, by answering "yes" to "can I call a constructor" you
provide a newbie with a clear explanation of what's going on and no real
confusion can arise, right?

What's the point of this? The entire C++ camp is divided into two apparent
crowds; one (bigger) that says "no" and gives the explanation from the
Standard and the other (including you) that says "yes" _insisting_ that
there is some context to the inquirer's question.

Yes, we "call" constructors every day, often millions of times. The same
way we rotate the Earth by driving our cars from the East to the West. Can
you explain that to somebody without solid understanding of how gravity and
inertia work?

I always assume the _simplest_ "context" in such question. And many of us
started that way too. I write a function. It is called "a constructor".
So what? It's a function. I want to call it. How do I do that? What's
the syntax? The biggest problem is that after telling them that the syntax

{classname} ( {arguments} )

is a call to a constructor (which it isn't, although it eventually does
lead to it), we get "I call another constructor from within my first, why
doesn't it work" kind of questions.

V

 

[Alf P. Steinbach]

* Victor Bazarov:

Do please. I am curious where in the Standard there is evidence to your
"That's incorrect" response. Don't be shy. Give it to me as it is.

There is no apparent meaning in what you write here, only emotion.

But for the record, the C++ standard does not say anywhere that a
conclusion must follow by some sound rule of inference from premises,
and the reference I gave (twice) to the standard was not about that.

Perhaps I should have written "nonsense" here instead of "incorrect".

So, it does not necessarily mean "ordinary source code level function
call", I get it. So, by answering "yes" to "can I call a constructor" you
provide a newbie with a clear explanation of what's going on and no real
confusion can arise, right?

There is no apparent meaning here either, just emotion.

What's the point of this? The entire C++ camp is divided into two apparent
crowds; one (bigger) that says "no"

That isn't necessarily correct.

and gives the explanation from the Standard

That is incorrect.

and the other (including you) that says "yes" _insisting_ that
there is some context to the inquirer's question.

That is incorrect.

Yes, we "call" constructors every day, often millions of times. The same
way we rotate the Earth by driving our cars from the East to the West. Can
you explain that to somebody without solid understanding of how gravity and
inertia work?

This pararaph seems to be meaningless.

I always assume the _simplest_ "context" in such question. And many of us
started that way too. I write a function. It is called "a constructor".
So what? It's a function. I want to call it. How do I do that? What's
the syntax? The biggest problem is that after telling them that the syntax

{classname} ( {arguments} )

is a call to a constructor (which it isn't, although it eventually does
lead to it), we get "I call another constructor from within my first, why
doesn't it work" kind of questions.

If you give an incorrect or too general (and thus misleading)
explanation you may get misconceptions.

 

[Peter Koch Larsen]

* DaKoadMunky:

do.

1: What is the syntax of an explicit ctor call?

[snip]


Presumably Peter Koch Larsen is referring to placement new, just using
an unfortunate choice of terms.

Yep - that is exactly what i meant. I agree that my wording was pretty
inaccurate ;-)

[snip]