|
Boost : |
From: Neil Stewart (nwstewart_at_[hidden])
Date: 2000-07-30 04:56:18
----- Original Message -----
From: Valentin Bonnard
> What is proposed is bugware (ie, having the wrong behaviour (invoking
> undefined
> behaviour) because someone else had the wrong behaviour (not handling
> standard C++)). Bugware is generaly bad; here I think it is the wrong
> solution because another simplier and working solution is already in
> use:
> make everything public.
>
> If some idiot tries to access undocumented members that are public by
> accident it's only his problem, let's not loose time on this.
I did come up with one solution for this with one of my own smart ptrs. It
uses a macro, so feel free to shout at me, but it does make it harder for
people to use the public members, which suited my needs at the time: other
team members with 'curious' programming practices. ;)
Basically, I use a define for the member name that is to be made 'public',
eg. (for the raw ptr in a smart ptr):
#define RAW_PTR_NAME pRaw_PRIVATE_DO_NOT_ACCESS
I then use the define to declare and use the raw ptr in the smart ptr code:
public:
Countable_ *RAW_PTR_NAME;
Making sure of course, I undef at the end of the smart ptr header, so no-one
can use the macro in external code:
#undef RAW_PTR_NAME
This way, if someone uses the member name directly (which they'd be mad to,
looking at the name), I can find out by changing the define, which will
break any code that accesses the member.
Of course, changing the define would cause a lot of files to be rebuilt,
which is bad on a large project, so I actually use a different define for
debug and release builds, which makes this less of a hassle and causes the
illegal 'public' member access to be rejected when the build type is
switched:
#ifdef _DEBUG
#define RAW_PTR_NAME pRaw_PRIVATE_DO_NOT_ACCESS
#else
#define RAW_PTR_NAME pRaw_DO_NOT_ACCESS_PRIVATE
#endif
Is this a reasonable way to go, or am I missing something?
- Neil
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk