This is a response to the discussion of what a standard string should be
and to Kay's message about "Type descriptor vs enum"
I want to go back to my message about Network Accessable Types. I proposed:
enum NadType {
nadTypeUnknown,
nadTypeBoolean,
nadTypeOctet,
nadTypeInt16,
nadTypeUInt16,
nadTypeInt32,
nadTypeUInt32,
nadTypeInt64,
nadTypeUInt64,
nadTypeFloat32,
nadTypeFloat64,
nadTypeString,
nadTypeArray,
nadTypeMDArray,
nadTypePropertyCatalog,
// Following are usefull common types
nadTypeTimeStamp,
nadTypeEnum,
nadTypeMap
};
This leads to a discussion of what is the actual type associated with
each NadType.
The types Boolean, ..., Float64 SHOULD be easy but I am no longer sure
because each may cause a class war, i.e. "Your class hierarchy sucks.
Mine came by devine revelation"
The other types are not at all obvious. I started the discussion of
Standard String with nadTypeString in mind. I hoped that if we could
agree on a standard way to handle strings then the type associated with
nadString would be a by product. The discussion that resulted showed
this to be a mistaken hope.
It soulds like we may never agree on an EpicsString so lets just discuss
what if needed for NadString.
Lets step back and ask "What is needed for the types associated with
each NadType?"
The type must be something that can make the associated data accessable
without any knowledge about what holds the data. The communicating
entities may be in different locations and may be using different
languages. This implies that the actual types depend on the language.
But we can decide what the semantics should be. Also we should be able
to define something so that it can be implemented in both C++ and Java.
The rest of the message will only discuss how to create an interface
for nadTypeString.
What are the requirements:
1) It only supports UTF-8 encoded strings.
2) It must be possible to both read and write UTF-8 encoded strings.
3) The container may only be able to handle the data in chunks.
How should it be implemented?
I will agree with Jeff that an interface (C++ pure virtual base class,
Java Interface) should be defined.
The code that holds the container can do whatever it wants but should
make the interface available so that other code can read and write UTF-8
strings.
All talk about constructors should not be part of the discussion
So how do we define it? Perhaps somthing like (Java syntax) :
Note: I will assume that nadOctet is a type that is an 8 bit byte and
nadInt32 is a 32 bit integer
interface NadString {
nadInt32 get(nadInt32 offset, nadInt32 len, nadOctet *pto);
nadInt32 put(nadInt32 offset, nadInt32 len, nadOctet *pfrom);
void reserve(nadInt32 capacity);
nadInt32 capacity();
bool mutable();
};
Some rules:
1) All sizes are in units of octets, NOT UTF_8 characters.
2) get and put return actual number of octets transfered. The caller
must be prepared to make multiple calls.
3) reserve tells the container that this many octets will be put.
4) capacity() can be called to find out how many bytes may be obtained
via gets.
5) mutable() false means that put and reserve will cause an exception.
Marty
- Replies:
- Network Accessable Data Marty Kraimer
- References:
- FW: Standard String Jeff Hill
- Re: FW: Standard String Benjamin Franksen
- Re: Standard String Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
RE: Type descriptor vs. enum Dalesio, Leo `Bob`
- Next:
Re: Standard String Andrew Johnson
- 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: Standard String Kay-Uwe Kasemir
- Next:
Network Accessable Data 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
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·