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: Thu, 28 Jul 2005 17:22:29 -0600
> std::out_of_range

A little know side effect of this type of exception class is that it drags
std::string and therefore many other large modules into the executable. This
has caused pain, I understand, with the EPICS port to Itron. I have been
thinking that CA should probably avoid this and it might use classes
directly deriving from std::exception instead and hence the following
interface class discussed during my CA interfaces talk at our 2nd to last
meeting.

class diagnostic : public std::exception {
public: 
    enum severity_t { 
        sevWarning, sevError, sevFatal };
    virtual severity_t severity () const = 0;
    virtual context ( stringSegment & ) const = 0;
};

no doubt we have sufficient material for spontaneous ignition of lively
discussion :-)

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Thursday, July 28, 2005 5:01 PM
> To: Jeff Hill
> Cc: 'EPICS Core Talk'
> Subject: Re: String Interfaces
> 
> Jeff Hill wrote:
> >
> > I'm not sure that there is a compelling reason - that there needs to be
> as
> > much performance hit as one might initially think. Consider if the
> string
> > interface has a call in it "virtual StringInterface::copy ( const
> > StringInterface & stringIn )". If we had that, then the native string
> > storage interface could, in its copy virtual method, use the block copy
> > method in stringIn to copy into its private storage w/o need for a
> scratch
> > pad. What do you think?
> 
> I concede the point.  I can also implement comparisons efficiently in a
> similar fashion, *but* I need another member function that does a
> comparison of part of the string with the contents of an external buffer
> in order to do this.
> 
> BTW your StringInterface::copy() function is named assign() in all the
> C++ standard library containers including std::string.  I want to use
> standard names where the operations match, as this makes our code easier
> for others to understand.
> 
> 
> Thanks for the DA string requirements.  I don't accept that all of them
> have to be implemented as string member functions, but I will make sure
> I cover all your needs.
> 
> 
> Ok, my next point:  char operator[] (size_t pos) const
> 
> I would like to provide indexed access to individual characters, so a
> user can write myString[5] to get the 6th character of myString.  If the
> index is too big, operator[] will throw an exception, probably
> std::out_of_range since that's what std::at() throws.
> 
> I realize that this is not going to be a very efficient way to scan a
> long segmented string, especially if operator[] has to go through a list
> of segments each time you call it to locate the one that actually
> contains the 723rd character.
> 
> On implementations that use a single buffer however, the performance of
> operator[] will be fast, as it requires just one comparison and one
> addition (note that std::string doesn't even bother with the comparison;
> behaviour is undefined if you try to access beyond the end of the string).
> 
> I think we should provide this method since many programmers will expect
> to see something like it in a string API, but we should recommend that
> it not be used on segmented strings where performance could be an issue.
> 
> 
> I'm going to have to stop here; for the next 8 working days I'll be on
> vacation, but will pick up again with this discussion when I get back.
> 
> - Andrew
> --
> Podiabombastic: The tendency to shoot oneself in the foot.



References:
Re: String Interfaces Andrew Johnson

Navigate by Date:
Prev: Re: String Interfaces Andrew Johnson
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: Re: String Interfaces Andrew Johnson
Next: Re: Standard String Andrew Johnson
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 ·