Kay-Uwe Kasemir wrote:
do you know any example where you actually need to destructively
update a string,
once you have it constructed?
I think Ben is right here.
I disagree, or maybe I don't fully understand the suggestion.
There is a record type called the stringCalc record, which is used
extensively by the BCDA group's synApps software (among other things, it
permits you to interface to new ASCII devices without having to write
device support). The VAL field of a stringCalc is string, which is
regenerated every time the record processes. I don't know how you would
implement this record type if all strings become read-only once created.
Similarly any device support that is driving a message-based device has
to be able to create a new message every time it processes; if we don't
support mutable strings, these device supports would have to use char*
buffers for generating their messages in.
I think we need to concentrate on the 99% where the string
is a short, contiguous (char *),
instead of the 1% where the string
is 1MB long, stored as non-contiguous 10 byte segments.
As I understand it, one of the main purposes of the segmented string
requirement is to permit Jeff to create a complete string out of the
characters that appear in the CA network input buffer, without having to
copy the character data at all. The chances that even a short string
would span two (or more) buffers are not that small, and the
implications of his having to copy the data are not just the time taken
to do the copy - if we force him to copy it out of the buffer before
presenting the string to the application, he has to temporarily allocate
memory for the destination string, and then manage the lifetime of that
memory allocation.
Sorry guys, I really can't support the development of an API that only
supports non-modifyable strings.
- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.
- Replies:
- Re: Standard String Kay-Uwe Kasemir
- References:
- FW: Standard String Jeff Hill
- Re: FW: Standard String Benjamin Franksen
- Re: Standard String Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: Standard String Marty Kraimer
- Next:
Re: Type descriptor vs. enum Marty Kraimer
- 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 Jeff Hill
- Next:
Re: Standard String Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|