Re: Passing template struct as an argument to a template function
From: Maitre Bart (lemieux_at_cae.com)
Date: 09/27/04
- Next message: Filipe Valepereiro: "Re: ++u or u++ which is faster?"
- Previous message: Howard: "Re: How does #define operate ?"
- In reply to: Victor Bazarov: "Re: Passing template struct as an argument to a template function"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Sep 2004 10:35:13 -0400
"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:dnK5d.116883$MQ5.24909@attbi_s52...
> "Maitre Bart" <maitrebart@videotron.ca> wrote...
> > [...]
> > Suppose I wish to make a library using templates (being classes or
> > functions). Of course, I don't want my source code (i.e. my little
> > secrets) being distributed along with my binaries (.lib, .dll, or .so,
> > name it!). On the other hand, I cannot start specifying all possible
> > instantiations, in my .cpp, any potential user will try to make up.
>
> You can't? Why can't you? Do you really have such a library that all
> types could be used to instantiate templates?
>
Well, here is a simple case. Let's say that some of my template functions,
for example, contain a functor (or a predicate) a user has to provide as an
argument:
template <class _A_ , class _R_, class _Op_>
_R_ DoSomething(_A_ a_from, _A_ a_to, _Op_ a_converter);
How can I possibly think about all of the possible instantiations that may
exist in the whole world for 'a_converter'?
> > Can someone tell me what are my options, as a Foo provider, to sell my
> > product to the Bar implementers?
>
> You have three options.
>
> One (just like many, if not all, other template code vendors do) is to
> obfuscate the hell out of your code and still supply it all in the
> headers you provide along with the rest of it. That's the most common
> way. If you really want to protect your "secrets", get a patent. If
> they are not patentable, they are not really secrets, are they?
>
That is what I can observe in MS' STL implemention. Still, I wouldn't take
is solution if all my invested $$$ in development could be
reverse-engineered in a couple of hours. Would you? !!!
> Two is to limit your clients to use of a compiler that implements "export"
> and make sure that all your object code (and template code) supplied is
> compiled with that compiler.
>
Then, I will need to read from Herb Sutter about 'export'.
> Three is to limit your clients to instantiating your templates with
> a short predetermined list of types. You library code has to contain the
> necessary _explicit_specialisations_ of all the templates.
>
That is precisely my point!
> Both two and three are the ways to put yourself at a huge disadvantage
> as far as software market goes. Since you said that you cannot rely on
> option "three", then you are stuck with one or two, and limiting your
> clients to a particular (potentially not very popular or even known)
> compiler is in no way a good idea. Of course, the final decision is for
> you to make.
>
I think I will conclue rapidely on the subject (see below)...
> Oh, the fourth option is to drop templates altogether and go with the
> plain ol' set of functions and classes. Nothing essentially wrong with
> that either. Majority of libraries on the market are still template-free.
>
Finaly, it all looks like that templates were not designed for "private"
libraries, unless they contain no secret and can be explicitely instantiated
for the basic types, which by nature is a "public" library.
> Victor
>
Thanks for your opinion.
- Next message: Filipe Valepereiro: "Re: ++u or u++ which is faster?"
- Previous message: Howard: "Re: How does #define operate ?"
- In reply to: Victor Bazarov: "Re: Passing template struct as an argument to a template function"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
