Class-C : new OOP C programming language

Hello everyone!

I had problems with C++/Objective-C, so I've just created my own version of the ideal object-oriented C language, maybe you find it useful also.

It's almost standard C, defining a class is just putting your existing code in a top-level block - global variables become member variables, functions become methods. Header files are generated automatically by the compiler, multiple inheritance is allowed - that's all! :)

But what do YOU think? I'm really interested in your opinion.

web : Class-C
git : www.github.com/milgra/clc
the compiler : www.github.com/milgra/clcc
demo project : www.github.com/milgra/dynamicsx

Thanks,

Milan

Quote:

---

Originally Posted by milgra's web site

But C++ and Objective-C became language monsters with over a 100 keywords

---

If that's true (only accepting that because I don't want to count right now) several of them are merely reserved words that have no definite purpose yet, only that they can't be used as variables.

Quote:

---

and confusing features, and more confusing libraries.

---

I would like to note that your specification is extremely unhelpful. You defer to the C standard, but not a specific standard, in many places. In other important places, like a library specification, you say nothing. In fact, I believe that the libraries, features, and keywords in your language can be no less confusing, because of this choice.

The lack of explanation on precisely how much C you support isn't even the worst example I could pick. I don't know how to define a Class-C program's entry point. Where does my program even start?

Quote:

---

Just because you need classes and objects, you don't have to overcomplicate things.

---

I'm a proponent of things being simple. As it is now though, I think the only person who can use Class-C is the person who made it.

That's fine.

But it needs a lot of polish before I want to.

I tend to agree with whiteflags.

There is much more to object oriented development than putting globals into a class and turning functions into member functions of that class. There is also much more to programming in C than global variables and functions - in fact, most experienced C developers recommend minimising the use of global variables and extensive use of global variables in C is one of the characteristics that separates novices from experienced developers.

So, in effect, your minimalisation notion "The idea behind Class-C is very simple : take your existing C code, put global variables and functions in a block and global variables become member variables, functions become methods. Class is ready. " is targeting an inexperienced C developer who is seeking an easier path to employ novice object-oriented techniques.

Like whiteflags, I'm all for keeping things simple. But that doesn't mean targeting the lowest common denominator. In fact, writing software that is no more complex than it needs to be requires a lot of practice - and it is an area of active research to identify the minimum set of language and library features that are appropriate to solving the widest range of real-world problems as simply as possible. It is another area of research, in various specific application areas, to identify the simplest set of language and library features that are appropriate to each application domain.

While I agree with you that modern programming languages are unnecessarily complex, and have too many features, the solution - unfortunately - is not to limit oneself to a simple subset. The trick is to get experience with multiple techniques in which problems may be solved, and be able to recognise which techniques are best suited for a task at hand.

By the way, a common test is to bootstrap your compiler. Can you implement the "Class-C to C" preprocessor using Class-C itself? What about example programs in Class C.

I looked at some of the implementation on github and it seems to use object-oriented concepts in C already. If you want to program object oriented in C, what is the advantage of using "Class-C" rather than using such object-oriented techniques in C directly?

O_o

From the examples, it seems as if your compiler only handles the trivial task of mangling method names without providing any features that would make migrating to "Class-C" a worthwhile endeavor.

Assuming we buy the "need classes and objects" angle, what about "Class-C" doesn't add a layer to what "OOP" exists in standard C?

I'm not trying to discourage you in any way; I'm only posting to point that the reason so many "complicated" dialects of C exist, included your "Class-C", is because people have found C lacking in some way, but here you fall short because migrating to your "Class-C" simply doesn't "buy" as much as migrating to Objective-C or C++. I'm not an Objective-C guy, but looking at C++, those many "complicated" features are options yet when useful provide more of a reason to migrate than you've offered.

Also, just for the sake of information, considering your description of how your objects and inheritance works you are near implementing "prototypical inheritance" (Granted, this is without proper mutability of prototypes.) and though that sounds repellent to me, (I pretty much hate the very nature of "prototypical inheritance".) I know a lot of programmers who would... let's just say they would need a change of pants... if offered such a compiled flavor of C.

Soma

I have a simple question: why not use a language that is OOP in nature already? If you are looking for an OOP language with C semantics, then what do you think of C++?

Hello everbody,

Thank you for the answers!

whiteflags : Yes, you are right, the introduction.pdf doesn't show too much examples, I'm planning on writing a few step-by-step tutorials. Until that, the demo projects ( the compiler and dynamicsX on github ) are the easiest way to understand how class-c works, the readme in those projects gives you a good hint on how to start. As the specification says, class-c is a very thin layer over C, and deals only with classes and instances, so the C compatibility depends on what compiler you use. The class-c compiler's source code is C89 compatible.

grumpy: "There is much more to object oriented development than putting globals into a class and turning functions into member functions of that class."
that's true, but that was the only thing I needed in C, nothing else. That's why I've created class-c, and refused C++.

c99tutorial : the class-c compiler was written in class-c since the second iteration

phantomotap : true, OOP can be done with plain C, but with a lot of typing. And class-c compiler does nothing else, but does this typing instead of you, so you can concentrate on the implementation instead of typing. That's why it generates the header files automatically.

Elysia : C++ was the main reason I created Class-C, it's just overloaded with things I don't need in a language :)

Quote:

---

And class-c compiler does nothing else, but does this typing instead of you, so you can concentrate on the implementation instead of typing.

---

O_o

Ah! The paradox of typing speed rears again its ugly head.

Soma

Quote:

---

Originally Posted by milgra

Elysia : C++ was the main reason I created Class-C, it's just overloaded with things I don't need in a language :)

---

So why don't you "ignore" the things you don't "need"?

because I just can't :) I can't even stand unnecessary things in my flat - I drop everything out I don't need, I love keeping it minimal. I'm sick, I know...

While it's fine to have this mentality, it's not good to push unto others. It's fine to keep this as a personal pet project, but trying to push it unto others is not a good idea.
Remember: C++ is all about don't pay for what you don't use. If you don't need something, you don't need to pay for it.

But C++ is like the best language ever... How could you not love it?

And if you aren't using the STL, what's wrong with you? It's like all your favorite data structures in one place already implemented for you!

O_o

You know, again not trying to harsh your buzz*, you seemingly lack a way to do spontaneous inheritance despite the fact that your "Class-C" "OOP" is somewhere around "mixins"/"monkey patching".

Consider:

Code:

---

Person
{
    void eat(){/*...*/}
    void move(){/*...*/}
    void talk(string * s)
    {
        printf("%s", s);
    }
}

Singer:Person
{
    void sing(){/*...*/}
}

---

Okay. We are good so far as it goes, but what do we do for `Dancers'?

If we follow the mechanic, as exists in the examples, we need to create two new classes to cover the spread:

Code:

---

Dancer:Person
{
    void dance(){/*...*/}
}

Dancer:Singer:Person
{
    void dance(){/*...*/}
}

---

The situation quickly grows into nightmares. Many strategies exist to solve such problems for C, C++, Java, and so on for many languages, but breaking with traditional inheritance as you have allows the compiler to "mix" the "classes" on the fly:

Code:

---

Person
{
    void eat(){/*...*/}
    void move(){/*...*/}
    void talk(string * s)
    {
        printf("%s", s);
    }
}

Singer /* patch: adds `sing' method */
{
    void sing(){/*...*/}
}

Dancer /* patch: adds `sing' method */
{
    void dance(){/*...*/}
}

---

Which might still be created, as if written similar to the previous thoughts, with a general syntax such as:

Code:

---

int main()
{
    Dancer:Singer:Person * s = Dancer:Singer:Person:alloc();
}

---

*shrug*

Of course, this is "unnecessary", "complicated", and "big" in exactly the same way as C++, Java, and such provide competing mechanisms.

Soma

*): My first attempts were abysmal.

Elysia : Oh, I really don't want to push it or force it - I just wanted to show it as an option, because I hope that there are a few minds like me out there amongst the 7 billion :)

MutantJohn : Oh you don't know how fun is it to reimplement already implemented things! :)