EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS base V4
From: Benjamin Franksen <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Andrew Johnson <[email protected]>, Eric Norum <[email protected]>, Jeff Hill <[email protected]>, Ralph Lange <[email protected]>, Bob Dalesio <[email protected]>, Ned Arnold <[email protected]>, Matej Sekoranja <[email protected]>
Date: Wed, 23 Feb 2005 19:11:02 +0100
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


Replies:
RE: EPICS base V4 Jeff Hill
References:
Re: EPICS base V4: iocCore database: Booleans Benjamin Franksen
EPICS base V4 Marty Kraimer

Navigate by Date:
Prev: RE: EPICS base V4: iocCore database Jeff Hill
Next: RE: EPICS base V4: iocCore database Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS base V4 Marty Kraimer
Next: RE: EPICS base V4 Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·