"object"

[CodeChaser]

Hi, glad I found this site. I have a question regarding the term "object".
When you create an instance of a class, it is an object, but then the book says that the name of the dog here is stored in a string "object" and NOT a string literal? This totally confuses me and throws me off. "Kato" is a string literal?

*m_pName = "Kato"; //Pointer to memory address of dog name

Can all variables then be called objects or is it only pointers to variables that are objects? Is m_pName the object, the memory address that points to "Kato" or is "Kato" the object....which clearly IS a string literal? Probably the former?

Can dogName in main be called an object?
string dogName = "Fluffy";

Is vetName in Dog class an object?
string vetName = "VetSupreme";

#include <iostream>
#include <string>

using namespace std;


class Dog
{
public:
	Dog (const string& name)
	{
		m_pName = new string (name);
		m_pName = name;				
	}	

	~Dog()
	{
		delete m_pName;
	}
	
	string m_pName;
	string vetName = "VetSupreme";
};

int main(){

	string dogName = "Fluffy";
	cout << dogName << endl;

	Dog dogGermanShepherd ("Kato");
	cout << *dogGermanShepherd.m_pName << endl;

	return 0;
}

[jonnin]

an object can, and usually does, have other objects inside it.
a c++ std::string is an object. Just because string is a class in the standard language libraries does not change that :)

more specific to your code:
"Fluffy" is a string literal. Actually its a const char*, or a "C language string literal" if you want to get really picky about it.

dogName is a string object, created from copying the literal into the object.

Can all variables then be called objects
No, an integer is NOT an object. It could have been, but the so-called 'methods' you see (eg operator +, assignment, etc) are actually CPU hardware. Making an integer an object is a massive performance hit, see pure python language.
^^^ this is NOT obvious. One way to see it is to do this in an IDE that lists members (like visual studio).
string s;
s. <-- typing that . will bring up a list of class stuff.
int x;
x. <--- will NOT bring up anything.


Is m_pName the object <- IT IS "an" Object, one of several string objects in your code.

, the memory address that points to "Kato" or is "Kato" the object....which clearly IS a string literal? Probably the former?
Ignoring the c++ optimizer for a moment, as it can play tricks on you, for now assume that the string literal KATO is copied into the string object, into a new memory location that is part of that object. So the object m_pName has a COPY of the data from the KATO literal.

Can dogName in main be called an object?
Yes, it is one.

Is vetName in Dog class an object?
Yes.

When you create an instance of a class, it is an object

Stand by this. The trouble is simply spotting the class with built in language tools.
It may be easier to list the things that are not classes...
all pointers, any kind of int (includes char), any kind of float, (however complex numbers are objects!) literals that are not cast or forced into a class ("foo"s is a string object, that s casts it into one), enums (there is an enum class, it is different), things like this. You will get a feel for it quickly as you learn. Even cout is an object.

[Ganado]

name of the dog here is stored in a string "object" and NOT a string literal?

Correct. The string literal is the literal text between quotes. This is stored in static memory somewhere in the program; if you search the binary executable file, you'll find those characters somewhere in it. When you assign it to a std::string object, that object has methods (member functions) that know how to copy the string literal into the std::string's own memory.

Is m_pName the object, the memory address that points to "Kato"

Your code excerpt has some typos in it, m_pName is supposed to be a pointer. m_pName points to a dynamically-allocated string object. That std::string object internally contains memory that has the bytes that make up "Kato". It is no longer connected to any string literals by the time the data is inside the std::string.

In this last part of my post, I think I'm muddying the waters here... but meh:

jonnin wrote:

Actually its a const char*, or a "C language string literal"

Just to clarify, it's an array somewhere in static memory; the pointer just points to it.

Can all variables then be called objects

From a C++ language lawyer perspective, ints are objects. https://en.cppreference.com/w/cpp/language/object
But of course that's not what people are talking about from an OOP perspective, so you are correct there.

[CodeChaser]

OK, objects make a lot more sense now. String is really just a class and gets handled as an array of char pointers.

Now you have got the wheels turning on where string is stored from origination, let me see if I get that part right.


Dog dogGermanShepherd ("Kato");

The string literal "Kato" gets stored in static memory(stack) from main and does not instantly get a copy inside Dog because it is passed by reference. It only refers to the static memory from main.

Dog (const string& name)

But then once in the constructor

m_pName = new string (name);

m_pName makes it's own copy on the heap and now there are two copies. One on the heap that the pointer points to and one on the stack from the main()?

Then when the program ends it calls the destructor, which erases the heap and then before the program fully ends the string literal "Fluffy" from the stack gets deleted?

Did I get that right?

[jonnin]

Close.
string only has 1 char pointer, not an array of them. its one string, not multiple. a pointer can be like an array, and a c string is an array/pointer/whatever block of characters. c++ string wraps up the ugly parts of that with a small amount of data (its length, the characters, a little more) and a LOT of methods and operators.

the rest of it is where the c++ optimizer may start to screw with you in a release/optimized build.
assuming a dumb optimizer or a debug build...
kato is in static memory (sorta the stack, but in an area that isnt pushed and popped, sometimes called the data segment in assembly)

but,
dog(string &name) //it actually has to construct a temporary string object behind your back and shovel the literal into this unnamed string object. So there are 3 copies! of the literal data, one on the stack/data segment from main, one in a temporary, and...

the third:
new string (name) //optimizer can smoke and mirrors the unnamed temporary object here, or if less intelligent it will make a new one and copy everything over.

if it made one, the temporary object dies when the ctor ends.

when the program ends your object dies which kills the strings inside it.
after that, at the operating system level, the program stack is released to be used by other programs. The stack exists until just past the life of the program.

I would skip all this crap for now. the low level "this guy is on the stack, this guy is on the heap" stuff is an obsession of old books and professors but its not critical to learning and is actually a hinderance when not explained patiently and carefully. Do you really, really care where your variables are right now? You will later, because large programs can't put all their data on the stack (even small programs can burn it up with some creativity) but dynamic memory has a cost (have to ask for it from the OS, its not that slow, but its not as fast as not asking, the stack does not need permission..!) so when you get into efficiency studies it will matter some too.

[CodeChaser]

Yes, yes meant to say a string pointer to an array of chars, play on words. Seems like there is a lot more under the hood and I get it but may have to read it again to sink in deeper.

Book mentions, if I recall correctly, that the stack is faster but limited to 1-2MB or so and the heap is slower but with a lot more memory. Where is the heap and stack really? Stack on the CPU somewhere and heap on the memory DIMMS/modules? Any way to find out how much memory on stack is being used?

[againtry]

@OP
It appears to me that this is getting far too complicated.

For a definitive answer to int being an object, go no further than this:
https://stackoverflow.com/questions/48026922/is-an-int-variable-an-object-according-to-the-c-standard

In short an int, along with all the other fundamental data types in C++, is an object.

A class (or struct) is simply a user-defined data type.

A class encapsulates combinations of fundamental and user-defined data types, as required by the user.

An instance of a class, as you say, is an object.

A string object (#include <string>) is an instance of the string class. How/where the data is arranged is deliberately hidden from the user and is irrelevant.

const's, &'s and pointers with delete's and new's, and as @jonnin says on stacks and heaps, even though they appear to be ever so slick, they achieve absolutely nothing and really only serve to obscure good programming especially for such a simple exercise.

Your Dog class might be better use to you along the following lines:

#include <iostream>
#include <string>

using namespace std;

class Dog
{
public: // Should be private with gettters and setters
    string dog_name{"Unknown dog"}; // one way to have a default value
    string vet_name{"Unknown vet"};

public:
    Dog(){};
    Dog (string name)
    {
        dog_name = name;
    }

    ~Dog(){}
};

int main()
{
    string dogName = "Fluffy";
    
    Dog dog1;
    cout << "Name: " << dog1.dog_name << ", Vet: " << dog1.vet_name << '\n';

    Dog dog2("Kato");
    dog2.vet_name = "VetSupreme";
    cout << "Name: " << dog2.dog_name << ", Vet: " << dog2.vet_name << '\n';

    return 0;
}

Name: Unknown dog, Vet: Unknown vet
Name: Kato, Vet: VetSupreme
Program ended with exit code: 0

[jonnin]

Book mentions, if I recall correctly, that the stack is faster but limited to 1-2MB

old book :)
the stack depends on the OS limits, if any, and the compiler limits/settings, as allowed, and more.

I think its 8MB on PC sized unix and on windows, the .exe file defines its desired amount depending on what the compiler is willing to allow. I believe if it exceeds available ram, it cannot launch, unlike dynamic/heap memory, it can launch but may not be able to grow to its needs (should handle this nicely, but some programs do not).

the stack itself isnt faster. It the request to get and release the heap memory that you pay, which could be paid once at start and end of the program, a tiny cost (nanoseconds) or it could be spread thin and *very* expensive (eg a function that allocates and releases every time it is called, spam called in a loop -- a problem from time to time with STL/string/etc containers and careless code). You can also be careless about page faults with the heap. Again, getting off in the weeds here for a beginner. None of this is critical until you have a great understanding of the basics down.

[JLBorges]

> "Fluffy" is a string literal.
> Actually its a const char*, or a "C language string literal" if you want to get really picky about it.

The string literal "Fluffy" is an object of type 'array of 7 const char' and it has static storage duration.
This object contains 7 sub-objects of type char


> No, an integer is NOT an object.

An named integer (for that matter, any materialized entity) is an object.
A non-static integer member of a class object would be a sub-object.