Re: How smart is g++

[Guy Harrison]

John Max Skaller wrote:

> On Wed, 03 Nov 2004 17:59:52 +0000, Guy Harrison wrote:
> 
>> John Max Skaller wrote:
>> 
>>> How smart is g++ handling references? Consider:
>>> 
>>> struct X { int j; };
>>> 
>>> void f(X x)
>>> {
>>>   int j_copy = x.j;
>>>   int & j_ref = x.j;
>>>   ...
>>> }
>>> 
>>> Is g++ smart enough to make uses of j_copy and j_ref
>>> the same speed? Meaning to use the same instructions?
> 
> []
> 
>>> Hmm .. did the question make sense?
>> 
>> Mostly. Depends why you're doing it.
> 
> Suppose I have systematically generated code like this:
> 
> void f(T const &arg) {
> T1 v1 = arg.mem1;
> T2 v2 = arg.mem2;
> T3 v3 = arg.mem3;
> ... use v1 v2 v3 ...
> }
> 
> and was thinking to change it to this:
> 
> void f(T const &arg) {
> argument = arg;
> T1 &v1 = argument.mem1;
> T2 &v2 = argument.mem2;
> T3 &v3 = argument.mem3;
> ... use v1 v2 v3 ..
> }

An unoptimised 'gcc' in practice, will generate pointer oriented code, A
'gcc', with optimisation will do exactly the same thing, then lose the
extra code in the back-end optimisation.
 
>> In contrast, if one were reading this struct only the once, as you imply,
>> then the design may be better off dispensing with that struct altogether
>> - or simply write an "import module" to read it once, thereafter write
>> out something more suitable. Alternatively one might decide to dispense
>> with the C++ wrapper and access the struct directly.
> 
> Indeed  -- there are many alternatives, and it's hard to
> pick a good one. The language being implemented allows this:
> 
> f (1,2,3)
> 
> but also this:
> 
> x = (1,2,3);
> f x;
> 
> and they mean the same thing:

Possibly (they ought, assuming programmer correctness). The former invokes
the ctor whereas the latter invokes the ctor (for 'x') then the 'x' cctor
for 'f'.

> call f with a single argument 
> that happens in this case to be a tuple. The function may
> be defined like this:
> 
> proc f (x:int, y:int, z:int) {
> print x; print y; print z;
> }
> 
> The implementation uses
> 
> struct { int mem1; int mem2; int mem3; };
> 
> as the argument type, and unpacks it as indicated above.
> At least one reason is so the names 'x' 'y' and 'z' appear
> in the generated code so the user can actually read it.

There is no standard "file definition" in either the C or C++ languages
(other than FILE/stream) - they have no mapping onto the real world...

> So roughly speaking we're talking about the function
> call protocol for a programming language.

Ah! Historically, C arguments are pushed right to left. Visit M$ for reasons
why even supposedly compliant code doesn't work in practice. In theoy 'tis
simple - what if sizeof(int/host) != sizeof(int/target).