That was quite informative. Clears up the reason why references exist. I heard a copy was made if you try to change an external value inside a function. Does this only occur when you pass a value into the parameter or is a copy made when you change a global from *within* the function as well (a function that takes no parameters, just does default calculations on a global).

I have another good case for pointers. Let's say you have 3 structures you're written to a file in their binary form. Then you can just load the file into memory and munge your pointers to the proper index.

char* pLoadedFileBuffer;STRUCT1* pStruct1;STRUCT2* pStruct2;STRUCT3* pStruct3;pStruct1 = reinterpret_cast<STRUCT1*>(pLoadedFileBuffer);pStruct2 = reinterpret_cast<STRUCT2*>(pLoadedFileBuffer[SIZEOF(STRUCT1)]);pStruct3 = reinterpret_cast<STRUCT3*>(pLoadedFileBuffer[SIZEOF(STRUCT1) + SIZEOF(STRUCT2)]);

Voila! You have your structs all back without having to write routines for loading each individual item.

'Course someone says this is "An overly complex example" but it's a perfect example of where pointers can truly be handy and effective.

Happy coding.

Quote:I heard a copy was made if you try to change an external value inside a function.

No. The only variables you can change inside a function are those that in scope. Such a variable is globally available, or the function is a member function of a class or structure and is accessing a member variable. Either way, they do not get copied.

Quote:Does this only occur when you pass a value into the parameter

Yes. The copy occurs in passing the parameter by value.

This:

Quote:The null pointer shall not be de-referenced.
Rationale: De-referencing a NULL pointer constitutes undefined behavior. [10] Note that this often requires that a pointer be checked for non-NULL status before de-referencing occurs.

...is obviously incompatible with this:

Quote:A pointer shall not be compared to NULL or be assigned NULL; use plain 0 instead.
Rationale: The NULL macro is an implementation-defined C++ null pointer constant that has been defined in multiple ways including 0, 0L, and (void*)0. Due to C++’s stronger type-checking, Stroustrup[2] advises the use plain 0 rather than any suggested NULL macro.

I don't know why Stroustrup would say such a thing, but it's just plain wrong. An invalid pointer is NULL, which is not equal to 0. This means that using 0 instead of NULL is a bug in your code, period. There are even plans for introducing a nullptr keyword in the next version of the C++ standard, to combat this bad behaviour.

Quote:Original post by ToohrVyk

Quote:Original post by Valderman
I don't know why Stroustrup would say such a thing, but it's just plain wrong.

It's perfectly correct, as per the standard, 4.10 §1. The basic idea is that the compile-time integer constant 0 gets converted by the compiler to a null pointer when evaluated in a pointer context (such as ptr == 0).

It still makes for less readable code, and all compilers might not be in on that part of the standard. Both MSVC and GCC sometimes have interesting interpretations of these things.

Quote:Original post by Valderman
It still makes for less readable code, and all compilers might not be in on that part of the standard.

The last standard is 10 years old. I doubt any recent compiler could have trouble with the issue.

Quote:Original post by daviangel

Quote:Original post by Valderman

Quote:Original post by ToohrVyk

Quote:Original post by Valderman
I don't know why Stroustrup would say such a thing, but it's just plain wrong.

It's perfectly correct, as per the standard, 4.10 §1. The basic idea is that the compile-time integer constant 0 gets converted by the compiler to a null pointer when evaluated in a pointer context (such as ptr == 0).

It still makes for less readable code, and all compilers might not be in on that part of the standard. Both MSVC and GCC sometimes have interesting interpretations of these things.

Then use nullptr if you have to name it:

"
Should I use NULL or 0?

In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days.
If you have to name the null pointer, call it nullptr; that's what it's going to be called in C++0x. Then, "nullptr" will be a keyword.
"

Sure. Personally, I wouldn't care if it was called the DivideByZeroPtrOHNOES or whatever, as long as you can plainly see that it's a NULL pointer and not a zero integer. Though I might just have been reading too much C code.

If you do any assembly level programming, you eventually realize that everything is an address. Every time you call a function, your parameters get copied unto the stack. Lets say you have a struct that has 100 integers, that makes your code 100 integers larger if you pass the struct by value into a function. If you throw in a reference, or a pointer to the struct, it only copies the address of the struct.

Also memory allocation plays a huge role when you don't know how much of something you'll have, i.e. linked lists. That way, you can allocate space at runtime. (You can allocate a huge chunk or however much you think you'll need before hand in an array of some sort, but allocating during run time makes it more efficient.)

Static has two meanings depending on where it's used. This is coming from a C perspective, but I'm not 100% on C++, can anyone confirm this?

If you declare a variable as static within a function or one that normally has no linkage (i.e. can't be accessed outside that file or block), it will be initialized only once at the beginning of the program and will exist until the program exits.

If you declare a function or variable outside of a block as static, you change the linkage from external to internal to the file. Which means that function or variable is only accessible from the file it is declared in. This is useful when you want to hide the implementation of something from the user.