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: Let's use the STL! [Was: about the abstractData.h]
From: Benjamin Franksen <[email protected]>
To: EPICS Techtalk <[email protected]>
Date: Thu, 05 Oct 2000 13:41:39 +0200
I post this to tech-talk since I think it's of general interest.

Jeff Hill wrote:
> ...
> When this [abstractData.h, a replacement for GDD] was written I was 
> receiving lots of advice _not_ to allow EPICS
> to become dependent on the standard library, but we will certainly
> find that we are off the path in the future if we don't support
> standard ways of dealing with strings.

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.

Also, as far as I know, the STL has been designed to avoid any kind of
overhead that is not absolutely necessary for the provided genericity,
i.e. performance is not an issue.

We should also use the STL container types, e.g. <vector>, wherever this
makes sense. A problem with STL is that there is no generic hashtable
provided. I'd say, that the hashtable that is part of the EPICS base
should be turned into a template container class that fits nicely into
the STL framework, thus making it easier to use and adapt.

Ben
-- 
The Notorious Neb Nesknarf


Replies:
Re: Let's use the STL! [Was: about the abstractData.h] Bob Dalesio
Re: Let's use the STL! [Was: about the abstractData.h] Kay Kasemir
Re: Let's use the STL! [Was: about the abstractData.h] Marty Kraimer

Navigate by Date:
Prev: Re: Performance of portable CA server ? Bernhard Kuner
Next: Tcl/tk Daniel BOGARD
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: MPF and mpfSerial Marty Kraimer
Next: Re: Let's use the STL! [Was: about the abstractData.h] Bob Dalesio
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 ·