>>> I'd definitely avoid this situation with gusto. Consider passing '3' >>> (just the number) as "by ref" into the parameter 'x' ---what happens >>> if the compiler inlines that variable, copying it to each place the >>> variable is used inside the function? That becomes problematic for, >>> e.g.,: >>> x = 10 >>> ....which becomes: >>> 3 = 10 > > That's not how function inlining works. And fbc is miles off doing any > optimisations as significant as function inlining anyway.
I was under the impression that function inlining (e.g., inline expansion) included constant propagation as one of its steps. >>> That, at least, is the reason it's illegal in C++ ---not sure what >>> the FB compiler says if you try this. > > I don't think so. C++ can pass other types of temporary values by > reference, so I assume the reason it's illegal is that if you're > passing "3" by reference, it's probably an unintentional bug. Passing > by reference indicates that you want to pass a *variable* instead of a > value. > > And like I said, it works in FB. What you said makes more sense in this case. But then if passing by reference always works in FB, what happens if you pass '3' as a parameter by reference? Does it push a temporary variable to the stack and store '3' in there? Does it declare a temporary variable on the heap and pass its memory address to the function? I'm just curious how FB manages this without corrupting memory. It seems like such a weird design choice. -->Seth _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
