I grasped pointers :D it took two months from complete c++ ignorance!! how long it take you?

[chrisname]

ne555 wrote:

If it failed you could return an invalid object

How does the caller know it's invalid? What if the callee is a templated function and thus doesn't know what kind object it's returning when you write it? If you're writing a container class that has a find() method which returns a reference to a contained object, what can it return when it doesn't find anything? You would have to use exceptions in that case.

ne555 wrote:

why is your function returning a pointer in the first place?

It's very common in C. Take the C streams API for example: FILE* fopen(const char* path, const char* mode);.

ne555 wrote:

The principal function of pointers is to point.

Which is totally useless by itself. It's only by applying that function that we can use pointers to do useful stuff.

I don't see what you're getting at. This all seems like hair-splitting to me.

L B wrote:

function overloading exists

Not in C. In C you have to manually mangle your function names which is ugly. Besides, consider a function like the GNU libc function int getline(char** buffer, size_t* size, FILE* stream);. If *buffer == NULL then it is allocated for you. If size != NULL it is used as the initial size of the buffer.

[Nexius]

That is out of context, however, as this isn't a C forum.
Overloading is relevant, and so are templates and namespaces and other things C++ allows that C does not.
In any case, the paradigm that pointers are useless by themselves can be applied to anything, not just pointers. I do see his point. No pun intended.

[Raezzor]

Honestly, for me, I think the key to understanding pointers was understanding the whole pass by value/reference thing. Once you understand just how functions accept and return arguments you begin to see how pointers work a bit more. That, and understanding arrays more. And just how to read long complicated names (ie, understanding the difference between const int * a, and int * const b.) And, if yer feelin pro, decoding this declaration: const double *(*(*pd)[3]))(const double*, int) = &pa

[chrisname]

@Nexius
This is the off-topic board, the subject matter is not restricted to C++ or even programming in general. The topic of the thread is pointers, which exist outside of C++ (and C, for that matter). Furthermore, C is the language from which C++ is derived, and can even be considered a subset of C++, so it's relevant on all the boards. Anyway, it doesn't matter if it's out of context, the points I made still stand.

In any case, the paradigm that pointers are useless by themselves can be applied to anything, not just pointers. I do see his point. No pun intended.

Who said pointers were useless?

[LB]

@Raezzor your reasoning for understanding pointers suggests you still do not understand pointers. The fact that you can use them as the type for function parameters is irrelevant.

[ne555]

Yep, but I started (tried to) with `explain pointers to a C++ programmer'

FILE* fopen(const char* path, const char* mode); OOP in C, it encapsulates the members showing only the interface (only needing a forward declaring to use)
Although you could still work that way in C++, you also have classes with methods, so you could simply return an stream (well, move it)


My point

class file_system;
class file: public file_system;
class directory: public file_system{
   container< file_system* > content;
};

Or if you prefer

class organ;
class human{
   container< organ* > body;
};

you need pointers if you intend to do a transplant, or account for Siamese twins.

[devonrevenge]

so how can there be black-belt c++ programmers then?

[LB]

There aren't?

[devonrevenge]

i bet you i could find more than one

[LB]

Well, there are probably people who are black belts in some art, who also happen to be C++ programmers, but there aren't colored belt designations that correspond to the C++ skill level of people...

[devonrevenge]

i think there should be, when im good i will create a website :D

[Raezzor]

@LB Ok man, I dunno what your issue is with me, but I'm done with you. I was simply saying what helped to make pointers click for me and you have to start talking down? Sure, I may not understand all the intricacies of their use, but I know what they are and what they do. If HOW I got to my understanding of pointers ruffles your feathers that's your problem, not mine. And if you are so sure that my understanding is flawed, instead of simply saying so how about you suggest HOW my understanding is flawed?

[LB]

Wow, I did not mean to come across so hostile to you - sorry :(

I'll be specific:

Raezzor wrote:

Honestly, for me, I think the key to understanding pointers was understanding the whole pass by value/reference thing. Once you understand just how functions accept and return arguments you begin to see how pointers work a bit more.

While pointers can be used a faction parameters, tha has little to do with the way they actually work. Pointers are just integral types that contain a memory address, along with soe syntactic sugar to make them easier to deal with. Their use with functions is based on convention, not language feature.

Raezzor wrote:

That, and understanding arrays more.

Unfortunately in C++, arrays are something I tend to avoid, as they almost always degrade into pointers. The actual Array type such asint arr[3]; isn't actually a pointer, though it is very often implicitly casted to one and treated as a pointer to a memory address on the stack. Dynamically allocated memory is not arrays, but can be very eaily (and almost always are) thought of as arrays. They're really just pointers to single variables and it just happens that due to the memory allocation process used, incrementing the pointer will allow it to point to yet another valid object in memory, but most people will make fun of you if you actually say that the pointer points to multiple objects. (they made fun of me, at least)

Raezzor wrote:

And just how to read long complicated names (ie, understanding the difference between const int * a, and int * const b.)

More syntax and precedence than pointers themselves, but OK.

Again, I'm not trying to be rude, I'm just pointing out that the way you phrased everything you made it sound like you didn't truly understand pointers. I don't doubt your understanding, I just doubted your explanation. I've probably got some stuff wrong with the array stuff I said - I generally tend to avoid arrays for that reason; they're evil, and they're almost never treated as true arrays like in other languages (eg Java).

[ETAkoG1T]

I think of pointers as a person pointing at something, that makes sense because then people can see that person and see what he is pointing at, but pointing at a person pointing is just stupid, why not just point at the thing he is pointing at? That is what confuses me the most :P

[cire]

Dynamically allocated memory is not arrays, but can be very eaily (and almost always are) thought of as arrays.

Dynamically allocated memory that is a chunk of contiguous memory holding objects of the same type is an array. Obviously not all dynamic memory allocations will result in what one would normally think of as an array, but many do.

They're really just pointers to single variables and it just happens that due to the memory allocation process used, incrementing the pointer will allow it to point to yet another valid object in memory, but most people will make fun of you if you actually say that the pointer points to multiple objects.

It doesn't just happen. That's pointer arithmetic, and it works that way because that's the way the standard requires it to work. A pointer can point to an array of objects, but it can't hold multiple addresses, so it only ever points to one of those objects at a time.

[D80DSL3A]

Filiprei wrote:

...but pointing at a person pointing is just stupid, why not just point at the thing he is pointing at?

That's his job!
Your job is to make sure others can find him.

[ETAkoG1T]

There is no point in pointer! Well actually there is, fail :P

[zb0S216C]

Pointers. A mechanism which is one of the most useful tools a programmer has in his/her work-belt. To this day, even though pointers were used way back in the assembly days, pointers are still used extensively. The majority of the STL rely on pointers and removing them will simply cause the STL to collapse.

Without pointers, you'd never have:-

1) References. Yes, references may be implemented with a pointer; if it did, you wouldn't have references.
2) Virtual Table. There'd be no run-time function resolution for you.
3) Iteration. Yeah'p, you wouldn't be able to use your beloved standard iterators.
4) Fast Code. Pointers are essential for efficient code.
5) Stack. That's right, your program's stack would be crippled since it relies on pointers to function.
6) Obtain Addresses. You'd never be able to refer to an address in memory.

For those who dislike pointers: you'd best accept the fact that they are everywhere and that they are the vertebrae of your code.

_Wazzak

[ETAkoG1T]

I like pointers, they make feel like im dealing with really low level stuff, manipulating the core of my computer. Even though that may be a bit of a hyperbole it is still cool to be able to give an adress to a function without having to pass the whole thing. Its not that I don't like them, its that the pointers don't like me :P

[hamsterman]

@Framework, this is a funny way to put it. You jumble together concepts of different importance and perspective. In reality there is only one thing you can'y do without a pointer - memory access.

I am referring to the internals of a CPU. If you, however, by "pointer" mean an explicit type then you are wrong.