Thread: is "Object" in "OOP" the same 'object' which is closely related to class and structur

Hi

I remember there is a particular kind of thing in C++ called 'object' which is part of the family whose members are also structure and class. But I think the "Object" in the title "Object-Oriented Programming" isn't the same 'object' which is much closely related to structure and class. Rather the "Object" only implies the concept where different sections of the software are seen as different entities or objects. Perhaps, other more descriptive and suitable term would be 'functional blocks'. What is your opinion on this? Please let me know. Thanks.

No, an "object" as defined in "Object Oriented Programming", is almost 100% compatible with current C++ Classes.

Originally Posted by jackson6612

Rather the "Object" only implies the concept where different sections of the software are seen as different entities or objects. Perhaps, other more descriptive and suitable term would ve 'functional blocks'. What is your opinion on this? Please let me know. Thanks.

Probably there is not as much difference between these two "things" as you think.

I'm guessing your alterior 'object' ("where different sections of the software are seen as different entities or objects") derives from object files, which are compiled modular components used in or by an executable ("libraries" are independent object files used the same way). Here's another guess: the term "object" in OOP does, in fact, derive from the concept of object files, since they have a lot in common: an object file provides variables and methods, a class definition does the same thing. I'm sure that object files have been around longer than OOP, so this etymology seems very probable, esp. since classes are derived from C structs, and OOP most likely began in C. C (and C++) compilers use and create object files.

What's more, class definitions commonly have their own source file, meaning they are literally compiled into an object file, then included in your executable.

That sort of conflates the word "object" with "class" and might account for the difference you perceive, since the modular code in an object file is the compiled version of the later and can be discussed that way. However, in the context of OOP you need two distinct words, and in English it would not make sense to call a class an instance of an object. One more guess: people preferred "class" and "object" to "object" and "instance", so "object" had to take on a slightly different meaning (one that previously did not exist, or not so clearly) in the context of OOP, so here we are.

Make sense? Also, in the spirt of concrete poetry "OOP" is exciting -- it's sunglasses waving a flag. Programmers, among others, often seem to think of an acronym they like first, and then fill in the blanks later.

I don't think that just because you find symmetry in places makes two things related, like objects in OOP being derived from object files..

They are such an unlikely source for me because the compiler doesn't attempt to work in a modular way, though it might work with modular code. The number of object files you get depends on how many translation units there are, which has nothing to do with what you could call a module. It is also stupidly easy for the compiler, thanks to the primitive preprocessor, to break modularity -- just forget to define an include guard, or define the wrong macro to conditionally compile the wrong thing. Other languages make it so you don't have to worry about how modules are imported, but C++ makes you care.

Originally Posted by whiteflags

Other languages make it so you don't have to worry about how modules are imported, but C++ makes you care.

Careful with that train of thought, both C and C++ attempted to walk the fine line of providing safeguards while still delivering power. I am not trying to start an argument here, as this topic is too big for any single thread, just wanted to point out a caution.

Originally Posted by whiteflags

It's a fact. I mean, I'm not making a bigger point here. C and/or C++ makes you "import" things with #include, and if you have any idea what that does, it doesn't really deliver power or provide safeguards.

I guess I didn't understand what you were saying then; would you mind elaborating? I mean I do understand some languages do hand-hold, but that is usually at the cost of "power".

Originally Posted by whiteflags

For example, if you've never just compiled a project and not linked it, you don't know what an object file is and therefore, you wouldn't understand where they come from, or how they don't relate to the object oriented paradigm and you wouldn't understand my post. I've written plenty of decent OOP programs in one source file, which means one object file. Is my code not modular then? Object files have nothing to do with encapsulation, abstraction or data hiding in any way that I care to appreciate. MK27 does make his point, it's interesting, and I don't care who agrees with him, but I think he's wrong.

I think I see what you are saying but I could be wrong. Have you tried "data abstraction" in C? I think what MK27 is talking about resolves around this issue.

I think I see what you are saying but I could be wrong. Have you tried "data abstraction" in C? I think what MK27 is talking about resolves around this issue.

Why do you think that? Because object files are an actual thing with a well understood definition, that MK27 sort of described.

http://en.wikipedia.org/wiki/Object_file

In computer science, an object file is an organized collection of separate, named sequences of machine code[citation needed]. Each sequence, or object, typically contains instructions for the host machine to accomplish some task, possibly accompanied by related data and metadata (e.g. relocation information, stack unwinding information, comments, program symbols, debugging or profiling information). A linker is typically used to generate an executable or library by combining parts of object files.

Every source file becomes an object file, which makes up part of the program.

MK27 is using common programming practices to his advantage, noting that classes typically are made up of several source files, (translation units) so it presents a comfortinh illusion of this is how encapsulation happens, this is how things are abstracted, and this is where people got the idea.

When in my experience it really depends on what you're using, what you're abusing, and how many files you can be arsed to write.