quote:
--------------------------------------------------------------------------------
Original post by Anonymous Poster
Especially considering a pointer is 32 bits long and so is an int.
--------------------------------------------------------------------------------


Not necessarily.<SabreMan>


You''re right, let''s clear this up. An int on a 32 bit system is 32 bits. An int on a 16 bit system is 16 bits. I''m assuming that the 64 bit system will yield a 64 bit int (for easier porting). Any operating systems or compilers not following this convention is doing its user a great injustice! (i.e. get a new compiler).

quote:
--------------------------------------------------------------------------------
People say a lot of things, and people often speak from ignorance. The rules[1] for using pointers in C++ are to only use them when there is no convenient alternative. In most contexts, a convenient and superior alternative is available in the form of smart pointers. The book Accelerated C++ will teach you how to use C++ as it is intended by its creators.

[1] of course, they''re not really rules, but heuristic guidelines distilled from many years of collective experience, also known as "patterns".
--------------------------------------------------------------------------------

Ok, when I first read the above, I think some might take it that you were flaming most of the people in the post (the first sentence directly above I should say). I understand otherwise seeing the problems people get in with pointers. I also read the second sentence and thought it was a load of bull UNTIL I read your footnote.

Let''s get this straight: Pointers are very dangerous if used incorrectly. They are the number one cause of memory leaks (through the new and malloc mechanisms). They often are used incorrectly and point to invalid or wrong memory locations, causing all sorts of problems for the host program and the entire operating system. Imagine writing to a wrong location that causes a page fault or locks up the OS.

That''s why there are patterns and methods for solving certain problems using pointers. And other methods that don''t require the knowledge of pointers (best to avoid pointers).

I personally don''t like the Standard Template Library(STL), but it happens to be probably the best solutions to most problems. If there''s a problem, there usually is a STL solution. One STL answer to pointers is auto_ptr:

#include <memory> //if necessary
using namespace std;

auto_ptr<type> name (new type);

STL also has a ton of other solutions that don''t require the end user knowing how to use pointers to solve their problem. For instance the ''vector container'' (very useful).

Here''s what a program is: algorithms that opperate on data. STL has a very diverse and flexible container system for data that includes common algorithms (sort, eliminate duplicates, rotate, etc..) that operate on its data.

The only book I have on STL is a light reference section in the C++ Black book. <SabreMan> endorsed a book called "Accelerated C++", I ''assume'' that book is for beginers so I haven''t read it, beings I prefer reference manuals.

Search the web for these keywords for a better understanding:
STL, standard template library

quote: Original post by SabreMan

Original post by Anonymous Poster
Ok, when I first read the above, I think some might take it that you were flaming most of the people in the post (the first sentence directly above I should say).

How could I have been if that was the first response in this thread?

quote:
That's why there are patterns and methods for solving certain problems using pointers. And other methods that don't require the knowledge of pointers (best to avoid pointers).

The phenomenon I've noticed is that more experienced users of C++ rarely have bare pointers in their code. In the cases where they do need pointers to solve a problem, they will write some sort of class which caters for the outer problem, and that will become part of their library. The pointer then doesn't need to be in the client code, where the immediate intention is being expressed. In many cases, there are existing handle classes (such as Boost::shared_ptr) which are sufficient for the requirements at hand.

What tends to happen in the Gamedev forums is that many responders know about pointers, but do not know enough to to control their use of pointers, so they end up misrepresenting when and how pointers should be used. A beginner is left with the impression that pointers are the best thing since sliced bread and scatter them liberally throughout their code without any thought for the potential problems. Once the beginner has learned about pointers, but is still ignorant of the alternatives, every problem starts looking like a pointer is needed. Then they come back to these forums with their new and exciting knowledge, telling other newbies that they must use pointers.

Pointers are a powerful tool, providing the oft-needed extra level of indirection, but they aren't as essential as is so often suggested on these forums.

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

[edited by - SabreMan on May 23, 2002 12:56:39 PM]

quote:
Reference. A more conventional syntax would use a reference.

Yes, you are right, that would be preferable. I was approaching it from the C angle, although since it is valid C++ for doing that and using a global pointer to return things is not as conventional as passing a pointer to a function. You and others might not like it but it is more conventional from a C background.

quote:
Reference. A more conventional syntax would use a reference.

References in stand-alone code are an ugly part of C++. I think those who designed the language went overboard in their "cleansing" of whatever C features they didn''t like. It is just a means of avoiding some syntax, which IMHO is needed to clarify code a lot of the time.

What is the difference between & (c++) and * (c)? The difference is that when you are trying to debug/understand the functions that received reference/pointers, using pointers you can CLEARLY identify when an outside value has been changed (*var = 5), but when you use references, it is not so clear and can be easy to forget or confuse (var = 5), especially if it''s older code or not your own code. The possibility for misinterpretation is there with references.

It''s also not so clear when you pass variables to such functions:

f(i, j, k); // we have to look at f''s prototype to know if it might modify i,j,k
f(&i, &j, &k); // we know right away that the variables passed might be modified

Overall, references breed laziness by hiding certain functionality. But the real bugger is when you are looking at other people''s code, or even your own code that you havent seen for a long time. Seeing that asterisk keeps you sharp, it is a visual reminder that "this is a pointer."

I realize they have specific uses in classes, but apart from that.. ugly, ugly...

A little flame to end the post. After reading several of his posts, I''m sure SabreMan will belittle my post and make me out as a newbie. That''s because he knows all, and I don''t agree with him on something, therefore I am inferior.

quote: Original post by foofightr
After reading several of his posts, I''m sure SabreMan will belittle my post and make me out as a newbie. That''s because he knows all, and I don''t agree with him on something, therefore I am inferior.

Yawn...

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

maybe i am dumb, or just too much of a novice, but i still do not understand pointers. i know that they allow memory allocation(forgive me if that is the wrong wording) but i dont know why this is so useful, or how it is implemented.
the way i see it is that you make a pointer. then a variable that holds a value. then i believe the pointer holds the address of the variable. and by accessing the pointer, you access the value of the variable?
i have read articles in the reference section here, and they do nothing for me. if you guys would help me understand how they get the address, and the true advantages for these pointers in gaming and other programming, i would be much abliged.

Mythril

well they are good for dynamic memory allocation.. Lets say you want to load a file in a program which the user of the program choose from a dialog box.. if you want to avoid a pointer you would have to allocate enough memory to hold the file whatever the file sizes.. but this would be stupid especially if your file could be several megs in size.. with a pointer you could do this:

char *buffer; //
buffer = (char *) malloc(filesize);
LoadFile(buffer);
// do something with the data here
free(buffer);

but this is C.. there are better ways of doing this in C++..

just trying to show one way of using a pointer :-)

quote: Original post by Anonymous Poster
You''re right, let''s clear this up. An int on a 32 bit system is 32 bits. An int on a 16 bit system is 16 bits. I''m assuming that the 64 bit system will yield a 64 bit int (for easier porting). Any operating systems or compilers not following this convention is doing its user a great injustice! (i.e. get a new compiler).

I always thought that the size of lets say an int depends rather on the compiler you''re using than the OS you''re running. Correct me if I''m wrong, but I don''t think there is some ISO/ANSI/Whatever standard that involves the size of the datatypes. I think it''s only specified to that point that char < short < int. I''m no expert at this since I''m quite stuck on windows using VC++ wich uses 32 bits for ints....
Flame me if I''m wrong

quote: Original post by foofightr

f(i, j, k); // we have to look at f's prototype to know if it might modify i,j,k
f(&i, &j, &k); // we know right away that the variables passed might be modified

Let's see

// do i need to use those ugly &x, &y, &z?// one glance at it, i know it is going to change x, y, zGetCoord(x, y, z); ...//instead of function name that hardly make any sense likegc(&x, &y, &z);   

Those days of using pointers as output parameters are slowly drifting away (except special cases ) Plus compilers should be able to 'understand' more on how to optimize 'passing by reference'... after all they act like alias (is it?)

quote:
...
Overall, references breed laziness by hiding certain functionality. But the real bugger is when you are looking at other people's code, or even your own code that you havent seen for a long time...

Laziness in the sense that to lessen the need for 'double checking' on pointers.

Anyway from my experience, usually when I see code that bloated with calling function by 'passing address to pointers' like:

..foo(&someObj, &someStruct, &someData);blahblah(&somethings, &certainthings);...  

they are often having lots of pointers problem.

One, two, or maybe ten, not more, of 'twinkle stars' should be no problem. But hundreds and thousands of them does 'hurt' ur eyes.


[edited by - DerekSaw on May 24, 2002 5:21:12 AM]

quote: Original post by DerekSaw
Plus compilers should be able to ''understand'' more on how to optimize ''passing by reference''... after all they act like alias (is it?)

Under the hood, a reference is often implemented as a pointer, so the optimisation trade-offs won''t be an issue. A reference also provides a stronger guarantee than a pointer in that it *must* point at a valid object of the referent type. You don''t hear of "wild" or invalid references. Every language feature brings with it the potential for abuse and, to be perfectly honest, I''''ve never had the problems with references that foofightr apparently experiences. I mean, if you are going to use a function and you don''t know what it does, you have to find out what it does anyway - and that involves looking at the function declaration along with any documentation. I don''t see how using a reference makes that process any more challenging. In practice, I rarely use pass-by-non-const-reference.

quote:
Laziness in the sense that to lessen the need for ''double checking'' on pointers.

Laziness in the sense that you are not getting a regular exercise regime of debugging and rewriting chunks of code. I guess I must be *really* lazy.

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]