Maxorators sig cought my eye...
I have noticed that while most people make classes with functions built in to handle stuff. I usually do it the C way, use a struct, and pass it's pointer to seperate handling functions, much like window handles work. Is this like a bad thing to so or somthing, why did the thing about putting handling functions in classes ever become 'standard'?Originally Posted by max's sig
I think he meant "Revolutional...NOT a word".
And I think it's just two different ways of looking at it. C comes from the idea that you have functions that control the data, while OOP has the data controlling itself, providing an interface to others on how it should be used.
Last edited by indigo0086; 08-13-2007 at 12:58 PM.
I think people like classes because then everything is declared in one place (inside the class element) and that the definitions of those functions have the ClassName:: in front of them. That way people can easily see what is what. Classes do have some special features but all of them can be done without classes by using some creativity. What I wanted to say was not that classes are bad or anything, I just wanted to say they're not so much different from the ordinary C-style and OOP should not be worshipped as it was something revolutional. It's just an alternative way with some extra features.
"The Internet treats censorship as damage and routes around it." - John Gilmore
I use openGL and have to use both ways, while the C style stuff is ususally bound to the OpenGL specific stuff, I put everything that uses the openGL in classes, seperating them by what they do, and encapsulating it as such. I think when using a library such as that which has no object oriented point of view, and a lot of the declaring handlers, pointers, and modifying them using functions, I find it a lot easier to use by creating objects.
Exactly my point. When C-style seems to get too messed up to understand anything, you can use classes. And it isn't bad to do it C-style - it's about how you like it.
Indigo0086, you just made your 1000th post!
Last edited by maxorator; 08-13-2007 at 01:14 PM.
"The Internet treats censorship as damage and routes around it." - John Gilmore
There is so much more to classes than just hiding the implementation.
What about inheritance, virtual functions, etc. Now these things used in excess are not needed, but in my experience these things are very useful.
Derived classes indeed simplify things, but there is also a C alternative - include the other struct in the new struct. So there is nothing you can't do in C, just that in C it does not look so straight-forward.
"The Internet treats censorship as damage and routes around it." - John Gilmore
It sounds more like you're comparing C and C++ than comparing C programming with object oriented programming (which seem to me like apples and oranges).
>Derived classes indeed simplify things, but there is also a C alternative - include the other struct in the new struct.
Yes, so you'd be implementing an aspect of OO--just in an ugly way. So what's your point? Obviously you can use OOP concepts in C, but you say it doesn't provide an advantage.
"Think not but that I know these things; or think
I know them not: not therefore am I short
Of knowing what I ought."
-John Milton, Paradise Regained (1671)
"Work hard and it might happen."
-XSquared
C++ is a bad framework for OOP discussions. If you want to discuss the merits of OO and whether it is a 'revolution', consider the task of taking a Java Application into an Applet, and consider how hard that would be to do without Java's run-time polymorphism facilities.
More importantly, the distinguishing (imo) features of C++ really don't have anything to do with OO. The following is a paper written by Bjarne Strostrup entitled "Why C++ is not just an Object-Oriented Language"
http://www.research.att.com/~bs/oopsla.pdf
Callou collei we'll code the way
Of prime numbers and pings!
Actually, maxorator's signature is just referring to syntactic sugar. That, of course, is very much language dependent and not revolutionary at all (though it may make things more fun/easy/messy/silly etc).
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I'd argue that saying OOP in C++ isn't a huge step over emulation of it in C using structs, functions, structs within structs (it will really start to get to be a big pain and mess with a large project), is like saying that C isn't a revolution over ASM, because all the nice constructs can be implemented with memory offsets, along with JMPs and CMPs.
Of course you can implement one paradigm inside another, after all, it all boils down to some hex, but a concept makes a difference when the average programmer can take advantage of it
Programming Your Mom. http://www.dandongs.com/
The advantage of C compared to asm is portability. C++ compared to C doesn't have that advantage.
C is kind of like a portable ASM.
OOP doesn't make the developing much faster, it makes it look clearer. Big and complex systems have been programmed in C. All the ways of handling data like classes do were used long before classes were invented.
Assembly isn't actually a programming language. It's human-readable machine code.
"The Internet treats censorship as damage and routes around it." - John Gilmore
OOP can make development faster, depending on the proficiency of the people using it and the type of system under development.
Same with any other paradigm, if used in the wrong context by people lacking understanding of the context and/or the paradigm you're asking for trouble.
Sadly many people diving into OOP have no idea what they're getting into nor do they have any idea about the problem domain they're writing software against.
C seems more productive therefore because it's less used by inexperienced people with little knowledge about their problem domain, simply because it's not a language that (these days) is taught to inexperienced programmers.
And of course other languages aren't? There is only one thing the processor(s) can execute: Machine code. Anything else has to be translated first. Whether you translate it DIRECTLY from assembler, macro assembler, C, Pascal, Fortran, Cobol, ADA or whatever is irrelevant - they are all "computer languages" - just more or less directly translated from what the programmer wrote to machine-code (and not ALWAYS obviously so, compilers sometimes produce not-so-obvious code). [Of course, there are languages like Java that is commonly translated to a pseudo-machine-code - but that's just a way to "commonalize" the compiler so that code can be compiled but not be machine/architecture dependant - and then translate the pseudu-machine-code to native code either by interpretation or some form of "compilation"].
By the way, I can pretty much predict the output of GCC or MS VC for a piece of C-code - I'm not always 100% spot on, but most of the time I get it very close to the actual output of the compiler.
Of course, assembler isn't particularly portable from one processor (macro-)architecture to another, but that doesn't make it less of a language ;-)
--
Mats
