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  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: EPICS base V4
From: Marty Kraimer <mrk@aps.anl.gov>
To: Benjamin Franksen <benjamin.franksen@bessy.de>
Cc: Andrew Johnson <anj@aps.anl.gov>, Eric Norum <norume@aps.anl.gov>, Jeff Hill <johill@lanl.gov>, Ralph Lange <Ralph.Lange@mail.bessy.de>, Bob Dalesio <bdalesio1@comcast.net>, Ned Arnold <nda@aps.anl.gov>, Matej Sekoranja <matej.sekoranja@ijs.si>
Date: Wed, 23 Feb 2005 08:14:07 -0600


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

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.

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.

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.

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.

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.

Marty



Replies:
Re: EPICS base V4 Benjamin Franksen
Re: EPICS base V4 Andrew Johnson
References:
Re: EPICS base V4: iocCore database Marty Kraimer
Re: EPICS base V4: iocCore database Andrew Johnson
Re: EPICS base V4: iocCore database: Booleans Benjamin Franksen

Navigate by Date:
Prev: Re: EPICS base V4: iocCore database Marty Kraimer
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 
Navigate by Thread:
Prev: Re: EPICS base V4: iocCore database: Booleans Benjamin Franksen
Next: Re: EPICS base V4 Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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 ·