What do they call this kind of constructor?

[Jason Heyes]

Is there a special name for a constructor that does struct-like
initialisation? Example:

class DefaultCtor
{
std::string class_name;
bool compiler_generated;

public:
DefaultCtor(std::string class_name, bool compiler_generated);

};

DefaultCtor::DefaultCtor(std::string class_name_, bool compiler_generated_)
: class_name(class_name_), compiler_generated(compiler_generated_)
{
}

Thanks.

[Victor Bazarov]

Jason Heyes wrote:

Is there a special name for a constructor that does struct-like
initialisation?
What's a "struct-like initialisation"?
Example:

class DefaultCtor
{
std::string class_name;
bool compiler_generated;

public:
DefaultCtor(std::string class_name, bool compiler_generated);

};

DefaultCtor::DefaultCtor(std::string class_name_, bool compiler_generated_)
: class_name(class_name_), compiler_generated(compiler_generated_)
{
}

What you have here is a normal _parameterized_ constructor. It is
*definitely* not a 'default' one, so there is a misnomer.

Also, as a side note, you shouldn't be passing 'std::string' by value,
there is no value in that (pun intended). You should pass it by a ref
to const:

SomeCtor(std::string const& class_name, ...

V

[Jason Heyes]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:jT******************@newsread1.mlpsca01.us.to .verio.net...

Jason Heyes wrote:

Is there a special name for a constructor that does struct-like
initialisation?

What's a "struct-like initialisation"?

Example:

class DefaultCtor
{
std::string class_name;
bool compiler_generated;

public:
DefaultCtor(std::string class_name, bool compiler_generated);

};

DefaultCtor::DefaultCtor(std::string class_name_, bool
compiler_generated_) : class_name(class_name_),
compiler_generated(compiler_generated_)
{
}

What you have here is a normal _parameterized_ constructor. It is
*definitely* not a 'default' one, so there is a misnomer.

Also, as a side note, you shouldn't be passing 'std::string' by value,
there is no value in that (pun intended). You should pass it by a ref
to const:

SomeCtor(std::string const& class_name, ...

V

I will call it a "default constructor that takes arguments" or a "default
parameterized constructor." How does that sound?

I don't pass std::string by const reference when I know it won't affect
performance.

[Dan Cernat]

Jason Heyes wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:jT******************@newsread1.mlpsca01.us.to .verio.net...

Jason Heyes wrote:

Is there a special name for a constructor that does struct-like
initialisation?

What's a "struct-like initialisation"?

Example:

class DefaultCtor
{
std::string class_name;
bool compiler_generated;

public:
DefaultCtor(std::string class_name, bool compiler_generated);

};

DefaultCtor::DefaultCtor(std::string class_name_, bool
compiler_generated_) : class_name(class_name_),
compiler_generated(compiler_generated_)
{
}

What you have here is a normal _parameterized_ constructor. It is
*definitely* not a 'default' one, so there is a misnomer.

Also, as a side note, you shouldn't be passing 'std::string' by value,
there is no value in that (pun intended). You should pass it by a ref
to const:

SomeCtor(std::string const& class_name, ...

V

I will call it a "default constructor that takes arguments" or a "default
parameterized constructor." How does that sound?

You provided it, therefore it is NOT a default constructor.

In your opinion, how a non-default parametrized constructor would look
like?

Thanks,
Dan

[Howard]

"Jason Heyes" <ja********@optusnet.com.au> wrote in message
news:42***********************@news.optusnet.com.a u...

DefaultCtor::DefaultCtor(std::string class_name_, bool
compiler_generated_) : class_name(class_name_),
compiler_generated(compiler_generated_)
{
}

What you have here is a normal _parameterized_ constructor. It is
*definitely* not a 'default' one, so there is a misnomer.

Also, as a side note, you shouldn't be passing 'std::string' by value,
there is no value in that (pun intended). You should pass it by a ref
to const:

SomeCtor(std::string const& class_name, ...

V

I will call it a "default constructor that takes arguments" or a "default
parameterized constructor." How does that sound?

A default constructor takes no arguments. Yours has arguments, so it's not
default. Why do you want to use the term "default" with it? It's simply a
(parameterized) constructor. Leave off the "default".

(By the way, who's going to hear/see you call it that? Is this for purposes
of discussion here, or for internal documentation purposes, or...?)

-Howard

[Dan Cernat]

You provided it, therefore it is NOT a default constructor.

That is erroneous. A default constructor is a constructor without any
arguments.

/dan

[Victor Bazarov]

Howard wrote:

"Jason Heyes" <ja********@optusnet.com.au> wrote in message
news:42***********************@news.optusnet.com.a u...

DefaultCtor::DefaultCtor(std::string class_name_, bool
compiler_generated_) : class_name(class_name_),
compiler_generated(compiler_generated_)
{
}

What you have here is a normal _parameterized_ constructor. It is
*definitely* not a 'default' one, so there is a misnomer.

Also, as a side note, you shouldn't be passing 'std::string' by value,
there is no value in that (pun intended). You should pass it by a ref
to const:

SomeCtor(std::string const& class_name, ...

V
I will call it a "default constructor that takes arguments" or a "default
parameterized constructor." How does that sound?

A default constructor takes no arguments.

Nit-pick: a default constructor is one that does not need arguments
specified to construct an object (IOW, it may have default argument
values). Both classes:

struct A {
A();
};

struct B {
B(int = 0);
};

have _default_ constructors.
Yours has arguments, so it's not
default. Why do you want to use the term "default" with it? It's simply a
(parameterized) constructor. Leave off the "default".

(By the way, who's going to hear/see you call it that? Is this for purposes
of discussion here, or for internal documentation purposes, or...?)

V

[Jason Heyes]

"Howard" <al*****@hotmail.com> wrote in message
news:n4********************@bgtnsc04-news.ops.worldnet.att.net...

A default constructor takes no arguments. Yours has arguments, so it's
not default. Why do you want to use the term "default" with it? It's
simply a (parameterized) constructor. Leave off the "default".

(By the way, who's going to hear/see you call it that? Is this for
purposes of discussion here, or for internal documentation purposes,
or...?)

I want the phrase "default parameterized" to mean "all arguments." This does
not affect the phrase "default" on its own, which means "no arguments."

I need to name various kinds of constructors. I want to write classes to
represent them. The classes must be given names.

[Jason Heyes]

"Dan Cernat" <dc*****@excite.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

You provided it, therefore it is NOT a default constructor.

Aren't you talking about compiler-generated constructors? Default
constructors take no arguments and do not have to be generated automatically
by a compiler.

[vish]

BTW, Dont the default and non default constructors receive a pointer
("this") implicitly??

[Victor Bazarov]

vish wrote:

BTW, Dont the default and non default constructors receive a pointer
("this") implicitly??

Every non-static member function does. What does it have to do with
the problem at hand?

[Peter Koch Larsen]

"Victor Bazarov" <v.********@comAcast.net> skrev i en meddelelse
news:iB*******************@newsread1.mlpsca01.us.t o.verio.net...

vish wrote:

BTW, Dont the default and non default constructors receive a pointer
("this") implicitly??

Every non-static member function does. What does it have to do with
the problem at hand?

Technically, I would say no. A constructor does not receive a this-pointer -
it "creates" one. But this is nitpicking, of course.

/Peter

[Shezan Baig]

Peter Koch Larsen wrote:

"Victor Bazarov" <v.********@comAcast.net> skrev i en meddelelse
news:iB*******************@newsread1.mlpsca01.us.t o.verio.net...

vish wrote:

BTW, Dont the default and non default constructors receive a pointer
("this") implicitly??

Every non-static member function does. What does it have to do with
the problem at hand?

Technically, I would say no. A constructor does not receive a this-pointer -
it "creates" one. But this is nitpicking, of course.

/Peter

Really? The 'this' pointer exists even before the constructor starts
executing (e.g, you can use it in the initializer list), so I would
have guessed that it is passed to the constructor.

-shez-

[Victor Bazarov]

Peter Koch Larsen wrote:

"Victor Bazarov" <v.********@comAcast.net> skrev i en meddelelse
news:iB*******************@newsread1.mlpsca01.us.t o.verio.net...

vish wrote:

BTW, Dont the default and non default constructors receive a pointer
("this") implicitly??

Every non-static member function does. What does it have to do with
the problem at hand?

Technically, I would say no. A constructor does not receive a this-pointer -
it "creates" one. But this is nitpicking, of course.

"Creates"? What does that mean? 'this' _pointer_ is valid before the
initialiser list is reached (although only as a pointer, the object has
not be constructed). Some other code allocates memory and therefore
"creates" the pointer, which is inserted into the expression any time
you use the 'this' keyword. That falls under "receive", not "create".

V

[Old Wolf]

Jason Heyes wrote:

I want the phrase "default parameterized" to mean "all arguments."
This does not affect the phrase "default" on its own, which means
"no arguments."

I need to name various kinds of constructors.

This is like calling a green apple "red variant".
IOW, "default" means "no arguments", as you say. (NB. not to be
confused with "no parameters"). That is the essence of the term
"default". It does not make much sense to use "default ....." for
something with arguments.

[Richard Herring]

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

I don't pass std::string by const reference when I know it won't affect
performance.

That would be "never", since you don't know how it's implemented.

--
Richard Herring

[Jason Heyes]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:R7**************@baesystems.com...

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

I don't pass std::string by const reference when I know it won't affect
performance.

That would be "never", since you don't know how it's implemented.

Have you considered how a std::string's size affects performance?

[Peter Koch Larsen]

"Victor Bazarov" <v.********@comAcast.net> skrev i en meddelelse
news:qc*****************@newsread1.mlpsca01.us.to. verio.net...

Peter Koch Larsen wrote:

"Victor Bazarov" <v.********@comAcast.net> skrev i en meddelelse
news:iB*******************@newsread1.mlpsca01.us.t o.verio.net...

vish wrote:

BTW, Dont the default and non default constructors receive a pointer
("this") implicitly??
Every non-static member function does. What does it have to do with
the problem at hand?

Technically, I would say no. A constructor does not receive a
this-pointer - it "creates" one. But this is nitpicking, of course.

"Creates"? What does that mean? 'this' _pointer_ is valid before the
initialiser list is reached (although only as a pointer, the object has
not be constructed). Some other code allocates memory and therefore
"creates" the pointer, which is inserted into the expression any time
you use the 'this' keyword. That falls under "receive", not "create".

V

I agree. What I meant to say was that while there is a this pointer, it does
not hold an object before the constructor completes. The this pointer
contains "raw" memory until that point.

/Peter

[Richard Herring]

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:R7**************@baesystems.com...

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

I don't pass std::string by const reference when I know it won't affect
performance.

That would be "never", since you don't know how it's implemented.

Have you considered how a std::string's size affects performance?

No. What does the standard say about it, and what aspect of that do you
think would make it better to pass by value than reference?

--
Richard Herring

[Peter Koch Larsen]

"Shezan Baig" <sh************@gmail.com> skrev i en meddelelse
news:11**********************@g47g2000cwa.googlegr oups.com...

Peter Koch Larsen wrote:

"Victor Bazarov" <v.********@comAcast.net> skrev i en meddelelse
news:iB*******************@newsread1.mlpsca01.us.t o.verio.net...

> vish wrote:
>> BTW, Dont the default and non default constructors receive a pointer
>> ("this") implicitly??
>>
>
> Every non-static member function does. What does it have to do with
> the problem at hand?

Technically, I would say no. A constructor does not receive a
this-pointer -
it "creates" one. But this is nitpicking, of course.

/Peter

Really? The 'this' pointer exists even before the constructor starts
executing (e.g, you can use it in the initializer list), so I would
have guessed that it is passed to the constructor.

-shez-

You are correct. What I meant was that "this" does not point to an object in
the constructor. It points to raw memory which gets created while the
constructor runs.

/Peter

[Victor Bazarov]

Dan Cernat wrote:

You provided it, therefore it is NOT a default constructor.

That is erroneous. A default constructor is a constructor without any
arguments.

Nit-pick again: a default constructor is one that can be invoked
without providing any arguments:

struct A {
A(int = 0); // default constructor
};

A a; // default-initialisation (actually A a(0); )
A aa(42); // parameterized

Victor

[Dan Cernat]

The size, in this case, doesn't matter. I can come up with an
implementation that even the string has one character, the copy
constructor could take forever to construct the object (eg it
calculates the billionth decimal of the PI number). Would you pass it
by value?

Dan

[Clark S. Cox III]

On 2005-06-10 09:21:58 -0400, Victor Bazarov <v.********@comAcast.net> said:

Dan Cernat wrote:

You provided it, therefore it is NOT a default constructor.

That is erroneous. A default constructor is a constructor without any
arguments.

Nit-pick again: a default constructor is one that can be invoked
without providing any arguments:

struct A {
A(int = 0); // default constructor
};

A a; // default-initialisation (actually A a(0); )
A aa(42); // parameterized

One illustration of that that I particularly like:

struct A
{
explicit A(int);

/*This constructor is both the default
constructor *and* a copy constructor*/
A(const A &a = A(123));
};

A a; //Equivalent to A a(A(123))

--
Clark S. Cox, III
cl*******@gmail.com

[Victor Bazarov]

Clark S. Cox III wrote:

On 2005-06-10 09:21:58 -0400, Victor Bazarov <v.********@comAcast.net>
said:

Dan Cernat wrote:

You provided it, therefore it is NOT a default constructor.
That is erroneous. A default constructor is a constructor without any
arguments.

Nit-pick again: a default constructor is one that can be invoked
without providing any arguments:

struct A {
A(int = 0); // default constructor
};

A a; // default-initialisation (actually A a(0); )
A aa(42); // parameterized

One illustration of that that I particularly like:

struct A
{
explicit A(int);

/*This constructor is both the default
constructor *and* a copy constructor*/
A(const A &a = A(123));
};

A a; //Equivalent to A a(A(123))

Interesting example. Is there a real need in something like that?
I do realize the need for 'explicit A(int)' and a copy c-tor in
general, but make a copy c-tor a default c-tor? Would it be better
to make the parameterized one the default?

struct A
{
explicit A(int = 123);

A(const A &a);
};

A a; // equivalent to A a(123)

or am I missing something WRT 'explicit' in that case?

V

[Jason Heyes]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:9C**************@baesystems.com...

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

Have you considered how a std::string's size affects performance?

No. What does the standard say about it, and what aspect of that do you
think would make it better to pass by value than reference?

Bjarne Stroustrup says in his book that "many common uses of strings are
better served by implementations that minimize copying, use no free store
for short strings, ..., etc." So if the implementation is good, passing
short strings by value is fine and appropriate. If not, a better
implementation should be used.

[Jason Heyes]

"Dan Cernat" <dc*****@excite.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

The size, in this case, doesn't matter. I can come up with an
implementation that even the string has one character, the copy
constructor could take forever to construct the object (eg it
calculates the billionth decimal of the PI number). Would you pass it
by value?

If you do that, then you are a poor programmer. This is your fault, not
mine. ;)

[Dan Cernat]

Well, it works both ways: if you pass strings by value, then you are a
poor programmer.

Tink of it. You are writing a generic function. You cannot control what
is passed to it. In your application you might know what values are you
dealing with, but in a team environment someone could take your class,
use it in a different application and pass to your function some huge
strings. Big performance problems! Then, they look at the code and,
wow! Jason is passing strings by value! Does that make you a good
programmer?

And BTW it is not only about strings.

Have a nice weekend.

[Julián Albo]

Jason Heyes wrote:

Bjarne Stroustrup says in his book that "many common uses of strings are
better served by implementations that minimize copying, use no free store
for short strings, ..., etc." So if the implementation is good, passing
short strings by value is fine and appropriate. If not, a better

But why do you need to care if the function will be always called with short
strngs or not?

--
Salu2

[Clark S. Cox III]

On 2005-06-10 11:17:10 -0400, Victor Bazarov <v.********@comAcast.net> said:

Clark S. Cox III wrote:

On 2005-06-10 09:21:58 -0400, Victor Bazarov <v.********@comAcast.net> said:

Dan Cernat wrote:

> You provided it, therefore it is NOT a default constructor.
That is erroneous. A default constructor is a constructor without any
arguments.
Nit-pick again: a default constructor is one that can be invoked
without providing any arguments:

struct A {
A(int = 0); // default constructor
};

A a; // default-initialisation (actually A a(0); )
A aa(42); // parameterized
One illustration of that that I particularly like:

struct A
{
explicit A(int);

/*This constructor is both the default
constructor *and* a copy constructor*/
A(const A &a = A(123));
};

A a; //Equivalent to A a(A(123))

Interesting example. Is there a real need in something like that?

Not that I can think of.
I do realize the need for 'explicit A(int)' and a copy c-tor in
general, but make a copy c-tor a default c-tor? Would it be better
to make the parameterized one the default?
In "real life", yes.

struct A
{
explicit A(int = 123);

A(const A &a);
};

A a; // equivalent to A a(123)

or am I missing something WRT 'explicit' in that case?

No, you're not missing anything. The example's really only there to
evoke a "hey that's interesting" response. And I only put the
"explicit" there out of habit (i.e. unless I have a reason to do
otherwise, I make *all* single parameter constructors explicit).
--
Clark S. Cox, III
cl*******@gmail.com

[Default User]

Dan Cernat wrote:

The size, in this case, doesn't matter. I can come up with an
implementation that even the string has one character, the copy
constructor could take forever to construct the object (eg it
calculates the billionth decimal of the PI number). Would you pass it
by value?

Please quote a relevant portion of the previous message when replying.
To do so from the Google interface, don't use the Reply at the bottom
of the message. Instead, click "show options" and use the Reply shown
in the expanded headers.

Brian

[Jason Heyes]

"Julián Albo" <JU********@terra.es> wrote in message
news:42********@x-privat.org...

But why do you need to care if the function will be always called with
short
strngs or not?

I don't care, I know.

[Jason Heyes]

"Dan Cernat" <dc*****@excite.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Well, it works both ways: if you pass strings by value, then you are a
poor programmer.

I already explained that passing by value is fine for small strings.

Tink of it. You are writing a generic function. You cannot control what
is passed to it. In your application you might know what values are you
dealing with, but in a team environment someone could take your class,
use it in a different application and pass to your function some huge
strings. Big performance problems! Then, they look at the code and,
wow! Jason is passing strings by value! Does that make you a good
programmer?

Why you talk about generic programming is beyond me.

And BTW it is not only about strings.

Actually, it is.

[Peter Koch Larsen]

"Jason Heyes" <ja********@optusnet.com.au> skrev i en meddelelse
news:42***********************@news.optusnet.com.a u...

"Dan Cernat" <dc*****@excite.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Well, it works both ways: if you pass strings by value, then you are a
poor programmer.

I already explained that passing by value is fine for small strings.

It might well be fine, but it is more a question of habit and documentation.

/Peter

[snip]
Actually, it is.

[Jason Heyes]

"Peter Koch Larsen" <pk*****@mailme.dk> wrote in message
news:zA********************@news000.worldonline.dk ...

"Jason Heyes" <ja********@optusnet.com.au> skrev i en meddelelse
news:42***********************@news.optusnet.com.a u...

"Dan Cernat" <dc*****@excite.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Well, it works both ways: if you pass strings by value, then you are a
poor programmer.

I already explained that passing by value is fine for small strings.

It might well be fine, but it is more a question of habit and
documentation.

Do you mind saying a bit more? I don't understand the problem.

[Richard Herring]

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:9C**************@baesystems.com...

In message <42***********************@news.optusnet.com.au> , Jason Heyes
<ja********@optusnet.com.au> writes

Have you considered how a std::string's size affects performance?
No. What does the standard say about it, and what aspect of that do you
think would make it better to pass by value than reference?

Bjarne Stroustrup says in his book that "many common uses of strings are
better served by implementations that minimize copying, use no free store
for short strings, ..., etc."

Indeed he does. My question was about the standard, which doesn't.
So if the implementation is good, passing
short strings by value is fine and appropriate.
And may well *still* be less efficient than passing by constant
reference.
If not, a better
implementation should be used.

It must be an exhilarating experience to live in a world where you have
a free choice of library implementations, constrained only by how
efficiently they copy short strings.

--
Richard Herring