Re: data access structures, strings

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

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.