You can use pure virtual functions (= 0;) for inherited classes, or more commonly, declare them but not define them. You can't call a function with no definition.
DeadMG
2010-07-22 23:27:13
views:
258answers:
6
A:
Pure virtual functions will need an implementation in one of the derived classes.
jamesdlin
2010-07-23 03:01:33
The point is not to do that. That way if they're tried to call, it'll fail.
DeadMG
2010-07-23 09:07:09
@DeadMG: the code won't compile, making the rest of the (already implemented) class useless.
rubenvb
2010-07-23 12:38:12
@DeadMG: The goal is to make sure that the specific *methods* can't be invoked, not to completely break existing derived classes (or consumers of the base class itself, which would suddenly become non-instantiable). And if a derived class then were to provide a stub implementation just to unbreak the build, then when the base class does provides the actual method implementation, the derived class would still happily use the wrong version. Great. Using pure virtual methods is pointless. (Your second recommendation about simply not implementing the methods is fine, though.)
jamesdlin
2010-07-27 08:56:44
Best option, methinks. If the code isn't usable code, just don't check it in until it's in a usable state. No harm if they can't use it anyway. Or branch-then-merge.
GMan
2010-07-22 23:29:05
+13
A:
The simplest answer is to tell them. Communication is key whenever you're working with a group of people.
A more robust (and probably the best) option is to create your own branch to develop the new feature and only merge it back in when it's complete.
However, if you really want your methods implemented in the main source tree but don't want people using them, stub them out with an exception or assertion.
Cogwheel - Matthew Orlando
2010-07-22 23:29:39
+1. for assert. Its the most direct answer for doing exactly what the question was asking.
Akusete
2010-07-22 23:52:04
assert/exception way is the said communication but with means of the code instead of verbal/chat communication. And in this case it should be preferred over verbal. Or what else? Every time one made a function stub, one have to bother his colleagues with meetings or phone calls, when most of them wouldn't ever call the stub?
Alsk
2010-07-23 09:44:12
Fabio Fracassi
2010-07-23 11:48:14
@Alsk, indeed I was intending "tell them" to be broadly applicable to many forms of communication (e-mail, comments, etc.). I personally would rather know not to use a function because that fact was communicated with me than to try and use it only to find out at compile/runtime that I shouldn't have been in the first place.
Cogwheel - Matthew Orlando
2010-07-23 17:19:51
+7
A:
You should either, just not commit the code, or better yet, commit it to a development branch so that it is at least off your machine in case of catastrophic failure of your box.
This is what I do at work with my git repo. I push my work at the end of the day to a remote repo (not the master branch). My coworker is aware that these branches are super duper unstable and not to be touched with a ten foot pole unless he really likes to have broken branches.
Git is super handy for this situation as is, I imagine, other dvcs with cheap branching. Doing this in SVN or worse yet CVS would mean pain and suffering.
docgnome
2010-07-22 23:34:14
Trust me, not nearly as much suffering as you get if you don't have version control. Even RCS on NFS is better than that. (Just. You might as well use VSS in that case for all the usability of that.)
Donal Fellows
2010-07-23 09:37:42
+7
A:
I actually like the concept from .Net of a NotImplementedException. You can easily define your own, deriving from std::exception, overriding what as "not implemented".
It has the advantages of:
- easily searchable.
- allows current & dependent code to compile
- can execute up to the point the code is needed, at which point, you fail (and you immediately have an execution path that demonstrates the need).
- when it fails, it fails to a know state, so long as you're not blanketly swallowing exceptions, rather than relying upon indeterminable state.
Nathan Ernst
2010-07-23 00:09:31
+1
A:
Assert is the best way. Assert that doesn't terminate the program is even better, so that a coworker can continue to test his code without being blocked by your function stubs, and he stays perfectly informed about what's not implemented yet.
In case that your IDE doesn't support smart asserts or persistent breakpoints here is simple implementation (c++):
#ifdef _DEBUG
// 0xCC - int 3 - breakpoint
// 0x90 - nop?
#define DebugInt3 __emit__(0x90CC)
#define DEBUG_ASSERT(expr) ((expr)? ((void)0): (DebugInt3) )
#else
#define DebugInt3
#define DEBUG_ASSERT(expr) assert(expr)
#endif
//usage
void doStuff()
{
//here the debugger will stop if the function is called
//and your coworker will read your message
DEBUG_ASSERT(0); //TODO: will be implemented on the next week;
//postcondition number 2 of the doStuff is not satisfied;
//proceed with care /Johny J.
}
Advantages:
- code compiles and runs
- a developer get a message about what's not implemented if and only if he runs into your code during his testing, so he'll not get overwhelmed with unnecessary information
- the message points to the related code (not to exception catch block or whatever). Call stack is available, so one can trace down the place where he invokes unfinished piece of code.
- a developer after receiving the message can continue his test run without restarting the program
Disadvantages:
- To disable a message one have to comment out a line of code. Such change can possibly sneak in the commit.
P.S. Credits for initial DEBUG_ASSERT implementation go to my co-worker E. G.
Alsk
2010-07-23 09:32:33