Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · Wed, 23 Feb 2005 13:34:16 -0700

> > There is no standard.

Nevertheless it will probably be a rare 64 bit C compiler that
does not provide a type for each integer size {8, 16, 32, 64},
and that guess leads to somewhat less uncertainty. In particular
the smaller sizes appear to be already assigned given this
consideration as follows {char=8, short=16, int=32}. That leaves
either "long" or "long long" for 64 bit integers. I am guessing
that after the 64 bit dust settles, and 32 bit machines are
becoming legacy equipment, there will be a tendency to end up
with "long" and "int" being different sized types and withholding
"long long" for 128 bit systems, but we will need to wait and see
I guess.

Jeff

> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]]
> Sent: Wednesday, February 23, 2005 11:11 AM
> To: Marty Kraimer
> Cc: Andrew Johnson; Eric Norum; Jeff Hill; Ralph Lange; Bob
> Dalesio; Ned Arnold; Matej Sekoranja
> Subject: Re: EPICS base V4
> 
> On Wednesday 23 February 2005 15:14, Marty Kraimer wrote:
> > Benjamin Franksen wrote:
> > >[Aside: Is this definition in epicsTypes.h:
> > >
> > >typedef int                epicsInt32;
> > >
> > >garanteed to work even on 64 bit systems? AFAIK, int is
> supposed to be
> > >whatever is the most natural (=fast) signed integral value
> on the given
> > >architecture. Correct me if I am wrong here.]
> >
> > There is no standard. The C99 standard only defines minimum
> sizes for
> > each of the integer types. In particular a long must be at
> least 32 bits
> > but may be more.
> >
> > Some 64 bit compilers use
> >
> > int   32 bits
> > long 64 bits
> >
> > I think that gnu uses
> >
> > int 32 bits
> > long 32 bits
> > long long 64 bits
> 
> Ok, thanks for enlightening me on this question.
> 
> > Although 3.14 currently has epicsTypes.h in src/libCom/misc,
> it can
> > easily be moved to
> > src/libCom/osi/osi/xxx. Thus there can be architecture
> dependent
> > versions. Of course, this will not be a complete solution for
> 3.14
> > because very little of the code uses epicsTypes.h. Jeff
> created
> > epicsTypes.h, which has the comment: "so far this is
> sufficient for all
> > archs we have ported to". Thus it was designed to allow
> architecture
> > dependent versions.
> >
> > For 3.15, code should use epicsTypes.h for anything that can
> be
> > architecture dependent or for anything that can is network
> accessable.
> 
> Yes.
> 
> > Benjamin,
> >
> > I may not respond to all of your messages because my mind is
> not big
> > enough to think about too many things at the same time. It
> does not mean
> > that I don't read and consider them. Also please send them to
> everyone
> > included on this message.
> 
> Ok.
> 
> > In paticular, I am reluctant to get in the C++ discussion. I
> am so
> > disappointed with what C++ became and Jeff is so much in
> favor of using
> > C++ that it is going to be a major problem for V4.
> 
> *Sigh*
> 
> > Let me give an example. You praised templates. My response is
> "How can
> > templates be OK if they are build on top of the mess that C++
> has
> > created for classes".  Just this comment could generate hours
> of
> > discussion.
> 
> Not necessarily. To give a short answer, it is because
> templates and classes
> are almost perfectly orthogonal features in C++. That doesn't
> mean I think
> that templates are unconditionally "OK". The syntax is
> extremely verbose and
> the lack of type inference limits their usability. Nevertheless
> they are not
> nearly as broken as the class stuff.
> 
> It is quite easy to arrive at such judgements if one takes the
> time to compare
> the C++ "solutions" to those in other languages. As reference
> for how
> OO/classes/inheritance should be designed, I recommend Eiffel.
> As reference
> for how to do parametric polymorphism (aka type variables, aka
> templates),
> see Haskell or ML.
> 
> Isn't it funny that when (almost) everyone in the EPICS
> community jumped on
> the C++ train I have issued strong warnings against it; and now
> as people
> jump off it again, I find myself (reluctantly!) arguing for it.
> 
> BTW, what happened to the project of re-writing dbStatic in
C++?
> Andrew?
> 
> > When I think about all the C++ syntax that MUST be done
> correctly for
> > defining interfaces, I wonder if we really want to require
> mere mortals
> > to get it all right. Remember that I WANT users to extend
> what epics
> > base supports. The bigger the learning curve before users can
> create and
> > implement their own interfaces, the less usefull the V4
> database will
> > be. Would asynDriver be easier to learn and extent if it was
> done in
> > C++? I don't think so. It has a huge learning cure as it is.
> 
> Maybe. And maybe I am not the right person to judge.
> 
> As always, I am tempted now to argue for solutions beyond the
> C/C++ camp.
> Relax, I won't. A special combination of essential requirements
> (predictable
> resource usage; separate compilation; large user base and wide
> availability
> of implementations; seamless interoperability with device
> drivers written in
> C) rule out almost all the otherwise vastly superior languages
> (Haskell,
> OCaml, Eiffel, Erlang), at least on the IOC side.
> 
> Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System