Re: [ALACPP] Chris' stupid C++ trick of the week

[<arlo@xxxxxxxxx>]

> While I agree with Arlo that combinatorial problems should be solved in
> like manner, this is not a combinatorial problem per se. It's really a

Actually, the combinatorial discussion had nothing to do with the problem.
The key point of that was that all solutions, to any problem, should be
orthogonal in nature. Thus, solutions are combinatorial, and future
problems can be broken down into subproblems, which have already been
solved. As long as your solutions are orthogonal from your solutions to
other problems, you continually increase the space of "solved problems"
and can re-use a lot of effort.

That's why I liked the solutions based on a modification of the types. It
creates one fixed point of indirection that all other solutions can
ignore. If other things need to modify the return value of the function,
it can be easily chained. Unlike the wrapper function approach (to pick an
arbitrary example), it doesn't conflict with other modifications that may
be made to the function or the call site (eg, exception handling).

> special case of a stupid compiler trick, and one that is, IMHO, utterly
> braindead. What Chris really wants to do is have the function take a
> reference and then have it return a reference, possibly the same one he
> passed in: the semantics are clear.

Very true.

I also agree with what you and Chris were saying: the best real solution
is to fix the language: that is an optimization that probably shouldn't be
allowed.

However, it is. I don't have the power to re-write the compiler that my
office uses, and so I have to find workarounds. ;)

> Chris, am I correct in presuming that the optimization occurs for small
> types only, i.e. T where sizeof(T) < X?
>
> If so, then what you can do is take the call traits solution (using both
> ParamT<> and RetT<>) and define policies for it deciding whether to
> return references based upon the expression sizeof(T) < X. This is
> "dangerous", in that X is an arbitrary and capricious number chosen by
> the damn compiler, but, hey, at least you've now got it in as a simple
> #define value**, which you can #ifdef based on the compiler.

A good idea. You could also, of course, modify this method to work with
compilers that choose other reasons to use the optimization (eg, that do
it for POD types, or builtins).

I'd probably make it just use the call traits to select boost::ref< Foo >
by default, and Foo& where it'll work. boost::ref is heavily inlined and
optimized, and a good compiler will generate the same code as for a normal
ref, but won't be able to take advantage of this particular optimization.
boost::ref is a POD type which we pass by value.

Arlo


_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp