pouët.net

I also do OO in C but it's a bit tedious when using objects on the stack .. since you end up needing to put explicit destructor calls in C. unless if you make some really evil macros like

#define WITH_INSTANCE(class, name, body) \
do { \
class __private_##name; \
class* name = &__private_##name; \
do { \
body; \
} while(0); \
name->destroy(name); \
} while(0);


WITH_INSTANCE(quux, foobar, { quux->doFoobar(quux); });

bleh :)

(note, i do not use that horrible thing myself)

actually stack objects^(*) were one reason why i quitted c++.. then i've come up with few others, language bloat not being the least significant.

(*) or more like the confusion between values and references. i'd prefer for each type to choose one way and stick with it.

uh, all you people desperately trying to "prove" that you can program OOP in C:

You didn't understand anything: You can't.

Of course you can put a few function pointers into a struct and claim that you just "implemented" virtual functions. Of course you can copy/paste a struct and claim that you "inherited" a "class". Of course you can write a completely unreadable mess of macros and helper functions and claim that you successfully did "encapsulation", simply because nobody will ever find out how the fuck you made it.

Fact is, this has got as much to do with OOP as if I wrote a string search/replace routine in assembler, coded the rest of my program as series of string replace operations in the form "mov eax, somesourcepointer; mov ebx, some destinationpointer; mov ecx, somedeclaration; call replace; jz somewhereelse" and then presented that pile of shit to the world as "declarative programming". Because a Prolog interpreter doesn't do much more than that, so it must be the same!

Fact is also that a good C++ compiler (and let's just count vc++/gcc/etc as such) outputs about the same code as if you faked your OOP manually. class accesses are the same as struct acesses, non-virtual function calls become "mov ecx, this; call class::method" (which is even faster than your __cdecl fakes), virtual function calls become "mov ecx, this; mov eax, [ecx+sizeof(class)]; mov eax, [eax+offsetintovtbl]; call eax". Oh my god, it's one friggin' CPU cycle per function call. How SLOW. Only exceptions and RTTI are somewhat complicated, but they neither take a single byte or CPU cycle if you just don't use them.

Trying do to OOP in plain C is just stupid, and it's the very reason why eg. GTK+ sucks major ass. They simply didn't understand C++.

(and no, I don't consider C++ the best language of all times. I do enjoy ASM, Java, PHP, Prolog and even VBScript when I feel it's appropiate. But we're still coding demos here, don't we? :)

I don't quite know why you get into such a rant, we (at least I ) never told you to code oo in C. I do it for a certain number of technical reasons.. (and it's obviously not for optimization purposes)

(My two main reasons: lack of standardized abi in c++ until know -- and it still is a problem to a certain extent -- and building the OO model in C makes it a lot easier to hook it in scripting (I know where the virtual table is, i know how method dispatching works etc.)

Besides, I really don't see how less OO (OO doesn't even HAVE a definition, it's a fuzzy concept) doing things this way is compared to C++. Actually, under certain definitions of OO c++ is not itself very object oriented.

And a last analogy to show how, again, I find C in OO is not stupid, even in C++ you have to do some similar 'hack around the language' work when implementing multi-dispatch, when emulating more complete OO languages.

About the last point.. my opinion is that demomaking almost disqualifies any language whose runtime is not the OS itself, mostly for size/convenience reasons. Demos are one of the last programs that can't require a 40M big runtime to run. (except java demos, and they almost only exist because the runtime was shipped with the os at some point)

_216_ .. I mainly only use "stack objects" for Iterators. It feels kinda stupid to allocate them on the heap. And for the obvious value objects too.

I can't see how anyone would get the idea of doing oo in c over c++ for speed. I do it because it's better suited for that;)

knos, you mean like:

class HardToWalkClass {
public:
Iterator getIterator() { return (Iterator)createComplexIterator(); }
}
for (Iterator i=htwc.getIterator(); i; i++) ...

Optimus: Learing OOP is like learning how to drive. When you haven't understood yet how it is done, it seems so awkward, complicated and difficult. When someone manages to show what it's all about, you begin wandering how could you live without it for so long :-) The problem is that there are few people who both grasp the OOP theory and have the ability to teach well, to pass it on to others succesfully.

Others: I once talked to tran (yes, Thomas Pytel) and asked him what he thought about OOP. You understand that his view was very important to me because I consider him a very good programmer. He told me that OOP is very good for software design and you should use it to break down your problem (program). But implementation is better done in structured programming (C in his case) because it is usually faster. Now I realise some of you disagree with his views (including myself, being an OOP zealot), but I thought you would be interested to know. I must say that tran's opinion troubled me alot since I like OOP and respect him so much.

Quickbasic has pointers, did you know it? Not that I ever use them :)

Quickbasic has structs too, so does this mean it is OOP ;))))

mot: Yes, or as a Java books puts it:

"OOP programming is like the beer.

Most people that drink a glass of beer for the first time, don't like it and make fun of those that compelled them to try.

After little time however, an estimate is developed to the beer by those who they continue drinking it.

OOP programming, as the beer, is something that is acquired. It's one of the most appreciable ideas that have been imported the last years and it also causes terror in the programmers that are not familiarized with it."

The problem is that I have to read a lot of things to get into, something that will happen oneday but don't know when. Till then, I might write my way in C++ since it supports other prorgamming styles, in order to just show to the screen what I thought of. I am only still worrying about not knowing what's going on, not because this will happen if I don't use OOP, but because everything seems to crash in C++ and there are several unpredictable errors. (For example,. why C++ languages don't have a check when I override the limits of a table? Why doesn't it prompt me for that as quickbasic does??? This is the most common thing that happens when I code in C/C++ when everything crashes and don't work well with me ;P) Perhaps I will have to learn it oneday since there might be nothing better for democoding. But that books are big ;(

Hoho ho, all these wonderful comments.. Now I must tell some story too.. In the past a worked for a team called ... (games) and they gave me a game to convert to ps1.. And it was incredible.. The whole code was OOP implemented in C.. And the whole game was for Microsoft and a good seller at this time.. I don't know, why these guys did it nor did I know at that time how to read this wicked code.. The conclusion is, that I didn't convert the game and that it was proved to me, that it is possible to do such a strange way in C even on market purposes.
--> the game selled well all over the world..

I mean: I worked..

"Why do you use DirectDraw BadSector? " - Mad
For my Diskmag engine, software rendering, eNotes, raytracing engine, etc...

"BadSector: You obviously don't know a shit - MFC is a normal class library no-one forces you to use (and not a particularly great one, yeah, but that's hardly the topic here)" - ryg
Never said that you have to use it. I just said that Optimus may think that C++ sucks because VC++ includes MFC and because an old message of him in the greek mailing list talked about a problem in "C++" but it actually was a problem in "MFC". Please don't argue without knowing some facts...

"VC++ has been a bit late on ISO C++ compliance, but that's fixed in the current release too, so there's really no reason to whine about anything." - ryg
I didn't...

"And in case you wonder, no, Visual C++ is not visual at all - it's simply the name of the whole product line." - ryg
I know it :-P. Visual is only Borland C++ Builder, however isn't named "Visual" :-]

"Neither . nor -> are C++ specific, both were already existant in K&R C. "." is used to access structure members, like "mystruct.var=3", and -> is a shorthand for the far clumsier "(*mystructptr).val=3" in case you don't have a structure variable, but a pointer to one (the version using "->" is "mystructptr->val=3")." - ryg
Yeah, i know all this stuff (i know more stuff that you may think :-). I didn't meant that . and -> are C++ specific. I mean that they have to do with C++ since they're used widelly. Anyway, i may misunderstood Nuclear's saying about that topic.

"uh, all you people desperately trying to "prove" that you can program OOP in C:
You didn't understand anything: You can't." - kb
Yeap, we can :-). Even you know it, you said about GTK+ :-)

"Of course you can put a few function pointers into a struct and claim that you just "implemented" virtual functions. Of course you can copy/paste a struct and claim that you "inherited" a "class". Of course you can write a completely unreadable mess of macros and helper functions and claim that you successfully did "encapsulation", simply because nobody will ever find out how the fuck you made it." - kb
You just said a "HOWTO for OOP in C" :-)

"Fact is also that a good C++ compiler (and let's just count vc++/gcc/etc as such) outputs about the same code as if you faked your OOP manually.... (blah) ...just don't use them." - kb
That's somehow true. Of course it has to do with a good compiler and thinking that most of us uses good compilers then it shouldn't matter. However i don't think that anyone proposed OOP in C as a faster way. Personally i said (did i?) just to say that "it can be done". However for OOP i prefer C++ (one or two years ago -can't remember- i used C for this thing, but now i realized that C++ exists even for the most obscure machine - which i don't own!).

"(and no, I don't consider C++ the best language of all times. I do enjoy ASM, Java, PHP, Prolog and even VBScript when I feel it's appropiate. But we're still coding demos here, don't we? :)" -kb
Yes we are! And now let's go code a kickin' ass demo ;-)

.EOF.

Optimus: The C/C++ compiler, will in fact let you shoot yourself in the foot. C was developed with performance and portability in mind. So it will not check if you cross the boundaries of an array, because this check costs performance. C assumes that you, the programmer will make it so that it doesn't cross the boundary or that you make the checks yourself if you wish. In the beginning I was frustrated with C as much as you are now, because I kept falling for strange errors in the code. Like for example:

int a = 0219;

You would assume that the above is correct, but it's not, because in C all numbers beginning with a zero (0) are assumed to be octal numbers, and octal numbers don't use the 9 digit :-) I fell for that one early, while putting zeros in front of numbers just to format them in the source.

Anyway. If you want to be protected by the compiler like in Basic, but still be able to write fast (compiled) and well structured code, maybe you should take a look at Delphi (Pascal). It may not be as powerfull as C++ but it beats the crap out of Basic anytime.

Bad Sector: you are right that's the way..
But I have looked in my DirectX8 Help (loosy?).. And was looking for DirectDraw, and I didn't found it..
Perhaps (that can be wrong) it isn't implemented int this version(so you have to use Direct3D instead)..
If wrong correction please I am not sure for myself.

Yeah yeah I know who codes on DirectX8...
And the best today I haven't checked DX9..
lame lame lame...

Man, this thread is becoming better and better with each hour that passes...

Please go on squeezing your brains to produce some super-whicked C-pretending-to-be-OO-stuff, that definitely rules. How about doing an entry for the obfuscated C contest?

hey, but you dont want this anyway, wont you ? ;)

do whatever you want. and void* is simply the best idiom ever :D

just for the case, somebody hasnt had enough - why do you need OO anyway, its just one of all that paradigms ? I like mixin' it all together - object-oriented, event-driven, procedural, functional, dataflow, table-driven, WHATEVER - and I love python :)

one handy thing about c (against c++) is that variables, fields and automatic variables are initialized to zero. but sure, i couldnt discover any performance or size improvements over c++.

I like Lua.. OO and funky.. But scripts? better doing some nicer thingy.. Like coding some c++ stuff..
Or optimizing some mainloops with vtune..

or without..

faor, as far as i know, only static variables are initialized to 0 in C.

sorry i'm wrong and faor is right

mm, duh finally i get back to my original comment, local variables are certainly not initialized to 0 :) (who use global variables anyway)