RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

You do realise that a reference is just a slightly modified pointer, with
required initialization and without any pointer manipulation allowed.

While you could do:
  const int &ref =3D 7;
the majority of code using references does:
  int var =3D 7;
  const int &ref =3D var;

Since 'const int &ref' allows for aliasing, i.e. that you have other
access methods to change the value that the reference points to, it is
hard - and often impossible - for the compiler to consider optimization
from a reference.

Since a reference - like a pointer - is an indirect access method, they
are not optimal for object access, unless you do a lot of localized
accesses using the same reference, in which case the compiler may cache
the reference in a register and thereby getting the same access times as
for a variable with a fixed address. Pointers and references are
at their best when you have a large object that you don't want to send as
a value, i.e. instead of a function taking a large struct as parameter, it
can take a reference to that struct.

However, that reference is - internally to the machine - identical to a
pointer, and when the compiler tries to access anything through the
reference, it have to do an indirection.

A reference isn't sometihng of zero size that doesn't exist. Except for
rare cases when the compiler is 100% sure about what it points to, the
reference have the same size - and will generate identical code - as a
pointer.

The whole id=E9a with a pointer or a reference is to either allow a variabl=
e
to point at different entities of something (such as when a constructor or
function takes a reference without knowing at compile time what it will be
initialized to) or when you have an object too large to send as a
parameter.

In both these cases, it is impossible for the compiler to optimize away
the address value stored by the reference, since that would either make
the constructor or function only supporting a hardcoded parameter, or
would in the second case force the large object to be sent on the stack
instead of just the address of the object.

So:
  const int &ref =3D 7;
would normally consume (sizeof(void*) + sizeof(int))




Don't know about writing of about data files. I think I mentioned map
files for looking at sizes of generated functions. But then again, the
size of the emitted code has very little correlation with the execution
speed.

About inlining - such as you get with
  #define MAX 7
or
  const int MAX =3D 7;
- are of course an advantage.

If the compiler generates code
  movl $7,%edx
instead of
  movl _MAX,%edx
there is no need for an extra memory reference, since in the first
alternative, the op-code already contained the value 7, while in the
second alternative, the processor must first parse the op-code, then check
it's data cache and/or issue a data read, and finally perform the move,
i.e. assigning a value to the eax 32-bit register.

/Per W

On Sun, 1 Jun 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 6:52 PM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > I don't know why gcc doesn't optimize a 'const int &var =3D
> > <value>' when
> > referenced.
>
>
> I was speaking compiler indepedently. You had said that const references
> occupy space while only const variables can be "inlined", and then you
> confused me with maps, data files and L1/L@ caches. :) I do not care what
> the current version of GCC does on this matter, the next version may beha=
ve
> differently or the previous versions or even ports of the same version on
> different machines.
>
> For built in array sizes only const variables and #define can do the job.=
 In
> general when I want to define a constant I use a const variable, but if I
> were space concerned I would use a const reference since references do no=
t
> have an address and in theory are more easy to be optimised out than obje=
cts
> (the same thing that happens when we pass const references to functions
> instead of object copies).
>
>
>
>
> > The only thing I could guess is that they never thought
> > it useful to optimize the use of the above declaration, since the
> > most common use for a const reference is something like:
> >
> > int var =3D 12;
> >
> > void func(const int& ref) {
> >     // do something
> > }
> >
> > int main() {
> >     func(var);
> > }
> >
> > In this case, the compiler doesn't know that func() is only
> > called with
> > var as parameter, i.e. with a constant value, so it can't optimize.
>
>
> Yes, but var is "inlined". On the other hand calling func(7), a temporary=
 is
> created.
>
>
>
> > If you think about it, what extra results are you expecting from the
> > following declaration? It is basically an unchangeable pointer to an
> > unchangeable value. But what improvements should it give to
> > your program?
> >
> > const int &var =3D 12;
>
>
> I consider that the compiler could more easily inline it than const int
> var=3D12; But anyway in real world programs for PCs, whether it will inli=
ne it
> or not, it doesn't matter.
>
> I disagree(d) with you that a const variable can be inlined while a const
> reference cannot. Theoretically both can be inlined, system-indepedently
> speaking.
>
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>