Constructor Definition C++ syntax [duplicate]
up vote
4
down vote
favorite
This question already has an answer here:
What is this weird colon-member (“ : ”) syntax in the constructor?
12 answers
What's the difference between these two declarations of constructors:
class Fruit
private:
int price;
public:
Fruit(int x): price(x)
;
VS
class Fruit
private:
int price;
public:
Fruit(int x)
price = x;
;
The first one I have seen in case of inheritance.
As per my knowledge, this is not a duplicate question. If you find one feel free to close this question.
c++ oop c++11 ctor-initializer
marked as duplicate by Jans, Lightness Races in Orbit
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 11 at 0:54
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
up vote
4
down vote
favorite
This question already has an answer here:
What is this weird colon-member (“ : ”) syntax in the constructor?
12 answers
What's the difference between these two declarations of constructors:
class Fruit
private:
int price;
public:
Fruit(int x): price(x)
;
VS
class Fruit
private:
int price;
public:
Fruit(int x)
price = x;
;
The first one I have seen in case of inheritance.
As per my knowledge, this is not a duplicate question. If you find one feel free to close this question.
c++ oop c++11 ctor-initializer
marked as duplicate by Jans, Lightness Races in Orbit
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 11 at 0:54
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Both will not compile, though, unless you add a ; after the declaration:int price;
– Aganju
Nov 10 at 23:04
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
This question already has an answer here:
What is this weird colon-member (“ : ”) syntax in the constructor?
12 answers
What's the difference between these two declarations of constructors:
class Fruit
private:
int price;
public:
Fruit(int x): price(x)
;
VS
class Fruit
private:
int price;
public:
Fruit(int x)
price = x;
;
The first one I have seen in case of inheritance.
As per my knowledge, this is not a duplicate question. If you find one feel free to close this question.
c++ oop c++11 ctor-initializer
This question already has an answer here:
What is this weird colon-member (“ : ”) syntax in the constructor?
12 answers
What's the difference between these two declarations of constructors:
class Fruit
private:
int price;
public:
Fruit(int x): price(x)
;
VS
class Fruit
private:
int price;
public:
Fruit(int x)
price = x;
;
The first one I have seen in case of inheritance.
As per my knowledge, this is not a duplicate question. If you find one feel free to close this question.
This question already has an answer here:
What is this weird colon-member (“ : ”) syntax in the constructor?
12 answers
c++ oop c++11 ctor-initializer
c++ oop c++11 ctor-initializer
edited Nov 10 at 23:07
gsamaras
48k2394174
48k2394174
asked Nov 10 at 22:26
random_28
713415
713415
marked as duplicate by Jans, Lightness Races in Orbit
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 11 at 0:54
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Jans, Lightness Races in Orbit
StackExchange.ready(function()
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();
);
);
);
Nov 11 at 0:54
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Both will not compile, though, unless you add a ; after the declaration:int price;
– Aganju
Nov 10 at 23:04
add a comment |
Both will not compile, though, unless you add a ; after the declaration:int price;
– Aganju
Nov 10 at 23:04
Both will not compile, though, unless you add a ; after the declaration:
int price;– Aganju
Nov 10 at 23:04
Both will not compile, though, unless you add a ; after the declaration:
int price;– Aganju
Nov 10 at 23:04
add a comment |
4 Answers
4
active
oldest
votes
up vote
8
down vote
accepted
The first one initialize price with x where the second one initialize price with its default value (default construct it; in case of a int variable, is initialized with an undefined value) and then copy x in price.
In other words, the first one is almost equivalent to
int price = x;
where the second one is almost equivalent to
int price;
price = x;
In case of a int variable (taking also in count the compiler's optimizations) I suppose there isn't an effective difference.
But when price is a complex object, with an heavy construction cost, there can be a great difference.
As better explain Peter, "It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception."
So, usually, is strongly suggested to use the first solution (initialize the object with the right value).
See also the Zereges's answer that point the attention over the fact that the first one method is the only available to assign a value to a constant member.
Indeed you can't write
int const price;
price = x; // error: price is const
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op likeint price;.
– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
add a comment |
up vote
6
down vote
The first one uses an initialization list, while the other doesn't, and assigns x to the data member price inside the body of the constructor.
We usually prefer to use initialization lists, and to keep the body of the constructor as simple as possible.
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
add a comment |
up vote
4
down vote
To add up to other answers, the first option is the natural way to initialize const members
struct C
const int val;
C() : val(5) // Perfectly OK
C(int) // error: uninitialized const member in 'const int' [-fpermissive]
val = 5 // error: assignment of read-only member 'C::val'
;
Also, when class has members of type, that are not default-constructible, this is the way to initialize them
struct D
struct not_default_constructible
not_default_constructible(int)
var;
int& ref;
D(int a) : ref(a), var(5) // Legal
D(int a, char) // error: uninitialized reference member in 'int&' [-fpermissive]
// error: no matching function for call to 'D::not_default_constructible::not_default_constructible()'
ref = a;
;
1
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
add a comment |
up vote
3
down vote
The second one does not initialize price with x when a Fruit is created which therefor default constructs it. Just as if you'd written:
class Fruit
private :
int price
public:
Fruit(int x) :
price() // default constructed
price = x
For effectiveness, it's better to initialize with the value you want to assign to it.
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
The first one initialize price with x where the second one initialize price with its default value (default construct it; in case of a int variable, is initialized with an undefined value) and then copy x in price.
In other words, the first one is almost equivalent to
int price = x;
where the second one is almost equivalent to
int price;
price = x;
In case of a int variable (taking also in count the compiler's optimizations) I suppose there isn't an effective difference.
But when price is a complex object, with an heavy construction cost, there can be a great difference.
As better explain Peter, "It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception."
So, usually, is strongly suggested to use the first solution (initialize the object with the right value).
See also the Zereges's answer that point the attention over the fact that the first one method is the only available to assign a value to a constant member.
Indeed you can't write
int const price;
price = x; // error: price is const
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op likeint price;.
– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
add a comment |
up vote
8
down vote
accepted
The first one initialize price with x where the second one initialize price with its default value (default construct it; in case of a int variable, is initialized with an undefined value) and then copy x in price.
In other words, the first one is almost equivalent to
int price = x;
where the second one is almost equivalent to
int price;
price = x;
In case of a int variable (taking also in count the compiler's optimizations) I suppose there isn't an effective difference.
But when price is a complex object, with an heavy construction cost, there can be a great difference.
As better explain Peter, "It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception."
So, usually, is strongly suggested to use the first solution (initialize the object with the right value).
See also the Zereges's answer that point the attention over the fact that the first one method is the only available to assign a value to a constant member.
Indeed you can't write
int const price;
price = x; // error: price is const
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op likeint price;.
– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
add a comment |
up vote
8
down vote
accepted
up vote
8
down vote
accepted
The first one initialize price with x where the second one initialize price with its default value (default construct it; in case of a int variable, is initialized with an undefined value) and then copy x in price.
In other words, the first one is almost equivalent to
int price = x;
where the second one is almost equivalent to
int price;
price = x;
In case of a int variable (taking also in count the compiler's optimizations) I suppose there isn't an effective difference.
But when price is a complex object, with an heavy construction cost, there can be a great difference.
As better explain Peter, "It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception."
So, usually, is strongly suggested to use the first solution (initialize the object with the right value).
See also the Zereges's answer that point the attention over the fact that the first one method is the only available to assign a value to a constant member.
Indeed you can't write
int const price;
price = x; // error: price is const
The first one initialize price with x where the second one initialize price with its default value (default construct it; in case of a int variable, is initialized with an undefined value) and then copy x in price.
In other words, the first one is almost equivalent to
int price = x;
where the second one is almost equivalent to
int price;
price = x;
In case of a int variable (taking also in count the compiler's optimizations) I suppose there isn't an effective difference.
But when price is a complex object, with an heavy construction cost, there can be a great difference.
As better explain Peter, "It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception."
So, usually, is strongly suggested to use the first solution (initialize the object with the right value).
See also the Zereges's answer that point the attention over the fact that the first one method is the only available to assign a value to a constant member.
Indeed you can't write
int const price;
price = x; // error: price is const
edited Nov 11 at 2:58
answered Nov 10 at 22:33
max66
32.7k63660
32.7k63660
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op likeint price;.
– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
add a comment |
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op likeint price;.
– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op like
int price;.– Quimby
Nov 10 at 22:42
Might be worth noting that for user-defined types the second option calls default constructor and that might not be no-op like
int price;.– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
Oh, you just added it :)
– Quimby
Nov 10 at 22:42
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
It's not construction cost that makes the difference between the two for complex objects. It is a question of whether reassigning after default initialisation is more costly than initialising in one step. Practically, the two stage process is often more expensive (by various measures) than direct initialisation, since it can be necessary to clean up the default setting in order to change the value. There are also concerns of exception safety - what if reassignment or construction throws an exception.
– Peter
Nov 10 at 23:11
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
@Peter - I was trying to explain this point but your explanation if far more clear than mine. I've simply copied it. Thanks.
– max66
Nov 11 at 0:18
add a comment |
up vote
6
down vote
The first one uses an initialization list, while the other doesn't, and assigns x to the data member price inside the body of the constructor.
We usually prefer to use initialization lists, and to keep the body of the constructor as simple as possible.
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
add a comment |
up vote
6
down vote
The first one uses an initialization list, while the other doesn't, and assigns x to the data member price inside the body of the constructor.
We usually prefer to use initialization lists, and to keep the body of the constructor as simple as possible.
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
add a comment |
up vote
6
down vote
up vote
6
down vote
The first one uses an initialization list, while the other doesn't, and assigns x to the data member price inside the body of the constructor.
We usually prefer to use initialization lists, and to keep the body of the constructor as simple as possible.
The first one uses an initialization list, while the other doesn't, and assigns x to the data member price inside the body of the constructor.
We usually prefer to use initialization lists, and to keep the body of the constructor as simple as possible.
edited Nov 11 at 9:53
answered Nov 10 at 22:27
gsamaras
48k2394174
48k2394174
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
add a comment |
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
It is unfortunate that initialization-lists' syntax is somewhat ugly and precludes the use of intermediate rvalues.
– Dai
Nov 10 at 22:28
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
Indeed @Dai, but still useful!
– gsamaras
Nov 10 at 22:30
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
This is not correct. It is not possible to "initialise a data member inside the body of the constructor". That is an assignment.
– Lightness Races in Orbit
Nov 11 at 0:55
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
@LightnessRacesinOrbit good catch, corrected, thanks!
– gsamaras
Nov 11 at 10:59
add a comment |
up vote
4
down vote
To add up to other answers, the first option is the natural way to initialize const members
struct C
const int val;
C() : val(5) // Perfectly OK
C(int) // error: uninitialized const member in 'const int' [-fpermissive]
val = 5 // error: assignment of read-only member 'C::val'
;
Also, when class has members of type, that are not default-constructible, this is the way to initialize them
struct D
struct not_default_constructible
not_default_constructible(int)
var;
int& ref;
D(int a) : ref(a), var(5) // Legal
D(int a, char) // error: uninitialized reference member in 'int&' [-fpermissive]
// error: no matching function for call to 'D::not_default_constructible::not_default_constructible()'
ref = a;
;
1
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
add a comment |
up vote
4
down vote
To add up to other answers, the first option is the natural way to initialize const members
struct C
const int val;
C() : val(5) // Perfectly OK
C(int) // error: uninitialized const member in 'const int' [-fpermissive]
val = 5 // error: assignment of read-only member 'C::val'
;
Also, when class has members of type, that are not default-constructible, this is the way to initialize them
struct D
struct not_default_constructible
not_default_constructible(int)
var;
int& ref;
D(int a) : ref(a), var(5) // Legal
D(int a, char) // error: uninitialized reference member in 'int&' [-fpermissive]
// error: no matching function for call to 'D::not_default_constructible::not_default_constructible()'
ref = a;
;
1
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
add a comment |
up vote
4
down vote
up vote
4
down vote
To add up to other answers, the first option is the natural way to initialize const members
struct C
const int val;
C() : val(5) // Perfectly OK
C(int) // error: uninitialized const member in 'const int' [-fpermissive]
val = 5 // error: assignment of read-only member 'C::val'
;
Also, when class has members of type, that are not default-constructible, this is the way to initialize them
struct D
struct not_default_constructible
not_default_constructible(int)
var;
int& ref;
D(int a) : ref(a), var(5) // Legal
D(int a, char) // error: uninitialized reference member in 'int&' [-fpermissive]
// error: no matching function for call to 'D::not_default_constructible::not_default_constructible()'
ref = a;
;
To add up to other answers, the first option is the natural way to initialize const members
struct C
const int val;
C() : val(5) // Perfectly OK
C(int) // error: uninitialized const member in 'const int' [-fpermissive]
val = 5 // error: assignment of read-only member 'C::val'
;
Also, when class has members of type, that are not default-constructible, this is the way to initialize them
struct D
struct not_default_constructible
not_default_constructible(int)
var;
int& ref;
D(int a) : ref(a), var(5) // Legal
D(int a, char) // error: uninitialized reference member in 'int&' [-fpermissive]
// error: no matching function for call to 'D::not_default_constructible::not_default_constructible()'
ref = a;
;
edited Nov 12 at 8:17
answered Nov 10 at 22:39
Zereges
3,74411337
3,74411337
1
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
add a comment |
1
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
1
1
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
Similarly, a member of class type, when that class does not have an accessible default constructor, can only be initialized using the mem-initializer-list.
– aschepler
Nov 11 at 0:47
add a comment |
up vote
3
down vote
The second one does not initialize price with x when a Fruit is created which therefor default constructs it. Just as if you'd written:
class Fruit
private :
int price
public:
Fruit(int x) :
price() // default constructed
price = x
For effectiveness, it's better to initialize with the value you want to assign to it.
add a comment |
up vote
3
down vote
The second one does not initialize price with x when a Fruit is created which therefor default constructs it. Just as if you'd written:
class Fruit
private :
int price
public:
Fruit(int x) :
price() // default constructed
price = x
For effectiveness, it's better to initialize with the value you want to assign to it.
add a comment |
up vote
3
down vote
up vote
3
down vote
The second one does not initialize price with x when a Fruit is created which therefor default constructs it. Just as if you'd written:
class Fruit
private :
int price
public:
Fruit(int x) :
price() // default constructed
price = x
For effectiveness, it's better to initialize with the value you want to assign to it.
The second one does not initialize price with x when a Fruit is created which therefor default constructs it. Just as if you'd written:
class Fruit
private :
int price
public:
Fruit(int x) :
price() // default constructed
price = x
For effectiveness, it's better to initialize with the value you want to assign to it.
answered Nov 10 at 22:35
Ted Lyngmo
961112
961112
add a comment |
add a comment |
Both will not compile, though, unless you add a ; after the declaration:
int price;– Aganju
Nov 10 at 23:04