Experimental Physics and Industrial Control System

> Is this as type-safe as the GNU version of CONTAINER, which checks that the 
> member's data type matches the pointer?

The user's code definitely will not compile if the type of the enclosure isn't consistent with the type of its member field, as specified by the C++ pointer-to-member-data. We have a three part consistency that is enforced by the compiler via the C++ pointer-to-member-data {enclosure type, member data type, member data offset}. The actual enforcement is a dide effect of the "enclosureOf ( M * pData, M T :: * pMemberData )" argument signature.

> I note that CONTAINER works for C code, whereas this is pure C++.

Yes, the value added here is 100% deriving from the C++ template implementation so its only for use in C++ code, and we wouldn't expect to implement an equivalent C interface.

> My main concern is getting the name right; since we're already using the word 
> Container would it make sense to use that instead of Enclosure?

The name enclosure implies more about a defined boundary of access which is perhaps appropriate for a C++ context. The container name is certainly very appropriate for C. I suppose that I personally have a small preference for the name enclosure in the C++ context. Nevertheless, names mean different things to different people so I am interested in what others prefer, and very willing to compromise if there is any objection at all to this particular name. I have some considerable amounts of code that already uses this interface, but most of it is currently wrapped by other interfaces, and also its very easy to do a global replace in the editor.

Is it a good or bad thing if the two interfaces have the same name? On the one hand is the possibility that the user might not grasp that they are comparable functionality, and on the other hand is the possibility that they might be confused and therefore used in the wrong context, but the compiler will have plenty to say about that. Overall, it would certainly look like we designed the code if they both used a common root in their names. Open to suggestions.

> Also, should we move the CONTAINER macro into this header (with guards to allow it 
> to be included from C code)?

I don't see any problem at all with that type of consolidation, or moving this code into another header file already in base. This is used quite a bit in the new server code so it might be a stretch to include dbDefs.h into the server since it can attach to other data systems. Personally, I am designing in the direction of smaller header files with only one, or just a few, classes per header file.

-- 
https://code.launchpad.net/~johill-lanl/epics-base/epics-base-enclosure-of/+merge/196010
Your team EPICS Core Developers is requested to review the proposed merge of lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base.

Replies:

Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base mdavidsaver

References:

[Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base Jeff Hill

Navigate by Date:

Prev: Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base Andrew Johnson

Next: Build failed in Jenkins: epics-base-3.15 #30 APS Jenkins

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: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base Andrew Johnson

Next: Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base mdavidsaver

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <2013>  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024