Re: Standard String

[Andrew Johnson <anj@aps.anl.gov>]

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.