One of the problem with template usage occurs occurs in the following scenario. For templatised functions and classes, the input template arguments usually have little or no restriction on the class that can be used, e.g.
Of course the compile will fail if you try to use an input type, T, that doesn't have the specialised interface you want, but the compile time error message is often very verbose and its difficult to find the error. An idea which is merging into the c++ mainstream as well as that used by the boost concept checking library is to characterise common behaviours into Concepts. A simplified version of this is utilised here.
Include the following at the top of any translation unit that requires compilation of signals and/or slots.
Since it is a collection of macros and template functions/classes, no linking is required if you are only utilising this functionality.
Usage is fairly simple. There are two steps:
If you are using an existing concept (see below), skip through to the concept check. Otherwise:
The example here is the same as that used in src/tests/concepts.cpp:
Hand-crafting the concept testing function will often require a little care to ensure the concept is appropriately covered.
Once you have a test in place, you only need to insert compile_time_concept_check() calls wherever you need them. Keep in mind, the sole purpose of these is to provide convenient error logs when something goes wrong.
- @ref changelogConcepts "ChangeLog"