Class member address is same as class pointer value

Question

I have a class Response that has a public member which is of another class type ResponseData. ResponseData has a string member.

What I've notice is that upon inspecting Response->responseData and Response->responseData->data, the value of ResponseData* and the address of ResponseData->data are the same.

Somehow the value of the pointer to the class is the same as the address of that class's string member.

https://onlinegdb.com/Bk-kJ3a_z

#include <iostream>
#include <string>
#include <vector>

// ResponseData

class ResponseData {
    public: 
        std::string data;
        ResponseData();
        ~ResponseData();
        void PrintToConsole();
};

ResponseData::  ResponseData(){
    data = "some data";
}
ResponseData::~ResponseData(){}
void ResponseData::PrintToConsole(){
    std::cout << this->data << std::endl;
}

// Response

class Response {
    public: 
        ResponseData *responseData;
        Response();
        ~Response();
        void SetResponseData(std::string data);
        ResponseData* GetResponseData();
};

Response::Response():responseData(NULL){}
Response::~Response(){}
void Response::SetResponseData(std::string data){
    this->responseData = new ResponseData();
    this->responseData->data = data;
}
ResponseData* Response::GetResponseData(){
    return this->responseData;
}

int main(){
    Response response;
    response.SetResponseData("hello");
    ResponseData* responseData = response.GetResponseData();
    // value of ResponseData* and address of ResponseData->data are the same..?
    std::cout << responseData << std::endl;
    std::cout << &responseData->data << std::endl;
    responseData->PrintToConsole();
    return 0;
}

I don't even know if this is a problem because my code runs fine. But it doesn't make sense to me. Maybe I still don't understand pointers. Calling PrintToConsole shouldn't work because apparently responseData is pointing to responseData->data which is a string...!?

There is no `requestData` in the code you posted. Please read how to post a [mvce]. — Richard Critten, Mar 07 '18 at 18:31
Class members necessarily occupy the same storage as their owning class. You can distinguish between them through the pointer type. Note that it's impossible for a class to have a member of it's own type, so there can't be an ambiguity there. — François Andrieux, Mar 07 '18 at 18:32
SO these days is more about being the first to criticize a post versus answering the question or being helpful. What a sad state of affairs. Appreciate the answers though, not the downvotes. — J Doe., Mar 07 '18 at 18:35
@JDoe. take care of biting the hand that feeds you. (And you're wrong). SO is all about helping people; but you forget that people helping here are busy; and if you don't post all the information then you are wasting other peoples time. — UKMonkey, Mar 07 '18 at 18:37
Stack Overflow is as much about keeping a collection of useful answers for future readers as it is about helping those who post the questions. It's very important that questions be of a certain level of quality so that they can be as useful as possible to future readers. — François Andrieux, Mar 07 '18 at 18:38
@ebyrob I've posted tiny samples of code that were sufficient for a question, to get reprimanded immediately for not posting something that can be compiled. Every comment is "MVCE bro." Now I'm criticized for the opposite? And yah I made a typo while writing my question versus my code - does it need to be downvoted? Does it have anything to do with MVCE (hint: no, @ Richard Critten). My problem with SO boils down to everything in these comments - no one even cares about the question, just the formatting, the nuances, etc. — J Doe., Mar 07 '18 at 19:01
Possible duplicate of [Dereference a structure to get value of first member](https://stackoverflow.com/questions/41506788/dereference-a-structure-to-get-value-of-first-member) — ebyrob, Mar 12 '18 at 18:27

Ashutosh · Accepted Answer · 2018-03-07T19:03:46.913

The address returned by the pointers ideally represent the starting address of that object. As you're printing the address of very first data element of the class, it's address will be identical to that of responseData object. (As long as it's not a virtual class)

#include <iostream>
#include <string>
#include <vector>

// ResponseData

class ResponseData {
    public: 
        std::string data;
        //a dummy data just to demonstrate
        int dummyData;
        ResponseData();
        ~ResponseData();
        void PrintToConsole();
};

ResponseData::  ResponseData(){
    data = "some data";
}
ResponseData::~ResponseData(){}
void ResponseData::PrintToConsole(){
    std::cout << this->data << std::endl;
}

// Response

class Response {
    public: 
        ResponseData *responseData;
        Response();
        ~Response();
        void SetResponseData(std::string data);
        ResponseData* GetResponseData();
};

Response::Response():responseData(NULL){}
Response::~Response(){}
void Response::SetResponseData(std::string data){
    this->responseData = new ResponseData();
    this->responseData->data = data;
}
ResponseData* Response::GetResponseData(){
    return this->responseData;
}

int main(){
    Response response;
    response.SetResponseData("hello");
    ResponseData* responseData = response.GetResponseData();
    // value of ResponseData* and address of ResponseData->data are the same..?
    std::cout << responseData << std::endl;
    std::cout << &(responseData->dummyData) << std::endl;
    responseData->PrintToConsole();
    return 0;
}

Here you can verify, the addressed would be different for dummyData, than that of responseData object.

*As your class contains only single data element, both addresses are identical.* This would be the case even if the object had multiple variables. The first member of a class and the class itself have the same address. — NathanOliver, Mar 07 '18 at 18:41
@NathanOliver Unless its virtual and the compiler inserted the vtbl pointer at the beginning. — Borgleader, Mar 07 '18 at 18:43
@Borgleader Yeah. Should have said that only applies to non virtual classes. — NathanOliver, Mar 07 '18 at 18:45

Alan Birtles · Answer 2 · 2018-03-07T18:44:24.290

-1

Non virtual classes are the same size as the sum of the space used to store their members, the class itself takes no space (unless its an empty class which will have a non-zero size, unless the empty class is a base class in which case the class is again allowed to have 0 size) so the first member has the same address as the class

edited Mar 07 '18 at 18:44

answered Mar 07 '18 at 18:31

Alan Birtles

32,622
4
31
60

4

The first part of this answer isn't true. Classes often take up *more* space than the sum of their members. – François Andrieux Mar 07 '18 at 18:32
Plus any padding used by the compiler. – R Sahu Mar 07 '18 at 18:32
I did say "space used by their members", I would include padding in this. Non virtual classes should be the same size as their members. – Alan Birtles Mar 07 '18 at 18:33
"Non virtual classes are *at least* the same size as the sum of the size of their subobjects" FTFY. – Borgleader Mar 07 '18 at 18:34
1

@AlanBirtles The padding between members isn't used by those members, and in most cases is unusable. – François Andrieux Mar 07 '18 at 18:35
OK, "the space used to store the members" – Alan Birtles Mar 07 '18 at 18:36
Related: https://stackoverflow.com/questions/119123/why-isnt-sizeof-for-a-struct-equal-to-the-sum-of-sizeof-of-each-member – UKMonkey Mar 07 '18 at 18:38
2

`the class itself takes no space` is false. `struct foo {}; sizeof(foo)` will have a non zero value – NathanOliver Mar 07 '18 at 18:39
@FrançoisAndrieux I swear I remember reading here that someone wrote a function that operated only in the padding of class members ... but finding the source is hard – UKMonkey Mar 07 '18 at 18:41

Class member address is same as class pointer value

2 Answers2