Suppose that I have two template functions declared in a header file:
template <typename T> void func1(const T& value);
template <typename T> void func2(const T& value);
And suppose that the implementation of these functions (also in a header file and not in a source file, because they are templates) uses some implementation helper function, which is also a template:
template <typename T> void helper(const T& value) {
// ...
}
template <typename T> void func1(const T& value) {
// ...
helper(value);
}
template <typename T> void func2(const T& value) {
// ...
helper(value);
}
In any source file that I include the header file, the helper function will be visible. I don't want that, because the helper function is just an implementation detail. Is there a way to hide the helper function?
A common approach (as used in many Boost libraries, for example) is to put the helper in a namespace called details, possibly in a separate header (included from the "public" header).
There's no way to prevent it from being visible, and callable, but this quite clearly indicates that it is part of the implementation, not the interface.
The established precedent is to put that sort of thing in a specially (i.e. consistently) named nested namespace. Boost uses namespace details, Loki uses namespace Private. Obviously nothing can prevent anyone from using the contents of those namespaces, but both names convey the meaning that their contents aren't intended for general consumption.
That being said, an easy alternative is to turn func1 and func2 from free function templates into static member function templates of some common class; this way, helper can simply be a private member of said class, invisible to the outside world:
struct funcs {
template<typename T>
static void func1(T const& value) {
// ...
helper(value);
}
template<typename T>
static void func2(T const& value) {
// ...
helper(value);
}
private:
template<typename T>
static void helper(T const& value) {
// ...
}
};
Two options off the top of my head:
Move all the implementation to an hpp file which you include at the bottom of your h file.
Refactor your code as class templates, then make the helpers private.
Since the user of your code needs to see the full definition of the func1 function, its implementation, nor its helper function implementation, cannot be hidden.
But if you move the implementation into another file, the user will only have to be confronted with the template declaration:
//templates.h
template< typename T > void f1( T& );
#include <templates_impl.h> // post-inclusion
And the definition:
// templates_impl.h
template< typename T > void f1_helper( T& ) {
}
template< typename T > void f1( T& ) {
// the function body
}
In C++20 you can now use modules.
For this you could create a module some_module.cppm holding all functions and marking only the interface (either the individual functions or a namespace) with export while not exposing the helper functions:
// some_module.cppm
export module some_module;
template <typename T>
void helper(const T& value) {
// ...
}
export
template <typename T>
void func1(const T& value) {
// ...
helper(value);
}
export
template <typename T>
void func2(const T& value) {
// ...
helper(value);
}
In the case above only the functions func1 and func2 are exported and can be accessed inside main.cpp:
// main.cpp
#include <cstdlib>
import some_module;
int main() {
func1(1.0);
func2(2.0);
return EXIT_SUCCESS;
}
In clang++12 you can compile this code with the following three commands:
clang++ -std=c++2b -fmodules-ts --precompile some_module.cppm -o some_module.pcm
clang++ -std=c++2b -fmodules-ts -c some_module.pcm -o some_module.o
clang++ -std=c++2b -fmodules-ts -fprebuilt-module-path=. some_module.o main.cpp -o main
./main
I would (as said before) make a template class, make all functions static and the helper function private. But besides that I'd also recommend making the constructor private as shown below:
template <typename T>
class Foo{
public:
static void func1(const T& value);
static void func2(const T& value);
private:
Foo();
static void helper(const T& value);
}
When you make the constructor private, the compiler won't allow instances of this template class. So the code below would become illegal:
#include "foo.h"
int main(){
int number = 0;
Foo<int>::func1(number); //allowed
Foo<int>::func2(number); //allowed
Foo<int>::helper(number); //not allowed, because it's private
Foo<int> foo_instance; //not allowed, because it's private
}
So why would someone want this? Because having different instances that are EXACTLY the same is something you probably never want. When the compiler tells you that the constructor of some class is private, then you can assume that having different instances of it would be unnecesarry.
I know you mean that you want to hide it so finely that callers have no way to find your helper functions as long as they don't change your code file. I know it so well because I have very similar needs recently.
So how about wrapping your helper functions in an anonymous namespace? This is recently the most elegant style I found:
namespace YourModule
{
namespace
{//Your helper functions}
//Your public functions
}
This practice effectively hides your internal functions from the outside. I can't find any way that a caller can access functions in anonymous namespaces.
It's usually not a good practice, as answered by #user3635700 , to convert your namespace to a class full of static functions, especially when you have templates of static variables like:
template <uint8_t TimerCode>
static uint16_t MillisecondsElapsed;
If this variable appears in a class, you'll have to initialize it somewhere outside the class! However, you can't do it because it's a template! WTF!
It seems that an anonymous namespace in the header file, which is criticized by some, is the only and the most perfect solution to our needs.
Related
I have a class template that looks like this:
foo.h
template<class C>
class Foo
{
public:
void memberFunc();
};
#include "foo.tpp"
foo.tpp
void Foo::memberFunc()
{
...
}
Ignore the .tpp file, it's just something I do to give the illusion of separating declaration and implementation, obviously that's (kind of) not possible with templates.
My implementation file is much longer in reality, and inside it I have some global scope helper function templates that the member functions use, functions that don't make sense as member functions and that I don't want users of the class to have anything to do with.
template<class C> int helper1() { ... }
template <class C> void helper2() { ... }
template<class C>
void Foo<C>::memberFunc()
{
...
helper1<float>();
...
helper2<C>();
...
}
I do this all the time in .cpp-implementation files and I forgot that when I do it in this fake version of a .cpp file, the declaration and implementation of these little helper functions actually end up in the class template header file. This leads to users of the class template header getting their namespaces cluttered with helper functions that are useless outside the member function implementations.
Obviously I could just put them in a namespace:
namespace foo_helpers
{
template<class C> void helper1() {...}
template<class C> int helper2() {...}
}
But it still leads to outside code being able to use these functions. They only matter to the implementation of the member functions and I want that to be reflected.
When looking for a solution, I learned about the concept of unnamed namespaces. As I understand it, they only allow the current translation unit access to its contents. That sounds like exactly what I need, so I changed the helper functions to this:
namespace
{
template<class C> void helper1() {...}
template<class C> void helper2() {...}
}
But it doesn't work, the functions are still usable from files that include the header.
Is there any way to hide these helper functions from outside code?
I have an overloaded function, their definitions are the same and only one parameter change.
So, I tried to create a template function but when I call it I got a symbol lookup error.
Header file
void func(Myobject obj);
void func(MySecondObject obj);
Source file
template<typename T>
void func(T obj) { obj.foo(); }
Test file
#include "MyHeaderFile.h"
func(MySecondObject()); // symbol lookup error at runtime
Thanks.
If you say
void func(Myobject obj);
void func(MySecondObject obj);
then you promise to the compiler that it will eventually find
void func(Myobject obj)
{ /* implementation */ }
void func(MySecondObject obj)
{ /* implementation */ }
Since you didn't provide these implementations (there are no definitions for these symbols you declared), you get an error.
What you can do however is this:
Header file
void func(Myobject obj);
void func(MySecondObject obj);
Source file
template<typename T>
void func_impl(T obj) { obj.foo(); }
void func(Myobject obj) { func_impl(obj); }
void func(MySecondObject obj) { func_impl(obj); }
This allows you to declare and define "real" (non-templated) functions for your users, but you can still implement all of them by delegating the work to the same template function. It is best practice to put the func_impl into an unnamed namespace (namespace /* no name here */ { /* code goes here */ }) which will make it internal to that translation unit (and also makes it clear that it's not intended to be seen/used by other code, without having to cross-reference the header).
(The following is already discussed at Why can templates only be implemented in the header file?).
An alternative approach is to declare the function template in the header, then define it in the source file and provide explicit instantiations for the types you want:
Header file
template<class T>
void func(T obj);
// Explicit instantiation declarations
extern template void func<Myobject>(Myobject obj);
extern template void func<MySecondObject>(MySecondObject obj);
Source file
template<typename T>
void func(T obj) { obj.foo(); }
// Explicit instantiation definitions
template void func<Myobject>(Myobject obj);
template void func<MySecondObject>(MySecondObject obj);
This approach is significantly more verbose, potentially confusing for users that are not template-affine, and trying to use it with the wrong type leads to linker errors instead of a nicer compiler error, so the first solution above can easily be the most appropriate.
Or you could define the entire template in the header file. There can be good reasons to avoid that though.
It seems that you want to have a template function with two explicit instantiations for MyObject and MySecondObject. Template function declaration should be in your header like that:
template<typename T>
void func(T obj);
Then in the corresponding source file you should provide generic implementation + explicit instantiations:
#include "header.hpp"
template<typename T>
void func(T obj)
{
obj.foo();
}
template void func<MyObject>(MyObject obj);
template void func<MySecondObject>(MySecondObject obj);
Then you can use that two versions in your code:
func(MyObject());
func(MySecondObject());
but call to func with another template parameter, e.g. func('c') will result in undefined reference.
cpp reference section "Explicit instantiation".
I would suggest defining the template specializations in the source file. It hides the template specializations in the current translation unit.
MyHeaderFile.h
template <typename T>
void func(T obj);
MyHeader.cpp
#include <iostream>
#include "MyHeaderFile.h"
template <typename T>
void func(T obj)
{
std::cout << "function name: " << __func__;
}
template void func<MySecondObject>(MySecondObject obj);
template void func<Myobject>(Myobject obj);
I hope this answer solves your problem.
Suppose that I have two template functions declared in a header file:
template <typename T> void func1(const T& value);
template <typename T> void func2(const T& value);
And suppose that the implementation of these functions (also in a header file and not in a source file, because they are templates) uses some implementation helper function, which is also a template:
template <typename T> void helper(const T& value) {
// ...
}
template <typename T> void func1(const T& value) {
// ...
helper(value);
}
template <typename T> void func2(const T& value) {
// ...
helper(value);
}
In any source file that I include the header file, the helper function will be visible. I don't want that, because the helper function is just an implementation detail. Is there a way to hide the helper function?
A common approach (as used in many Boost libraries, for example) is to put the helper in a namespace called details, possibly in a separate header (included from the "public" header).
There's no way to prevent it from being visible, and callable, but this quite clearly indicates that it is part of the implementation, not the interface.
The established precedent is to put that sort of thing in a specially (i.e. consistently) named nested namespace. Boost uses namespace details, Loki uses namespace Private. Obviously nothing can prevent anyone from using the contents of those namespaces, but both names convey the meaning that their contents aren't intended for general consumption.
That being said, an easy alternative is to turn func1 and func2 from free function templates into static member function templates of some common class; this way, helper can simply be a private member of said class, invisible to the outside world:
struct funcs {
template<typename T>
static void func1(T const& value) {
// ...
helper(value);
}
template<typename T>
static void func2(T const& value) {
// ...
helper(value);
}
private:
template<typename T>
static void helper(T const& value) {
// ...
}
};
Two options off the top of my head:
Move all the implementation to an hpp file which you include at the bottom of your h file.
Refactor your code as class templates, then make the helpers private.
Since the user of your code needs to see the full definition of the func1 function, its implementation, nor its helper function implementation, cannot be hidden.
But if you move the implementation into another file, the user will only have to be confronted with the template declaration:
//templates.h
template< typename T > void f1( T& );
#include <templates_impl.h> // post-inclusion
And the definition:
// templates_impl.h
template< typename T > void f1_helper( T& ) {
}
template< typename T > void f1( T& ) {
// the function body
}
In C++20 you can now use modules.
For this you could create a module some_module.cppm holding all functions and marking only the interface (either the individual functions or a namespace) with export while not exposing the helper functions:
// some_module.cppm
export module some_module;
template <typename T>
void helper(const T& value) {
// ...
}
export
template <typename T>
void func1(const T& value) {
// ...
helper(value);
}
export
template <typename T>
void func2(const T& value) {
// ...
helper(value);
}
In the case above only the functions func1 and func2 are exported and can be accessed inside main.cpp:
// main.cpp
#include <cstdlib>
import some_module;
int main() {
func1(1.0);
func2(2.0);
return EXIT_SUCCESS;
}
In clang++12 you can compile this code with the following three commands:
clang++ -std=c++2b -fmodules-ts --precompile some_module.cppm -o some_module.pcm
clang++ -std=c++2b -fmodules-ts -c some_module.pcm -o some_module.o
clang++ -std=c++2b -fmodules-ts -fprebuilt-module-path=. some_module.o main.cpp -o main
./main
I would (as said before) make a template class, make all functions static and the helper function private. But besides that I'd also recommend making the constructor private as shown below:
template <typename T>
class Foo{
public:
static void func1(const T& value);
static void func2(const T& value);
private:
Foo();
static void helper(const T& value);
}
When you make the constructor private, the compiler won't allow instances of this template class. So the code below would become illegal:
#include "foo.h"
int main(){
int number = 0;
Foo<int>::func1(number); //allowed
Foo<int>::func2(number); //allowed
Foo<int>::helper(number); //not allowed, because it's private
Foo<int> foo_instance; //not allowed, because it's private
}
So why would someone want this? Because having different instances that are EXACTLY the same is something you probably never want. When the compiler tells you that the constructor of some class is private, then you can assume that having different instances of it would be unnecesarry.
I know you mean that you want to hide it so finely that callers have no way to find your helper functions as long as they don't change your code file. I know it so well because I have very similar needs recently.
So how about wrapping your helper functions in an anonymous namespace? This is recently the most elegant style I found:
namespace YourModule
{
namespace
{//Your helper functions}
//Your public functions
}
This practice effectively hides your internal functions from the outside. I can't find any way that a caller can access functions in anonymous namespaces.
It's usually not a good practice, as answered by #user3635700 , to convert your namespace to a class full of static functions, especially when you have templates of static variables like:
template <uint8_t TimerCode>
static uint16_t MillisecondsElapsed;
If this variable appears in a class, you'll have to initialize it somewhere outside the class! However, you can't do it because it's a template! WTF!
It seems that an anonymous namespace in the header file, which is criticized by some, is the only and the most perfect solution to our needs.
I'm currently writing a template class for archiving (or serializing) and unarchiving data into/from a binary format. First off, I'm trying to close on what pattern I'll use. I am mostly inclined to using templates because unarchivers don't have an input type for method overloading. For instance, the following example is OK:
Archiver ar;
int i;
archive(ar, i);
But it's counterpart isn't:
Unarchiver unar;
int i;
i = unarchive(unar);
I would like to avoid using the function's name, such as unarchive_int because it would be troublesome when using templates. Say:
template <class T> class SomeClass
{
public:
void doSomething()
{
// Somewhere
T value = unarchive(unar);
}
};
This would make things messy, and as such I rather really use templates for this, whereas the previous expression would be T value = unarchive<T>(ar);. It also seems silly (arguably) to write a global function if either the first or only parameter are always the archiver and unarchiver objects; a template class seems to be in order:
template <class T> class Archiver
{
public:
void archive(T obj);
};
This works, but the archiving method always copies its input object. This is OK with POD data types, but not so much which classes. The solution seems obvious, and instead use a const reference as in void archive(const T & obj), but now it also seems silly to be passing integers, floats, and other PODs by reference. Although I would be happy with this solution, I tried to go a little further and have the object make the distinction instead. My first approach is std::enable_if, while assuming a copy by default (for all non-class members) and provide a class specialization where the archive method gets its input by reference instead. It doesn't work. Here's the code:
template <class T, class E = void>
class Archiver
{
public:
// By default, obj is passed by copy
void archive(T obj);
};
template <class T>
class Archiver<T, typename std::enable_if<std::is_class<T>::value && !std::is_pod<T>::value>::value>
{
public:
// I would expect this to be used instead if is_class<T> && !is_pod<T>
void archive(const T & obj);
};
The problem is that the second declaration is not visible at all to the compiler, and here's proof:
template <> void Archiver<std::uint8_t>::archive(uint8_t obj);
template <> void Archiver<std::string>::archive(const std::string & obj);
The former compiles fine, but the later gives:
out-of-line declaration of 'archive' does not match any declaration in
'Archiver<std::__1::basic_string<char>, void>'
On the other hand, if I get the std::string instead by copy if compiles just fine. I think I know why this happens, the compiler chooses the first template as it's generic enough for both declarations, but then how do I make it choose the more specialized version?
You want std::enable_if<...>::type, not std::enable_if<...>::value.
Here's a full demo:
#include <type_traits>
#include <cstdint>
#include <string>
template <class T, class E = void>
struct Archiver {
void archive(T obj);
};
template <class T>
struct Archiver<T, typename std::enable_if<std::is_class<T>::value && !std::is_pod<T>::value>::type>
{
void archive(const T & obj);
};
template <> void Archiver<std::uint8_t>::archive(std::uint8_t obj);
template <> void Archiver<std::string>::archive(const std::string & obj);
IIUC, the question boils down to how to define a generic template type that is optimized for calling functions.
For this, you can consider boost::call_traits, in particular, param_type:
template<typename T>
void foo(typename boost::call_traits<T>::param_type t);
This question builds up on my:
C++ library: .hpp + .inl (separate definitions and declarations) vs .hpp only (in-class body code)
Moving templated functions into inline files is definitely an official hell. See below three examples. From my OLD neat way of doing things (#0), to a really expanded way (#1), to a more compacted way (#2) to the imaginary dream pipe way (#3).
// #0 the actual class definition
namespace CA {
template <typename tnChar>
class MyClass {
public:
typedef tnChar tChar;
typedef std::basic_string<tChar> tString;
MyClass(); // {}
tString Method1(const tString& aParam) const; // { return aParam; }
};
};
This is the inline version #1. It has both namespace and class.
template <typename tnChar>
CA::MyClass<tnChar>::MyClass(){}
template <typename tnChar>
typename CA::MyClass<tnChar>::tString
CA::MyClass<tnChar>::Method1(const tString& aParam) const {
return aParam;
}
template <> // specializing
typename CA::MyClass<wchar_t>::tString
CA::MyClass<wchar_t>::Method1(const tString& aParam) const {
return aParam;
}
This is the inline version #2. It is wrapped in namespace. Saved from adding the CA::.
namespace CA {
template <typename tnChar>
MyClass<tnChar>::MyClass(){}
template <typename tnChar>
typename MyClass<tnChar>::tString
MyClass<tnChar>::Method1(const tString& aParam) const {
return aParam;
}
template <> // specializing
typename MyClass<wchar_t>::tString
MyClass<wchar_t>::Method1(const tString& aParam) const {
return aParam;
}
}
This is the inline version #3. It is wrapped in namespace and class. Saved from adding the template <...> ... CA::MyClass. IMAGINARY version. Not possible but desirable!
#if 0 // like this is ever gonna work
// inline version #3 (IMAGINARY)
// wrapped in namespace and in class
// 'inline class' should make this functionality happen in C++my
namespace CA {
template <typename tnChar>
inline class MyClass { // :)
MyClass(){}
tString Method1(const tString& aParam) const {
return aParam;
}
};
template <>
inline class MyClass<wchar_t> { // :) - too much imagination
tString Method1(const tString& aParam) const {
return aParam;
}
};
}
#endif // disabled
My question is: Is anything like version 3 even remotely possible? Without having to typename the return values and write the template <...> each and every single time. I know the reasons why we need to do this, but I'm wondering if the new C++11 or the next C++14 has any plans to address template class inline method grouping?
Having the inline class keywords trigger the imaginary functionality in #3 would be mind blowing and it would make externalizing template class methods so easy... and logic... and grouped... and short :)
At the risk of stating the obvious, that syntax is available when declaring member functions inside the class body. If your religion requires you to put the member functions in a separate .inl file, you could include that file inside the class body itself.