A debug-only assertion that the parameters are valid helps catch bugs (inconsistent calling code checks) and can remind you of these design choices later when you go to call a member function from a new location.by design not passing parameters to a method that will cause an invalid state
as opposed to additional run time checks (when possible).
especially in the called code. i would think it would be better to perform such checks in the calling code before calling the object method. if your parameters are whacked, odds are you don't want to make the call anyway and want to somehow recover instead.
the easiest bugs to fix are the ones you prevent by design (or coding convention w/ strict coder discipline).
an ounce of prevention can prevent a pound of cure. likewise, an ounce of design can sometimes prevent a pound of runtime checks. <g>.
Constructor gotcha's?
One thing that tripped me up in the early days of learning c++ was calling virtual functions in constructors.
Do not call virtual functions in constructors, as they will not work properly!
^_^
One thing that tripped me up in the early days of learning c++ was calling virtual functions in constructors.
Do not call virtual functions in constructors, as they will not work properly!
Depends on what you mean by "not work properly" though. Calling virtual functions in constructors is well defined and well behaved by the language, but may not be obvious or work how you initially expect it work. I suspect that the problem was a lack of understanding of what will happen, rather than it "not working properly".
Depends on what you mean by "not work properly" though. Calling virtual functions in constructors is well defined and well behaved by the language, but may not be obvious or work how you initially expect it work. I suspect that the problem was a lack of understanding of what will happen, rather than it "not working properly".One thing that tripped me up in the early days of learning c++ was calling virtual functions in constructors.
Do not call virtual functions in constructors, as they will not work properly!
It is hard to argue that the way C++ works in that regard as "intuitive", however, unless you are familiar with a lot of the "dusty corners" of the language. As such, to preserve your own sanity and the sanity of those people trying to read your code it should probably be avoided if at all possible
(This applies to destructors too, which also have the same "problem")It's also why people don't recommend giving virtual function parameters default values - it doesn't do what most people expect it to.
Author
A debug-only assertion that the parameters are valid helps catch bugs (inconsistent calling code checks) and can remind you of these design choices later when you go to call a member function from a new location.
yes, an excellent way to help trap out those you don't catch by inspection. unfortunately, you have to throw bad data at the method for it to show up. and if you don't happen to do that before release, you may still have issues later.
it seems that inspection, perhaps augmented by parameter validation, is the most reliable tool we have for making sure code is bullet proof. of course this requires source access. something we may not have.
Author
Maybe you should add a few unittests then to be sure it works correctly?
i'm blessed in that i have full source code access to everything except the c/c++ RTL, directx, and asm output from VS express.
in the case of a 3rd party lib, nothing beats a solid product from a good engineering firm. SOS sound operating system, ProComm telecom lib, DiamondWare STK sound tool kit, and Rendermorphics Reality Lab from back in the day come to mind.
for something of a more questionable nature - automated black box testing of the entire input domain is the next most thorough thing one can do. but such validation tests may be overly time consuming or simply not practical due to the size of the input domain set. A fallback alternative is automated back box testing of the _expected_ input domain set. but again even this my not be practical or possible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
