On Thursday 03 March 2005 00:35, Jeff Hill wrote:
> > -----Original Message-----
> > From: Benjamin Franksen [mailto:[email protected]] >
> >
> > On Wednesday 02 March 2005 22:02, Jeff Hill wrote:
> > > My solution to the wide character issue was to have the
>
> putChar
>
> > > and getChar interfaces pass type int. UTF-8 then becomes an
> > > implementation (an internal storage compression) issue.
> >
> > Ok, this is a possibility. But it means that, for instance,
> > an IOC will use wide characters throughout its code. Just
> > caring about our precious memory, you know... ;) That is,
> > provided it doesn't want to re-encode everything
> > again, of course...
>
> The stringSegment interface requires only that internal string
> tokens
> can be converted to a int sized universal code only when getChar
> and putChar are called, but there is no requirement that the
> implemenation use an internal storage of size int.
Yes, I understood that. As I wrote above, in order to avoid using wide
character strings for storage, the user code has to re-encode the data into
UTF-8.
> The getChar interface will be used in one character at
> a time situations where the storage overhead of an int can be
> safely
> neglected. Otherwise if there are any multi-token segments being
> stored
> they would only be stored in an implementation defined format
> accessed
> through the stringSegment interface. Anyways, that is the
> standard
> dataAccess approach: interface to data, but do not specify a
> storage
> format.
Yes and this is clearly a very versatile approach. The problem is that there
is always some tradeoff between versatility and efficiency. Efficiency could
be improved if we would enforce for instance a certain encoding, but probably
not enough to make it worthwhile. Another approach would be to provided
methods for the user code to make its encoding preference known to the data
object, so that decoding and re-encoding could be avoided if external and
internal encodings coincide. I am not sure how much this would complicate the
interface, though.
Ben
- References:
- RE: memory management Jeff Hill
- Navigate by Date:
- Prev:
RE: memory management Jeff Hill
- Next:
Re: EPICS base V4: iocCore database Benjamin Franksen
- 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: memory management Jeff Hill
- Next:
RE: memory management Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|