Re: [boost] shared_ptr implementation without template friends

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-07-30 13:41:48

Neil Stewart wrote:

> Valentin Bonnard wrote:
> 
> > 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, 

I never shout at people because they use macros, only when they don't
understand 
what a macro is.

> 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?

I have used such tricks in TurboPascal (an ``OO'' languag with no 
concept of private data members -- only private function members).
 
It is ugly, anoying, complicated... and useless on conformant c
ompilers.

This is bugware, and it costs something, here: lines of code, use 
of the preprocessor, complexity. Don't loose too much time with 
bugware.

The more we want to support compilers idiosyncracies, the more 
we need conditionnal compilation. We cannot perfectly support 
every broken compiler. With too much conditionnal compilation, 
the Boost source will be as readable as the SGI STL source, 
or even worse.

We used to say in the Boost library guidelines that libraries 
did not had to do anything useful, but could also be examples 
of well written C++. Let's not make shared_ptr an example of 
ugly C++.

So no, don't do it.

-- 
Valentin Bonnard