Boost logo

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