quote:Original post by rypyr
"just learn to code properly"...that''s a good one...

If you dislike references so much, don''t use them, it''s that simple. You don''t need to get upset about them.

However, the main argument for references is to ensure that what you''re "pointing at" is valid and not NULL. It''s very hard to get around this if you''re using references.

If you don''t accept that argument, the only other ones I can think of are: 1) it''s easier to declare a const reference (i.e. a pointer to an object that you cannot modify) than it is for pointers and 2) you can still use the dot notation with references.

Generally, when programming interfaces, it is better to use const references wherever possible.

Regards,
Jeff

From the link that was posted earlier
"Some people take the fact that a reference can''t be null to mean that references are somehow safer than pointers. They may be a little safer, but I don''t think they''re a lot safer. Although a valid reference can''t be null, an invalid one can be null. In fact, there''s a ton of ways programs can produce invalid references, not just null references. For example, you can define a reference so that it refers to the object addressed by a pointer, as in:


int *p;
...
int &r = *p;

If the pointer happens to be null at the time of the reference definition, the reference is a null reference. Technically, the error is not in binding the reference, but in dereferencing the null pointer. Dereferencing a null pointer produces undefined behavior, which means lots of things could happen, and most of them aren''t good. It''s likely that, when the program binds reference r to *p (the object that p points to), it won''t actually dereference p. Rather, it will just copy the value of p to the pointer that implements r. The program will keep running only to have the error manifest itself more overtly sometime later during program execution. Oh joy."

It''s certainly possible to have invalid references in your program. They are not necessarily any safer than using pointers. To me, the advantage to references is that they''re easier to read. Pointers tend to make you have 100 ''*''s in your program. There are things you can only do with references, but there are also things you can only do with pointers. After gaining a good understanding of how your computer stores data, pointers are rather intuitive and references are more abstract. Usually, it''s obvious when you should use pointers, when you should use references, and when it doesn''t matter which one you use.. In the last case, it''s just a matter of preference.

well im not upset about them really... but maybe a little, true. if i read any docs about them, all authors seem completely brainwashed by refereces, while failing to explain to me why theyre so enthousiastic about them. almost like they got money to propagade them..

and besides, i think the last post has the most important argument for me: theyre less intuitive than pointers. i still dont get witch way compilers handle references, witch i dont like much: i like to know what im doing to my computer.

and whats the thing(s) mentioned you can only do with a reference and not with a pointer?

quote:
and whats the thing(s) mentioned you can only do with a reference and not with a pointer?

I''m not positive, but it seems like there are some instances when you must use references to overload an operator. At least, that what i was refering to. There are probably others.

Might have been covered, and you might disagree with me, but I find pointers are helpful also for generic functions.

Say I have a function which calculates X from an array A[n]. Now, I have a similar function which calcutes X from an array A[n][m]. And I have another function which calculates X from A[n][m][o]. Now, these are unknown numbers. I don''t know how big the arrays actually are. They were dynamically created.

As an example. Write a single function which takes any array, be it A ' Target=_Blank>Link