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

What do they call this kind of constructor?

P: n/a
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.
Jul 23 '05 #1
Share this Question
Share on Google+
34 Replies


P: n/a
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
Jul 23 '05 #2

P: n/a
"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.
Jul 23 '05 #3

P: n/a


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

Jul 23 '05 #4

P: n/a

"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

Jul 23 '05 #5

P: n/a
You provided it, therefore it is NOT a default constructor.


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

/dan

Jul 23 '05 #6

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

P: n/a
"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.
Jul 23 '05 #8

P: n/a
"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.
Jul 23 '05 #9

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

Jul 23 '05 #10

P: n/a
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?
Jul 23 '05 #11

P: n/a

"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
Jul 23 '05 #12

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

Jul 23 '05 #13

P: n/a
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
Jul 23 '05 #14

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

Jul 23 '05 #15

P: n/a
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
Jul 23 '05 #16

P: n/a
"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?
Jul 23 '05 #17

P: n/a

"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
Jul 23 '05 #18

P: n/a
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
Jul 23 '05 #19

P: n/a

"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
Jul 23 '05 #20

P: n/a
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
Jul 23 '05 #21

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

Jul 23 '05 #22

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

Jul 23 '05 #23

P: n/a
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
Jul 23 '05 #24

P: n/a
"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.
Jul 23 '05 #25

P: n/a
"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. ;)
Jul 23 '05 #26

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

Jul 23 '05 #27

P: n/a
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
Jul 23 '05 #28

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

Jul 23 '05 #29

P: n/a


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

Jul 23 '05 #30

P: n/a
"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.
Jul 23 '05 #31

P: n/a
"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.
Jul 23 '05 #32

P: n/a

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

Jul 23 '05 #33

P: n/a
"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.
Jul 23 '05 #34

P: n/a
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
Jul 23 '05 #35

This discussion thread is closed

Replies have been disabled for this discussion.