|
Thanks Michael,
Do you think it is C++ standard to initialize POD type to zero?
regards,
George
|
|
|
|
|
I deduce yes, by looking at the disassembly. But I wouldn't trust VC6 when it comes to current standards. Try with VC8 or 9 or check out web pages about the standard like this one[^]
|
|
|
|
|
Thanks Michael,
Could you let me know which part of the wiki page do you refer which relates to my question please? It is too long. 
regards,
George
|
|
|
|
|
|
Hi Mike,
What you referred is a Google search result. What I am asking is which part of the standard do you think relates to my question?
regards,
George
|
|
|
|
|
Well, I don't have the entire spec memorized. I did some initial research, and gave you a starting point for you to find out the answer yourself.
|
|
|
|
|
Thanks Mike,
I find this stuff.
http://www.codeguru.com/forum/showthread.php?p=1695187&postcount=9[^]
Seems this statement "otherwise, the object is zero-initialized" in post #9 covers this topic. Any comments?
But do you think,
T t = T(); and T t; are the same? I think the standard only covers the 1st case, for T t it is undefined value?
regards,
George
|
|
|
|
|
Hello everyone,
Even if I have tested with MSVC 2008 that no resource leak, I want to confirm with you whether it is good code to maintain resource and avoid resource leak. Also whether the code is dependent on some non-Spec regulated points, e.g. MSVC 2008 specific things.
The design pattern is, embed a sub-object into another object (e.g. embed Goo object g into Foo object), but in destructor of Foo, destructor of its sub-object (e.g. Goo object g) is not called explicitly.
I have tested destructor of Goo object g will be called in MSVC 2008, but I am not sure whether we could rely on this -- when object goes out of scope, its sub-object also goes out of scope and destructor always gets called?
#include <iostream>
using namespace std;
class Goo {
public:
Goo()
{
cout << "constructing Goo" << endl;
}
virtual ~Goo()
{
cout << "destructing Goo " << endl;
}
};
class Foo {
public:
Goo g;
Foo (Goo _g) : g (_g)
{
cout << "constructing Foo " << endl;
}
virtual ~Foo()
{
cout << "destructing Foo " << endl;
}
};
int func()
{
Goo g;
Foo f (g);
return 0;
}
int main()
{
func();
return 0;
}
thanks in advance,
George
|
|
|
|
|
Yes it gets called automatically. What you've done is a composition and it is Not bad at all, but this is :
Goo* g;
If you are using a raw pointer/heap-allocate inside your "container" class, then it's unsafe. In the sense, you need to manually checks if it's get getting deleted properly.
OK,. what country just started work for the day ? The ASP.NET forum is flooded with retarded questions. -Christian Graus
Best wishes to Rexx[^]
|
|
|
|
|
Thanks VuNic,
Question answered.
regards,
George
|
|
|
|
|
George_George wrote: The design pattern is, embed a sub-object into another object (e.g. embed Goo object g into Foo object),
Where did you get the code for this design pattern.
|
|
|
|
|
Thanks Rajkumar,
I simplified the code from the code written by others. Any answers to my original question?
regards,
George
|
|
|
|
|
can you give the link, and what is the name of such design pattern.
|
|
|
|
|
Sorry, Rajkumar,
It is not a public design pattern, or else I can learn and do research by myself. It is from some public code.
Any comments or answers to my original question?
regards,
George
|
|
|
|
|
The Goo Constructor Goo( Goo g ) isnt defined, so it would have standard implementation, that means copy all standard values. So there should be no leak.
Good code would implement the Goo( Goo g ) to clarify. What if you extend the Goo class with a object pointer? 
Greetings from Germany
|
|
|
|
|
Thanks KarstenK,
What do you mean "What if you extend the Goo class with a object pointer?"? Could you show some pseudo code please?
regards,
George
|
|
|
|
|
I altered your code, and see this.
include <iostream>
class Goo
{
public:
int id;
Goo() {
printf("Goo()\n");
}
virtual ~Goo() {
printf("~Goo(%d)\n", id);
}
};
class Foo
{
public:
Goo g;
Foo(const Goo& v) : g(v) {
printf("Foo()\n");
g.id = 2;
}
virtual ~Foo() {
printf("~Foo()\n");
}
};
void func()
{
printf("--> func()\n");
Goo g;
g.id = 1;
printf("sep\n");
Foo f(g);
printf("<-- func()\n");
}
void main()
{
printf("before func()\n");
func();
printf("after func()\n");
}
Result:
before func()
--> func()
Goo()
sep
Foo()
<-- func()
~Foo()
~Goo(2)
~Goo(1)
after func()
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
What do you want to prove in this sample?
regards,
George
|
|
|
|
|
George_George wrote: What do you want to prove in this sample?
It's the answer to your original question. 
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
I have two questions,
1. whether there is resource leak;
2. the order of destructors (of current instance and members) being called.
Your sample answered (1), but how about (2)?
regards,
George
|
|
|
|
|
George_George wrote: 2. the order of destructors (of current instance and members) being called.
Your sample answered (1), but how about (2)?
Why do you ask (2) [the order of destructions] again?! 
You have already seen the result <pre> section in my previous reply.
Ah... Maybe you did not scroll down the page. 
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
I have looked at the result -- I think it is what you mean. What I mean is (sorry I have not made myself understood), is it Spec regulated that destructor of current object instance is invoked before destructors of member variables? Or implementation specific things?
regards,
George
|
|
|
|
|
George_George wrote: I have looked at the result -- I think it is what you mean. What I mean is (sorry I have not made myself understood), is it Spec regulated that destructor of current object instance is invoked before destructors of member variables? Or implementation specific things?
I got your point now!
See comp.lang.cpp[^] for Section 12.4 of ISO/IEC 14882:1998.
(... becasue I'm unable to copy-and-paste. )
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
It just mentioned in the reverse order of construction. Not mentioning the order of construction in the link you referred.
I have found the initialization order below. I think it means construction of member variables before the completion of constructor of current object. I think it also means the construction of member variables are before construction of current object.
So, the reverse order should be, destruct current object, then destruct member variables. Right?
--------------------
12.6.2 Initializing bases and members [class.base.init]
Initialization shall proceed in the following order:
— First, and only for the constructor of the most derived class as described below, virtual base classes shall
be initialized in the order they appear on a depth-first left-to-right traversal of the directed acyclic graph
of base classes, where “left-to-right” is the order of appearance of the base class names in the derived
class base-specifier-list.
— Then, direct base classes shall be initialized in declaration order as they appear in the base-specifier-list
(regardless of the order of the mem-initializers).
— Then, nonstatic data members shall be initialized in the order they were declared in the class definition
(again regardless of the order of the mem-initializers).
— Finally, the body of the constructor is executed.
[Note: the declaration order is mandated
--------------------
regards,
George
|
|
|
|
|
George_George wrote: It just mentioned in the reverse order of construction. Not mentioning the order of construction in the link you referred.
Hey, you only asked about resource leak, asked whether the destructors not being called, and asked the order of destruction. Why should I answer you the order of construction?!
George_George wrote: I have found the initialization order below. I think it means construction of member variables before the completion of constructor of current object. I think it also means the construction of member variables are before construction of current object.
So, the reverse order should be, destruct current object, then destruct member variables. Right?
In your case, "yes", because your example constructs Goo member in the initialization list, which is earlier than Foo constructor.
Maxwell Chen
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
