Experimental Physics and Industrial Control System
> 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
<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: String Interfaces Andrew Johnson
- Next:
Re: Standard String Andrew Johnson
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024