dereferencing question

[technologist]

Leading up to the question, this example shows simple dereference:

value foo = 500;
int * n_ptr = &foo;
cout<<*n_ptr;

500

Below, what does (*n_ptr) dereference to? Like the value 500 above what is the dereferenced value here?

struct foo
{
int member = 70;
}
...

foo *n_ptr = new foo();
(*n_ptr).member = 3; <--here is the question

I know it must be dereferenced to access object member(s). That only tells me it has to be done, but not how its done.

[MikeyBoy]

It dereferences to the object of type foo that n_ptr points to, i.e. the object you create in line 7.

[technologist]

Hey MB

It dereferences to the object of type foo that n_ptr points to

I guess I am having trouble conceptualizing how it dereferences to an object (behind the scenes). So far I have learned about dereferencing to a value, or to a number but not as esoteric as an object.

[MikeyBoy]

Why? The value of a basic numerical variable is just a sequence of 1's and 0's at a memory location. The value of an object is just a sequence of 1's and 0's at a memory location. What works for one, works for the other.

It's the type of the pointer that tells the compiler how to interpret those 1's and 0's, regardless of whether it's a simple integer or a complex object.

[TheIdeasMan]

Can I mention that here it is easier to use the pointer to member operator -> :

n_ptr->member = 3;

This operator was invented for this very purpose: to avoid dereferencing to get at a member varaible :+)

[technologist]

Thx for the answers IDM et al.

I thought the operator

n_ptr->member

implicitly dereferences and is a 'step saver' for the programmer. Dereferencing still occurs.

For the (*n_ptr) in the above code is it dereferencing to the address of object foo?

[MikeyBoy]

I thought the operator

n_ptr->member

implicitly dereferences and is a 'step saver' for the programmer. Dereferencing still occurs.

Yes.

n_ptr->member

does exactly the same as:

(*n_ptr).member

For the (*n_ptr) in the above code is it dereferencing to the address of object foo?

foo isn't an object. It's a type.

In line 7, you create on the heap a new object of type foo, and set the value of the pointer n_ptr to be the address of that object. Obviously, when you dereference a pointer, you get the object at the address that's stored in the pointer.

[doug4]

Pretend you own a bunch of houses. You give someone a note that says "Go to 123 Main St., go into the living room and report on the number of chairs you see."

123 Main St. is the address, or pointer, to the house. This is equivalent to n_ptr.

The house located ate 123 Main St. is equivalent to the foo object. The number of chairs in the living room is equivalent to foo::member.

When the guy shows up at 123 Main St., that is dereferencing the pointer. No longer are we considering a vague address, we are instead dealing with a real house object.

You could give the same note to various people with different addresses. You could find out the number of chairs in the living rooms of houses at 438 Elm St., 221 Park Pl., etc. The fact that a house has a living room that contains chairs is a property of houses. The address refers to a specific house.

[technologist]

Following the analogy by doug4, what makes the structure at the address a house, a hotel, a church, a cabin, or something else? I hate to ask, what makes them objects?

you get the object at the address that's stored in the pointer.

Got that MB -- but what is an "object".

I hope I am not asking unintentionally for ASM code. : )

[cire]

Got that MB -- but what is an "object".

https://isocpp.org/wiki/faq/classes-and-objects#overview-object

[MikeyBoy]

Following the analogy by doug4, what makes the structure at the address a house, a hotel, a church, a cabin, or something else? I hate to ask, what makes them objects?

what is an "object".

The simple answer is that an object is an instance of a class.

But really, these are questions you're asking about the most basic elements of OOP. If you're having trouble with this, then I don't think asking questions on a forum is going to help much - you need to go back to your textbook and get an understanding of the very basics of the subject.

You need to do the groundwork for understanding this properly, rather than trying to muddle through with a few half-understood thoughts.

[technologist]

Hey MB,

I've worked with classes and objects for a long time now. I just have not been able to phrase the question properly hence "muddled thoughts". Its something clearly I will continue to pursue. I knew that asking the what is the object question might kill my credibility in this thread. Unfortunately just that happened.

But I do appreciate everyone's help, I've clarified a lot. I look forward to more help in the future.

You need to do the groundwork for understanding this properly, rather than trying to muddle through with a few half-understood thoughts.

That's harsh and not the case.

[MikeyBoy]

It's one thing how to know how to "work with" something. You can learn that just from copying other people's code, and following the same pattern. It's quite another to understand that thing.

Maybe the question you asked was too vague? Is there something specific you don't understand about objects?

Because this whole thread suggests some misunderstandings of some very fundamental, basic things.

[technologist]

You can learn that just from copying other people's code, and following the same pattern. It's quite another to understand that thing.

I can't stand when people cut and paste. I never use other people's code. I am dedicated to learning c++. I over analyzed and overthought the object question.

[TarikNeaj]

I can't stand when people cut and paste.

It's quite easy to understand. People are wired to choose the easy way out, that's why most do it.

[MikeyBoy]

I can't stand when people cut and paste. I never use other people's code. I am dedicated to learning c++. I over analyzed and overthought the object question.

I didn't mean copy-and-pasting; rather, I meant that you can learn how to use them by looking at other people's code and copying the way they use them. It's easy to pick up on the patterns of code usage, without ever understanding why things are done that way.

So when your questions imply that you don't know what an object it, or that you don't understand what de-referencing a pointer does, or what the difference between a class and an object is, then it's hard to know what to think.

Perhaps you need to ask better questions? Explain more clearly what it is you don't understand? When you ask vague questions, we can't possibly know what it is you do and don't understand.

[technologist]

To be totally honest I used to program microcontroller prototypes using assembly. I occasionally make the mistake of trying to dig too deep even on simple things to get underneath the hood hence this mess with objects.

[MikeyBoy]

That's nice and all, but it doesn't help us understand what it is you actually want to know. What exactly is "this mess with objects"?

[technologist]

So when your questions imply that you don't know what an object it, or that you don't understand what de-referencing a pointer does, or what the difference between a class and an object is, then it's hard to know what to think.

I do know what all of these are. I have a good grasp of pointers, objects, classes. A lot of information in theis thread I already knew.

Perhaps you need to ask better questions?

Yes, this may be the case for this topic. A few pointers would be appreciated.

[MikeyBoy]

Yes, this may be the case for this topic. A few pointers would be appreciated.

Um, it's hard to tell you how to ask the question, when we don't know what the question is. You need to figure out how to express more clearly and precisely what it is you want to ask.

I do know what all of these are. I have a good grasp of pointers, objects, classes. A lot of information in theis thread I already knew.

And this is the problem; by asking the wrong questions, you're wasting our time, because we're telling you things you apparently already know. We're not helping you, because you make it impossible for us to help you.