Experimental Physics and
Industrial Control System

Hello Andrew:

I like your approach very much.
It's unfortunate that your reader/write is of course
similar to std::string, MFC::CStr, ... and yet
we can't use any of the existing but have to make
our own again, but I guess that's just the way it is.
C++ just doesn't live up to any of the
sharing-of-code dreams.

On Sep 26, 2005, at 19:07 , Andrew Johnson wrote:

I'm hoping Jeff will replace his stringSegment in dataAccess with the string API that I've been working on. These are the current base classes; there will non-member non-friend functions for doing numeric conversions, and other convenience functions like operator==:

I think we should be careful with
all C++ specialties like operators, templates,
multiple inheritance, Meyer's rules #1-99.
When EPICS started, there was C.
Now there's C++, but more and more people agree
that's a bad idea. So they use Java whenever possible.
Yet that's somewhat of a sandbox language which can't be used
for e.g. device drivers.

In a few more years there will be another language.
Today, however, I have to acknowledge that C++ is the only
practical language for implementing V4.
But the APIs for strings, data access, ... could still
be kept basic enough that SWIG can translate the C++
header files into perl bindings,
a perl script could turn the C++ into objective C,
and the C++ and Java implementations also match.

Meaning:
Use 'assign' instead of 'operator =',
'isEqual' instead of 'operator ==',
'getElement' instead of 'operator []', ...

After replacing all operators, I think your suggestion is great.

-Kay

 class StringReader {
 public:
     // String length
     virtual size_t size() const = 0;

     // Comparison functions
     virtual bool equals(const StringReader & rhs) const = 0;

virtual bool contains(const StringReader & rhs, size_t pos) const = 0; virtual bool contains(const char *str, size_t len, size_t pos = 0) const = 0;

     // Individual character access
     virtual char operator[] (size_t pos) const = 0;

     // Copy out to buffer, no terminator

virtual size_t extract(char *buf, size_t cap, size_t pos = 0) const = 0;

 };

 class StringEditor :
     public StringReader {
 public:
     // Length adjustment
     virtual void resize(size_t len, char fill = '\0') = 0;

     // Buffer storage management
     virtual size_t capacity() const = 0;
     virtual void reserve(size_t cap) = 0;

     // Assignment

virtual void assign(const StringReader & src, size_t pos = 0) = 0;

     virtual void assign(const char *str, size_t len) = 0;

     // Append
     virtual void append(char chr) = 0;

virtual void append(const StringReader & src, size_t pos = 0) = 0;

     virtual void append(const char *str, size_t len) = 0;

     // Overloaded operators
     StringEditor& operator = (const StringReader &rhs);
     StringEditor& operator = (const char *rhs);
     StringEditor& operator += (char chr);
     StringEditor& operator += (const StringReader &rhs);
     StringEditor& operator += (const char *rhs);
 };

I have three tested concrete implementations which use contiguous buffers:

ConstString : Concrete implementation of StringReader for wrapping "string literals" and other const char* buffers.

FixedString<int> : Template implementation of StringEditor, using a fixed size buffer which is a class data member (no new/delete). The size is set at compile time by the template parameter, so this is a safe version of a regular char[] buffer.

VariableString : Implementation of StringEditor, using new[] and delete[] to provide a contiguous buffer which increases in size as needed by multiples of 2.

All the above implementations maintain a hidden \0 terminator byte after the end of the string data, and also provide a c_str() function (not part of the base class interface) for compatibility with C functions. If you created the string, you get to look inside the box; if you're given a StringReader or even a StringEditor you don't, and you'll have to copy it to pass it to printf().

I am also working on another implementation using multiple fixed size buffer segments that are allocated from and returned to a freelist. This is the implementation I'm hoping we'll use in the IOC database for string fields as it solves the memory fragmentation problem.

Comments and questions on the above are welcome.

- Andrew
--
English probably arose from Normans trying to pick up Saxon girls.

Replies:

RE: data access structures, strings Jeff Hill

Re: data access structures, strings Andrew Johnson

Re: data access structures, strings Marty Kraimer

References:

RE: data access structures, strings Jeff Hill

Re: data access structures, strings Kay-Uwe Kasemir

Re: data access structures, strings Andrew Johnson

Navigate by Date:

Prev: RE: data access structures, strings Jeff Hill

Next: RE: data access structures, strings 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 

Navigate by Thread:

Prev: RE: data access structures, strings Jeff Hill

Next: RE: data access structures, strings 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