GTK programming has almost never been this easy: IBM developer shares his skills, his enthusiasm, and his modified code for the SimpLIstic sKin interface (or SLIK). SLIK provides a great tool for building advanced user interfaces in Linux or Unix systems. A part of the GQmpeg toolset, it is written using the GTK toolkit, a powerful set of widgets for graphics used by such applications as the GIMP and other GNOME-based apps.
Advanced UI Development in GTK+
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
the coding style reminded me of the Windows straight SDK programming.
the screenshot ? only the wallpaper looks good.
I really, really was hoping we’ve gotten beyond the skinnable application craze already. All you end up with is more worthless UI bloat, and an interface that’s inconsistent with regards to the rest of your desktop environment. I don’t need my DVD player to look like the thing sitting in my entertainment center, I need it to look like all the other programs on my computer so I don’t need to waste my time fishing around for buttons and clumsily waving around for tooltips in a poorly-designed (and probably ugly) interface.
“..GIMP and other GNOME-based apps..”
I love it when gnome folks try pass GIMP, Abiword, Mozilla, even OpenOffice etc. as GNOME programs. Nice try. This time, they have it backwards. Actually, GNOME is GIMP based, and GIMP 1.2.x for that matter (check GIMP2 binary with ldd to see how they eliminated dependency on gnome libs. It depend on GTK+, on which GNOME is based, but not on gnomelibs.)
That’s true, but this is what the GNOME developers want: remove the gnomelibs. They don’t want it, they want that all good stuff that there is there is added to the GTK+.
(Yup, that means that GNOME will lose its “development plataform” in its name)
Code:
gtk_signal_connect(GTK_OBJECT (ui->window), “delete_event”,
GTK_SIGNAL_FUNC(window_delete_cb), ui);”
Good grief, how ugly can it get? GTK should have been written as a clean C++ API. This is just a mess. Take a look at QT, which is brilliantly documented and the C++ API keeps your code readable, and not cluttered with countless functions like the above.
Just give me a clean C++ API and we’ll do business, but plain C for GUI coding is just horrible.
Well, that is the problem with trying to implement a graphical environment (which is object based) using a non-object oriented procedural language. That is what hard-headedness gets you.
You guys don’t know history do you? GTK+ was written in C because back then there were no good C++ compilers for Unix!
Don’t like the C API? Fine, go use the C++ or Python bindings or whatever. Nobody’s forcing you to use the C API.
As for me, I was a Delphi programmer, and I learned GTK+’s C API with ease. I don’t even think it’s horrible. In fact, GTK+ is the best C API I’ve ever seen. Microsoft’s C API is far, far worse.
“back then there were no good C++ copilers for Unix”.
Well g++ was good enough for Qt already when GTK+ was started. Both started development at roughly the same time. Qt a little earlier, IIRC.
As for GTK+ being the best C api… well, that’s like saying my monkey is the best opera singing monkey ever 😉
On another issue:
The article says “Traditional user interfaces are evolving from crude rectangular windows with buttons and menus to full-fledged real-world virtual “gadgets.” It is only a matter of time until rectangular-window based application become a thing of the past. Linux is leading the pack as the open source platform of choice for advanced user interface design. ”
GaaaaaH! Yuuuuuuuuuck! Emulating phisical devices that you manipulate with your hands into a picture that you manipulate with your mouse is like trying to play the piano using oven mittens.
Usually, those skinned GUIs are a nightmare usability-wise. A choice of skins is just a choice on HOW you want it to hurt. Usually the only usable skins are the ones that look… well, rectangular, filled with little rectangular thingies.
“As for me, I was a Delphi programmer, and I learned GTK+’s C API with ease. I don’t even think it’s horrible. In fact, GTK+ is the best C API I’ve ever seen. Microsoft’s C API is far, far worse.”
Actually, I never bothered to learn C, but went to C++ straightaway, so you could argue that I have no objective view on the quality of the GTK C API. Fair enough.
Now, I just think in objects all the time, but thinking in a functional language such as C is beyond my reach. Weird, isn’t it? Anyway, GUI coding *is* just inherently object based, no matter how you look at it. I’m just wondering how one is structuring the code in C . Where lies the modularity and reusability in C coding? It just looks like an endless collection of functions …
” Don’t like the C API? Fine, go use the C++ or Python bindings or whatever. Nobody’s forcing you to use the C API. ”
I don’t like bindings that much because they are often not up-to-date and sometimes completely lack certain features. This is a no go for me.
Actually, it wouldn’t be a bad idea to make a clean C++ API for GTK, no binding or crap like that, just C++. But doing this would take a life time
These are the days when language neutrality is becoming a reality.
You dont have to use the C API. There are many bindings including C++, Python, C#, Ruby, VB, Perl etc. The choice is yours.
Just because GTK is not written in C++ doesnt mean its not a good API. Take MFC for example which is a hideous C++ UI API (for window programming)…
c++ or c. its totally useless to discuss this. most of the people learned C++ straight away, yet there are nice things you can do with c, that take a headache in c++. object oriented doesnt mean better in the end.
and i dont get whats so bad about:
gtk_signal_connect(GTK_OBJECT (ui->window), “delete_event”,
GTK_SIGNAL_FUNC(window_delete_cb), ui);”
should you not understand what this line says, you better not make comments on what language is better. it might be better for you, but others might well disagree on that.
if you dont understand the line you obviously have no understanding about C programming and thus your post is pointless.
The problem with API wrappers is that you have layers of code sitting on top of other layers of code. Good thing I have a 2 ghz processor because software just gets slower and slower for no reason other than poor choices were made in the tools used to implement things to begin with. Just because MFC is a pile of crap doesn’t mean that GTK could not have been more elegantly created with an object oriented language, especially since gui frameworks are logically object based anyway. Also, MFC is just a C++ wrapper that sits atop win16/32 anyway.
You’re right. I would much rather have to pass a dozen parameters to a C function to make up for the fact that it is pooly suited for things that are better implemented with classes. But wait, my opinion differs from yours so I must be a troll right?
“and i dont get whats so bad about:
gtk_signal_connect(GTK_OBJECT (ui->window), “delete_event”,
GTK_SIGNAL_FUNC(window_delete_cb), ui);”
For starters, can we just stop using does ugly underscores all the time, you C guys seem to have a fetisch for those, but this is probably caused since you don’t use the “.” for methods, which are absent
I believe that C must be used for for glorified assembler stuff, kernel hacking, embedded systems etc. When it comes down to GUI programming, C is just SO no good.
Best wishes,
Troll
“For starters, can we just stop using does ugly underscores all the time, you C guys seem to have a fetisch for those, but this is probably caused since you don’t use the “.” for methods, which are absent
”
hmm, the STL uses underscores.
Even though Gtk is written in C, it is a well designed object oriented API with inheritance. Just because it’s written in C does not’t mean it’s not well designed. With an API in C, it’s much easier to write bindings for other languages, and if anybody has followed the history of Gtk, this was an important goal of Gtk.
I do believe C++ is a better suited language for GUI’s. Qt is an excellent api. The only flaw I find with Qt is the slots mechanism for passing signals. The extra preprocessing step is not a good thing. Gtk’s signal implementation is cleaner IMHO.
I’m interested in judging the GUI as a GUI, and in nothing else. It sucks. If that’s what GTK+ and advanced approaches to GUI APIs can do, then throw GTK+ and the API approach in the garbage right now.
Seriously.
I can’t play any instruments and I can’t write any code, but I can tell you who does know how to play any instrument and I can tell you who can write GUI code or design GUI APIs.
It SERIOUSLY SUCKS.
<<Now, I just think in objects all the time, but thinking in a functional language such as C is beyond my reach.>>
C is not a functional programming language. Believe me. There is a huge difference between functional and _procedural_ languages
I actually like the underscores. Of the styles, my favorite is the STL style, for its clarity and unobtrusiveness. I like the Lisp/Dylan identifier style just a wee bit better though, because you can use foo-bar instead of foo_bar, which saves pressing the shift key, and looks nicer
I don’t really see what’s so bad about the GTK+ code that was presented. The Qt equivilent is a bit better, but not by much. The main thing the Qt version buys you is type safety.
GTK+’s C API flaws really don’t come out until you start doing larger amounts of code with it. Then, the lack of default parameter values, overloaded functions, namespaces, and some advanced class features make things less nice to code with.
Well, if you don’t like programming in C then write a C++ application with GTK+ objects in them. That way you won’t have to deal with the layers of ‘bindings’ that you have to deal with in something like gtkmm and at the same time you will get access to all the lower level functions of the C API. Ofcource, when you write the app. in C++ you cannot be relaxed. One has to cast the function types and object properly or errors will popup all over the place.
This is a good way (I have found) to balance between C and C++ in GTK+. Not a replacement though for a good ground-up C++ API.
-D
1. For those (like me) that prefer C++ to C, what’s wrong with gtkmm?
2. Smoke: What can one do with C that one cannot do with C++ (especially given that C code is generally valid C++ code)?
3. I also found Qt’s preprocessing annoying, but I suspect that was just that it was new to me and I was lazy. I would guess that, if I were of the KDE persuasion, the advantages of Qt would render the preprocessor annoyance trivial.
C++ programers are those who never could be able to right C code.
To learn C++ please, learn C firsth.
“C++ programers are those who never could be able to right C code.”
C programmers are those who never understand class design patterns.
C and C++ are completely different languages. Good C code looks completely different from good C++ code. You should learn both languages, but as seperate languages, not C++ as an extension of C. If you can help it, run C++ first, then C. Since you *can* write C code in C++, its difficult to unlearn your C habits when learning C++.
Some of you trolls never cease to amaze me. For the love of sandwiches, how can a code look ugly just by the mere fact that it is written in a specific language? Lets follow their reasoning. The code would only look better if it was written in their favorite language. Hmmm…yeah, it’s beginning to make no sense.
Let me tell you what ugly code is. Ugly code is when don’t understand the purpose of the variables defined. Ugly code is never, or improperly, commented. Ugly code is code that is written every six months, because it was not planned or designed to begin with. Ugly code is poorly formatted. Ugly code is code you and I will never understand. Ugly code has an estimated life cycle of 2 years before it is trashed for ever. Ugly code is difficult to maintain. Ugly code is not documented. Ugly code can be written in any language, yes, that includes C++.
Whoever doesn’t understand how to use a function, what a function does, how to reuse functions, how functions and structures relate to objects, or says C is not modular, shouldn’t even be commenting on this thread and shouldn’t even be programming. But of course, they have every right to troll.
But again, this has nothing to do with GTK+ as an API, right? This is all about how “functional” languages can’t be used for developing GUI s because they are ugly, right? And this has nothing to do with the fact that GTK+ is an object oriented API, the use of a procedural language makes its object oriented framework invalid, right? Enough of you guys, you make me ill.
I find writing programs in GTK+ a blessing. One of the best contributions or extensions to the C library has to be Glib. The developers of Glib need an award for their work of incalculable genius. In fact, I wager that Glib should be an addition to the ANSI/ISO C standard libraries. This API is a C programmers dream come true. It is the most structured and intelligently limiting object oriented framework I’ve ever used, for better or for worse.
It is very easy to write spaghetti code in C++, Java, Perl and you name your object oriented language or framework. It is hard to do that in GTK+/C. Of course, this is just from my experience. I also think object oriented languages are clearly overrated and unduly hyped. It is not the holy grail methodology of software design. They are good for some tasks and horrible for many.
>…how can a code look ugly just by the mere fact that it is written in a specific language?
Simple, a language(C) can have little or no support for expressing concepts(classes, objects, inheritance…) in a particular problem domain(Graphical User Interfaces). To make up for this deficiency, the programmer has to waste time re-implementing features offered by the more appropiate language. This increases the complexity of the code, hence making it more ugly. You can see this in the large number of paramaters that the functions in GTK have and the large amount of casts that you have to do to use them.
The whole C vs C++ argument is the same crap that has been going on the field of programming forever. The assembly language bigots used the same arguments(too slow, too bloated, I can’t understand it) against Fortan. The Fortran bigots used the same arguments against C. And now the C bigots are using the same arguments against C++. I think this is caused by the fact that most programmers are locked in the mind-set that was prevalent when they were learning programming. They are locked in a certain way of doing things and can’t break out and consider a new way of doing things. I’m sure that when OO is superceded by something better, the C++ bigots will sneer and laugh at it.
This is all about how ?functional? languages can’t be used for developing GUI s because they are ugly, right?
Uh.. functional languages can’t be used for developing GUIs because interactive programs need functions with side effects, which can’t be done in (purely) functional languages without ugly magic with monads.
Monads aren’t ugly, they just make your head hurt
But, Clean’s uniqueness typing offeres interactivity without monads, so they’re not the *only* way.
When C projects got too large to manage, they invented C++.
When C++ grew out of control, they slim it down and call it Java.
I’m still following your logic. Ugly code is one in which functions have four parameters, therefore, GTK+ produces ugly code.
Monads aren’t ugly, they just make your head hurt
I didn’t say they were, I said that the magic was ugly.
That said, I don’t like monads either, precisely because of them making my head hurt. It’s nice to hear that I’m not the only one that finds monads arduous. 🙂
But, Clean’s uniqueness typing offeres interactivity without monads, so they’re not the *only* way.
Very true. There are probably other ways, too. However, I haven’t yet seen a clean (imo, that is) solution for this problem. (Nor have I seen a clean solution for multithreading in functional languages, but that is another chapter.)
> I’m still following your logic.
No you are not.
Marcus Sundman : Uh.. functional languages can’t be used for developing GUIs because interactive programs need functions with side effects, which can’t be done in (purely) functional languages without ugly magic with monads.
GTK+ has been used successfully to write many powerful graphical user interface applications. Even one of the most prominent desktop environment in Unix, GNOME, is written using entirely GTK+. XFCE4 also another light weight and fast desktop environment is written using GTK+. The language one uses to write a graphical user application becomes irrelevant if there are powerful application programming interfaces available for the language. This is assuming the interface enables programmers achieve their intended objectives.
C is a procedural language. Via GTK+, programmers knowledgeable and experienced in C, can, and have, written powerful graphical user interfaces used on many Unix platforms today. Again this emphasizes the needlessness and sometimes childishness of programming language rebuttals/wars. Languages that attempt to be a conglomerate of all features, end up being masters of none.
For many programs one doesn’t need and abundance of needless and redundant array of software engineering theories to write simple and functional graphical user interfaces. Disturbingly, of late, the strength of a language is not based on it’s maturity, simplicity and the wealth of trusted and tested programs available for it, but on feature X, Y, Z that virtually nobody will ever use.
People are quick to jump at an interface saying it doesn’t have feature X or Y, that they themselves don’t have a need for. According to them the interface is incomplete because those features are absent, even though the usefulness and usage of those features are not analyzed by the person appealing their absence.
It’s one thing for an interface to be obfuscated with features, it’s another thing for it to be easy to use and properly designed even if its trade offs are a few trivial features you’d only need in extremely rare and complex situations– in which case you should use a better suited toolkit.
I don’t know about you, but I prefer my interfaces clean and simple as opposed to littered with features, bloat and needless overhead. GTK+ provides me with such an interface, and I have yet to experience the ugly magic with monads when using C to develop my graphic user interfaces courtesy of GTK+ and Glib.
Your mileage may vary. But to say an API is ugly because it is implemented in a language you don’t understand or despise is silly and immature to say the least.
Marcus Sundman: […]can’t be done in (purely) functional languages without ugly magic with monads
root: I have yet to experience the ugly magic with monads when using C
I wouldn’t suspect you would have. 🙂
Apparently you have misunderstood something. C is not a functional language. It is a procedural one, as you said yourself.
On the other hand, it was I who was a bit off topic. I apologize for that.
Fun to see people trying to catch up with Enlightenment again. Unfortunately this one falls really short.
http://www.enlightenment.org/pages/edje.html
It would be OK if this managed to even scratch the surface of what Edje can do, but it’s butt ugly to boot!
> Via GTK+, programmers knowledgeable and experienced in C, can, and have, written powerful graphical user interfaces used on many Unix platforms today.
Yes, you are correct. One positive aspect of GTK is that it allows people who only understand C to create a GUI.
> Languages that attempt to be a conglomerate of all features, end up being masters of none.
I hate to break this to you, but C++ is not a “conglomerate of all freatures”. It’s a language that is specialized for OO. The nice thing is that OO is a superset of procedural programming(think of each class as a little procedural program), and so C++ can understand C.
> For many programs one doesn’t need and abundance of needless and redundant array of software engineering theories to write simple and functional graphical user interfaces.
CORRECTION: For many TRIVIAL programs one doesn’t need and abundance of needless and redundant array of software engineering theories to write simple and functional graphical user interfaces.
> People are quick to jump at an interface saying it doesn’t have feature X or Y, that they themselves don’t have a need for.
How do you know what other people need? Just because you don’t need them doesn’t mean that others don’t.
> …I prefer my interfaces clean and simple as opposed to littered with features, bloat and needless overhead.
WHAT! GTK provides an interface without needless overhead? Have you ever seen a GUI API for an OO language?
Yes, you are correct. One positive aspect of GTK is that it allows people who only understand C to create a GUI.
If you understand C++, Java, Python, Perl, Ada, Objective C, to mention a few you can use GTK.
I hate to break this to you, but C++ is not a “conglomerate of all freatures”. It’s a language that is specialized for OO.
I hate to break it to you, C++ is a hack of C to make it OO. Languages designed from scratch and specialized for OO are Java, Ada, Perl, Python or even C#.
The nice thing is that OO is a superset of procedural programming(think of each class as a little procedural program), and so C++ can understand C.
If you are using C++ for projects that can be done procedurally, then you need programming lessons.
CORRECTION: For many TRIVIAL programs one doesn’t need and abundance of needless and redundant array of software engineering theories to write simple and functional graphical user interfaces.
In that case many programs are trivial.
How do you know what other people need?
I know what they need based on the applications they are writing.
Just because you don’t need them doesn’t mean that others don’t.
I know that.
WHAT! GTK provides an interface without needless overhead?
Yes it does.
Have you ever seen a GUI API for an OO language?
Every other GUI API I’ve used has been in an OO language, except for GTK+. Where did you think I got “needless features, lack of structure, complexity” from?
> If you understand C++, Java, Python, Perl, Ada, Objective C, to mention a few you can use GTK.
My original statement meant that GTK+ gives you the option to use C, while other C++ toolkits don’t. Yes, it also gives you the option of using other languages as well.
> I hate to break it to you, C++ is a hack of C to make it OO.
Yes, a specialization of C to make it OO. Not a “conglomerate of all freatures”.
> If you are using C++ for projects that can be done procedurally, then you need programming lessons.
You totally mised the point of what I was saying. I did not say that I write procedural programs in OO. All programs can be written procedurally. Does that mean that all programs should be written in C?
What I said was that OO is an extension of procedural programming. Instead of forcing a lot of functionality in one monolithic procedural program, you write lots of simple procedural programs(classes) that do one thing really well and connect them toghether. Similar to how UNIX systems work. OO concepts(inheritance, etc.) deal with how these simple procedural programs are connected.
> In that case many programs are trivial
Trivial programs don’t require GUIs.
> Every other GUI API I’ve used has been in an OO language, except for GTK+.
GTK requres wrappers to be used in any sane manner. You don’t thing that is useless overhead and bloat?
As time passes, GTK will become harder to manage simply because C provides poor tools for managing complexity. In a couple of years GTK will be replaced (just like Mono is being positioned to replace C for GNOME applications) because it will become too difficult to extend and modify.
Uhm.. maybe you don’t realize that most people think that skinned UIs are UGLY and should be avoided like the plague…
Even media players are switching (at last) away from that trend: xine has a gtk2 gui (totem), mplayer has a kde one iirc (gmplayer is still the old skinned mess), music players are more and more “itunes style” apps…
Get out of the skin age…
Bye, Renato
Yes, a specialization of C to make it OO. Not a “conglomerate of all freatures”.
So what did they do to C to make it OO?
You totally mised the point of what I was saying. I did not say that I write procedural programs in OO. All programs can be written procedurally. Does that mean that all programs should be written in C?
No. But I didn’t claim so.
What I said was that OO is an extension of procedural programming.
OO is not an extension of procedural programming. Geez! Where did you learn programming?
Instead of forcing a lot of functionality in one monolithic procedural program, you write lots of simple procedural programs(classes) that do one thing really well and connect them toghether.
Ahem, isn’t that what functions and function pointers are for?
Similar to how UNIX systems work. OO concepts(inheritance, etc.) deal with how these simple procedural programs are connected.
Yes, I know that.
Trivial programs don’t require GUIs.
I see. I guess GCC is trivial then.
GTK requres wrappers to be used in any sane manner. You don’t thing that is useless overhead and bloat?
I use GTK+ without wrappers, what the hell are you moaning about?
As time passes, GTK will become harder to manage simply because C provides poor tools for managing complexity.
Could you be any more vague?
In a couple of years GTK will be replaced (just like Mono is being positioned to replace C for GNOME applications) because it will become too difficult to extend and modify.
What land have you been in? GTK+ was just recently extended and modified from the 1 series to the 2 series.
You see, that’s why tell people to learn procedural practical languages before learning abstract concepts. When someone begins to tell you one can’t reuse C code or it’s not modular, then you know his first language was C++ or Java.
Like my friend says, “When everything is an object, everything remains an object”. These are just concepts and they have nothing to do with language. I could write OO in Fotran, for instance, even though fotran is procedural.
Your compiler, your processor, your machines don’t process codes as object at all. It’s only we humans that use these concepts to make programming more meaningful, or easier for us to grasp, to manipulate or to design.
I could write C code that is object oriented using functions, function pointers and structures easily. It won’t be as polished as using C++, but I’d achieve similar effects and in many instances my code will be cleaner, leaner and more structured.
That’s why when people say one can’t do OO in C, I just laugh. It’s better when people say I’m not good enough to do OO in C than say one can’t do OO in C. The object oriented concepts developed from C. In fact, most kernel programs use object oriented programming. It’s just not glaring because it’s done in C.
Anyway, I’m tired. Have a wonderful day, and continue living in your abstraction.
/me remembers his C++ professor.
Like my friend says, “When everything is an object, everything remains an object”. These are just concepts and they have nothing to do with language. I could write OO in Fotran, for instance, even though fotran is procedural.
Well, technically speaking, an object is just an instance of a class. So how can you create an OO application with a language that doesn’t include support for classes? Sure, you can try to simulate them by having structs that are manipulated by any number of procedures and calling them “objects”, but then the strengths and reasons for using a true OO language (things like data encapsulation, inheritance and polymorphism) are being cast aside.
To me, this:
button.caption = “Click me”
is much more elegant than:
setTitle(button, “Click me”)
and that is an overly simplistic example.
> So what did they do to C to make it OO?
You are hopelessly ignorant. Come back after you have learned what OO is. Then you might be qualified to discuss the issue.
“Have you ever seen a GUI API for an OO language?”
Just look at this fantastic documentation:
http://developer.kde.org/documentation/library/3.0-api/classref/
Not to troll, but GTK can’t beat this sort of quality
If your code is cleaner, leaner and better structured, just how is it not so polished? I think it will NOT be cleaner, because the syntax will be worse, I think it won’t be leaner, because it will be more wordy (the binaries could be leaner, the code won’t), and I think it won’t be better structured because you will have your “methods” grouped by naming conventions instead of syntax.
But hey, that’s just what I think after reading code for 20 years, so what do I know.
Also, you say that some people shoud say they are not good enough to write OO in C.
I say that some people are not good enough to realize writing OO in C may not be such a hot idea.
And yes, many can’t do it very well. If a tool needs some high level of skill to use it, and produces roughly the same output as another who doesn’t, that’s a sign the tool SUCKS compared to the other, dude!
If any moron can write decent OO code in C++ and only 31733 h^x0rz can do it in C, that shows C SUCKS FOR OO PROGRAMMING. You are, in your post, making the case for C++!
But hey, maybe you are not as good making points as you are programming in OO C 😉
Well, technically speaking, an object is just an instance of a class. So how can you create an OO application with a language that doesn’t include support for classes?
Using structures, unions, typedefs and function pointers, I already mentioned that above.
e, you can try to simulate them by having structs that are manipulated by any number of procedures and calling them “objects”, but then the strengths and reasons for using a true OO language (things like data encapsulation, inheritance and polymorphism) are being cast aside.
You are following into the same trap the other fellow and many people fall into. Treating object orientation as a language not as a concept. GTK+ provides encapsulation, inheritance and polymorphism. It can be done in C.
To me, this:
button.caption = “Click me”
is much more elegant than:
setTitle(button, “Click me”)
and that is an overly simplistic example.
That is a matter of taste. I find both of them equally readable.
If your code is cleaner, leaner and better structured, just how is it not so polished? I think it will NOT be cleaner, because the syntax will be worse, I think it won’t be leaner, because it will be more wordy (the binaries could be leaner, the code won’t), and I think it won’t be better structured because you will have your “methods” grouped by naming conventions instead of syntax.
Yes, and I think syntax should remain relatively simple and limited. That’s why I emphasize clean and lean.
Also, you say that some people shoud say they are not good enough to write OO in C.
I say that some people are not good enough to realize writing OO in C may not be such a hot idea.
Prior to the invention of C++, a lot of software engineers, kernel developers, API designers were writing object oriented C, Pascal, Fortran, etc. Again we need to stop thinking language and start thinking concept. GTK+ is an exemplary illustration of concept over language. I have seen too many projects use C++ because their designers thought using an object oriented language automatically meant their project was modular, reusable and cleaner. Language doesn’t dictate either of those. Good preparation, planning and design does. Technically speaking, heavy use of well designed data structures does.
And yes, many can’t do it very well. If a tool needs some high level of skill to use it, and produces roughly the same output as another who doesn’t, that’s a sign the tool SUCKS compared to the other, dude!
Not every can fly an F-16, so I guess an F-16 SUCKS. There’s no excuse for not mastering your tools. Either you are good at it or you suck at it. A proficient and experienced C coder will write anything in C, and with ease. That’s because he has devoted years to mastering, wielding and exploiting the strength of his tools while being cautious of its weaknesses. When someone says you can’t reuse C code, it doesn’t say much about me, I know I can and have, the light of doom is on the person who said so. And it speaks volumes of his understanding of the language.
If any moron can write decent OO code in C++ and only 31733 h^x0rz can do it in C, that shows C SUCKS FOR OO PROGRAMMING. You are, in your post, making the case for C++!
Perhaps I need to make it clear that C++ is the worst object oriented language I’ve used. I am not making the case for any programming language. This whole argument started with someone saying an API was ugly because he didn’t agree with the authors formating style. I simply disagreed. And then it led to all these language wars. I still stand by the fact that GTK+ has a powerful, clean and simply API. Many people arguing against that haven’t used it, which is evident by their comments about what you can and cannot do in C.
I’ve always hated C++ as an OO language. If you want a real OO language get Java, Python, Ada or C#. Unfortunately, I simply hate languages that use VM or runtime environment for system resource efficiency reasons. But the languages I have mentioned are a million times better than C++.
But hey, maybe you are not as good making points as you are programming in OO C 😉
Fortunately, I’m more into embedded stuff, libraries and drivers, where anything above C++ doesn’t cut it. 🙂
> Fortunately, I’m more into embedded stuff, libraries and drivers, where anything above C++ doesn’t cut it.
This explains a lot of your ignorance. Your experience disqualifies you from making any intelligent comments on GUI APIs which are aimed for use in end-user desktop PC applications(not low-level drivers and embedded stuff).
This explains a lot of your ignorance. Your experience disqualifies you from making any intelligent comments on GUI APIs which are aimed for use in end-user desktop PC applications(not low-level drivers and embedded stuff).
Don’t be silly.