4

We have several C++ functions that will be implemented in phase 2 of our project that are part of the public interface or their respective classes and modules. Because they are part of the public interface, we think they should be present, at least in the headers, during phase 1 so that we are still thinking about them as we implement the rest of the classes. However, since they are unimplemented, we want no one to call them. We would like this check to occur at compile time, to ensure correctness.

My desires are:

  • Compile time (could be an error or warning; warnings are better because they are more flexible - we can selectively turn them off)

  • Works on G++4.8.1 and doesn't kill the build under Visual Studio 2013 (we use Visual Studio/VisualAssistX only as an editor but the refactoring tools don't work without building)

  • Not too hard to understand what was done and why

  • Functions are present in class documentation (we can include some \warning not implemented in phase 1 notation for doxygen to pick up)

I am considering three options:

  • A belt and suspenders approach of marking them as deprecated (which will generate a warning) and throwing a custom exception - this is almost what I want except the compiler warning that it is "deprecated" is opposite of the real situation: a deprecated method works now but won't work later; this method will work later but does not work now

  • Another answer tells how to forbid using a function while still having it exist - this is good but unreadable and hard to search for. Plus, it is a compile-time error - we can't just let some functions call it if we change our minds - it is all or nothing. And making every unimplemented function a template makes me wonder if the trick will always work. For example, virtual functions can't be templates.

  • Just putting them in as a comment - Keeps people from calling them, but they also don't show up in auto-generated documentation (and we can't decide later to have selective calling)

Is there a better way? And if not is there a reason to prefer the template or comment options over the deprecated option?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Eponymous
  • 6,143
  • 4
  • 43
  • 43
  • [`static_assert`](http://en.cppreference.com/w/cpp/language/static_assert)? – Some programmer dude Apr 01 '15 at 15:15
  • @JoachimPileborg That (with templates) is what is used in the [forbid using](http://stackoverflow.com/a/18814056/309334) answer I mention above. [This answer](http://stackoverflow.com/a/5246686/309334) tells why the templates are necessary. – Eponymous Apr 01 '15 at 15:20

1 Answers1

3

As alternative:

You can just declare them without definition, so you get link error.
You may then provide a library not_yet_implemented with empty definition to allow the premature usage of these functions.

or

Mark you method deleted: = delete, eventually by wrapping that in a macro

#define NOT_YET_IMPLEMENTED = delete
Jarod42
  • 203,559
  • 14
  • 181
  • 302
  • By including the `not_yet_implemented` library, it would effectively make the function callable everywhere - removing the check for not-implemented-ness. The situation where I can conceive of wanting to do this is something like `int foo(){ do_stuff_needed_in_all_phases(); if(condition_only_true_in_phase2){ unimplemented_function(); } }` which would save us from having to reimplement `foo()` in phase 2. However, I'd like `int bar(){ unimplemented_function(); }` to still fail. – Eponymous Apr 01 '15 at 15:40
  • 1
    Because of the above, I like my "deprecated" solution better. However, this is the only answer, so I'll accept it. Thank you for taking time out to work on someone else's problem and making the Internet a better place. – Eponymous Apr 02 '15 at 19:50