Idioms to handle backward compatibility using templates

Discussion in 'C++' started by =?iso-8859-1?q?Ernesto_Basc=F3n?=, Nov 10, 2006.

  1. 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
     
    =?iso-8859-1?q?Ernesto_Basc=F3n?=, Nov 10, 2006
    #1
    1. Advertising

  2. 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
     
    Victor Bazarov, Nov 10, 2006
    #2
    1. Advertising

  3. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Guest

    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
     
    , Nov 10, 2006
    #3
  4. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Guest

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

    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
     
    , Nov 10, 2006
    #4
  5. A library that provides a lot of templates!


    wrote:
    > ..sorry Maybe I misunderstood ... A library that 'uses' alot of
    > templates or a library that 'provides' alot of templates ?
    >
    > 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
     
    =?iso-8859-1?q?Ernesto_Basc=F3n?=, Nov 10, 2006
    #5

  6. > "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 T> class CustomList<T>;

    class CustomString
    {
    public:
    CustomString(CustomList<char>& list);
    };


    The user of my library creates a set of instances of my template class:

    CustomList<int> intList;
    CustomList<Person> personList;
    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(charList);


    Is probable that my implementation of CustomList<T> will 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
     
    =?iso-8859-1?q?Ernesto_Basc=F3n?=, Nov 10, 2006
    #6
  7. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    Guest

    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 T> class CustomList<T>;
    >
    > class CustomString
    > {
    > public:
    > CustomString(CustomList<char>& list);
    > };
    >
    >
    > The user of my library creates a set of instances of my template class:
    >
    > CustomList<int> intList;
    > CustomList<Person> personList;
    > 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(charList);
    >
    >
    > Is probable that my implementation of CustomList<T> will 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
     
    , Nov 10, 2006
    #7
  8. =?iso-8859-1?q?Ernesto_Basc=F3n?=

    BobR Guest

    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-lite/how-to-post.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?
     
    BobR, Nov 10, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?TUxpYmJ5?=

    Netscape - Backward compatibility testing

    =?Utf-8?B?TUxpYmJ5?=, Sep 4, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    648
    [MSFT]
    Sep 6, 2004
  2. Maziar Aflatoun

    ASP 2.0 backward compatibility to 1.0

    Maziar Aflatoun, Apr 12, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    1,613
    Steve C. Orr [MVP, MCSD]
    Apr 13, 2005
  3. Muhammed Syyid

    Maintaining backward compatibility

    Muhammed Syyid, Dec 22, 2003, in forum: Java
    Replies:
    0
    Views:
    390
    Muhammed Syyid
    Dec 22, 2003
  4. Rich
    Replies:
    1
    Views:
    340
    Rhino
    Dec 5, 2004
  5. Ben Charrow

    Idioms and Anti-Idioms Question

    Ben Charrow, Jun 22, 2009, in forum: Python
    Replies:
    11
    Views:
    552
    Lawrence D'Oliveiro
    Jul 4, 2009
Loading...

Share This Page