Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-01 13:12:16

On Sunday 01 July 2001 12:57, you wrote:
> Douglas Gregor wrote:
> > One need only lift the restriction that operator, cannot be overloaded
> > for primitive datatypes to give tuples a more natural construction
> > interface.
> That is equivalent to banning the current meaning :-)

Well, yes, and it goes against the C++ philosophy that the language should be
extensible but not mutable. I like mutable languages :)

> > Tuples may be an exception because they are so basic, but I would say
> > that the first question one should ask when implementing a new language
> > feature is 'what prevents this from being part of a library instead of
> > the language?'
> Apart from efficiency, and a low limit on the maximum
> arity of a tuple, a binary operation won't do. Tuple formation
> isn't associative, distinct operators of arity 0,2,3, .. n.
> Function call is fine
> tuple(1,2,3,4);
> if you provide n of them for large enough n.

Having code in a library does not prevent a particular compiler from
implementing it and overriding the library (_if_ the library semantics are

The low limit can be increased. Using something like the preprocessor library
there is very little ( = no) maintenance required to increase the maximum
value of "n". Yes, I understand the compile-time hit, but I have never had a
use for more than 10 arguments. With 10 arguments I would start to wonder if
there is a design and/or usability problem.

The binary operator is, of course, a problem :)


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