One way to simulate polymorphism in C is to create structs with identical fields in identical order and add the extended fields after:



Any function that takes a BaseClass pointer can take a SubClass pointer as long as it is cast. This technique works well, but can easily become a nightmare to maintain if you make heavy use of it. Imagine if you need to add a new field to BaseClass. Every struct that 'derives' from it will need to be changed. One way to help with this is to keep the 'class' declarations as macros so that they are all in one place:



There's a lot you can do to work in an object oriented design in C, but it's best if you don't try to shoehorn things in that just don't fit and make concessions where you need to. In other words, don't get overly zealous. Work within the OO paradigm where you can, but be careful that you don't make your code more complex than it needs to be. C is about simplicity. I've found the best way to use C is to keep things modular and just use OO concepts only where they enhance the design.

Polymorphism in C - The Code Project

- xeddiex

First off thanks everyone, you're comments are useful and good.

Quote:Original post by RDragon1
LUA might fit somewhere between C and Python.

But seriously, why do you want to create a new language, and why does that mean you need to know how to use OO facilities in C?

Quote:Original post by Falling Sky
I love to make new languages, its all I ever do when programming. If your making a compiler I dont see why you would need to know how to do OO in C...and why dont you just write the interpreter in C++?

First run of the approach will be to change everything to working C code, and then see if there are any patterns. Typically one would just write a Grammar, and then generate a Lex/Parser. But the problem is that I think languages that try to take on too much operate under the assumption that just because something is possible in the language makes it suitable for "every" problem with programming. Python does things simply, and elegantly, but its fairly difficult to combat ref counting, or garbage collection, if need be. C is simple as well, but gets bogged down when appealing to greater abstractions.

But you're right I don't think that the end result will be a compiler, but a happy marriage between Python and C.

L-

Quote:Original post by smr
What's the goal of your C/Python hybrid?

Good questions, I've been thinking about how to state this, but here is a little of what I have in mind:

1.) Removal of the dependency of Macros, (and Header files from C, at least from having to be hand written).

2.) Design a Programmable Programming language. (ie Lisp like). But once again without macros. And yes it seems a little odd as to what a Programmable Programming language is, however, its not easy (or very possible) in C/C++ to do something like Obj.GetFunction("blah").doSomething(x,y,z), or Obj.GetAllFunctions() : returns a list, without programming it yourself. That is it's pretty easy to add a member variable that is a list and store pointers to the methods of the class in that list and then return that list, but that's a lot of work when it's something a parser/compiler could do pretty easily.

3.) Add without too much difficulty the ability to plug the language into a data base so as to perform some queries on the attributes of the source. For instance how many objects are dependent on function x, or class y, or variable z. With SQL this would be fairly trivial if the information was already stored properly. The thing is how does one do such a thing with C/C++, easily? (There is little to no freely available grammar ware out there).

4.) Generate Documentation without relying too heavily on seperate tools.

5.) Manipulate the source code programmatically (this is similar to #2 above but should also include the idea of templating/generic programming). Rearranging organizing, and generating builds from within the language. That is the Python portion of the language is more than suitable replacement for Make (with some additional library modules).

I think that covers the big issues,
L-

With OOP in C, you'll have an easier time using delegation ("has a") instead of inheritance and polymorphism ("is a").

Here are a few references.

Object-Oriented Programming With ANSI-C (pdf)
Object Oriented Programming in C
Object Oriented Programming in C
Object-Oriented C Programming

Quote:Original post by LessBread
With OOP in C, you'll have an easier time using delegation ("has a") instead of inheritance and polymorphism ("is a").

Here are a few references.

Object-Oriented Programming With ANSI-C (pdf)
Object Oriented Programming in C
Object Oriented Programming in C
Object-Oriented C Programming

Thanks for that, I think those will be pretty helpful.

L-

PS The second C link is broken, but thanks anyhow.