Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 27 Sep 2005 12:47:25 -0600

Please pardon an internal debate converted to a mail message :-)

>> Use 'assign' instead of 'operator =',
>> 'isEqual' instead of 'operator ==',
> Shouldn't this also apply to dataAccess? {Or should I say :-) }

PropertyCatalog currently has "operator =" and "operator ==". 

O Do they meet the conventional wisdom test? That is, is their purpose
roughly equivalent to the purpose of these operators with primitive types? I
Originally I thought yes, but I have thought about this further and its
probably more accurate to call 'operator =' "extract what's in the LHS from
the RHS", and what 'operator ==' does "return true if everything in the LHS
is equivalent in the RHS". So perhaps a new name could be used, but I am not
sure that assign would convey more of the above subtleties than "operator ="
would. So maybe "operator =" is not completely ok here, but then again
"assign" isn't really better and it would maybe take a really long name to
be better.

O I think that one does need to be very careful about writing overly general
constructors and or assignment operators, but in this case "operator =" only
accept a const reference to a PropertyCatalog which is probably non
ambiguous enough. So perhaps "operator =" is ok here.

O As for avoiding these things so that a perl script might process the code
into java? I though that perl could convert anything into anything using
only one line of code ;-). Seriously, with perl wouldn't it be possible to
look for "operator = (" about as easy as looking for "assign ("? So perhaps
"operator =" is ok here.

O As for C++ and Java matching this presumably would be a benefit only for a
person who works both in Java and in C++. Surely Java / C++ dual personality
types have many other issues to deal with? Nevertheless, I suppose that this
could be solved by adding an assign that calls "operator =" or visa versa.
Or we could just have assign although perhaps that would be annoying to
persons that actually like to say "this = that" in C++ (hey, it is C we are
programming in - the language of terseness). Initially one might conclude
that "operator *" is ok here if some redundancy is allowed into the design,
but as a general design guide I really hate redundancy so perhaps it isn't.
Still, I hypothesize that Java programmers need to remember many things when
switching to C++ so perhaps this isn't really a significant issue?

Jeff

> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Tuesday, September 27, 2005 11:57 AM
> To: [email protected]
> Subject: Re: data access structures, strings
> 
> 
> 
> Kay-Uwe Kasemir wrote:
> 
> >
> >
> > 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 []', ...
> >
> 
> Shouldn't this also apply to dataAccess? {Or should I say :-) }
> 
> I would also like to quote the first sentence of the second paragrah of
> Stroustrup "The C++ Programming Language" in the chapter titled "Strings"
> 
> "Experience shows that it is impossible to design the perfect string"
> 
> Working on the V4 database design has made me think about what it needs
> for strings.
> 
> For most strings all it needs is a nonmutable string.
>  For these it wants to be able to pass a reference to it to arbitrary
code.
> It needs this for things like record type names, field names, record
> instance names, menu choice names, etc. etc. Some of these may change
> but very infrequently.
> The string always contains UTF-8 encoded strings, which I believe can
> be printed with a "%s" format if
> the string is made available as a "const char *"
> 
> Perhaps the only type of  string connected with an IOC record that
> changes frequently is a field in a record type like stringin and
> stringout. In this case the record support can do what ever it wants to
> handle the string. It can even just use C style strings!!!
> 
> Thus all the IOC database needs is a:
> 
> 1) nonmutable reference counted continguous string. When the reference
> count goes to 0 the storage can be reclaimed
> 2) The ability to copy the value from a nonmutable string to a mutable
> string.
> 
> 
> In Java String and StringBuffer are all that is needed.
> 
> In C++ all that is needed is
> 
> 1) A class that holds UFT-8 encoded non-mutable strings and make the
> contents available as a "const char *" and it's length. The class keeps
> a reference count and frees the storage when done.
> 2) The ability to copy the nonmutable string to a "char *" array
> allocated by the requester.
> 
> That is all.
> 
> What the IOC database needs for strings is very different than what
> dataAccess requires.
> 
> Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System