Boost logo

Boost :

From: Dirk Gerrits (dirk_at_[hidden])
Date: 2002-10-07 13:18:52


David Abrahams wrote:
> Dirk Gerrits <dirk_at_[hidden]> writes:
>
>>isn't 'really' an initialization. The vector gets default constructed
>>first. Still, the functionality seems pretty nice. But I'm personally
>>not such a fan of operator overloading 'mutilation' as in the
>>IOStreams, Boost.Format and your set_cont.
>
>
> Then I bet you'll hate the Boost.Python library, the Spirit parser
> framework, and the Boost Lambda Library, among others...

I'm sorry, I should have given some more argumentation why I think those
are mutiliations.

IOStreams: my objections here are not entirely due to the << and >>
operators. I think it's a pity that binary IO is a 'second class
citizen' compared to text IO. If you have a float f=1.0f and write it to
a filestream opened in binary mode, it will be written as 1 instead of
it's binary representation. I would have liked it if there were two read
and write functions instead of the 1 set of operators.

Although, on second thought, it would be better if there was a single
set of functions/operators that acted differently depending on the
'binary-ness' of the stream.

Boost.Format: I don't see why % (a) % (b) % (c) is better in anyway than
.arg(a).arg(b).arg(c) In my eyes, the latter is clearer. But I guess %
is clearer to those with a scripting background. I would like to see
both syntaxes adopted into the library. But this has been discussed
before so I won't continue any further here.

set_cont: adding 1,2,3,4 to set_cont(v) doesn't seem natural to me.
set_cont(v, (1,2,3,4)) or something similar seems much more natural. Or
even: cont(v) = 1,2,3,4; Am I really the only one who thinks so?

Boost.Python: never used it

Boost.Lambda: never used it either

Spirit: the operator overloading of Spirit follows naturally from the
Extended Backus Normal Form. (Or was the N Naur?) EBNF in any case. ;)

I hope I have rectified my rather rash statement somewhat.

Kind regards,

Dirk Gerrits


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