Experimental Physics and Industrial Control System
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
<2005>
2006
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
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024