2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | EPICS base V4 |
From: | Marty Kraimer <[email protected]> |
To: | Benjamin Franksen <[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 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 bitsAlthough 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