To put some of Jeff's question into a bit more context for those who were
not at the collaboration meeting at Oak Ridge, I will repeat the purpose
behind the changes we propose for the container facilities in libCom.
Jeff Hill wrote:
>
> There is also now a strong push originating at APS to change or
> completely rewrite nearly all of my existing C++ based utility libraries.
> Bob has requested that I not assume that backwards compatibility is
> needed, and instead query all of you to see how much interest there
> is in maintaining backwards compatibility with these original C++
> based APIs.
The alternatives we are proposing involve changing the utility templates
to use an API that is compatible the the ISO/ANSI C++ standard library
where an equivalent facility exists in the standard or where an extension
is in common use. When compared to Jeff's C++ classes there is a very
slight performance hit to using some of these APIs, but both C++ versions
are faster than the equivalent C libraries that have been in libCom for
many years.
We have also said that Jeff's templates should remain available to allow
time for changes to be made, but that they be placed in a deprecated area.
> o tsDLList (APS intends to install their complete rewrite)
The C++ standard library includes a doubly-linked list which provides a
richer interface than tsDLList. The implementations provided with several
of our standard target platforms do not meet acceptable performance, but I
have developed an implementation that does. It may be possible to replace
epicsList with std::list at some time in the future if the performance of
the standard implementations improves.
> o tsSLList (APS intends to install their complete rewrite)
There is no singly-linked list in the standard library, although early
versions of the standard did include one and many vendors supply this
using the API described in the early Standard Template Library that was
the basis for the C++ standard library. I would be interested to hear of
any sites that are actually using tsSLList for itself; within EPICS base
it is currently only used to implement resoureLib.
> o resourceLib (APS intends to install their complete rewrite)
The C++ standard library equivalent of this would be a hash_map; while not
actually part of the standard either, many vendors already provide an
implementation of the hash_map API that was developed as part of the early
STL work. I have not had a chance to characterize the performance of
these yet, but I suspect that there may be similar performance problems
with some of these, in which case EPICS should provide a fast
implementation.
There was also a suggestion at the ORNL meeting that we provide a B-Tree
implementation, called a map in C++ standard library terms. Any comments
on the desirability of this in addition to the hash_map are welcomed.
- Andrew
--
Every great idea appears crazy to start with.
- Replies:
- Re: C++ API backwards compatibility Chris Larrieu
- References:
- C++ API backwards compatibility Jeff Hill
- Navigate by Date:
- Prev:
C++ API backwards compatibility Jeff Hill
- Next:
Re: C++ API backwards compatibility Chris Larrieu
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
C++ API backwards compatibility Jeff Hill
- Next:
Re: C++ API backwards compatibility Chris Larrieu
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|