4

I'm rewriting my Windows C++ Native Library (an ongoing effort since 2002) with public release in mind. For the past 10 years I've been the sole beneficiary of those 150+ KLOC and I feel others might find good uses for it also.

Currently the entire library is quite-templated and header only. That means all code is in the body of the classes. It's not very easy to manage but it's OK.

I'm VERY tempted, after reading several C++ library coding guidelines, to break it into .hpp + .inl files. Experimentally done so for a few classes and it does increase readability and makes it easier for others to deal with. I know where everything is at any given time. But other users might want to a quick overview of a classes declaration... and the definition only if necessary (debugging).

QUESTION:
What are the pros/cons of splitting the member definitions from the class' definition for a class template? Is there a commonly accepted practice.

This is important for me because it's a one way road. I can't refactor it the other way later on so any feedback matters...

LittleBobbyTables - Au Revoir
  • 32,008
  • 25
  • 109
  • 114
CodeAngry
  • 12,760
  • 3
  • 50
  • 57
  • Opinions are great, but not on-topic for Stackoverflow. – Casey Aug 05 '13 at 18:36
  • @CodeAngry [Read this](http://blog.stackoverflow.com/2010/09/good-subjective-bad-subjective/). There's still the "risk" that even a *good* opinion-based question will be closed and re-opened (and so on, with lots of discussion in the comments). – dyp Aug 05 '13 at 19:02
  • why not let doxygen create the quick class overview, and save yourself a lot of work? – TemplateRex Aug 05 '13 at 20:28
  • @TemplateRex Does doxygen work with VC XML comments? I've never tried it as I use XML comments. – CodeAngry Aug 05 '13 at 20:43
  • 1
    http://www.stack.nl/~dimitri/doxygen/manual/xmlcmds.html – TemplateRex Aug 05 '13 at 20:47
  • @TemplateRex This'll keep me busy for a while tomorrow. *The question still stands though...* Rewriting will happen anyways, I need to review everything and improve readability, enforce a unitary naming convention *(which is 80% now)*, fix stuff. Some code is quite old... – CodeAngry Aug 05 '13 at 21:08

1 Answers1

1

I've found my answer in another question.

Question: When should I consider making a library header-only? - and answer is here^.

And the answer is I will break it into .cpp and .hpp files and make it ready to compiler both as header only and static library or DLL.

@Steve Jessop:

If you think your non-template library could be header-only, consider dividing it into two files anyway, then providing a third file that includes both the .h and the .cpp (with an include guard).

Then anyone who uses your library in a lot of different TUs, and suspects that this might be costing a lot of compile time, can easily make the change to test it.

^ this is an awesome idea. It will take a bit more work but it's SO versatile.

UPDATE

It's important to explicitly instantiate^ the templated classes in the .cpp files.

Community
  • 1
  • 1
CodeAngry
  • 12,760
  • 3
  • 50
  • 57
  • 1
    This answer is about *non-template* libraries. How does that relate to your *template-only* problem? – dyp Aug 06 '13 at 15:17
  • @DyP The library has about 50% of the classes as templates *(some of which can be explicitly initialized, like string class and such)*. I'm making it hybrid and already done some tests. A part of the code `.cpp` gets compiled to a `.lib` and the rest is `.inl`. So templates stay templates and non-template classes will go into the `.lib`. Reduces compile times drastically too. *PS: I said quite-templated not template-only.* – CodeAngry Aug 06 '13 at 15:26
  • 1
    What I meant with *template-only* is that (I thought) the problem with separation of class definition and member (function) definition was only related to templates, because a) the syntax is ugly in the case of templates and b) for non-template classes, there are well-known advantages of this separation (compilation time, class dependencies) but these don't apply for the template case. – dyp Aug 06 '13 at 15:36
  • @DyP I will most likely separate functionality. Already ported about 5 classes. It looks much cleaner now. The `.cpp` or `.inl` files are more set and forget. Write the code, make sure it works, get it out of your sight. Keeping it in the class body keeps it in front of you all the time, especially if you group related classes in the same header. It's more work to write things... but the result is better. – CodeAngry Aug 06 '13 at 15:44