That handy function select() would have more utility if it successfully passed along container references e.g:
void foo(f32& Out, const f32& In1, const f32&In2) { ... }
dense a1, a2, b1,b2; // some data
map(foo)( select(cond, a1, a2), b1, b2 );
Compiles OK, but the JIT seems to decide neither a1 nor a2 is a map output so this code gets optimized away...
- paul
Paul,
Please help me to understand your example. The first argument to 'foo' is the output to be updated inside 'foo'. select() returns a temporary dense object. Passing a temporary object as the output argument for 'foo' does not make sense to me, because the temporary object ceases to exist after 'foo' returns. What do you expect to see as results? Am I missing something here?
Thanks,
Zhang
Hi Zhang,
I'd like select() to return a reference to one of two existing dense containers, for e.g. map() to work its magic on. Obviously my examplecould be hard codedwith an _if block andmostly duplicatedcode, butthis functionality would streamline some thingsI've been working on and be more like the ternary conditional in C & C++ (http://en.wikipedia.org/wiki/%3F:#C.2B.2B) e.g. can be used as an lvalue.
Best regards,
- paul
Paul,
Thanks for the clarification. Now I understand what you meant. As far as I know, C++ does not allow overloading of the ?: operator. I guess this is why ArBB has to use select(), instead of ternary conditional operators, for dense containers. I can see why you'd like select() to return an lvalue. We'll take your request and carefully think about the best way to provide this feature.
Thanks,
Zhang
Hi Zhang,
You are correct regarding overloading ?:, but I'm getting by using (gasp!) pointers and would like to know if this is OK withArBB "behind the scenes" e.g. reference counting, garbage collection, etc.
Ugly code:
template
T* my_select(arbb::boolean& Test, T& ItemT, T& ItemF)
{
T* ret;
_if(Test) {
ret = &ItemT;
} _else {
ret = &ItemF;
} _end_if;
return ret;
}
Example use:
map(foo)( *my_select( cond, a1, a2), b1, b2 );
Seems to work, as long as actually-actually existingcontainers are the arguments. Am I breaking ArBB?
Thanks,
- paul
Hi Paul, Unfortunately your pointer-based approach won't work right - "ret" will always point to &ItemF because assignments to pointers are not captured by ArBB (plain C++ pointers are not ArBB types) and therefore when capturing my_select both pointer assignments will execute and the last one will take effect. The simplest solution to your problem would be to defer the assignment to a1 or a2:
map(foo)(tmp, b1, b2);
_if (cond) { a1 = tmp; } _else { a2 = tmp; } _end_if;
To get the semantics you want, ArBB would need to expose a reference-like or pointer-like type for its variables. This is certainly something we will consider but it is not a trivial feature to design or implement correctly, and you can generally work around it by moving assignments further back as indicated above.
Thanks,
Stefanus
Hi Stefanus,
Thank you for that.I also noticed, last night, that I had run aground on that "baked in" aspect of ArBB, which I seem to do, irritatingly, as an immigrantfromthe C/C++ world.
Best regards,
- paul