2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 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: | 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) constI 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.