Slashdot Mirror
Guillaume Laurent On GTK And The New Inti
KS writes: "Old time GNOME hacker and Slashdot familiar Guillaume Laurent has finally written up an explanation on why he left the GTK-- project. In summary, he disagrees with some of the fundamental features of GTK-- but sees a bright future for Red Hat's Inti. I don't know why but I always find these sorts of things eye opening." Update: 08/10 02:50 PM by H :Guillaume wrote me asking me to mention the an update to the story.
Red Hat wants KDE dead for reasons of revenge.
Red Hat spent a lot of money in the early days rolling out a propretary CDE release that was supposed to be their cash cow. (Tri-Teal CDE). They had it all positioned, along with ApplixWare, etc. to take over the Linux market. Along came KDE and LessTiff, which drew all the energy away from the closed-source stuff that Red Hat had all the shrinkwrapped boxes printed up for at great cost. Red Hat ended up taking a bath as a result, out of reaction they hyped up Gnome as a counter-attack.
All the Tri-Teal boxes probably ended up about 140 feet above the PC Junior parts in the same landfill.
O well. Ray Noorda at Caldera is primarily involved in Linux for revenge purposes, too.
Aaaahhh, but you are aware of it. I reported the inability to create an LS120 boot disk for 6.0, and although I haven't tried it for 6.2, I guess from the above comment that it still isn't fixed.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
#include <objgtk.h>
class MainWin : public Window
{
public:
MainWin();
gint OnDeleteEvent(void);
void OnHelloButtonClicked(void);
private:
Button *hello_button;
};
MainWin::MainWin()
{
SetupTable(3, 3);
SetTitle("Hello, World");
SetUSize(300, 150);
SetPosition(GTK_WIN_POS_CENTER);
hello_button = new Button("Hello!");
hello_button->ConnectClicked(CALLBACK(OnHelloButt
Add(hello_button, 1, 2, 1, 2);
}
gint MainWin::OnDeleteEvent(void)
{
OG_Quit();
return FALSE;
}
void MainWin::OnHelloButtonClicked(void)
{
g_message("Hello!");
}
int main(int argc, char *argv[])
{
OG_Init(&argc, &argv);
MainWin *mainwin = new MainWin;
mainwin->Show();
OG_Main();
return(0);
}
Anyway, as soon as this got on Freshmeat, I received some responses (a first!), some encouraging (including some w/ patches, etc.), and one from Karl admonishing me for duplicating his work and urging me to give up ObjGTK and join the Gtk-- project. Now, Karl was very courteous and he did have some points -- a lot of my complaints were really stylistic issues which could presumably be fixed, and Gtk-- had some features which I could not easily duplicate (at the time they were starting to adopt libsigc++, which Guillaume apparently thinks is badly written, but regardless was a very useful idea which worked perfectly in this context. They also had the aforementioned stack-heap duality, whereas all my widgets were on the heap. The implementation of this was so awful I can barely describe it, let alone duplicate it). ObjGTK, although it was fully documented and somewhat useful, was incomplete (hey, I had only been working on it for two weeks), and Gtk-- had classes for almost every GTK+ type and then some. And so after a few such e-mails, I removed ObjGTK from the net and subscribed to the Gtk-- mailing list.
At this point my C++-wrapper development in Linux was pretty much over. I observed the mailing list for a couple of weeks, decided that the first thing I wanted to do was work on the documentation (at this point Gtk-- had no reference documentation and a couple of short programs acting as a tutorial), and quickly foundered. The source was very hard to work through. The headers seemed to be in three places at once, and the methods themselves were sometimes designed so circumlocutiously that it was almost impossible to tell what they did. It was hard to separate the "real" code which I was supposed to be writing from the code which was auto-generated from the GTK+ header files. And, my naive intentions of "fixing" the style issues were undoable; Gtk--'s conventions were simply too deeply rooted and too at-odds with my "simple"
style of programming.
My last run-in with Linux GUI programming was when I had the urge to continue working with an old program which had a GUI interface. I had originally written it in GTK+, then ported it to ObjGTK+ as a test of the latter's capabilities. Now since ObjGTK was dead, I figured the next logical step would be to re-write it in Gtk--. I downloaded the latest libsigc++ and libgtkmm, and got cracking. The first thing I started to write was the toolbar code. I scanned the Gtk-- documentation, found some methods which seemed appropriate, and started writing. It didn't compile because the methods didn't seem to exist. Flummoxed, I sent a message to the Gtk-- mailing list, and recieved a reply from Karl stating that yes, those methods didn't exist anymore, and giving me an example of the "better" way to write toolbar code, which was basically about 50 lines of horrible template code (in contrast to 40 or so lines of GTK+ code, or 20 of ObjGTK).
That was the last straw for me...not because of the bad documentation or the weird style standards, but because of how much this situation reminded me of the chapter in the "UNIX Hater's Handbook" where the UNIX style (make it easy to program) was contrasted with the Lisp style (make it easy to use). In my mind, Karl had become too obsessed with keeping to his academic theoretical perfection, and had disregarded the thing which make an API worthwhile, namely usability.
Looking back I suppose one could see Gtk-- as a shame, a deplorable situation that should never have happened. Personally, I disagree. When I worked with QT, I found it easy to use but I thought their pre-processor approach was terrible. Libsigc++ was a much more elegant solution to the problem which we have Karl to thank for. Likewise, I heavily disagree with another poster here who claimed that pointers are better than references. Pointers create unsafe interfaces, whereas with a reference you are always guaranteed to be passing an object which actually exists. ObjGTK+ used pointers exclusively, and if I re-did it today I would definitely change that.
I look forward to working with Inti; from the descriptions I've read it sounds like a good balance. I'm glad that it's there now since I no longer have the kind of free time I had in college to work on Open Source projects. Maybe soon I'll reorganize my schedule, subscribe to the Inti mailing list and start pestering them with stylistic issues
-W.W.
"Well it should be obvious to even the most dim-witted individual who holds an advanced degree in hyperbolic topology...
Red Hat wants KDE dead for reasons of revenge.
Two wrongs don't make a right - and this is two wrongs. We don't want KDE dead and we have no reason to take revenge on KDE.
Red Hat spent a lot of money in the early days rolling out a proprietary CDE release that was supposed to be their cash cow.
Sorry, but this isn't true. Proprietary software is not and has never been a major part in Red Hat's business plans.
At that time, there was no free and good user interface available, CDE was a kind of standard, so it got included, because a proprietary solution seemed to be better than no solution at all. We're glad that this is no longer necessary.
They had it all positioned, along with ApplixWare, etc
If we bought ApplixWare, somebody forgot to tell me.
to take over the Linux market
If that was our intention, why would we GPL our installers and permit distributions to just copy Red Hat Linux and add/remove/change some stuff?
Can't be about acceptance - SuSE don't GPL their installer and yet they're widely accepted.
If you had had a look at Red Hat Linux in the last couple of years, you would have noticed that we aren't including any proprietary software with the exception of Netscape (because it's important and there's no good free replacement, though Konqueror and Mozilla are getting there).
We don't want proprietary software.
Along came KDE and Lesstif, which drew all the energy away from the closed-source stuff that Red Hat had and all the shrinkwrapped boxes printed up for at great cost. Red Hat ended up taking a bath as result, out of reaction they hyped up Gnome as a counter-attack.
Entirely untrue. Red Hat chose to support Gnome because of Qt (1.x)'s restrictive license. The Qt 2.x license is not a problem, the old license was.
By the time Qt 2.0 was released and the license problem was fixed, Gnome was already usable and at a point where simply dumping it wouldn't have made sense. (Yes, I personally still prefer KDE, but Gnome isn't bad, and it would be a pity to see it go.).
Next time, please take the time to check the facts before posting.
This message is provided under the terms outlined at http://www.bero.org/terms.html
4 years ago, BeOS was in developers preview. As I remember it, it didn't have a lot of technologies back then. For an example of the BeOS APIs, take a look at/ index.html.
http://www-classic.be.com/documentation/be_book
A deep unwavering belief is a sure sign you're missing something...
This combined with some other really bad experiences with Red Hat (both the company and the software)
;)
Such as? We aren't perfect, but we're trying.
Red Hat will not be happy until it owns the Linux market. Not just in the sense of most market share, but they want all market share.
Entirely untrue.
We'd be stupid if we wanted that, even from a pure business point of view (hey, all those people being paid by Mandrake, SuSE, Caldera and all are FREE developers for us!).
Similarily, why would we GPL all our developments if we wanted to shut everyone else out?
they would have been better off to try to create some great Windows rip off. Then they could make it proprietary.
We could make our installer proprietary. Do we?
We could have made rpm proprietary. Do we?
The day Red Hat starts making proprietary software without a good reason (such as having to do NDAs to be able to get a solution at all, which is bad, but the lesser of 2 evils with the alternative being forcing users on Windoze), I'm out of here, and so are a number of other developers. It won't happen.
This message is provided under the terms outlined at http://www.bero.org/terms.html
If you're writing GUI apps in C++, fltk is the way to go. I've used X, motif, MFC, GTK, Qt, Java Swing, and god knows what else and the only pleasureable experience was with FLTK. It's very fast, very light, very simple, just lets you get on with it.
Qt was pretty good - close second, but it's not LGPL and you need to pay for the windows version.
Fltk is just cleaner. MFC was the worst, closely followed by swing.
http://rareformnewmedia.com/
You know, like most sane people, I use C++. But I don't have any problem with GTK+ being only in C. I just go on writing my C++ code and using the C interface to GTK+. Who needs a C++ wrapper?
On a related note, using C for GTK+ was driven by more than just a love of C. It was also a practical decision because it makes it easier to use GTK with other non C programming languages, such as perl, or TCL. The only major criticism I'd have was that they didn't write a GTK-- style system simultaneously. However, I don't really care about that since I prefer my GTK+ straight anyway.
-- Superlame http://catpro.dragonfire.net/joshua/
Who needs another library that doesn't offer any new functionality? When I have to use GTK+ in C++ applications, I simply wrap the most commonly used components myself. What's the point of making the user obtain yet another library?
Yesterday we were complaining about DLL hell/lack of code reuse, and here we are today talking about another implementation of something that already exists.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
On the other hand, a zillion one-man projects doesn't get us anywhere. And that is what we will get, since there aren't two programmers who agree on everything.
Which means free software programmers should think very hard before staring their own project. Is your own better design ideas really so much better, that they outweight the advantage of sharing the work with other programmers in an existing project? And don't overestimate your own programmimng ability, like most programmers do.
Sometimes the answer is yes. This might be one of them. But most times, it is not.
I just spent much of my free time over the past 2 years writing a landscape generator/modeller (see terraform.sourceforge.net) and I used Gtk-- for it. As such, I think I have some experience dealing with it.
At the time I started writing it, QT was not free enough for me to contribute (application) code for it and plain Gtk programming (in C) required such an insane amount of pointer casts that it was pretty obvious to me that I wanted to avoid it. I think Gtk-- is a very nice toolkit although it requires some discipline as (like Guillaume said), it lets you shoot yourself in the foot in a variety of ways.
That said, I really think Gtk needs a well supported and clean C++ wrapper. I dont care which one it is but I dont want to be faced with the task of rewriting the GUI part of my application every 2 years. This kind of stuff makes me consider using QT, even though I prefer Gtk.
Oh well, this might just be a case where the beauty of open source (lots of options and development in many directions) has come back to haunt me. I dont care what the solution is, but we need something that is the official Gtk C++ wrapper and is guaranteed to be around a few years from now.
The C++ network kit is simply a wrapper for the BSD-based API. The are moving networking into the kernel now, and the API will still be C based (because there is no C++ allowed in the kernel.) The network kit will still be a wrapper for the C based functions.
A deep unwavering belief is a sure sign you're missing something...
I'm still reading. I do understand what I wrote, but I don't know if everyone else does. I've never read Marcel Proust. But that might happen in my personal time.
now we need to go OSS in diesel cars
That would be great. Now if I can just find the time (besides what gets wasted on /. ) for it.
Sounds like a lot of man pages and texinfo files I know :-)
Most of the documentation out there for so much stuff is written with the idea of sequential reading in mind. I don't have the time to do that in most cases, so documentation that gives an introductory concept explanation (without the usual sales talk that most use as introductions), and has all the rest as a well indexed reference, would do better for me (and a lot of people I know).
I still think of what is being compiled to the machine level (carefully thinking about diverse machines) even as I write code in C. I was able to write a set of functions to write and read arbitrary sized chunks of bits (up to the size of a long) and made it not only work on both big endian and small endian platforms with no tests for endianess anywhere, but the two different platforms could even exchange data between them correctly. Sometimes abstractions just get in the way, especially when dealing with a real world.
There's always more than one way to code it in just about any language, especially assembly.
now we need to go OSS in diesel cars
> Qt is already available under a perfectly free > software license.
Yes, but not all Red Hat's customers write free software. Red Hat need a competitive solution for them too. And currently Qt is much more expensive than any of the other widespread GUI tools. You can buy Delphi _and_ C++Builder _and_ Visual C++ (with MFC) for less than the price of a single Qt license.
Ok, here's you first C++ lover's comment :)
You're definitely misguided about the pass-by-reference comment. Sure, pointers have their uses, and sometimes (maybe even often, depending on what you're doing) pointers are the sane choice and references aren't.
But references guarantee you one thing: they always reference something, there's no such thing as a null reference. Functions taking pointer arguments should check for (assert() or properly handle) null pointers. A function taking a reference _knows_ that it's a valid addressable object (object as in struct, simple variable, or whatever).
Besides, why do you mention STL along with ``dangerous interfaces'' ? STL is type-safe, and it's a proven implementation (usually - but there could be bugs in glibc too remember). Using std::map<something> is *a lot* safer than re-implementing your balanced tree every time. Sure you can use glib, but STL is type safe and C-casts/void-pointers aren't.
Did I mention that std::map<foo,bar> will also often be faster than your generic C tree ? if the comparison operator for the foo type is simple (eg. integer compare or similar), it can be (and will be) inlined in the core map implementation, something you cannot do in C without either re-implementing your map every time, or implementing it in a macro. You simply save a function call for every compare - something that is noticable when the compare is a simple operation.
The real problem with C++ is that people tend to think of it as object-oriented C. Well, it is, but it's also *much*much* more. A C programmer trying to bake up a ``pretty'' API i C++ will often fail - we've all seen that. But good interfaces are definitely possible - take a look at STL. And note, that STL is not just object-oriented wrappers, it's a type-safe interface of objects and functions relying heavily on parameterized types, actually allowing you to write non-trivial programs that run as fast, or faster, than equivalent C code.
The other real problem with C++ that I have to admit to, is compilation time. It is the *only* real drawback that I can point my finger at. But I can accept it. When the compiler builds type-safe trees of lists of strings for me, that run as fast as they do, I can accept the extra hardware cost as ``fair''.
FLTK (Fast Light ToolKit) is available at http://www.fltk.org/
-- Floyd
-- Floyd
No.
Looking at the headers available at http://sources.redhat.com/inti/inti-manual/ I see that each class member representing a signal is a SignalProxy, which seems to be quite like the signalling facilities provided by libsigc++. Looking at the definitition of SignalProxy, its connect method is parameterized for both the type of the signalled object and the member being connected to.
--
"Where, where is the town? Now, it's nothing but flowers!"
True. And loops are just glorified gotos when one looks beneath the surface. So? I don't want to look beneath the surface too often.
--
Maybe I'm on crack, but it sounds like RedHat is building a completely new development platform based on GTK+ and compatible at the user level with GNOME. They do not actually have anything more in common than GTK! And it's totally motivated by the KDE/Qt development platform at that.
(Please browse at -1 to read this comment.)
Gtk-- never had the backing of a company like Troll Tech og Red Hat, it was (is) one of these old fashioned free software projects made by volunteers in their spare time. You may laugh at that, but I think they did made some incredible good work, compensating with clever design for the lack of manpower. Sometime driven hackers can do that.
I'm happy the design will be reused in Inti, it probably represents a much larger part of the work put into Gtk-- than the main code.
I haven't used Gtk-- in anything but a pilot project, but it as a joy to use. Compared to Qt i liked that it was just a GUI library (which Inti unfortunately won't be), that it used STL, and that it didn't depend on a preprocessor. I believe Gtk-- has always been driven by technical goals, not commercial or political goals, so the Qt license or "Stallmans decrees" have never been important. Inti will probably be driven by commercial goals, but if they keep the good design from Gtk-- and add full-time programming ressources, that will be fine with me.
If Troll Tech get bought out, Qt becomes GPL-compatible New-style BSD licensed. If this were to happen, the last valid objection other than NIH syndrome that Americans have to Qt/KDE would falter, and Linux would instantly have a very cool, de-facto standard C++ development platform. I would predict that moc would be banished in fairly short order, and a somewhat libsigc++ standrd C++ solution fitted in. surely a large company such as IBM could afford such a buyout.
Choice of masters is not freedom.
As an amateur developer, I have encountered tools where an interface was provided, but every FAQ, on-line doc, and expert on the tool would tell you to avoid it. It always makes me wonder why in hell the interface was built in the first place.
Many of these dangerous interfaces may be there by accident, or because the original designer did not forsee the danger in their inclusion. But that still leaves them as bad interfaces; you should try to avoid providing such interfaces in a new library or tool.
My $2E-2 (Actually, I think it's Miguel's $0.02, because I hadn't thought about it until I read his paper yesterday :-)
SteveInheritance and polymorphism may not be the only features of C++, but they are the important ones. First, templates are a fairly good idea, but they often get one into trouble. A lot of people use templates when they really shouldn't. Also, templates and inheritance overlap a little bit, and the uses of each should be more clear.
The reason that the kernel, support, netowork and storage kits are non-OO are because it makes more sense that way. That's a big thing in a well designed API. YOu have a unifying concept, but don't use it in places where it really doesn't make sense. It really doesn't make sense to have an object simply for translation loading purposes. You could put them into an object, but then you end up with an object that has members that have no other relation aside from the fact that they are in the support kit. For more important than that, though, is the fact that many functions in those kits need to be accessible from kernel drivers, where C++ isn't really allowed.
A deep unwavering belief is a sure sign you're missing something...
I think Guillaume's nice discussion about some of the drawbacks of Gtk-- mixed memory management policy is fine as far as it goes, but I would like to add some points.
First, there are really many alternatives to choose to decide what kind of memory management to use for a C++ program. Telling is that the C++ standardization committee could only agree on one memory management class (auto_ptr<>). It uses gross hacks for ensuring the type checker does the right thing (And I'm not convinced it's right as it is).
Ok, to get to my real point, here is a list of all memory management policies I could remember having seen used in C++:
1) explicit deallocation (programmer responsible for deleting; e.g. C++ plain pointers)
2) strict ownership (e.g. a creation function returning a smart pointer )
3) transferrable ownership (e.g. auto_ptr)
4) Stack (objects created first are deleted last)
5) Static allocation (memory for object always exists)
6) no deallocation (sometimes you just can leave memory as leaks)
7) garbage collection (The garbage collector takes care of deallocation)
8) Cluster allocator (see "Ruminations on C++" by Andrew Koenig; basically objects are deallocated in clusters, and whenever the cluster is deallocated, all the objects in it are deallocated as well).
9) reference counting with explicit ref/unref.
10) Intrusive reference counting (the objects being pointed to contain a reference count)
11) Non-intrusive reference counting (the reference count is separate from the object, e.g. like boost shared_ptr template)
12) Handle-Body idiom (you write a specialized handle for managing memory for your class)
13) Container-managed (like Gtk-- manage())
14) Containment (like Gtk-- containment based solution)
15) Library-owned objects (library only returns references without ownership to users)
16) Distributed garbage collection
17) Evictor (the objects are maintained in a fixed size array, and the least used objects are deleted when new objects are created that would o verflow the array When the object is next needed after being deleted, it's re-created).
18) Copy semantics (you always do a copy)
19) Lazy copy semantics (you make a copy when you have to)
20) Reaper (The memory is scanned at fixed intervals for freed-up objects, and any objects marked to be deleted are freed).
21) Shared memory allocation
22) Persistent allocation (You mmap() some disk space for your objects, and leave it there to allow it to be used on subsequent invocations of your program)
23) Class allocator (overloading operator new and operator delete for allocating small objects efficiently)
24) Self-managed allocation (the object deallocates itself)
25) Singleton (The object is allocated when it's first used, and deallocated at the end of the program)
26) Mixture of several of the above policies
The design space for memory allocation of C++ objects is really HUGE. So it's no wonder there is some disagreement on what is the preferred way to handle memory management, especially as many of these alternatives are actually contradictory in that it is hard to combine many of these strategies.
I personally prefer auto_ptr combined with a non-intrusive reference counted pointer class and creation functions that return memory wrapped in auto_ptr. You do need some solution for putting references to objects in containers, plain auto_ptr doesn't work for that.
-- Esa Pulkkinen
What are you talking about "vaporware"? Inti is mostly written, you can download the code from the web site and see for yourself.
Ah, but the 'func(*(int*)NULL);' part is illegal in and of itself (in C and C++), or more accuratly undefined. Most implmentations of C++ references just lazy evaulate the core dump :-)
There really is no such thing as a NULL reference really means
I don't find those things to be a huge advantage for references. Nor do I find that they make my code cleaner looking (except as a return type so I can have lvalue functions). I find it a modest disadvantage that I don't have the "out of bound" signaling path of passing a NULL to mean something "specail" (default value, or skip that part, or something).
Left to my own devices I use pointers. Then again I kinda grew up on C (and APL, but we'll not mention that again). On the other hand I really really love the STL. One of the few saving graces of C++. And a huge one at that. Frequently even signifagantly faster then C.
I started to learn Gtk-- because the rival, Qt, wasn't C++. In a visceral sense, something that required a pre processor (moc), just wasn't C++.
So, to me, something that leveraged tempates to acomplish what was, in Qt, little more that a macro hack, was a bonus-- though I never did look at the internals.
I learned C++ by first tackling the STL, and then moving on to classes and inheritance. Gtk-- fit my (odd) style more so than Qt...
As for Gtk+: yuck...
Eh? I wrote a whole (modestly) big Gtk-- program and never used strings other the the standard C++ string, and standard C char*'s. Never used a vector other then the STL's. Gtk-- might (or might not) have it's own string and vector classes, but I definitly didn't do anything to avoid their use, and yet I'm also not using them.
since I am now posting in the 'company' of a Red Hat employee will probably end up with a lawsuit on my hands to boot
No way, unless you're inventing this to harm our reputation (which I don't think, shit happens).
Sorry for the trouble with ApplixWare - this is probably too long ago to track down and see what caused it, so I'll take it for a typical "shit happens" thing and make sure it gets fixed at least now.
For the software, all I can say is that I can't reproduce it and neither can our other customers - if you send me some details of the hardware (and the version of Red Hat Linux you were using), I'll check what's causing the problems. (We have upgraded some drivers; it may be a problem with one of them).
These problems should go into bugzilla, where actual developers can read them and take care of them. (Unless you have a support contract, the support people will help you with installation; some of them aren't qualified to fix bugs.)
Make crappy software
We're trying not to do that - and I'd really like to know if any of your problems are still occuring with the 7.0 beta version.
blame the user when it doesn't work
I guess every software company is a bit guilty about this one - if something works perfectly for you, then someone tells you it doesn't work, what would you blame first, if you don't know how much the other person knows about the piece of software?
screw the user if you can make a buck
If that was our intention, we'd be making proprietary software.
and sling mud when you have no facts
That's Microsoft's job, not ours.
This message is provided under the terms outlined at http://www.bero.org/terms.html
NOTE: This rant isn't about anyone in particular in this story, it's just a rant I've been meaning to get off my chest for a long time.
Until we can get out of the kindergarten-like pi$sing matches that characterise anyone in a "scene", we're sunk.
There's ABSOLUTELY NOTHING WRONG with multiple languages, multiple toolkits, multiple libraries, etc. No one library, language, or whatever can do everything. Although I'm sure there's a sarky reply coming that C# is the best thing since sliced bread.
I'm not making any judgments about the people involved in this, but part of me really wishes that the whole "Qt people hate GNOME people, LINUX people hate FreeBSD people, Inti people hate GTK-- people" thing would stop.
Being "Lord High God" of a given project gives one a certain measure of prestige, sure. But shouldn't hackerdom be about skills, not who's got final signing authority over Project X. There's a HAPPY MEDIUM between anarchy and "well, if you aren't going to recognise my genius I'm going to go play somewhere else, and take my ball with me."
You see this in ANY crowd, from volunteer paramedics to Goths to football players to insurance salesmen.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
I'm sorry, but... it's my private time.
FS development is *not* done by a corperation. A manager can't tell me what I should do (and neither can a zillion users).
If I want to start a new project, even if it doesn't further any imaginary goal of *other* people, even if a zillion other programmers have done it before me, and maybe even better; quite frankly, that's my time and my choice.
Je ne parle pas francais.
No, no, no, god no. Read last months' C++ users Journel, or Strousup (damm those forginers and their hard to spell names!).
As "NULL References" are not defined, making one can do anything. They can crash you right as they are created. They can crash you when you try to take their address.
What you show works on some implmentations, but is a programming error, every bit as much as using memory after you free it is (which normally works until you allocate more memory). But any garbage collected implmetation, or an implmentation that does anything odd with references (perhaps because the CPU is odd, or the ABI) can show the breakage, even if you try to check for the NULL reference, because the bug is not the use of the NULL reference, but the mere existance, the bug starts when you create the reference, and an implmentation can crash at any moment after (or as) you do it, attempts to find and not use the NULL reference are just masking the bug, and not allways masking it.
Expect a future compiler rev to break such code. Expect porting the code to make the bug come live.
In other words, you are living the life of a VAX programmer that assumes '0 == *NULL' works, and will forever work (and that 'strlen(NULL) == 0' works as well). Soon everyon will want your code ported to that hot new Sun3 platform, and you will have to find and fix all those damm bugs.
What I am saying is that Red Hat is spending their development money to make Red Hat (and Linux in general, since that's their strategy) more attractive to developers of both free and non-free applications.
Troll Tech is spending their ressources to make their product (Qt) more attractive to their customers, and part of their strategy is to give it away for free to people who wouldn't be able to pay anyway.
Both strategies make commercial sense, and both strategies benefit both the free software community, and Linux(/Unix) users in general.
I don't see the need to take side, or declare one for the moral winner.
You need more tinfoil ... the orbital mind-control laser (in pink now!) appears to be leaking through.
Redhat releases all of their software GPL. TriTeal and CDE date to before there were ANY desktop environments for Linux, beyond FVWM.
RedHat didn't include KDE/QT until the licensing was sorted out, because they support the GPL.
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
If by your remark you intended to imply and mean that programming in C (as opposed to C++) is insane, then fine, I am Happily insane.
I learned C programming not from the books (though I had both K&R and H&S handy as references to look up stuff) but from actually diving in and doing it. Having started in 1982, I've had quite a bit of time to progress to the point I am today with C programming skills. I also had the foundation of several years of assembly programming before then.
I did not learn C from the books. I didn't read them. They didn't make sense the way they were written. Obviously they were not written for me, a very experienced programmer from the mainframe legacy with already several languages of experience. Those books appeared to be written for someone somewhere between "newbie" and "academic". They were not written for a working programmer.
I have yet to find any programming book for any programming language which is written for an audience with specific experiences to draw on, and specific questions that need to be answered about the new language. I was lucky with C because it became quite clear with a few experiments with pointers, and dumping the generated assembly code, and testing out some kernel calls (in TOPS-20 at the time), that C was just "portable assembly code". Neither K&R nor H&S explained things that way. Nor has any other book explained the basis and concepts of their language in terms all experienced programmers could catch on to quicky.
Learning a new language by the book is for newbies only!
Now how does this affect C++? Unlike my relation between assembly and C, C++ has no already existant basis to learn it from. While I do object oriented design and then code it in assembly (did that even before I learned C) and in C, I do not comprehend that way C++ has approached the OO principles in its language design. I have tried languages like CLU (from back in the early 1980's) and Java, but they were too slow to commit to and I soon abandoned them because by projects were real, not abstract. None of the C++ books I have looked at are oriented to explaining C++'s particular OO language philosophy. Even Stroustrup's own book didn't cover it the way I needed it.
While these books probably would work fine for a "newbie" who can spend the next couple years trying, failing, and learning from failure, they do no good for me. I cannot just stop all programming and spend the time as a "newbie" to learn something new. Every time I might even think of something I could do in C++ (or some other language I might learn) it is so temping to go do it in C because I can whip it right out faster than in the new language, debug it quickly, and have it totally kick ass on the computer.
While I do know of some specific shortcomings of C++ and could use those to say that C++ is not the best choice of language, I also know that shortcomings exist in C as well. But I have worked around them. Specific shortcomings aren't the point, anyway. If you want to know why it is so many people have not transitioned from C to C++, might I suggest surveying C++ programmers and ask them how many years experience they have had programming in C, and compare that with the results of a similar survey of C programmers. You can start with my 18 years experience programming in C.
If you still want to convert C programmers to use C++ then I suggest writing a book ... a short one, that explains every concept in C++ ... not just language syntax, but practical concepts ... clearly and concisely. Don't drag it out for newbies; focus on experienced C programmers. Explain how it is that C++ takes basic OO design concepts and puts them into a programming language. Explain how C++ behaves with each concept at higher abstract as well as lower real levels. Include a full reference section. And make sure there are examples of whole programs, not just snippets everywhere. Maybe then you might see more converts. But until someone does this, I doubt you will see very many.
Now if you do want to see an example of how I program in C, visit http://phil.ipal.org/freeware/avlmap/ and take a look. I suppose this merits my "insane" label.
now we need to go OSS in diesel cars
Inti looks strikingly similiar to QT with its use of Slots/Signals. I don't think RedHat will ever be happy until QT and the whole KDE project is dead, and that is a shame. The licensing issue isn't really a factor anymore, it has been declared "open source" by the powers that be. Now it seems RedHat is more interested in saving face.
For an object oriented framework class library, QT is pretty darn nice. Not just in theory, but in actuallity (see KDE 2.0 beta). Its had several years to mature as well, whereas Inti is brand new and will undoubtedly go thru all the same growing pains.
At any rate...I find it hard to get excited about yet another framework (Inti) when there is a perfectly acceptable and mature one available (QT).
Sig (appended to the end of comments you post, 120 chars)
How much would Troll Tech sell QT for? Or how much would Troll Tech cost? Or how much would it cost for them to GPL QT? Every day they're probably getting more and more expensive. You could score a lot of points.
The author keeps harping on how much he likes Qt, yet was working on C++ wrappers for Gtk. There was a disagreement about how to wrap Gtk, so he leaves. But does he join the new Inti project, or does he happily code wth Qt and Kde while working for RedHat? I thought RedHat didn't approve of non-free tools like Qt.
You mean there were only 3 people at the project's peak working on Gtk-- ? Now there is one, plus this new Inti project which hasn't produced anything by white papers so far.
I bet Qt is rolling on the floor.... Why should Gtk-- team and Gnomers have to study Qt to do their own C++ ? I thought Qt was non-free and off limits to Gnomers. How much of Qt have they copied? There are certain ethics to reverse enginering such as you don't look at the source even if it is available.
What's wrong with plain old C with the object system imposed by Gtk+? I thought that it was Stallman's decree to use plain old C allocating objects with pointers, which works for most people.
How many apps have been written with Gtk-- to date? Would some of those who have used Gtk-- in applications which have progressed beyond the pre-alpha stage care to comment?
How many open source project suffer from this type of problem? They decide to be increadibly flexible, and try and please everyone, but in the end they end up being too complicated. Commercial products have external pressurers (eg, deadlines) that help them avoid this.
Not that I'm saying flexibility is bad - just flexibility should be measured against ease of implementaion, ease of use and maintainability.
It duplicates parts of the standard library. For programmers who already uses the standard library, it means you have to deal with two string classes, two vector classes, etc. If nothing else, that is ugly.
> But references guarantee you one thing: they
> always reference something, there's no such thing
> as a null reference.
Not quite true:
void func (int &a)
{
a += 5;
}
func(*(int*)NULL);
That should crash quite reliably =]
-Matt
-Cheetah
"*(int*)NULL" isn't legal C++, although most compilers accept it.
Too bad, their discussions on the gtk-- lists where always interesting and insightful, even if somewhat longish.
The thing is that there are too many eostoric features in C++ that would be better left out. Why the hell is new implemented with exceptions? Is there any sane reason for doing tis? Why the hell do references exist. It's like Microsoft, which defines LPSOMETHING as SOMETHING*. People should be clear when the thing they are using is a pointer. The best way to use C++ is really as C with classes. for example, in an API, use it for overloadable functions, single inheritance, and not having to typedef structs. Otherwise, it is too insanely compicated to use. (For a good example of C++ gone bad, take a look at MFC) Although, not all C++ interfaces are crappy. Take a look at Be's. It actually makes sense, they use standard C functions when it makes sense, and there are no multply inherited templated virtual base classes.
A deep unwavering belief is a sure sign you're missing something...
I wrote a few simple programs with gtk--. I can say that its design does have some flaws, but you could still write some nice code with it.
:) Sorry, but I implemented expression templates and I just don't like ugly compile-time hacks any more. Hard to maintain.
First, the program you wrote was plain C++, that's one advantage over poor QT and MFC. That meant you weren't constrained by a foolish macro/preprocessing system. (The preprocessor that was used building the library is no problem, IIRC) The signaling system also was not at all bad, although it is another bloated C++ hack.
OTOH, I found a lot of things that gtk-- simply didn't care covering. I've had to plug in lots of C calls in my proggys to get the right behaviour. Anyway, it seemed to work. But try writing a drawing program in gtk-- and you're going to blow up. Another very disappointing mistake is in the apparent lack of documentation. This goes for the GTK+/GNOME people on their high horses as well:
NO LIBRARY WITHOUT COMPLETE DOCUMENTATION!!
Get it? That's why Qt still seems to hold the edge despite the zillion disadvantages that it entertains. When you're writing with Qt, if you have a bit of experience with MFC, you can have your browser at your documentation and dive right in.
Thanks,
--exa--
Typical example of a C++ project. I see that everywhere. Untrained people that try to do thing the most flexible way and end with a mess. Stack vs. Heap vs. Member based object is typical. STL integration is about the same (ie: much work for nothing but dangerous interfaces). Or trying to do pass-by-reference interfaces (how dangerous. Pointers are much cleaner, if you wasnt pass-by-reference, because both caller and callee _knows_ what is happening). He doesn't talk about it, but there are probably a few const methods in there and throw clauses. Maybe even operator overloading, in which case we have about all the misfeatures of C++ used in a single place.
I know that many of C++ lovers here will disagree, but it is just because they don't ran into those walls _yet_.
C++ gave them enough rope to that to hang themselves *and* hang their users. At least Guillaume Laurent understand part of the issue now...
What makes me wonder is its feeling that C is obsolete. That's fun: the C implementation is working very well, and all the C++ wrappers failed...
Cheers,
--fred