best way to avoid calling virtual methods (directly or indirectly) from a constructor
-
For those of you who have adopted one of the various techniques that have been proposed to avoid inadvertantly calling a virtual method from a constructor, which method did you choose? So far, this one [^] seems the most promising to me but I've not tripped over this problem (that I'm aware of ;) ) till today so I have not given it much thought in the past and I need some guidance.
-
For those of you who have adopted one of the various techniques that have been proposed to avoid inadvertantly calling a virtual method from a constructor, which method did you choose? So far, this one [^] seems the most promising to me but I've not tripped over this problem (that I'm aware of ;) ) till today so I have not given it much thought in the past and I need some guidance.
If you use test driven development and write unit tests for your code you pick up very quickly when you've committed a virtual crime in a constructor or destructor. Another good way is never inheriting concrete classes but in existing code bases you've often not got that choice (and if you're using something like MFC you're well stuck). Cheers, Ash
-
For those of you who have adopted one of the various techniques that have been proposed to avoid inadvertantly calling a virtual method from a constructor, which method did you choose? So far, this one [^] seems the most promising to me but I've not tripped over this problem (that I'm aware of ;) ) till today so I have not given it much thought in the past and I need some guidance.
The indicated method is a good one. However, it's not "illegal" or "invalid" to call a virtual method in a ctor so long as you are aware of what you're doing and that's what you intend. You just need to remember what it will actually call in that instance.
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
-
For those of you who have adopted one of the various techniques that have been proposed to avoid inadvertantly calling a virtual method from a constructor, which method did you choose? So far, this one [^] seems the most promising to me but I've not tripped over this problem (that I'm aware of ;) ) till today so I have not given it much thought in the past and I need some guidance.
Looks like a malposed attempt to resolve a malposed problem (so it is a good question!). Actually calling a vistual function from a constructor is LEGAL. It is not something the dumb compiler allows even if shouldn't. The problem is that C++ is a "complex language" and that what such a call will do may be not what dumb programmers suppose it to do. But whoever has a minimum of logic should understand that -during the execution of a base constructor- the derived component is not yet come into existence, and hence the base v-table cannot contain references to it. The virtual function at that point is not yet been overridden. Now trying to find a way to "fix the language" to disallow this is like trying to make C++ to turn into something else. It is not something related to your implementation. Every C++ programmer MUST KNOW what happens if a constructor / destructor calls a virtual function. Ther is nothing to fix, here. Unless you don't like how C++ works. But -at that point- just use another language. Afer all, if you do
#define begin {
#define end }you'd better to use Pascal/Delphi/Ada, and not C/C++/C#/Java/D ...
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Looks like a malposed attempt to resolve a malposed problem (so it is a good question!). Actually calling a vistual function from a constructor is LEGAL. It is not something the dumb compiler allows even if shouldn't. The problem is that C++ is a "complex language" and that what such a call will do may be not what dumb programmers suppose it to do. But whoever has a minimum of logic should understand that -during the execution of a base constructor- the derived component is not yet come into existence, and hence the base v-table cannot contain references to it. The virtual function at that point is not yet been overridden. Now trying to find a way to "fix the language" to disallow this is like trying to make C++ to turn into something else. It is not something related to your implementation. Every C++ programmer MUST KNOW what happens if a constructor / destructor calls a virtual function. Ther is nothing to fix, here. Unless you don't like how C++ works. But -at that point- just use another language. Afer all, if you do
#define begin {
#define end }you'd better to use Pascal/Delphi/Ada, and not C/C++/C#/Java/D ...
2 bugs found. > recompile ... 65534 bugs found. :doh:
Oh, I am aware that it is legal and the C++ behavior makes sense but I unfortunately tripped over it anyway. I wasn't criticizing the language as I still consider C++ my language of choice. I was merely looking for an approach to initialization that would protect me from inadvertantly calling some virtual function from a constructor as it is so tempting with some class hierarchies. The effect of doing so blindly had subtle effects that had me chasing my tail for a bit, quite embarrassing but a reality with so many rules to remember. Looking for a pattern to use that will allow me to initialize the base and derived class objects, with any function (virtual or not) which requires avoiding calling methods from the constructor directly except for simple member initialization lists and such. I'm definitely not trying to fix the language. :-D thanks for the comments.