Best way to exploit "export"

[Tomás]

I have a few really long template functions. They belong in a source
file... and thus must be "exported".

Seeing as how few compilers support "export", could someone please point
me to a webpage/post that gives a very decent method of exploiting
"export" for those compilers that *do* export it, while still remaining
compatible with the defective compilers (which are in the majority!).

I've seen in the comp.lang.c++ FAQ that you can do:

#ifndef SUPPORT_EXPORT
#define export /* Nothing */
#endif

and so on. I works fine, but I just thought I'd check to see if there's
any better ideas before I go modifying all of my code...


-Tomás

 

[Axter]

I have a few really long template functions. They belong in a source
file... and thus must be "exported".

What make you believe they belong in a source file?

A common method to use is to put the templates in a *.hpp or *.hxx
file, and than add an include to the header at the bottom.

#ifndef FOO_H_
#define FOO_H_

template<class T>
class foo
{
public:
//member declartion here
};

#include "foo.hpp" //Put your long template implementation here

#endif // FOO_H_

However, I recommend just simplifying things, and keep the really long
template implementation inside the class declaration.
You don't gain anything by putting it in a seperate file. This is even
true of the TWO compilers that due support export keyword.

 

[Gavin Deane]

What make you believe they belong in a source file?

A common method to use is to put the templates in a *.hpp or *.hxx
file, and than add an include to the header at the bottom.

#ifndef FOO_H_
#define FOO_H_

template<class T>
class foo
{
public:
//member declartion here
};

#include "foo.hpp" //Put your long template implementation here

#endif // FOO_H_

However, I recommend just simplifying things, and keep the really long
template implementation inside the class declaration.
You don't gain anything by putting it in a seperate file. This is even
true of the TWO compilers that due support export keyword.

You can gain by putting the implementation in a separate file. If the
class definition contains just declarations for the member functions,
it's possible to quickly look in the header file and see everthing in
the public interface in one place [*]. Hopefully it even all fits on
the screen at once. Since the public interface is all a user of the
class cares about, this can be very helpful.

The same applies to the protected interface if inheritance is involved.

Once you start putting non-trivial member function definitions in the
header, you lose this clarity.

[*] Assuming the author of the class hasn't sprinkled public, protected
and private declarations amongst each other.

Gavin Deane

 

[Ben Pope]

I have a few really long template functions. They belong in a source
file... and thus must be "exported".

Seeing as how few compilers support "export", could someone please point
me to a webpage/post that gives a very decent method of exploiting
"export" for those compilers that *do* export it, while still remaining
compatible with the defective compilers (which are in the majority!).

I've seen in the comp.lang.c++ FAQ that you can do:

#ifndef SUPPORT_EXPORT
#define export /* Nothing */
#endif

and so on. I works fine, but I just thought I'd check to see if there's
any better ideas before I go modifying all of my code...

One other way to do it is to implement the functionality using something
akin to void*, and then only provide type safe wrappers using templates.

I'm not sure this is generally applicable, but it works in at least some
cases. I think I read that in TC++PL, but I don't have it to hand.

Ben Pope

 

[Ian Collins]

However, I recommend just simplifying things, and keep the really long
template implementation inside the class declaration.
You don't gain anything by putting it in a seperate file. This is even
true of the TWO compilers that due support export keyword.

If your compiler supports export, or template definitions in a separate
file you can gain clarity by not mixing declarations and implementations.

You can also gain in compile times as the compiler doesn't have to check
the implementation code if it isn't required.

 

[Jacek Dziedzic]

Axter wrote:

What make you believe they belong in a source file?

A common method to use is to put the templates in a *.hpp or *.hxx
file, and than add an include to the header at the bottom.

#ifndef FOO_H_
#define FOO_H_

template<class T>
class foo
{
public:
//member declartion here
};

#include "foo.hpp" //Put your long template implementation here

#endif // FOO_H_

However, I recommend just simplifying things, and keep the really long
template implementation inside the class declaration.
You don't gain anything by putting it in a seperate file. This is even
true of the TWO compilers that due support export keyword.

You can gain by putting the implementation in a separate file. If the
class definition contains just declarations for the member functions,
it's possible to quickly look in the header file and see everthing in
the public interface in one place [*]. Hopefully it even all fits on
the screen at once. Since the public interface is all a user of the
class cares about, this can be very helpful.

What about inlining? Don't you lose this if you put
your implementation outside of class{};?

- J.

 

[Tomás]

Jacek Dziedzic posted:

Axter wrote:

Tomás wrote:

I have a few really long template functions. They belong in a source
file... and thus must be "exported".

What make you believe they belong in a source file?

A common method to use is to put the templates in a *.hpp or *.hxx
file, and than add an include to the header at the bottom.

#ifndef FOO_H_
#define FOO_H_

template<class T>
class foo
{
public:
//member declartion here };

#include "foo.hpp" //Put your long template implementation here

#endif // FOO_H_

However, I recommend just simplifying things, and keep the really long
template implementation inside the class declaration.
You don't gain anything by putting it in a seperate file. This is even
true of the TWO compilers that due support export keyword.

You can gain by putting the implementation in a separate file. If the
class definition contains just declarations for the member functions,
it's possible to quickly look in the header file and see everthing in
the public interface in one place [*]. Hopefully it even all fits on
the screen at once. Since the public interface is all a user of the
class cares about, this can be very helpful.

What about inlining? Don't you lose this if you put
your implementation outside of class{};?

- J.

Hence the "inline" keyword.

-Tomás

 

[Gavin Deane]

However, I recommend just simplifying things, and keep the really long
template implementation inside the class declaration.
You don't gain anything by putting it in a seperate file. This is even
true of the TWO compilers that due support export keyword.

You can gain by putting the implementation in a separate file. If the
class definition contains just declarations for the member functions,
it's possible to quickly look in the header file and see everthing in
the public interface in one place [*]. Hopefully it even all fits on
the screen at once. Since the public interface is all a user of the
class cares about, this can be very helpful.

What about inlining? Don't you lose this if you put
your implementation outside of class{};?

Yes, but that's not relevant to my point. You snipped the part where I
said

<quote>
Once you start putting non-trivial member function definitions in the
header, you lose this clarity.
</quote>

The OP talked about a "really long" function. While "really long" and
"non-trivial" are not precise terms, I think they both suggest the sort
of function that is unlikely to be a good candidate for inlining.

I wasn't suggesting that function definitions should never be placed in
the header. I was pointing out a possible disadvantage - loss of
clarity - of doing so. But that disadvantage might sometimes be
outweighed by other considerations.

Gavin Deane

 

[Jacek Dziedzic]

You can gain by putting the implementation in a separate file. If the
class definition contains just declarations for the member functions,
it's possible to quickly look in the header file and see everthing in
the public interface in one place [*]. Hopefully it even all fits on
the screen at once. Since the public interface is all a user of the
class cares about, this can be very helpful.

What about inlining? Don't you lose this if you put
your implementation outside of class{};?

- J.

Hence the "inline" keyword.

Ah yes, I missed on the part where the "separate file"
was in fact #included in the header file. I was thinking
about the case in which definitions wind up in a separate
file that is not #included in the header and hence the
function definitions are not seen and inline cannot be used.

thanks,
- J.