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

Subject: Re: ICE and TIPC
From: Andrew Johnson <[email protected]>
Cc: [email protected]
Date: Wed, 27 Jul 2005 16:55:21 -0500
Jeff Hill wrote:

In my example at the meeting I showed how DA could be enhanced to introspect
the structure of the data - w/o an instance of the data. I communicated this
information using an simple template class as follows.

template < class T >
struct TypedVoid { };
>
I don't see any reason why the interface to this struct couldn't, or
shouldn't, be extended as Ralph suggested at the meeting, to include member
functions returning type codes for (B) above (it already does A).

Shouldn't a propertySurveyor also be given access rights information (i.e. whether a particular property is writable or not)? Do you intend to use a different mechanism to communicate that somehow? Unfortunately your very clever template mechanism only works with fully symmetrical property sets; in many cases I think we're going to have to write all three traverse() routines ourselves, to cope with read-only properties.

WRT (2) above I have no problem using someone else's (Marty's) size locked
type set in the CA protocol, but given the features in DA this would only be
a organizationally cosmetic benefit, but not a feature required to make sure
that the proper size locked type code for what the users is really using is
discovered by CA for its use on the wire. Of course the TypedVoid interface
(or whatever the correct class name is) should use a common type code set.

Can I urge that we make use of the size-locked integer types that are already defined for us in the C99 header files stdint.h and inttypes.h, rather than defining our own typedefs and having to check for each platform whether a long is 32 or 64 bits. There are standard typdefs for int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t and uint64_t. There are other typedefs defined too which might prove useful, but I won't go into them here.

C99 also defines a matching set of string macros for use in printf() and scanf() format specifications, which means you can pass an int64_t into printf() without worrying whether to say "%ld" or "%lld" in the format string - you use "%" PRId64 instead.


- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Replies:
Data Interface (was: ICE & TIPC) Kay-Uwe Kasemir
RE: ICE and TIPC Jeff Hill
Re: ICE and TIPC Ralph Lange
References:
RE: ICE and TIPC Jeff Hill

Navigate by Date:
Prev: RE: ICE and TIPC Jeff Hill
Next: Data Interface (was: ICE & TIPC) Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: ICE and TIPC Jeff Hill
Next: Data Interface (was: ICE & TIPC) Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
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 ·