Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Concisely, what aspects of C++ make it not fully OOP?

Author
Message
Indie Rock 13
20
Years of Service
User Offline
Joined: 1st Sep 2004
Location:
Posted: 9th May 2008 06:23 Edited at: 9th May 2008 06:24
It has abstraction through structures/classes (one of the primary reasons for it coming into existence, no?) It has inheritance and polymorphism, as well as (correct me if I'm wrong, I don't understand the term 100%) encapsulation...

So what exactly makes it "Not fully OOP" and warrant OOP wrappers to be written for it? What would these add to it? What OOP methods can't be fully exploited using it?

I just want to wrap my head around it as all my reading has not succeeded in making it clear in my mind. At times it has almost seemed like a purely semantic argument.

PC Specs: eVGA 780i Mobo, Intel C2D E8400 OC'ed @ 4.0Ghz, Tuniq Tower 120 heatsink, 2GB Kensington 1066Mhz DDR2 RAM, 2 x eVGA 8800 GT KO Edition 512MB in SLi
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 9th May 2008 06:38 Edited at: 9th May 2008 06:52
It isn't C++ that is not OOP, but the GDK is a collection of functions, and there are no objects in the OOP sense exposed by default.

Also, OOP is a buzzword, not well defined, and the source of alot of confusion and inefficient programming practices when it is the driving force in program development. DBPro is OOP as far as I am concerned.

My opinion is that the "OOPedness" of an application is solely the responsibility of the programmer writing the code.

I can write fully "OOP-compliant" assembly language code for that matter. I just don't have that much time, or motivation to do it when it is really a programming philosophy, and not an actual thing that you can define completely in concrete terms.

The basis for what I consider OOP in C++ is the abstract base class. MFC is a good example of OOP in Windows. CObject is the base class of all MFC objects. COM/ActiveX/ATL and .NET are similar, but MFC was first and actually outperforms those others in my experience.
Indie Rock 13
20
Years of Service
User Offline
Joined: 1st Sep 2004
Location:
Posted: 9th May 2008 06:46 Edited at: 9th May 2008 06:47
"it is really a programming philosophy, and not an actual thing that you can define completely in concrete terms."


That is what I hoped the answer would be, because this is about the best thing I could formulate from the various sources on the net. It seems like some people are so adamant about what is and is not OOP and say it like it's a bad thing if it isn't.

I really wanted to know because my learning process with programming is going back and forth between languages right now as it seems to be helping me understand concepts and terms, and I'm learning a lot of OOP ideas and didn't want to find out I can't use all of them in C++, which hadn't seemed the case so far.


To that end I have no idea how much actual C++ I'll be using when programming with DarkGDK. Could I access something like say, the data of the bone structure of an .X model using C++ without it throwing DarkGDK's handling of this model out of whack?

That is an entirely hypothetical situation that might not even make sense... I'm just being rambly...

PC Specs: eVGA 780i Mobo, Intel C2D E8400 OC'ed @ 4.0Ghz, Tuniq Tower 120 heatsink, 2GB Kensington 1066Mhz DDR2 RAM, 2 x eVGA 8800 GT KO Edition 512MB in SLi
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 9th May 2008 07:00 Edited at: 9th May 2008 07:01
Actually, all you need is straight up C. (Not that that is easy, either, just much more prevalent.)

You could totally do that. If you look at the file DBOData.h, it is your DBO, defined in reverse order. That is a collection of structures, which have both actual values, and pointers to the other structures. That is a big part of why I say DBPro is OOP. DBOs are objects that implement their own behavior, have data hiding/abstraction to some degree, and exhibit a form of polymorphism. There, I've used a few of the terms, now.

Now, you could create a class in C++ to wrap a DBO, and that would be great and all, but...you are already able to access the DBO through function calls, and also using pointers to the various structures, so it would only be necessary if you wanted to change the basic behavior of DBOs. (Which makes them something other than DBOs, so it doesn't really follow the nebulous rules of OOP, anyway.)

DBOs all behave the same way, the different file formats just have front ends that make DBOs, for example. (An .X one, a .MD2 one, etc.)
Indie Rock 13
20
Years of Service
User Offline
Joined: 1st Sep 2004
Location:
Posted: 9th May 2008 08:43 Edited at: 9th May 2008 08:45
Hmm, interesting. I'm forgetting atm, can structures/classes be nested? If so, are dbo's or .x's or any model type merely classes made up of more classes or structures that a new class could inherit to create a new model type with more functionality? I think that's pretty much what you just said anyways...

In any case, I would like to be able to see what certain DGDK functions are doing in C/C++ code so I can learn more what exactly is happening in lower-level code. Obviously it'll be way over my head and contain windows API stuff and DirectX code and all that, but I'm feeling ambitious about learning programming not just DGDK or DBPro.

Thanks for the responses!

PC Specs: eVGA 780i Mobo, Intel C2D E8400 OC'ed @ 4.0Ghz, Tuniq Tower 120 heatsink, 2GB Kensington 1066Mhz DDR2 RAM, 2 x eVGA 8800 GT KO Edition 512MB in SLi
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 9th May 2008 10:27
Yes, they can be nested. Yes, that's a fair assessment of what I was trying to say.

I think that seems like the logical thing to do and the hardest part will be finding appropriate documentation regarding specific questions. The docs help alot, but sometimes they only help you to learn a concept.

Cheers, and you're welcome.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th May 2008 02:48
Quote: "I can write fully "OOP-compliant" assembly language code for that matter"
FINALLY Someone else with a clue!!!!

Indie - I too dislike the various "definitions" of OOP - in that there is not definitive "what is and what isn't" spec..

Not that we need one.. but when you're trying to learn all that stuff.. it gets confusing!

I think you'll find that "oop" techniques, as was alluded to, can be used for good or evil.

sometimes coding oop for the sake of being oop is silly, other times its the cat's meow.. depends on what you want to do, your goals with your code, plans for it... etc.

Now to answer you're original post, I think C++ pretty much fits the "oop" spec if there was one... same for free pascal. Many here believe the .Net Languages are also, and in many ways they are.. but the inheritance is capped.. you can get around that .. but you need to jump through a couple hoops to make "an interface".

(And like JinZai said more or less... You can utilize OOP programming techniques even in languages that don't natively "support it". Now for the assembly thing.. that language doesn't "support it" but you can 100% MAKE OOP code because of the flexibility assembly offers with pointers etc. In fact... In Assembly language, you can literally have inheritance, objects, classes, and so much more.. unfortunately... it takes a long time to get a working code lib going if you start from scratch...

Indie Rock 13
20
Years of Service
User Offline
Joined: 1st Sep 2004
Location:
Posted: 10th May 2008 07:36
I'm glad you guys helped solidify this topic for me. I like programming because I figure out what the problem is and then figure out how to solve it in any way possible, and OOP principles seem like the obvious route in many of the cases I've seen, but it would also seem a handicap to limit your solutions to just that.

I obviously have next to no experience though so I'm just making suppositions based on what I've read.

PC Specs: eVGA 780i Mobo, Intel C2D E8400 OC'ed @ 4.0Ghz, Tuniq Tower 120 heatsink, 2GB Kensington 1066Mhz DDR2 RAM, 2 x eVGA 8800 GT KO Edition 512MB in SLi

Login to post a reply

Server time is: 2024-09-29 19:26:22
Your offset time is: 2024-09-29 19:26:22