Hi,
I have split my original answer up into ths separate sub-topics.
On Tuesday 22 February 2005 16:44, Andrew Johnson wrote:
> Marty Kraimer wrote:
> > Benjamin Franksen wrote:
> >> (1) I don't think type BOOL is needed. We can use a MENU instead, e.g.
> >>
> >> menu(menuBool) {
> >> choice(menuBoolFalse,"False")
> >> choice(menuBoolTrue,"True")
> >> }
> >
> > Perhaps bool is such a fundamental data type that we should support it?
>
> Both the C++ and C99 standards committees decided that bool should be
> added to their respective languages and we need a way to be able to
> interface to their types anyhow.
Of course we want to do that. That doesn't mean we have to follow C99 in
making it a basic type. As the current proposal stands, none of the basic
field types get directly translated to a standard C type. The intervening
typedef is there to ensure that we can garantee sizes on each platform and
compiler. Why should bool be any different?
[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.]
> The problem with using a menu is that
> an IOC designer might think they're allowed to change the menu
> definition, such as swapping the order of the choices or adding extra
> onces.
Why would anyone want to do that? I think a strong warning in the docs would
suffice to scare off at least any non-expert. It is true that with 'include'
as the basic tool for modularization, stability of standard definitions is
hard to enforce. OTOH, at the moment nothing prevents users from exchanging
the choices in menuYesNo, which would surely have fatal consequences. In
fact, /all/ the dbd files that get compiled into the core must never be
changed without recompiling base.
> Trying that would reveal the hidden internal dependencies that
> exists - False must always be the first choice, and any extra choices
> will probably act as synonyms for True, but some code might not work
> with them. I'd rather just have a fundamental type for boolean values -
> there are fields in the current dbCommon that are defined as DBF_CHAR to
> minimize memory usage (note that ENUM/MENU are both currently 16 bits),
> but which are used to hold boolean values.
I will not insist on my POV but neither am I convinced. Whether boolean is a
basic type or not is probably not an issue important enough to warrant such a
lengthy discussion. Therefore let me put the question into a larger context.
If we are really so concerned about memory consumption per record, then I'd
suggest to change menu choices to use only 8 bit, at least as regards memory
layout for records and CA data types. I'd be very much surprised if there is
any menu definition in the world that uses more than 256 choices (other
than /maybe/ some instances of menuConvert because of many breaktables; this
necessity to extend menuConvert for each breaktable is a mis-feature we we
should get rid of anyway).
OTOH, any code that handles choices internally should use plain int rather
than any kind of size locked type; int is always the fastest integral type
and is trivially converted from/to byte or short, signed or unsigned. Also,
handling non-int integral values is error-prone in C because of very
non-obvious silent integral promotions (for instance whenever you use bitwise
operations).
One could go even further and consider dbToRecordtypeH to perform
optimizations like using bit fields for consecutive booleans. Of course this
would complicate the access code a bit, but if memory per record is *that*
important, shouldn't it be worthwhile?
So long,
Ben
- Replies:
- EPICS base V4 Marty Kraimer
- References:
- Re: EPICS base V4: iocCore database Marty Kraimer
- Re: EPICS base V4: iocCore database Andrew Johnson
- Navigate by Date:
- Prev:
RE: [Fwd: RE: EPICS base V4: iocCore database] Jeff Hill
- Next:
Re: EPICS base V4: iocCore database: registrar, special Benjamin Franksen
- 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:
Re: EPICS base V4: iocCore database Andrew Johnson
- Next:
EPICS base V4 Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|