13 replies to this topic

[feel_energetic]

i wrote a math library using template in most classes
as you know, all implementation of templated class should be included in the headers
or it can't to be properly linked to user application
so what can i do if i want to hide these function bodies?

[.oisyn]

You can't. Even with the export declarator, which only a few of the C++ compilers support, you aren't guaranteed that nobody can access your sourcecode, like when using a library.

[monjardin]

You can export explicit template instantiations:

template <class T> class TemplClass {

  // ...

}


// use this when building the DLL on windows

template class __declspec(dllexport) TemplClass<int>;

template class __declspec(dllexport) TemplClass<float>;

template class __declspec(dllexport) TemplClass<double>;

// etc...


// use this when using the DLL on windows

extern template class __declspec(dllimport) TemplClass<int>;

extern template class __declspec(dllimport) TemplClass<float>;

extern template class __declspec(dllimport) TemplClass<double>;

// etc...

You can use macros to handle the export/declspec stuff.

[CobraLionz]

First of all, most numerical libraries must go through a very thorough accreditation process which I doubt yours has gone through.

Second, I think it is highly unlikely that you came up with any of these algorithms yourself, so isn't it ironic that you feel that you have something proprietary to hide??

Third, if its templated it's probably so general that it isn't optimized for any PC architecture.

Lastly, if your code is of any value at all, it probably won't be understandable by anyone even with commented source code.

My point is that even if you released the code, I doubt anyone will even use it. Welcome to reality.

[.oisyn]

CobraLionz: nice arguments, except for the fact they don't have _anything_ to do with the problem the topicstarter has. I don't see what his type of library has got anything to do with it

[monjardin]

Maybe he just doesn't want to clutter his interface header files...

[eddie]

@CobraLionz
I find the negative tone to your post rather disheartening, given some of the great advice people give here without trying to bring others down. As such, let me play devil's advocate to the items you mention, in the hopes of giving people reasons why to help rather than be snide.

CobraLionz said:

First of all, most numerical libraries must go through a very thorough accreditation process which I doubt yours has gone through.

1.- Noone said he was going to release this library, and perhaps he's doing it just to learn.

CobraLionz said:

Second, I think it is highly unlikely that you came up with any of these algorithms yourself, so isn't it ironic that you feel that you have something proprietary to hide??

2.- Implementation hiding is not necessarily for security of your code. It can be for other reasons, most notably to defeat unnecessary rebuilds if your interface doesn't change yet your implementation does (this is my chief argument for implementation hiding).

CobraLionz said:

Third, if its templated it's probably so general that it isn't optimized for any PC architecture.

3.- Not necessarily true. You can still do ifdef based on platform inside of templated functions, and it will thereby be specialized for that particular platform. You can even get crazier using Boost's support for conditionals based on types and such (albeit I don't know much on that subject), so you can get a great degree of granularity on this.

CobraLionz said:

Lastly, if your code is of any value at all, it probably won't be understandable by anyone even with commented source code.

4.- This is simply an unfounded negative opinion.

CobraLionz said:

My point is that even if you released the code, I doubt anyone will even use it. Welcome to reality.

5.- Noone said he's releasing it. And coding for the sake of learning is probalby one of the best ventures possible.

I'm sorry if I seem snarky in my replies, but the one thing I've noticed in this forum is that everyone from the most junior person to the most senior is able to ask questions without fear of being mocked. This question is quite valid, and while I knew the outcome of this, I would've loved to be proven wrong.

Keep askin' questions feel_energetic, and good luck with your library. :)

[Reedbeta]

Indeed. CobraLionz, I have noticed that your few posts on this forum are rather consistently negative toward other forum members. Please try to improve your attitude.

[m4x0r]

One thing you can do in some situations is separate your class into a non-templated base class and a templated derived class.

Max

[feel_energetic]

.oisyn said:

You can't. Even with the export declarator

thanks for your reply:)
I also cared about 'export'
when searching the standard for help

what i want to know about this keyword is
"if it can't do any help to the templated functions,
is the declarator really implemented? and is it really useful?"

[feel_energetic]

monjardin said:

You can export explicit template instantiations:

code
...

You can use macros to handle the export/declspec stuff.

yes this was the way how i managed it first:)
it runs well with both dll and template , it's nice for most cases

but i also found something not so good
all different types used to instantiated(spell wrong?) the template class should be declared in the exported DLL, this forbids the user of the DLL to use their ADT as template parameter
furthermore, if i use an int as template paramter of class Vector(for example) to set the vector size at compile-time, i should write many declarations with different number, each of them with a whole specialized implementation.

after that, I realized DLL and template have different design goal, DLL is based on the run-time resolving, and template is based on compile-time computation. To combine them is not a good idea. Then i removed the DLLs and came here for help:)

[feel_energetic]

CobraLionz said:

First of all, most numerical libraries must go through a very thorough accreditation process which I doubt yours has gone through.

Second, I think it is highly unlikely that you came up with any of these algorithms yourself, so isn't it ironic that you feel that you have something proprietary to hide??

Third, if its templated it's probably so general that it isn't optimized for any PC architecture.

Lastly, if your code is of any value at all, it probably won't be understandable by anyone even with commented source code.

My point is that even if you released the code, I doubt anyone will even use it. Welcome to reality.

Thanks for these words
I'm sorry that I didn't mention that I create this subject is only for technical feasibility, not for finding a way to get my source locked

actually, the math library is used in a vision library to help my further reseach on computer vision
i'm also learning template metaprogramming and maybe this is a good chance to practise it

[.oisyn]

feel_energetic said:

thanks for your reply:)
I also cared about 'export'
when searching the standard for help

what i want to know about this keyword is
"if it can't do any help to the templated functions,
is the declarator really implemented? and is it really useful?"

That very same question is asked by many of the compiler vendors, and most of them answered it with "no, it isn't very useful, it's certainly not worth all the time and effort to implement it". Due to the nature of templates, you can't compile them as a seperate piece of code, like you can with seperate sourcefiles and libraries. It can only be compiled at the moment of instantiation, and it even needs the context at the point of the template definition itself (for example, if a templated function calls some other overloaded function, all the overloaded functions declared after the template function shouldn't be considered in the list of possible overloads).

So even when using export, the "library" containing the exported code is imported and "recompiled" on instantiation. Therefore your library either contains the actual sourcecode, or some literal translation of it. And just like java bytecode, which is a near 1:1 translation of the sourcecode, such an exported library can easily be decompiled back into C++ sourcecode. And the compiler which implement export basically require you to keep your implementation sourcefiles as the library for the "exported" code. And since you can just as easily seperate your implementation from the class definition and include the implementation from your header, I don't really why compiler vendors should implement the export keyword, or even why the export keyword even exists in the standard.

[feel_energetic]

thanks
i've got it