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: Andrew Johnson <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'EPICS Core Talk'" <[email protected]>
Date: Thu, 28 Jul 2005 18:00:30 -0500
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.

Replies:
RE: String Interfaces Jeff Hill
References:
RE: String Interfaces Jeff Hill

Navigate by Date:
Prev: DA's string requirements Jeff Hill
Next: RE: String Interfaces Jeff Hill
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 Jeff Hill
Next: RE: String Interfaces Jeff Hill
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 ·