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: | Re: epicsTypes.h question |
From: | "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov> |
To: | "zan.pratnemer at cosylab.com" <zan.pratnemer at cosylab.com> |
Cc: | EPICS core-talk <core-talk at aps.anl.gov>, Ziga Oven <ziga.oven at cosylab.com> |
Date: | Tue, 2 Mar 2021 18:46:12 +0000 |
Hi Zan,
On Mar 2, 2021, at 4:58 AM,
zan.pratnemer at cosylab.com wrote:
Good question.
When I added Int64 type support to the IOC I didn’t extend the epicsType enum because it isn’t used inside the IOC, and it contains the enumerations
epicsStringT and epicsOldStringT which correspond to types that aren't used by the IOC code, although some of them might be used outside – I suspect this enum pre-date the “new” dbAccess
API, but I wasn’t involved at the time. I hope we will someday deprecate some of the unused definitions in epicsTypes.h and eventually remove them, but nobody particularly enjoys doing housekeeping...
We actually have a few other similar enumerations that we do use, the main ones being
dbfType as defined in dbFldTypes.h and
menuFtype defined in menuFtype.dbd and provided in the menuFtype.h header file. The DBF_ and
DBR_ macros defined in db_access.h are for the data types supported by Channel Access and don’t include unsigned or 64-bit choices, so don’t try to use them.
I recommend switching to the menuFtype enumeration. These values correspond to the field types supported by the waveform record and other array record fields, and do include values for the 64-bit integer types. They are thus directly related to
the types that device support normally needs to implement.
HTH,
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|