I was talking with a co-worker about C and C++ and he claimed that C is object-oriented, but I claimed that it was not. I know that you can do object-oriented-like things in C, but C++ is a true object-oriented language.
What are your thoughts?
Also, it triggered discussion on who decides what it means to be object-oriented and that it's tough to say what object-oriented really officially means. What are you thoughts on this?
If by "is C object oriented?" you mean "is C designed with facilities specifically to support object oriented programming?" then, no, C is clearly not object oriented.
You can program in an object-orientated style in more or less any language. (I think runtime polymorphism -- i.e. virtual methods -- requires a language that supports function pointers.)
Here are a couple of examples:
A short summary of object-orientated style in C: http://www.emilmont.net/doku.php?id=c:object_oriented_c
A comparison between the same program written in C and C++: http://www.eventhelix.com/realtimemantra/basics/object_oriented_programming_in_c.htm
C isn't object oriented. That was the entire purpose behind the ++
As far as a definition of what it takes to be object oriented: check wikipedia.
Personally, if it supports inheritance, encapsulation, and polymorphism then your good to go. Another key here is having nice keywords like class and object tend to help...
Examples of real object oriented languages (not conclusive) are: Smalltalk, Java, c#, Python, Ruby, C++..
Also, it's possible to have extensions to provide OO features like PHP, Perl, VB (not .Net), ...
Real programmers can write object-oriented code in ANY language.
But no, C is not an 'object-oriented' language. It has no concept of classes, objects, polymorphism, inheritance.
Answer can be yes or no, depending on:
if you ask "is C an object oriented language?", the answer is "no" because it do not have object oriented constructors, keywords, semantic etc...
if you intend "can I realize OOP in C?", the answer is yes, because OOP is not only a requirement of a language, but also a way of "thinking", an approach to programming, before to touch some language or another. However the implementation of OOP in C (or any other language not natively designed to be OOP) will be surely "forced" and much hard to manage then any other OOP language, so also some limitation shall be expected.
C is not an O-O language under any definition of "O-O" and "language".
It is quite easy to use C as the implementation language for a component that gives an O-O API to its clients. The X Windows system is essentially a single-inheritance O-O system when viewed from its API, but a whole mess of C when viewing its implementation.
The confusion may be that C can be used to implement object oriented concepts like polymorphism, encapsulation, etc. which may lead your friend to believe that C is object oriented. The problem is that to be considered an object oriented programming language, these features would need to be built into the language. Which they are not.
Unless your friend was talking about Objective C (an OO superset of C) then no, C isn't an OO language. You can implement OO concepts using C (that's what the old cfront C++ compiler did, it translated C++ into C) but that doesn't make C an OO language as it doesn't specifically offer support for standard OO techniques like polymorphism or encapsulation.
Yes, you can write software OO style in C, especially with liberal (ab-)use of macros but as someone who has seen the results of some of those attempts, I'd strongly suggest to use a better suited language.
C is not object oriented in strict sense since it doesn't have a built-in syntax supported object oriented capability like class, inheritance and so on.
But if you know the trick you can easily add object oriented capability to it simply using struct, function pointer, & self-pointer. DirectFB is such a C library written in an object oriented way. The bad thing it is more error prone since it is not governed by syntax and compile type checking. It is based on coding convention instead.
e.g.
IDirectFB/*a typedef of a struct*/ *dfb = NULL;
IDirectFBSurface/*another typedef of a struct*/ *primary = NULL;
DirectFBCreate (&dfb); /*factory method to create a struct (e.g. dfb) with
pointers to function and data. This struct is
like an object/instance of a class in a language with build-in
syntax support for object oriented capability */
dfb->SetCooperativeLevel/*function pointer*/
(dfb/*self pointer to the object dfb*/,
DFSCL_FULLSCREEN);
dsc.flags = DSDESC_CAPS;
dsc.caps = DSCAPS_PRIMARY | DSCAPS_FLIPPING;
dfb->CreateSurface/*function pointer, also a factory method
to create another object/instance */
( dfb/*self pointer to the object dfb*/,
&dsc,
&primary/*another struct work as object of another class created*/ );
primary->GetSize/*function pointer*/
(primary/*self pointer to the object primary*/,
&screen_width,
&screen_height);
2 . C++ is object oriented since it has built-in support for object oriented capability like class and inheritance. But there is argument that it is not a full or pure object oriented language since it does allow C syntax (structural programming syntax) in it. I also remember that C++ lack a few object oriented capabilities but not remember each one exactly.
C is not object oriented language.
C is a general-purpose, imperative language, supporting structured programming.
Because C isn't object oriented therefore C++ came into existence in order to have OOPs feature and OOP is a programming language model organized around objects.
A language in order to have OOPs feature needs to implement certain principles of OOPs.Few of them are Inheritance, Polymorphism, Abstraction , Encapsulation.
C is a object based language, it does not support many features of object oriented languages such as inheritance, polymorphism etc.
Real programmers can write object-oriented code in ANY language.
I have seen Object Oriented Cobol. Cobol that calls Cobol. Do you want to call these programmers "Real"?
C is not Object Oriented.
C does not orient to objects.
C++ does.
Though C itself was bulit as procedural language (it "thinks" in terms of procedure: You first execute function A then you pass the output to function B etc. it supports "out of the box" only functional program flow),
It's possible to implement OOP over C (in OOP, the story is driven by Objects and their responsibilities rather than functions and their calling order).
In fact, some early C++ implementations were translating the code to some C code and then building it.
However, sometimes you must use C (for Embedded devices / GPU languages that don't support C++ etc). And you want OOP. I'd suggest you to check out COOP - my C OOP lightweight yet powerful framework for C object-oriented programming.
C is not object oriented. C++ is not object oriented. Let me explain:
Object Oriented is an extension to Simula's old fashion event driven subset. Real Object Oriented are functional and reflective because Object Oriented is really a group of paradigms (event driven, functional, reflective). Only four language are really object oriented and these are Lisp,Smalltalk,Ruby and Ocaml. Perl lags between because its not functional. Scala is not reflective so also lags behind. C++ is only event driven with some Simula like facilities but its completely structured programming language and its not declarative or even matchs real world. Object Oriented matchs real world with Functional (Maths), Event Driven (Conversations) and Reflectiveness (Evolution). C++ only has conversations. C++ is not declarative like maths or doesnt evolve like life. C++ only converses like people. C++ is like an idiot that doesnt know how maths work or how life evolves.
No, it is not, your friend is wrong.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Can you write object oriented code in C?
Object oriented programming in C
So, as I get it, "objects" are basically just wrappers for values and methods. Can't you have the same functionality in C, with structs? A struct seems just like a simple class, but, of course, it doesn't have any methods. Here we get to the heart of my problem: I don't understand why methods are needed at all. Wouldn't it be simpler and more memory-efficient if we had an outside function, which just accepted a pointer to an instance of a struct? Or even have the structs have pointers to these functions, but this seems purely aesthetic...
Being object-oriented means being object-oriented out of the box. Sure you can simulate object orientation with C (and with many other non-OO languages), but if the language (and/or its standard library) does not help you with that in any way (special syntax, standard objects, etc) and does not encourage to write in OO style by default, it will not be called object-oriented.
Using c-style function pointers as struct members, you can indeed make C object oriented.
I like the concept of having a class with its attributes and methods all defined together. Its easier to see what the related entities are, as opposed to having separate functions that take pointers to the struct like you mention.
Here are 2 related SO questions:
Is there a simple way to code the strategy (or other) design pattern in ANSI C that would fit on the screen of an 11" MacBook Air?
How do function pointers in C work?
What you suggest is already used to implement OO features in C. But many people find easier to use dedicated languages where OO features are included.
This is the same trend as why people switched to C from assembly.
Object is real-world entity and it has state, behavior. In class(c++/java) we can define state as member variables and functions as behavior. In case of C: in struct, you may have state but not behavior. Therefore C is not object oriented. This is just a small e.g. Also C does not support OOPS principals like inheritance, function overloading, polymorphism etc.
It seems that most new programming languages that have appeared in the last 20 years have been written in C. This makes complete sense as C can be seen as a sort of portable assembly language. But what I'm curious about is whether this has constrained the design of the languages in any way. What prompted my question was thinking about how the C stack is used directly in Python for calling functions. Obviously the programming language designer can do whatever they want in whatever language they want, but it seems to me that the language you choose to write your new language in puts you in a certain mindset and gives you certain shortcuts that are difficult to ignore. Are there other characteristics of these languages that come from being written in that language (good or bad)?
I tend to disagree.
I don't think it's so much that a language's compiler or interpreter is implemented in C — after all, you can implement a virtual machine with C that is completely unlike its host environment, meaning that you can get away from a C / near-assembly language mindset.
However, it's more difficult to claim that the C language itself didn't have any influence on the design of later languages. Take for example the usage of curly braces { } to group statements into blocks, the notion that whitespace and indentation is mostly unimportant, native type's names (int, char, etc.) and other keywords, or the way how variables are defined (ie. type declaration first, followed by the variable's name, optional initialization). Many of today's popular and wide-spread languages (C++, Java, C#, and I'm sure there are even more) share these concepts with C. (These probably weren't completely new with C, but AFAIK C came up with that particular mix of language syntax.)
Even with a C implementation, you're surprisingly free in terms of implementation. For example, chicken scheme uses C as an intermediate, but still manages to use the stack as a nursery generation in its garbage collector.
That said, there are some cases where there are constraints. Case in point: The GHC haskell compiler has a perl script called the Evil Mangler to alter the GCC-outputted assembly code to implement some important optimizations. They've been moving to internally-generated assembly and LLVM partially for that reason. That said, this hasn't constrained the language design - only the compiler's choice of available optimizations.
No, in short. The reality is, look around at the languages that are written in C. Lua, for example, is about as far from C as you can get without becoming Perl. It has first-class functions, fully automated memory management, etc.
It's unusual for new languages to be affected by their implementation language, unless said language contains serious limitations. While I definitely disapprove of C, it's not a limited language, just very error-prone and slow to program in compared to more modern languages. Oh, except in the CRT. For example, Lua doesn't contain directory functionality, because it's not part of the CRT so they can't portably implement it in standard C. That is one way in which C is limited. But in terms of language features, it's not limited.
If you wanted to construct an argument saying that languages implemented in C have XYZ limitations or characteristics, you would have to show that doing things another way is impossible in C.
The C stack is just the system stack, and this concept predates C by quite a bit. If you study theory of computing you will see that using a stack is very powerful.
Using C to implement languages has probably had very little effect on those languages, though the familiarity with C (and other C like languages) of people who design and implement languages has probably influenced their design a great deal. It is very difficult to not be influenced by things you've seen before even when you aren't actively copying the best bits of another language.
Many languages do use C as the glue between them and other things, though. Part of this is that many OSes provide a C API, so to access that it's easy to use C. Additionally, C is just so common and simple that many other languages have some sort of way to interface with it. If you want to glue two modules together which are written in different languages then using C as the middle man is probably the easiest solution.
Where implementing a language in C has probably influenced other languages the most is probably things like how escapes are done in strings, which probably isn't that limiting.
The only thing that has constrained language design is the imagination and technical skill of the language designers. As you said, C can be thought of as a "portable assembly language". If that is true, then asking if C has constrained a design is akin to asking if assembly has constrained language design. Since all code written in any language is eventually executed as assembly, every language would suffer the same constraints. Therefore, the C language itself imposes no constraints that would be overcome by using a different language.
That being said, there are some things that are easier to do in one language vs another. Many language designers take this into account. If the language is being designed to be, say, powerful at string processing but performance is not a concern, then using a language with better built-in string processing facilities (such as C++) might be more optimal.
Many developers choose C for several reasons. First, C is a very common language. Open source projects in particular like that it is relatively easier to find an experienced C-language developer than it is to find an equivalently-skilled developer in some other languages. Second, C typically lends itself to micro-optimization. When writing a parser for a scripted language, the efficiency of the parser has a big impact on the overall performance of scripts written in that language. For compiled languages, a more efficient compiler can reduce compile times. Many C compilers are very good at generating extremely optimized code (which is also part of the reason why many embedded systems are programmed in C), and performance-critical code can be written in inline assembly. Also, C is standardized and is generally a static target. Code can be written to the ANSI/C89 standard and not have to worry about it being incompatible with a future version of C. The revisions made in the C99 standard add functionality but don't break existing code. Finally, C is extremely portable. If at least one compiler exists for a given platform, it's most likely a C compiler. Using a highly-portable language like C makes it easier to maximize the number of platforms that can use the new language.
The one limitation that comes to mind is extensibility and compiler hosting. Consider the case of C#. The compiler is written in C/C++ and is entirely native code. This makes it very difficult to use in process with a C# application.
This has broad implications for the tooling chain of C#. Any code which wants to take advantage of the real C# parser or binding engine has to have at least one component which is written in native code. This eventually results in most of the tooling chain for the C# language being written in C++ which is a bit backwards for a language.
This doesn't limit the language per say but definitely has an effect on the experience around the language.
Garbage collection. Language implementations on top of Java or .NET use the VM's GC. Those on top of C tend to use reference counting.
One thing I can think of is that functions are not necessarily first class members in the language, and this is can't be blamed on C alone (I am not talking about passing a function pointer, though it can be argued that C provides you with that feature).
If one were to write a DSL in groovy (/scheme/lisp/haskell/lua/javascript/and some more that I am not sure of), functions can become first class members. Making functions first class members and allowing for anonymous functions allows to write concise and more human readable code (like demonstrated by LINQ).
Yes, eventually all of these are running under C (or assembly if you want to get to that level), but in terms of providing the user of the language the ability to express themselves better, these abstractions do a wonderful job.
Implementing a compiler/interpreter in C doesn't have any major limitations. On the other hand, implementing a language X to C compiler does. For example, according to the Wikipedia article on C--, when compiling a higher level language to C you can't do precise garbage collection, efficient exception handling, or tail recursion optimization. This is the kind of problem that C-- was intended to solve.
Does C language support inheritence. If so is is it using structures as classes are not defined in C.
Yes, it does. See http://gcc.gnu.org/ml/gcc/2010-05/msg00725.html . See Axel-Tobias Schreiner's book Object-Oriented Programming with ANSI C. There's an English translation of it available.
Also, see Object-orientation in C and How can Inheritance be modelled using C? .
No it doesnt. C is not an Object Oriented language. Inheritance is a property of OO languages.
You should try C++. It's OO and supports much more than inheritance
No, it doesn't.
There is no Compiler-level support for inheritance in C. Nevertheless, as others have already pointed out, Object Oriented coding does not REQUIRE such support. However, its a lot easier to write OO code in C++.
C inherits from ALGOL C Programming Language
C is not an Object Oriented language. Inheritance is a property of Object Oriented languages. There is no Compiler-level support for inheritance in C. Object Oriented coding does not REQUIRE such support.
well, c is NOT OBJECT ORIENTED language so,it is not available in C
No it doesn't support inheritance because C language is not oops
No it doesn't. C is not an Object Oriented language. You can try C++ or Java for inheritance functionality.
C is not an object oriented language as inheritance is supported only in object oriented programming language C doesn't support inheritance
Does the FILE type used through standard C functions fopen, etc. have an object-oriented interface?
I'm looking for opinions with reasoning rather than an absolute answer, as definitions of OO vary by who you ask. What are the important OO concepts it meets or doesn't meet?
In response to JustJeff's comment below, I am not asking whether C is an OO language, nor whether C (easily or not) allows OO programming. (Isn't that a separate issue?)
Is C an object-oriented language?
Was OOP (object-oriented-programming) anything more than a laboratory concept when C and FILE were created?
Answering these questions will answer your question.
EDIT:
Further thoughts:
Object Oriented specifically means several behaviors, including:
Inheritence: Can you derive new classes from FILE?
Polymorphism: Can you treat derived classes as FILEs?
Encapsulation: Can you put a FILE inside another object?
Methods & Properties: Does a FILE have methods and properties specific to it? (eg.
myFile.Name, myFile.Size, myFile.Delete())
Although there are well known C "tricks" to accomplish something resembling each of these behaviors, this is not built in to FILE, and is not the original intent.
I conclude that FILE is not Object Oriented.
If the FILE type were "object oriented", presumably we could derive from it in some meaningful way. I've never seen a convincing instance of such a derivation.
Lets say I have new hardware abstraction, a bit like a socket, called a wormhole. Can I derive from FILE (or socket) to implement it. Not really - I've probably got to make some changes to tables in the OS kernel. This is not what I call object orientation
But this whole issue comes down to semantics in the end. Some people insist that anything that uses a jump-table is object oriented, and IBM have always claimed that their AS/400 boxes are object-oriented, through & through.
For those of you that want to dip into the pit of madness and stupidity that is the USENET comp.object newsgroup, this topic was discussed quite exhaustively there a few years ago, albeit by mad and stupid people. If you want to trawl those depths, the Google Groups interface is a good place to start.
Academically speaking, certainly the actual files are objects. They have attributes and you can perform actions on them. Doesn't mean FILE is a class, just saying, there are degrees of OO-ness to think about.
The trouble with trying to say that the stdio FILE interface qualifies as OO, however, is that the stdio FILE interface doesn't represent the 'objectness' of the file very well. You could use FILEs under plain old C in an OO way, but of course you forfeit the syntactic clarity afforded by Java or C++.
It should probably further be added that while you can't generate 'inheritance' from FILE, this further disqualifies it as OO, but you could argue that's more a fault of its environment (plain C) than the abstract idea of the file-as-object itself.
In fact .. you could probably make a case for FILE being something like a java interface. In the linux world, you can operate almost any kind of I/O device through the open/close/read/write/ioctl calls; the FILE functions are just covers on top of those; therefore in FILE you have something like an abstract class that defines the basic operations (open/read/etc) on an 'abstact i/o device', leaving it up to the various sorts of derived types to flesh those out with type-specific behavior.
Granted, it's very hard to see the OO in a pile of C code, and very easy to break the abstractions, which is why the actual OO languages are so much more popular these days.
It depends. How do you define an "object-oriented interface"? As the comments to abelenky's post shows, it is easy to construct an argument that FILE is object-oriented. It depends on what you mean by "object-oriented". It doesn't have any member methods. But it does have functions specific to it.
It can not be derived from in the "conventional" sense, but it does seem to be polymorphic. Behind a FILE pointer, the implementation can vary widely. It may be a file, it may be a buffer in memory, it may be a socket or the standard output.
Is it encapsulated? Well, it is essentially implemented as a pointer. There is no access to the implementation details of where the file is located, or even the name of the file, unless you call the proper API functions on it. That sounds encapsulated to me.
The answer is basically whatever you want it to be. If you don't want FILE to be object-oriented, then define "object-oriented" in a way that FILE can't fulfill.
C has the first half of object orientated.
Encapsulation, ie you can have compound types like FILE* or structs but you can't inherit from them which is the second (although less important) half
No. C is not an object-oriented language.
I know that's an "absolute answer," which you didn't want, but I'm afraid it's the only answer. The reasoning is that C is not object-oriented, so no part of it can have an "object-oriented interface".
Clarification:
In my opinion, true object-orientation involves method dispatch through subtype polymorphism. If a language lacks this, it is not object-oriented.
Object-orientation is not a "technique" like GTK. It is a language feature. If the language lacks the feature, it is not object-oriented.
If object-orientation were merely a technique, then nearly every language could be called object-oriented, and the term would cease to have any real meaning.
There are different definitions of oo around. The one I find most useful is the following (inspired by Alan Kay):
objects hold state (ie references to other objects)
objects receive (and process) messages
processing a message may result in
messages beeing sent to the object itself or other objects
a change in the object's state
This means you can program in an object-oriented way in any imperative programming language - even assembler. A purely functional language has no state variables, which makes oo impossible or at least awkward to implement (remember: LISP is not pure!); the same should go for purely declarative languages.
In C, message passing in most often implemented as function calls with a pointer to a struct holding the object's state as first argument, which is the case for the file handling api. Still, C as a language can't be classified as oo as it doesn't have syntactic support for this style of programming.
Also, some other definitions of oo include things like class-based inheritance (so what about prototypal languages?) and encapsulation - which aren't really essential in my opinion - but some of them can be implemented in C with some pointer- and casting magic.
Having learned Java and C++, I've learned the OO-way. I want to embark on a fairly ambitious project but I want to do it in C. I know how to break problems down into classes and how to turn them into class hierarchies. I know how to abstract functionality into abstract classes and interfaces. I'm even somewhat proficient at using polymorphism in an effective way.
The problem is that when I'm presented with a problem, I only way I know how to do it is in an Object-Oriented way. I've become too dependent on Object-Oriented design philosophies and methodologies.
I want to learn how to think in a strictly procedural way. How do I do things in a world that lacks classes, interfaces, polymorphism, function overloading, constructors, etc.
How do you represent complex concepts using only non-object-oriented structs? How do you get around a lack of function overloading? What are some tip and tricks for thinking in a procedural way?
The procedural way is to, on one side, have your data structures, and, on the other, your algorithms. Then you take your data structures and pass them to your algorithms. Without encapsulation, it takes a somewhat higher amount of discipline to do this and if you increase the abstraction level to make it easier to do it right, you're doing a considerable part of OO in C.
I think you have a good plan. Doing things the completely OO way in C, while quite possible, is enough of a pain that you would soon drop it anyway. (Don't fight the language.)
If you want a philosophical statement on mapping the OO way to the C way, in part it happens by pushing object creation up one level. A module can still implement its object as a black box, and you can still use reasonable programming style, but basically its too much of a pain to really hide the object, so the caller allocates it and passes it down, rather than the module allocating it and returning it back up. You usually punt on getters and setters, or implement them as macros.
Consider also that all of those abstractions you mentioned are a relatively thin layer on top of ordinary structs, so you aren't really very far away from what you want to do. It just isn't packaged quite as nicely.
The C toolkit consists of functions, function pointers and macros. Function pointers can be used to emulate polymorphism.
You are taking the reverse trip old C programmers did for learning OO.
Even before c++ was a standart OO techniquis were used in C.
They included defining structs with a pointer to srtuct (usually called this...)
Then defining pointer functions in the struct, and during runtime initialize those pointers to the relevant functions.
All those functions received as first paremeter the struct pointer this.
Don't think C in the complete OOP way. If you have to use C, you should learn procedural programming. Doing this would not take more time than learning how to realize all the OOP features in C. Furthermore, basic encapsulation is probably fine, but a lot of other OOP features come with overhead on performance when you mimic them (not when the language is designed to support OOP). The overhead may be huge if you strictly follow the C++ design methodology to represent every small things as objects. Programming languages have specific purposes in design. When you break the boundary, you always have to pay something as the cost.
Don't think you have to shelve your knowledge of object-oriented work - you can "program into the language".
I had to work in C after being primarily experienced in object-oriented work. C allows for some level of object concepts to pull through. At the job, I had to implement a red-black tree in C, for use in a sweep-line algorithm to find the intersection points in a set of segments. Since the algorithm used different comparison functions, I ended up using function pointers to achieve the same effect as lambdas in Scheme or delegates in C#. It worked well, and also allowed the balanced tree to be reusable.
The other feature of the balanced tree was using void pointers to store arbitrary data. Again, void and function pointers in C are a pain (if you don't know their ins and outs), but they can be used to approximate creating a generic data structure.
One final note: use the right tool for the job. If you want to use C simply to master procedural technique, then choose a problem that is well-suited to a procedural approach. I didn't have a choice in the matter (legacy application written in C, and people demand the world and refuse to enter the 21st century), so I had to be creative. C is great for low/medium abstractions from the machine, say if you wanted to write a command-line packet inspection program.
The standard way to do polymorphic behavior in C is to use function pointers. You'll find a lot of C APIs (such as the standard qsort(3) and bsearch(3)) take function pointers as parameters; some non-standard ones such as qsort_r take a function pointer and a context pointer (thunk in this case) which serves no purpose other than to be passed back to the callback function. The context pointer functions exactly like the this pointer in object-oriented languages, when dealing with function objects (e.g. functors).
See also:
Can you write object-oriented code in C?
Object-Orientation in C
Try not to use OOP in C. But if you need to, use structures. For the functions,
take a structure for an argument, like so:
typedef struct{
int age;
char* name;
char* dialog;
} Human;
void make_dialog(Human human){
char* dialog="Hi";
human.dialog=dialog;
}
which works exactly like python's self, or something like that and to access other functions belonging to that class:
void get_dialog(Human human){
make_dialog(human);
printf(human.dialog);
}