EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: String Interfaces
From: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>
Cc: "'EPICS Core Talk'" <[email protected]>
Date: Wed, 27 Jul 2005 18:19:13 -0600

> Jeff: Would you accept something like this method in a string interface
> class?
> 
> protected:
>      virtual bool getSegment(size_t offset,
>                   const char * & segment, size_t & len) const = 0;

My reservation about this is # 29 in Effective C++ 2nd edition - avoid
returning handles to internal data. I think that these concerns are
magnified in systems that have a) dynamically created and deleted strings,
b) dynamically modifiable string values, c) dynamically modifiable string
storage sizes, and d) have multiple threads accessing shared strings.

> 
> If not, please describe how you would write an efficient comparison
> operator between two different segmented string implementations.
> 

In the String Segment interface we have the following:

    virtual StringDiff compare ( const StringSegment & ) const = 0;

My conclusion was that it would be easy, and relatively efficient enough (we
need to remind ourselves that nothing is particularly efficient when we use
strings), to inside of the implementation of striongSegment::compare()
attempt to downcast the incoming StringSegment typed parameter using
dynamic_cast to the local type deriving from interface StringSegment. If
that cast is successful we are comparing two implementations of the same
type that we have private access to and we can implement a very fast and
efficient version. If not then we drop back to a slower generic version that
requires copying into a scratchpad, but since that situation will occur only
when crossing between subsystems or when transitioning from an old string
implementation to a new one then perhaps the overhead would be acceptable.

PS: I would also like to see strings accessed through a pure virtual
interface class so that multiple implementations are possible. This is,
among other apple pie reasons, because DA is interfacing with the world, and
the world will use many different string implementations including
std::string.

Jeff



Replies:
Re: String Interfaces Marty Kraimer
Re: String Interfaces Kay-Uwe Kasemir
Re: String Interfaces Andrew Johnson
References:
String Interfaces Andrew Johnson

Navigate by Date:
Prev: RE: ICE and TIPC Jeff Hill
Next: Re: ICE and TIPC Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: String Interfaces Andrew Johnson
Next: Re: String Interfaces Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·