Question about the efficiency of using an array or individual variables

[Jarvis323]

Yes, it said int *pint define as address of pointer pint. int *pint initiates a pointer of address.

Right. It also has a type. The book described it, but didn't say what type it is. Where is the problem?

 

[yungman]

Right. It also has a type. The book described it, but didn't say what type it is. Where is the problem?

You can have an address pointing to a float variable. All that means is pointing to the first byte of the float variable myFloat. The address is an integer.

 

[Jarvis323]

You can have an address pointing to a float variable. All that means is pointing to the first byte of the float variable myFloat. The address is an integer.

What is its type?

 

[yungman]

What is its type?

myFloat is a float.

What is the address of the first byte of myFloat? Int or float?

 

[Jarvis323]

myFloat is a float.

What is the address of the first byte of myFloat? Int or float?

The type is (float*). Do you understand that?

 

[PeterDonis]

The address is an integer.

No, it isn't. The address is a pointer. "Pointer" and "integer" are different types in C. The fact that you, a human, can take the bits stored in a pointer and interpret them as an integer is irrelevant; C doesn't care and doesn't treat them the same way.

What is the address of the first byte of myFloat? Int or float?

Neither. It's a pointer. A pointer in C is a different type from either int or float.

More specifically, it's a pointer to a float, which is a different type in C from a pointer to an int.

 

[yungman]

No, it isn't. The address is a pointer. "Pointer" and "integer" are different types in C. The fact that you, a human, can take the bits stored in a pointer and interpret them as an integer is irrelevant; C doesn't care and doesn't treat them the same way.
Neither. It's a pointer. A pointer in C is a different type from either int or float.

More specifically, it's a pointer to a float, which is a different type in C from a pointer to an int.

int *pint defines the address of the physical memory location. It HAS TO BE an integer. I designed plenty of real hardware with physical memory. It HAS to be integer. It cannot be a fraction. Take my word on this one. I can show you plenty of example of real schematic of address from A0 to whatever 64bits or 32 bits, it's INTEGER. This is physical hardware.

 

[PeterDonis]

int *pint defines the address of the physical memory location. It HAS TO BE an integer.

Sorry, but the actual workings of the C compiler trump your intuitions.

To the C compiler, an address is not an integer, it's a pointer, which is a different type from an integer. No amount of ranting by you will change that.

You can either accept this fact, or you can continue to waste the time of others here by asking questions to which you refuse to accept the correct answers.

I designed plenty of real hardware with physical memory.

We all understand how hardware works. But you don't understand how the C language and the C compiler work. And since you are trying to program in C, not enter hardware instructions directly into the hardware, it is knowledge about how C works that is relevant for this discussion. Knowledge that you do not have, and which you are never going to acquire if you refuse to listen to people who do have it.

It cannot be a fraction.

Nobody is saying it's a fraction. It's a pointer.

Take my word on this one.

No. The one who needs to be taking the word of others is you. Other people who know far more than you do about how the C language and the C compiler actually work are trying to help you. You need to listen to them, not demand that they listen to you.

If you are unable or unwilling to do this, your thread will end up getting closed. This one exchange has already taken up more time and energy from other posters than it should.

 

[Jarvis323]

int *pint defines the address of the physical memory location. It HAS TO BE an integer. I designed plenty of real hardware with physical memory. It HAS to be integer. It cannot be a fraction. Take my word on this one.

As an example, a char is for storing an integer that is interpreted as an ascii2 character, its type is char.

 

[PeterDonis]

As an example, a char is for storing an integer that is interpreted as an ascii2 character, its type is char.

The OP's confusion is not about different ways bytes stored in memory can be interpreted. His confusion is about how the addresses of those bytes are interpreted.

 

[Jarvis323]

The OP's confusion is not about different ways bytes stored in memory can be interpreted. His confusion is about how the addresses of those bytes are interpreted.

Yeah, but also confused about what types are. I was trying to get him to understand the distinction between integer and char, or integer and int*.

 

[yungman]

Sorry, but the actual workings of the C compiler trump your intuitions.

To the C compiler, an address is not an integer, it's a pointer, which is a different type from an integer. No amount of ranting by you will change that.

You can either accept this fact, or you can continue to waste the time of others here by asking questions to which you refuse to accept the correct answers.
We all understand how hardware works. But you don't understand how the C language and the C compiler work. And since you are trying to program in C, not enter hardware instructions directly into the hardware, it is knowledge about how C works that is relevant for this discussion. Knowledge that you do not have, and which you are never going to acquire if you refuse to listen to people who do have it.
Nobody is saying it's a fraction. It's a pointer.
No. The one who needs to be taking the word of others is you. Other people who know far more than you do about how the C language and the C compiler actually work are trying to help you. You need to listen to them, not demand that they listen to you.

If you are unable or unwilling to do this, your thread will end up getting closed. This one exchange has already taken up more time and energy from other posters than it should.

Read page 492 to 495 of Gaddis book
https://cplusplushelp.weebly.com/st...-control-structures-through-objects-book.htmlWhat is the physical address location of a float variable.

 

[yungman]

Yeah, but also confused about what types are. I was trying to get him to understand the distinction between integer and char, or integer and int*.

I am trying to distinguish the address of the variable with the content of the variable.

 

[Jarvis323]

I am trying to distinguish the address of the variable with the content of the variable.

The & operator acts like a function, it takes myFloat as an argument and returns something. Both the argument myFloat and the returned value each have a C++ type. The type of the argument is (float). The return type is (float*). Those, with their exact syntax are valid types that the compiler can recognize and parse. The compiler flagged an error because (int*) is not the same type as (float*), and it has been decided by the C++ committee that this type mismatch should throw an error. Why? Because it can be problematic. As in Mark's post, getting the value from a pointer (de referencing) has to interpret the bits as something. Those bits could be encoding a float or an int, the only way to know is if the compiler keeps track of what is supposed to be there. If you really want to convert a value of type (float*), into a type (float*), then you can do type casting as Mark shows, where you ask the compiler to convert/consider the value of type (float *) as a type (int*), and maybe that means that the bits which were encoding 3.75 will now be encoding 1081081856 as far as the compiler knows.

 

[PeterDonis]

What is the physical address location of a float variable.

In C, it's represented by a pointer.

I am trying to distinguish the address of the variable with the content of the variable.

We all know that. We are trying to explain to you how C does that. It does that by having a separate type, pointer, which represents addresses of things.

More precisely, as has already been noted, for each type in C, C also has a corresponding pointer type; the C type "pointer to X" represents the address of something with type X.

So in your case, the address of a float variable would be represented in C by a variable of type "pointer to float". Which would be written as float *. So the correct way of coding the original snippet of yours that started this subthread, assuming your purpose was to store a pointer to a float variable, would be:

float myFloat;
float *pFloat = &myFloat;

 

[Jarvis323]

What is the physical address location of a float variable.

Maybe this analogy can help: A 24 kOhms resistor is a resistor. An 8 Ohms resistor is a resistor. Will you think it is fine to use a 24 kOhms resistor where the schematic specifies an 8 Ohms resistor should go? Both are resistors, isn't it the same thing? Or do you think that a schematic will just say resistor? Or if your employee wrote a schematic and it just said resistor here, and you read it, you will give it the thumbs up? The book said it's a resistor so the book must be wrong?

 

[yungman]

I am not arguing whether the C++ language allow you to do this or not. I have to obey the C++ regardless. BUT what I am trying to say is the book said &myfloat is the physical address of the float myfloat. So why can't I use pointer to point to the first byte of myfloat?

// address of float variable
#include <iostream>
using namespace std;

int main()
{
    float test;
    int* ptr;
    cout << "the address of float test is " << &test << "\n\n";

    return 0;}

You can see the program actually return with the physical address of the variable myFloat.

My question is why C++ don't allow to use pointer for a float? Why have to restrict to int variable. what if I need to work with a float variable?

If we are allow to initiate float *pint; for pointer for float, I would not have a problem.

I guess I am very literal, when you say *pint is an address pointer, you should be able to point to anything within the physical memory.

Are you telling me if I work with float variable, I can forget the whole chapter of pointers as it won't work?

 

[PeterDonis]

what I am trying to say is the book said &myfloat is the physical address of the float myfloat

Yes.

why C++ don't allow to use pointer for a float?

It does. I just told you how to write the code in post #105.

If we are allow to initiate float *pint; for pointer for float, I would not have a problem.

Apparently you have not read post #105, since that's exactly the code I wrote there (except that I said float *pFloat to make the pointer variable name more descriptive).

 

[Mark44]

@yungman, you are having difficulty understanding the difference between an integer value and a pointer value. In the past, on machines with segmented memory, pointers were stored in a form with a part that indicated the memory segment, and another part that indicated the offset within that segment. The onset of 32-bit programming led to a so-called "flat" memory model, with bytes labelled from 0 to some relatively large number.
The fact that these memory addresses are now integers does not mean that they are of type int or long or whatever. As already mentioned C and C++ are strongly typed, and compilers distinguish between the addresses of an int or of a float, which is something I pointed out a few posts back.
If you have an int variable, and add 1 to it, you get an int value that is 1 larger. The same is not true in general for pointers.
Here's an example.

double val = 3.75;
double * dPtr, * dPtr2;
dPtr = &val;
dPtr2 = dPtr + 1;
cout << "dPtr: " << dPtr << "\n";
cout << "dPtr2: " << dPtr2 << "\n";

When I ran this, the output was

dPtr: 00EFFEC8
dPtr2: 00EFFED0

Notice that by adding 1 to the address in dPtr, I got a value that was larger by 8, which should not happen if dPtr was an ordinary integer.

 

[yungman]

Yes.
It does. I just told you how to write the code in post #105.
Apparently you have not read post #105, since that's exactly the code I wrote there (except that I said float *pFloat to make the pointer variable name more descriptive).

Sorry I did not see that when I was busy responding. Now I am happy. that there is a float *ptr for &myFloat.

Why the book did not say that in the same sentence? I am not arguing, but who give a C#$% whether the *ptr is pointing to the address of an int, a float or char, just point at the first address of the variable!

I hope there's no char *ptr just for pointing at a char variable!

Thanks

 

[yungman]

I was joking too soon, they sure use different ones for different variabes! I wrote a quicky:

#include <iostream>
using namespace std;

int main()
{
    char testC;        char* ptC;        ptC = &testC;
    cout << "the address of char testC is = " << &testC << "    The content of ptC is  = " << ptC << "\n\n";

    float test;        float* ptr;        ptr = &test;
    cout << "the address of float test is = " << &test << "    The content of ptr is  = " << ptr << "\n\n";

    double* ptD;    double testD;   ptD = &testD;
    cout << "the address of double testD is = " << &testD << "    The content of ptD is  = " << ptD << "\n\n";

    const int* ptCS;    const int testCS=7;   ptCS = &testCS;
    cout << "the address of const int testCS is = " << &testCS << "    The content of ptCS is  = " << ptCS << "\n\n";

    return 0;
}

All except char work.

If you run this, the address of char looks funny, all the other ones work.

 

[Jarvis323]

All except char work.

If you run this, the address of char looks funny, all the other ones work.

The cout class has member functions called operator <<. One of them takes a char * as an argument, and considers it as a c-string (null terminated array of char), so it tries to output the characters pointed to by the pointer rather than the pointer itself. They chose this behaviour so it's convenient to print c-strings.

 

[yungman]

The cout class has member functions called operator <<. One of them takes a char * as an argument, and considers it as a c-string (null terminated array of char), so it tries to output the characters pointed to by the pointer rather than the pointer itself. They chose this behaviour so it's convenient to print c-strings.

Didn't think of "*" is a character! So how do you define a char pointer? I flip through half the chapter on pointers, no mention on any of these. and this is the best book I have so far.

 

[Mark44]

Didn't think of "*" is a character!

In the context of your example, * is not a character. The type char * is a pointer to a character.

If you do this, your first section works.

char testC = 'a';
char* ptC = &testC;
cout << "the address of char testC is = " << (void *)ptC << "    The character pointed to is  = " << *ptC << "\n\n";

The overload of ostream:: operator << that takes a char * expects what is pointed to be a C string, and this operator inserts all of the characters starting from that address until and including a terminating null character.
If you add the cast that I showed, you get just the pointer's address value.

 

[PeterDonis]

I hope there's no char *ptr just for pointing at a char variable

they sure use different ones for different variabes

For different types, as I already told you:

for each type in C, C also has a corresponding pointer type; the C type "pointer to X" represents the address of something with type X

 

[Tom.G]

Hi @yungman, let's try this.

In your Notes you have: *Page 496: Pointer variable: int* ptr;
Which is fine.

A point that has not been mentioned is that internally the C compiler keeps track of what kind of object is being pointed to. Here is the reason.
If you write x= &ptr + y, the compiler has to know whether the variables are Integers, Floats, Longs, and so on. That way it can call the correct Add routine, or maybe first call a conversion if the types are not all the same.

In the int* ptr; you are declaring a variable called ptr, telling the compiler to treat it as a Pointer to something by using the *, then telling it that it is pointing to a variable that is an Integer.

When ptr is entered into the compilers symbol table for later use, it has attached to it the information that it is a Pointer, and that it refers to an Integer. So yes, PART of the information saved in ptr is an address (these days it looks like an unsigned integer, or maybe an unsigned long), but it also contains that "Hey, it's an Integer There" information. So referring to ptr returns all of this, not just the address (which may look like an integer).

(A rather lame equivalent, like reading a mystery novel where all the players and suspects are not introduced!)

Hope this helps!

Cheers,
Tom

 

[yungman]

The OP's confusion is not about different ways bytes stored in memory can be interpreted. His confusion is about how the addresses of those bytes are interpreted.

Yes, I was confused because the way the book is written for this chapter. I decided to stop talking and went through most of chapter 9. It is NOT a well written chapter. It just gave the example that pointing to a float is an error and left it at that. The book later just talk about each type one at a time and mostly with example instead of listing pointers of different type from the beginning. That cause my confusion and concern. Like it spread these through 20 to 30 pages and never have a summation of all the pointers and their reason of why to have different types.

Yes, I did jump to conclusion after reading the next few pages that did not talk about other types of pointers. I thought that was it? That I apologize. Sorry.

 

[yungman]

Hi Everyone

I want to apologize for being so stubborn. I finished a lot of Chapter 9, it did explain those later and I understand a lot more. It's NOT a well written chapter. But that doesn't excuse the fact that I jumped the gun. That I am sorry and apologize to everyone that tries so hard to help me.

I think the first thing I am doing is to slow down and take it easy for a day or two. I guess I am very driven and want to push to learn as fast as I can. I used to think I can learn a new language in like two or three weeks back in the days. I have been on this C++ for over a month and still have some ways to go. That kind of putting the pressure on me to work harder. C++ just have so much more things than assemble, FORTRAN, Basic and Pascal. That it's not a two weeks thing and frustration starting to get to me. To that, again, I am sorry.

 

[yungman]

I want to check with you guys how much I need to cover in the Gaddis. I understand of cause I should finish the whole book. But I also know from my grandson that his class covered up to chapter 11 only, and they skipped around also.

Here is an online copy of the book:https://cplusplushelp.weebly.com/st...-control-structures-through-objects-book.html

I definitely want to cover chapter 12 on files, that's my interest. Sounds like from response here, I better study Chapter 13 on introduction of Classes. Do I need to study chapter 14 and 15?

My goal is to learn computer science, not necessary be expert in C++. It is only the first modern language I decided to learn. I want to know what is the next logical step of my learning. Please advice.

In the olden days, people advice me to learn data structure and algorithm that is not language specific. Are the later chapters in Classes, structures have anything to do with these? That if I study chapter 13, 14 and 15 will help on my programming regardless of what language? I really don't know exactly what I am asking as the advice was from 40 years ago, obviously things have changed tremendously in programming already.

Thanks

 

[Mark44]

I definitely want to cover chapter 12 on files, that's my interest. Sounds like from response here, I better study Chapter 13 on introduction of Classes. Do I need to study chapter 14 and 15?

My advice is to definitely study Ch. 13. The concepts presented in that chapter start to cover what makes C++ an object-oriented language. Without it, what you've been doing is pretty much C plus the C++ take on I/O (i.e., using the cout and cin stream objects). The fact that your grandson's class covered only the first 11 chapters shouldn't enter into your decision. After all, his class was constrained by time, with either 10 weeks for a quarter of 15 weeks or so for a semester. No doubt his class was in Intro to Programming with C++. You don't have those constraints.
I would also advise that you study at least the first half of Ch. 14, where it discusses writing your own classes. If you don't want to do the whole chapter, you could skip that latter part where Gaddis goes over operator overloading. Since you don't intend to become an expert, you could skip Ch. 15, which gets into the concepts of inheritance, polymorphism, and virtual functions.

My goal is to learn computer science, not necessary be expert in C++. It is only the first modern language I decided to learn. I want to know what is the next logical step of my learning. Please advice.

In the olden days, people advice me to learn data structure and algorithm that is not language specific. Are the later chapters in Classes, structures have anything to do with these?

Not very much. You'll need another book for data structures and algorithms, but what you learn from the book you're working in will be helpful, as it will likely show examples in C++ (unless you get a book that is Java-based). The data structures will include things like singly- and doubly-linked lists, binary trees, and other structures, plus algorithms for searching through the various structures or sorting them. A fair amount of the presentation on algorithms will be focused on how efficient various algorithms are.

That if I study chapter 13, 14 and 15 will help on my programming regardless of what language?

Ch. 13 and at least the parts in Ch. 14 that are about writing classes will definitely help.