From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2000-12-04 14:13:42
Gary Powell wrote:
> We started with a "simple" solution too. On reading the standard and trying
> to cover all the edge cases we ended up with the code you see. It's not the
> clearest due to the number of overlapping cases but its actually not that
> bad either.
I wasn't saying it's bad :). Actually it's pretty good and I've stolen some
ideas from your implementation ;). My point is that right now the
'return_type_traits.hpp' header used by LL is not a general "types
promotion/deduction library/framework/whatever'" that an ordinary user (like
me :) could use 'out of box' (I know, it was not supposed to be such, too :).
It's more, and there are some Lambda-specific parts there, which kind of scare
What I want to see is a more lightweight set of components, splitted into a
few categories, so I can use one of them or another for my simple (relatively
to LL) stuff, and yet don't be depreseed by including into my headers a huge
amount of code which I could not understand ;). Actually, personally I have no
problem with that, but users of *my* library could feel different...
And by combining all of these components together I can still get something
equivalent to the current functionality in the 'return_type_traits' header.
Something like our 'operators' library :).
> BTW did you read the article "A Portable typeof Operator" by Bill Gibbons?
> It think it was in CUJ October or September 2000. (I didn't find a copy on
> their site.)
I did, and that's an interesting technique, but whit it you can't write
template<class T1, class T2>
my<typeof(T1 + T2)>
operator+(my const&, my const&);
so it isn't much of interest for me now...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk