Subject: |
Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base |
From: |
mdavidsaver <[email protected]> |
To: |
Jeff Hill <[email protected]> |
Date: |
Thu, 21 Nov 2013 00:12:25 -0000 |
I take it that the use of reinterpret_cast<>() is meant to bypass the
restriction that offsetof() won't work on complex types? Is the
compiler being able to calculate "&klass::member" an equivalent
restriction? What, if any, trouble could I expect when using
"enclosureOf" on a class w/ inheritance? Are there any restrictions
which need to be documented (ie with virtual inheritance)?
On 11/20/2013 06:44 PM, Jeff Hill wrote:
> > 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?
>
> ...Open to suggestions.
"containerOf"?
> > Also, should we move the CONTAINER macro into this header (with guards to allow it
> > to be included from C code)?
As long as CONTAINER continues to be pulled in by dbDefs.h I see no problem.
--
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.
- References:
- Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base Jeff Hill
- Navigate by Date:
- Prev:
Build failed in Jenkins: epics-base-3.15 #30 APS Jenkins
- Next:
Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base Jeff Hill
- 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 Jeff Hill
- Next:
Re: [Merge] lp:~johill-lanl/epics-base/epics-base-enclosure-of into lp:epics-base Jeff Hill
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|