|
Hi!
Installing the SP1 for Visual Studio 2005 fixed this error. Thank you.
|
|
|
|
|
|
I have a similar question, the one that somebody ask me recently : If I have a simple class, with only one method
class Foo
{
public:
Foo();
virtual ~Foo();
void DoSomething();
};
what generate the compiler ? Code for constructor, destructor and method DoSomething() only ? Don't generate a default copy constructor and assigning operator, even is doesn't explicity implemented ?
modified 26-Jul-12 7:22am.
|
|
|
|
|
|
Thank you for your answer.
|
|
|
|
|
Why don't you try to actually compile such code?
For instance you may discover the missed the return value type in DoSomething declaration.
Veni, vidi, vici.
|
|
|
|
|
|
You are perfectly right !
|
|
|
|
|
Hi all,
Is there any particular reason you would initialise private members of a class like this...
<br />
SomeClass::Constructor(void): privateVar1(NULL), privateVar2(true) {<br />
<br />
}<br />
As opposed to this?
<br />
SomeClass::Constructor(void) {<br />
privateVar1 = NULL;<br />
privateVar2 = true;<br />
}<br />
From what I understand the first instance would be useful when inheritance is involved.. Perhaps this is just a favored style?
Cheers,
Mark
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
|
|
|
|
|
Const and reference members can only be initialized in an intializer list. Moreover if we don't initialize the variables in the initializers list the compiler will have to do it for us and later on in the constructor this will be initialized again. Hence, there would be two calls for variable initialization
You talk about Being HUMAN. I have it in my name
AnsHUMAN
|
|
|
|
|
_AnsHUMAN_ wrote: Moreover if we don't initialize the variables in the initializers list the compiler will have to do it for us and later on in the constructor this will be initialized again.
I doubt that.
The easiest way for a compiler to provide default values is to do the following
- Request memory block for the object
- Overwrite the entire block with zeros.
- Continue the construction process.
Providing code to set the default value for each member is thus not required.
Any other initialization, beyond the default value, would occur regardless.
|
|
|
|
|
In standard C++, member without default constructor are not initialized to 0 automatically but are random.
Philippe Mori
|
|
|
|
|
Philippe Mori wrote: In standard C++, member without default constructor are not initialized to 0 automatically but are random.
Wrong.
Section 4.9.5 C++ specification clearly states that class member variables have a default value if they do not have an initializer.
class Any
{
....
int var1 = 2;
int var2;
}
Local variables (those declared in a method) have not such default value.
|
|
|
|
|
|
Philippe Mori wrote: As far as I can tell, you have misunderstood the standard.
Yep, you are correct.
|
|
|
|
|
Some compilers initialize memory to zero. But for compatibility reasons, the C++ standard leaves (built-in type) members untouched (I don't know the latest one). Of course, if your members have default constructors, they will be called (before the constructor body) unless you place them in the initializer list.
|
|
|
|
|
w-peuker wrote: Some compilers initialize memory to zero. But for compatibility reasons, the C++ standard leaves (built-in type) members untouched (I don't know the latest one).
Wrong. The only compilers that leave data members non-initialized would be compilers that are not implementing the ANSI C++ specification.
Section 4.9.5 C++ specification clearly states that class member variables have a default value if they do not have an initializer.
class Any
{
....
int var1 = 2;
int var2;
}
<pre>
This happens regardless of how construction occurs.
|
|
|
|
|
See my answer above. You have misunderstood the standard. I have found many links that proove otherwise. By the way, your example is not even valid C++ code.
Philippe Mori
modified 27-Jul-12 21:04pm.
|
|
|
|
|
Philippe Mori wrote: See my answer above. You have misunderstood the standard.
Yes, you are correct.
|
|
|
|
|
It's just a matter of style, although I think the first option is preferred. MSDN has this to say[^] on the matter. You may also like to check if Bjarne Stroustrup has more to offer.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
|
Thanks George
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
|
|
|
|
|
...and don't forget that the compiler processes the initializer list following the declaration order given in the class definition.
So you better stick to that order in the list (to prevent confusion). There are tools availabe that check this (e.g. cppcheck)
|
|
|
|
|
// Is there any particular reason
Yes :
class A
{
public:
A();
A(int);
A& operator=(int);
};
class B
{
A m_a;
public:
B() { m_a = 3; }
};
They sought it with thimbles, they sought it with care;
They pursued it with forks and hope;
They threatened its life with a railway-share;
They charmed it with smiles and soap.
|
|
|
|
|
The difference is that, in the first way of initialization (known as 'Initialization List'), the constructors of the initialized members are called.
While in the second option, all the objects get constructed before reaching the first executable statement of the constructor. Hence in the second way of initialization, the assignment operators gets called.
|
|
|
|