EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Let's use the STL! [Was: about the abstractData.h]
From: [email protected] (Kay Kasemir)
To: Benjamin Franksen <[email protected]>, EPICS Techtalk <[email protected]>
Date: Thu, 05 Oct 2000 08:55:03 -0600
At 01:41 PM 10/5/00 +0200, Benjamin Franksen wrote:
>I strongly agree. I even vote that the aitString type should be
>abandoned completely. All these proprietary string types on the several
>plattforms and C++ compilers give you a headache. Try to develop a
>server tool on a windows system using MFC and you currently have to deal
>with three string types: std:string, MFC's CString and aitString. Of all
>these, std::string gives you the greatest flexibility, the most complete
>interface *and* the most seamless fit to other, e.g. stream,  libraries.
>In my point of view it is nonsense to duplicate such a nice string type
>with an inferior and non-standard version.
>
>The funny thing about this is that everybody uses <stdio.h> and similar
>standard libraries without any second thought, while on the other hand
>there is stiff resistance against using the STL. This is like
>programming your own printf() for fear of being dependent on the C
>standard libraries.

You are completely right:
Since there is a STL (now no longer called STL but part of the
standard C++ library), one should use it.
No need to re-invent lists, strings, maps, vectors, exception base classes, ...!
Every book you can buy on C++ will stress that.

It's also annoying when you try to mate e.g. EPICS libraries with aitString
with MFC apps' CString and some OPC library with yet another string idea.

But what does the std lib. look like in reality?

1) Availability
I went ahead and tried to built the ChannelArchiver with std::string, 
std::list, ...
Turned out that MS Visual C++ had most of those,
but g++ isn't there, yet:
Exception classes are very different, so is iomanip.
For HPUX' acc, the iostream is different again.

2) Premature Implementation
At least string and list worked somehow, until I got a memory leak on Linux
when using std::string. No leak with other std::string implementations.
-> I wrote my own string again, stdString, which looks like
std::string as far as I need it, just without the memory leak on Linux' g++.

3) Speed
Bob mentioned this. Here are some details that I recently send
to Jeff, Marty, Andrew J. and Bob because we wanted to use std::list
instead of Jeff's tsDLList:

Some update on std::list vs. Jeff's tsDLList.

My summary would be that
1) std::list is much too slow
2) allocators which are supposed to help don't work, yet

The std::list API is still desirable
because in a few years it'll look ridiculous
to have non-std classes for strings, list, ... around.

-> we could build our own non-intrusive list,
using a free list for the nodes,
where all the methods follow the API of std::list.

-Kay


* Performance
For adding new elements (create element, add to list),
the times for std::list and Jeff's are very similar,
but speed clearly speaks for Jeff's list
when we agree on add/remove as the most common operation.

Test: Create a list of 10000 things,
then for 500000000 runs
pop item from one end and add back to the other:
       
Jeffs	29.83secs	100.00%
Std	56.47secs 	189.31%

(800 Mhz Pentium, RedHat 6.2 Linux, g++)

* Conclusion?
The reason for this is that in Jeff's case only pointers
are moved for add/remove, the std::list creates/deletes
a list element.

Except for a big Thing class, it doesn't matter if I use a 
	list<Thing>
or a 	list<Thing *>,
the list node is still created/removed.

The solution - as Marty suggested all along - would be to use
list nodes from a free list.

In principle the STL list allows to use your own "allocator".

Well, for two hours I tried to implement a freelist-allocator.
I did this according to Stroustrup.
Problem: No compiler seems to follow that standard.

VS VC wants an allocator with a _Charalloc method for the std::list
	char _FARQ *_Charalloc(size_type _N)
instead of the "rebind" structure.

g++ complains about "no matching function for call to
`freelist_alloc<Thing *>::deallocate (__list_node<Thing *> *&, unsigned int)'
So g++ actually wants an allocator for __list_node<T>, not T.

Maybe you are more succesful...







References:
Let's use the STL! [Was: about the abstractData.h] Benjamin Franksen

Navigate by Date:
Prev: Tcl/tk Daniel BOGARD
Next: Re: Let's use the STL! [Was: about the abstractData.h] Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  <20002001  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: Re: Let's use the STL! [Was: about the abstractData.h] Bob Dalesio
Next: Re: Let's use the STL! [Was: about the abstractData.h] Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·