Boost logo

Boost :

From: Neil Stewart (nwstewart_at_[hidden])
Date: 2000-07-30 17:48:47


----- Original Message -----
From: Valentin Bonnard

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

Yes, but isn't making the member public also useless on conforming
compilers? Surely if that is a valid argument against this method, it is
also a valid argument against allowing the member to be made public, as is
currently done in shared_ptr?

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

I'm not convinced that this actually is bugware. It does not change the code
seen
by the compiler (after preprocessing) and therefore is not introducing any
undefined behaviour to get round non-conforming compilers.

There is a cost, but there is also a potential gain, by making the member
harder to get at, and detectable when used illegally.

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

Is the readability of the Boost source far more important than the abiility
to use it (on non-conforming compilers as well as conforming ones)? What is
the exact policy here? It is obvious that Boost does in fact cater for
broken compilers (and quite extensively). Are you saying that it shouldn't,
or simply that it shouldn't go too far to fix everything and, if so, how do
you define how far is acceptable?

> 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++.

I though shared_ptr was also supposed to be an example of useful, practical
C++. If so, isn't a little ugliness a fair trade for increased usefulness or
practicality?

> So no, don't do it.

Oh, ok then. :)

- Neil


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk