Idioms to handle backward compatibility using templates

[Ernesto Bascón]

Hi everybody:

I want to develop a library that uses heavily templates.

Is there an idiom or some tips about things that I should care of in
order to provide backward compatibility with my library?

(i. e., if I release new versions of my library, what things must I
consider to allow the applications that use it, run with no
recompilation? There is some idiom that helps to handle that (like the
pimpl idiom)? )

Regards,
Ernesto

[Victor Bazarov]

Ernesto Bascón wrote:

I want to develop a library that uses heavily templates.

Is there an idiom or some tips about things that I should care of in
order to provide backward compatibility with my library?

(i. e., if I release new versions of my library, what things must I
consider to allow the applications that use it, run with no
recompilation? There is some idiom that helps to handle that (like the
pimpl idiom)? )

"A template library changes to which don't require recompilation" seems
like an oxymoron.

Since most of what you're going to supply to your customers is source
code (in headers), any change in those will require recompilation.
I am unable to imagine a template library that only has interfaces to
some pimpl stuff. How useful is a template library when its guts are
independent from the types the user can use to instantiate the templates?
Or, looking from the other side, how can you actually implement that?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Nindi73]

Hi,
I have similar needs and one thing I do is to have a 'pimpl' idiom at
Library level. That is
If my core Library is CoreLib, then I have a library PimplLib which
sits on top of CoreLib and behaves like a pimpl. I then use PimplLib to
tightly control what I expose from CoreLib and keep this interface a
minimal. ALL my clients then strictly interact with CoreLib through
PimplLib only. It works great for me. On lots of occasions I have
drstically changed the internals of CoreLib with no or very minor
modifications to PimplLib.

N
Ernesto Bascón wrote:

Hi everybody:

I want to develop a library that uses heavily templates.

Is there an idiom or some tips about things that I should care of in
order to provide backward compatibility with my library?

(i. e., if I release new versions of my library, what things must I
consider to allow the applications that use it, run with no
recompilation? There is some idiom that helps to handle that (like the
pimpl idiom)? )

Regards,
Ernesto

[Nindi73]

...sorry Maybe I misunderstood ... A library that 'uses' alot of
templates or a library that 'provides' alot of templates ?

Nind...@yahoo.c o.uk wrote:

Hi,
I have similar needs and one thing I do is to have a 'pimpl' idiom at
Library level. That is
If my core Library is CoreLib, then I have a library PimplLib which
sits on top of CoreLib and behaves like a pimpl. I then use PimplLib to
tightly control what I expose from CoreLib and keep this interface a
minimal. ALL my clients then strictly interact with CoreLib through
PimplLib only. It works great for me. On lots of occasions I have
drstically changed the internals of CoreLib with no or very minor
modifications to PimplLib.

N
Ernesto Bascón wrote:

Hi everybody:

I want to develop a library that uses heavily templates.

Is there an idiom or some tips about things that I should care of in
order to provide backward compatibility with my library?

(i. e., if I release new versions of my library, what things must I
consider to allow the applications that use it, run with no
recompilation? There is some idiom that helps to handle that (like the
pimpl idiom)? )

Regards,


Ernesto

[Ernesto Bascón]

A library that provides a lot of templates!
Nind...@yahoo.c o.uk wrote:

..sorry Maybe I misunderstood ... A library that 'uses' alot of
templates or a library that 'provides' alot of templates ?

Nind...@yahoo.c o.uk wrote:

Hi,
I have similar needs and one thing I do is to have a 'pimpl' idiom at
Library level. That is
If my core Library is CoreLib, then I have a library PimplLib which
sits on top of CoreLib and behaves like a pimpl. I then use PimplLib to
tightly control what I expose from CoreLib and keep this interface a
minimal. ALL my clients then strictly interact with CoreLib through
PimplLib only. It works great for me. On lots of occasions I have
drstically changed the internals of CoreLib with no or very minor
modifications to PimplLib.

N
Ernesto Bascón wrote:

Hi everybody:
>
I want to develop a library that uses heavily templates.
>
Is there an idiom or some tips about things that I should care of in
order to provide backward compatibility with my library?
>
(i. e., if I release new versions of my library, what things must I
consider to allow the applications that use it, run with no
recompilation? There is some idiom that helps to handle that (like the
pimpl idiom)? )

Regards,


Ernesto

[Ernesto Bascón]

"A template library changes to which don't require recompilation" seems
like an oxymoron.

Look this case:

Let's say I provide the following classes:

template <class Tclass CustomList<T>;

class CustomString
{
public:
CustomString(Cu stomList<char>& list);
};
The user of my library creates a set of instances of my template class:

CustomList<inti ntList;
CustomList<Pers onpersonList;
CustomList<char charList;
As he has the implementation of the code, there is no problem when I
modify my implementation (because his binaries will implement the list
completely) except if he wants to share an instance of the class
template with a class implemented in the shared library, like:

CustomList<char charList;
CustomString myString(charLi st);
Is probable that my implementation of CustomList<Twil l be modified
and then, my CustomString class (implemented in my libraries) will
handle a wrong charList instance.

Since most of what you're going to supply to your customers is source
code (in headers), any change in those will require recompilation.
I am unable to imagine a template library that only has interfaces to
some pimpl stuff. How useful is a template library when its guts are
independent from the types the user can use to instantiate the templates?
Or, looking from the other side, how can you actually implement that?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Nindi73]

Is there a similar issue in the STL ? I would take my lead from there.
Ernesto Bascón wrote:

"A template library changes to which don't require recompilation" seems
like an oxymoron.

Look this case:

Let's say I provide the following classes:

template <class Tclass CustomList<T>;

class CustomString
{
public:
CustomString(Cu stomList<char>& list);
};
The user of my library creates a set of instances of my template class:

CustomList<inti ntList;
CustomList<Pers onpersonList;
CustomList<char charList;
As he has the implementation of the code, there is no problem when I
modify my implementation (because his binaries will implement the list
completely) except if he wants to share an instance of the class
template with a class implemented in the shared library, like:

CustomList<char charList;
CustomString myString(charLi st);
Is probable that my implementation of CustomList<Twil l be modified
and then, my CustomString class (implemented in my libraries) will
handle a wrong charList instance.

Since most of what you're going to supply to your customers is source
code (in headers), any change in those will require recompilation.
I am unable to imagine a template library that only has interfaces to
some pimpl stuff. How useful is a template library when its guts are
independent from the types the user can use to instantiate the templates?
Or, looking from the other side, how can you actually implement that?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[BobR]

Ni*****@yahoo.c o.uk wrote in message ...
Is there a similar issue in the STL ? I would take my lead from there.

Ernesto Bascón wrote:

I do not respond to top-posted replies, please don't ask

Nice top-post. Been takeing lessons long?

(http://www.parashift.com/c++-faq-lit....html#faq-5.4).

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?