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
<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:
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
<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
|