Boost logo

Boost :

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
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):
> 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
> #else
> #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

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at