A bit off topic but.

There is one, and only one, stack per thread.
Multiple stacks is a nonesense.

Static variables are stored in the global heap (in good ol x86 the DS, Data Degment).
Local variables increment the SP when they are in scope, and decrement the SP when they are out of scope.

declaring a function static limits that function''s scope to that module only.

the same goes in C++ for C style fuctions. See previous posts for C++ static usage

--------------------------
Carpe Diem

Making every member function (member functions are functions inside a class) static is just mimic-ing procedural C coding, with the addition of a fancy name. gimp, you''re right - static member functions should be very rare. In fact, they are the OOP equivalent of global functions (with a few additional tricks up their sleeve). If you somehow need a class with all static member functions, then you should use a namespace instead of a class.

TIP: Any time you see someone using one particular language keyword everywhere for everything is a sure sign he/she doesn''t understand how the language works (believe me, I''ve done it before).

TIP: For a language to be an Object-Oriented Programming (OOP) language, it has to support data encapsulation, inheritance, and polymorphism. So C cannot be used to produce OOP code. Don''t get offended; OOP is just a term.




- null_pointer
Sabre Multimedia

While null_pointer has been pretty solid in his arguments for C++ from what I've seen, I must respectfully disagree with his last tip here.

Although I prefer C++ constructs for OOP programming, saying that C cannot be used for OOP code is blatantly incorrect. OOP simply stands for Object-Oriented Programming, and all this requires is that your code is object-oriented. You can use explicit object pointers/handles, manual v-tables (if you even need to) and other C facilities and still have your code be object-oriented. It may be nastier than the equivalent C++ code, but as long as the organization is based on objects, it's still OOP code.

As for saying that "an OOP language must support encapsulation, inheritance, and polymorphism", I must make a couple points:

Encapsulation is not a matter of putting code and data together in a class construct, rather it is a logical organization which keeps the code and data in a cohesive unit. This can be done in C as well as C++; even though the code and data are not tied in the language, they are tied in logical usage. Encapsulation is a logical principle, not a physical one (and the equivalent physical principle is insulation, which C is more than capable of as well, via normal procedural methods).

Inheritence and polymorphism are typical features of an OOP language, but they are not in any way required. Inheritence itself is just a form of polymorphism, and polymorphism is done in all manner of different ways depending on the language. And while polymorphism is certainly an expected feature of an OOP language, one can write OOP code which never uses any polymorphic facilities and still have it be OOP.

Note that I'm not in any way endorsing using C for OOP code instead of C++, far from it. But saying that C cannot be used for OOP code at all is a falsehood.


Edited by - Chris Hargrove on July 3, 2000 5:31:24 PM

oh god, I almost don''t want to reply this...

Inheritance is most definetly a requirement of OOP, polymorphism is well. C++ is often critized for its poor polymorphic behavior (when compared to things like ML) making it fringy on full OOP status. (Those other languages are not concerned with efficent execution at all, so C++ is one of most used OOP lang''s)

OOP has a very specific CS meaning... but I sold that book to a sorotity girl before I graduated so I dont have it here to look it up. It has a list of requirements...

And as I mentioned elsewhere, you can bit-bang the registers with TBASIC, you can dynamically allocate memory in COBOL, but I don''t want to.

...

It can be used to reduce the stack usage (can''t eliminate it)... but thats a *bad* thing! Other methods are likely to be slower or just the same

If you insist that "inheritence is definitely a requirement of OOP, polymorphism as well", you're missing the point of my argument. Inheritence is an expected feature of an OOP language, as I said. The only requirement of OOP itself, however, is having one's code written in an object-oriented manner. Object-Oriented Programming. That's all. That does not implicitly require inheritence (which is a form of polymorphism), or any other kind of polymorphism for that matter. It is expected, but it is not required. Hence why OOP code can be written in C.

An example is Quake. The Quake code is entirely C, but claiming that the Quake code isn't largely object-oriented anyway is ludicrous. A large majority of games out there are object-oriented no matter what language they use (at least in some sections), simply because of the fact that one of the base elements of many games is the "actor" or "entity". If you have data structures defining actors, and code that is explicitly designed for use with those actors where the actors effectively control themselves, then that code is object-oriented. Even in C.

You're confusing the assumptions of what a language designed with OOP in mind usually has, with what the term "OOP" itself actually stands for and thus truly demands. Remember that my argument has been against null_pointer's statement that "C cannot be used to produce OOP code". C is not an "OOP language" in the common meaning of the term, but it can and has been used for OOP code for a long time.

Key point: "Writing OOP code" and "using an OOP language" are two different things.

Once again I'm not arguing using C over C++. I am very much a C++ advocate.


Edited by - Chris Hargrove on July 4, 2000 4:12:42 PM

quote: Excerpt from C++ for Dummies, page 225

Polymorphism is the key to the power of object-oriented programming. It's so important that languages that don't support polymorphism cannot advertise themselves as OO languages. Languages that support classes but not polymorphism are called object-based languages.

Author's email: Stephen R. Davis
Publisher's site: Dummies Press TM


You can't write OOP in C. You can't do inheritance, polymorphism, or encapsulation. Why?

First, data encapsulation means protecting the state of the instance data. Constructors and destructors are REQUIRED for encapsulation, or else the module cannot maintain the state of the data. How can you maintain the state of the data if you have no control over which values are valid? If the initializer isn't called, well... and even if you get over that (by checking for initialization in each and every function in the module), what happens when the uninitializer (dynamic memory, etc.) isn't called? How can you possibly check for that? Answer that, and maybe I'm wrong about data encapsulation.

Second, polymorphism IS a requirement of an OOP language. Chris, you can't just give vague definitions and define the terms as you wish. Terms have definitions, and we must stick by them if we intend to communicate. I have nothing against C - it's just not an OOP language.

Third, inheritance is required for polymorphism, so it, too, is a requirement of an OOP language. C doesn't do inheritance. You would have to do do lots of copy/paste operations and (very messy) casting to achieve the desired effect.


I don't know how you can write OOP code in a non-OOP language.



- null_pointer
Sabre Multimedia


Edited by - null_pointer on July 4, 2000 6:47:45 PM

Ok, i KNOW that im gonna regret this question...
What IS inheritance in C++? any examples?

(as you might understand, im pretty new to C++)

========================
Game project(s):
www.fiend.cjb.net

JonatanHedborg, you WILL regret asking since inheritance is a tottaly different subject that should require a totally different thread. Heres what to do: make a thread called "What is Inheritance in C++?", and then everyone that knows anything about C++ (more specifically, classes ) will post and you will know everything to your hearts content. Better yet, lemme do it for you...

=======================================
A man with no head is still a man.
A head with no man is plain freaky.

null_pointer, let me repost my key point again, in the hopes that this time it will sink in. You''ve been very sensible in most of your arguments on other C++ topics, but this time I''m afraid you''re simply not reading the point I''m making.

Key point: "Writing OOP code" and "using an OOP language" are two different things.
Key point: "Writing OOP code" and "using an OOP language" are two different things.
Key point: "Writing OOP code" and "using an OOP language" are two different things.

I''m going to assume that posting it three times in a row is enough here.

Your quote from the "Dummies" book does not refute this point. Here''s the quote:

quote: "Polymorphism is the key to the power of object-oriented programming. It''s so important that languages that don''t support polymorphism cannot advertise themselves as OO languages. Languages that support classes but not polymorphism are called object-based languages."

Saying that "polymorphism is the key to the power of" does not mean "polymorphism is required for", it merely means that it is an expected and extremely useful feature of an OO language... a point which I addressed.

Saying that "languages that don''t support polymorphism cannot advertise themselves as OO languages" is accepted as well, because it is an expected feature of an OO language, as addressed. But, that''s for OOP languages, and an OOP language is not required to write OOP code, once again part of the Key Point.

I am *not* saying that C is an OOP language. Never anywhere in my posts have I implied as such. I have said that C can be used to write OOP code. This is the difference.

quote: You can''t write OOP in C. You can''t do inheritance, polymorphism, or encapsulation. Why?

This line reflects a misunderstanding of my Key Point. Hopefully by now this is cleared up.

quote: First, data encapsulation means protecting the state of the instance data. Constructors and destructors are REQUIRED for encapsulation, or else the module cannot maintain the state of the data. How can you maintain the state of the data if you have no control over which values are valid? If the initializer isn''t called, well... and even if you get over that (by checking for initialization in each and every function in the module), what happens when the uninitializer (dynamic memory, etc.) isn''t called? How can you possibly check for that? Answer that, and maybe I''m wrong about data encapsulation.

You do have a fundamental misunderstanding of what encapsulation is, yes. I''m not trying to insult you here though, believe me. A whole lot of people don''t understand what encapsulation actually is.

The arguments you''re making relate to initialization and uninitialization, and while these tasks are certainly simpler when constructors and destructors are involved, they have absolutely nothing to do with encapsulation itself. Encapsulation''s definition ties with another definition for "Insulation", something that many computer science professors and C++ books fail to mention or clarify with relation to encapsulation (which they''re more than happy to talk about all over the place).

Encapsulation is the logical self-containment of related code and data for an object, in a manner that prevents undesirable exposure or manipulation of the object''s internals.

Insulation is the physical self-containment of ... (insert exact same quote for the rest).

When people talk about C++ supporting easier encapsulation, that''s what this definition reflects, because the code is syntactically bound with the data as well as semantically. While that''s largely a physical insulation issue, it has repercussions in encapsulation since the public/private/protected blocks can prevent logical abuse.

In contrast, while C++ is very good at allowing encapsulation, C++ classes are extremely bad with regards to insulation. If you have a class with public and private members, and you must put the class in a header file for others to access its public interface, you must still declare its private contents within the same header file. This has all sorts of repercussions from increased compile time to generally nastier header files. You can use tricks like the "cheshire cat" technique to put the private contents in a hidden implementation module underneath, but that''s basically using the hidden pointer as a handle, something which you can do even in C.

Now, let''s compare these things to C. C has a more difficult time with encapsulation, since data and code cannot be syntactically tied... however, they can be semantically tied, and that''s a large part of where encapsulation''s "logical" basis comes into play, hence why C still allows encapsulation. In addition, standard C "handle" techniques work exceptionally well with regards to insulation.

Let''s take Win32 as an example. You know as well as I do that the Win32 API is in C. You also know as well as I do that HWND is a handle to a window, however it''s hard to argue that a GUI window is not an object... of course it''s an object, even in C. The Win32 functions for window handling (code) are logically bound to the instance contents of that window (data), therefore implying encapsulation. They are also insulated, since the entire access mechanism is done via HWND handles. You do not know the layout of the window data structures, and you do not know any internal-linkage hidden static functions that they don''t want to expose. This is all in C. This is all OOP code, even though it is a non-OOP language (see the Key Point).

None of this has anything to do with constructors or destructors.

quote: Second, polymorphism IS a requirement of an OOP language. Chris, you can''t just give vague definitions and define the terms as you wish. Terms have definitions, and we must stick by them if we intend to communicate. I have nothing against C - it''s just not an OOP language.

I never said C was an OOP language, I said you can write OOP code in C (see the Key Point).

quote: Third, inheritance is required for polymorphism, so it, too, is a requirement of an OOP language.

Incorrect. Parameterized types (such as C++ templates) are also a form of polymorphism, as are other indirect access techniques. Some of these techniques are even referred to as inheritence, even when they have absolutely zero resemblance to inheritence in languages like C++ (for example, the "Self" language).

quote: C doesn''t do inheritance. You would have to do do lots of copy/paste operations and (very messy) casting to achieve the desired effect.

Agreed. However, while an OOP language is expected to support polymorphism, using polymorphism mechanisms such as inheritence is not required in order to write OOP code, and hence OOP code can be written in non-OOP languages (see the Key Point).

quote: I don''t know how you can write OOP code in a non-OOP language.

The example of Quake in my previous post, and Win32 in this one, should serve as enough evidence that it can be done, and that it infact has been done for a long time.

I''m not trying to be insulting null_pointer, like I said I''m a C++ advocate as well. I simply think the fundamental misunderstanding here lies around the Key Point, hence why I''m restating it so often. Once that''s accepted, I don''t think we''ll have much of a debate on this.