Gtk and C++, again.
mlw
I LOVE the idea of Gnome. I think open OS and operating environments are
the right way to go for the future of computers. Free and standard roads
helped allow the automobile industry to thrive. I want to use Gnome,
but, the more I look at the Gtk, I shake my head and say "What were they
thinking?" It is clear that C++ would have made the whole thing much
easier to implement, much more efficient, and more fault tolerant.
The paranoid type checking code that is necessary on almost every call
is unnecessary with C++. Implementing virtual functions in structure
memory is very inefficient when a large number of classes are
instanciated. Data corruption can lead to untraceable program errors
because the virtual tables in the structures are not in read-only
memory. Very thin (2 lines) C wrappers would have made external linkage
easy for non-C languages.
As I look through files like gtktypeustils.c, I think to myself I'd fire
they guy who designed this.
This is not a religious troll. I am a firm believer in the right tool
for the job. C++ has many many flaws, and I am very careful not to use
many of its dubious features, but, this is the one thing that C++ does
really well. Using C for this is a bone headed move. Why the olympian
effort in avoiding it?
It is like a guy bent on using an old dial type torque wrench when he
could use a 'click' type. One is harder, requires more care, and is, in
general, less accurate. C++ was designed, explicitly, for this type of
architecture. I just don't get it.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
Navindra Umanee
you and me. Take a look at http://developer.kde.org/. Unless you
want to write proprietary applications, of course, it which case you
might want to think twice about choosing.
-N.
--
"These download files are in Microsoft Word 6.0 format. After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft website]
< http://www.cs.mcgill.ca/~navindra/editors/ >
J. Mark Brooks
applications with GTK+ and GDK. The author, Eric Harlow, has this
to say about the choice of C over C++:
"Deriving widgets from each other seems to call out for the use of
C++ in writing GTK+. C was chose for GTK+ for several reasons. C
is the primary language for developers on Linux. C is also more
portable than C++ is and has been standardized longer. C++ is only
now becoming standardized, and not all C++ compilers work on the
same set of code. When GTK+ was started, C++ standardization was
still a pipe dream. C++ has come a long way, but it still has some
problems working across multiple compilers on multiple platforms."
He then makes a vague reference to the GTK-- C++ wrapper project
for GTK+.
I see the foregoing explanation as being somewhat contradictory. The
clear indication is that C was chosen because existing Linux developers
use C. However, it then talks about standardization issues across
platforms. My impression is that the "real" reason that C/Objective C
was chose for GTK+ is that GTK+/Gnome relies heavily on the GNUStep
project, which is derived from NextSTEP.
My position is that the choice of GTK+ or QT is going to be determined
ultimately by the language you choose to use to do your programming.
I have heard generally very positive things about both libraries, but
QT was unquestionably developed from the ground up as a C++ GUI
library. I've not had the opportunity to use GTK--, and perhaps there
is someone who has who can comment on its utility in comparison to
straight GTK+ or QT. With the announcement of the new licensing for
QT, I don't see licensing as an issue anymore.
I will say that if the focus is on getting existing Linux/Unix
developers to develop GUI apps for Linux on a traditional OpenSource
GPL model, then GTK+/Gnome is the way to go, but if there is any
hope to have developers who have focused on NT/Win9x to port their
applications or develop new ones for Linux, QT looks a lot more like
what they would be used to using than GTK+/Gnome.
--
****************************************
* J. Mark Brooks, Attorney at Law *
* P.O. Box 39, Randleman, NC 27317 *
* law.o...@jmbrooks.net *
* ICQ# 31732382 *
* http://www.jmbrooks.net/law.html *
****************************************
mlw
>
> Not to start a flame war or anything but it sounds like KDE/Qt is for
> you and me. Take a look at http://developer.kde.org/. Unless you
> want to write proprietary applications, of course, it which case you
> might want to think twice about choosing.
>
> -N.
That's the thing isn't it. I do not think the Gtk is a well designed
environment. I shudder to use it. Gnome, is not good enough for
professional quality work. It is clear that the code was written by
competent people, but, the architecture is misguided.
I do not want to use QT because I believe the underlying environment in
an OS should be open and free. Paid for by professional dues,
contribution or ancillary services.
So it is a rock and a hard place, QT is better architecture but not GPL,
Gnome is GPL but poor architecture.
mlw
>
> I've picked up the brand new New Riders book on developing Linux
> applications with GTK+ and GDK. The author, Eric Harlow, has this
> to say about the choice of C over C++:
>
> "Deriving widgets from each other seems to call out for the use of
> C++ in writing GTK+. C was chose for GTK+ for several reasons. C
> is the primary language for developers on Linux. C is also more
> portable than C++ is and has been standardized longer. C++ is only
> now becoming standardized, and not all C++ compilers work on the
> same set of code. When GTK+ was started, C++ standardization was
> still a pipe dream. C++ has come a long way, but it still has some
> problems working across multiple compilers on multiple platforms."
> He then makes a vague reference to the GTK-- C++ wrapper project
> for GTK+.
This is gibberish by someone ignorant of C++. C++ has been around,
standard enough for real projects for almost 10 years. The things that
these guys are doing could have been done with CFront and still compile
today.
>
> I see the foregoing explanation as being somewhat contradictory. The
> clear indication is that C was chosen because existing Linux developers
> use C. However, it then talks about standardization issues across
> platforms. My impression is that the "real" reason that C/Objective C
> was chose for GTK+ is that GTK+/Gnome relies heavily on the GNUStep
> project, which is derived from NextSTEP.
>
> My position is that the choice of GTK+ or QT is going to be determined
> ultimately by the language you choose to use to do your programming.
> I have heard generally very positive things about both libraries, but
> QT was unquestionably developed from the ground up as a C++ GUI
> library. I've not had the opportunity to use GTK--, and perhaps there
> is someone who has who can comment on its utility in comparison to
> straight GTK+ or QT. With the announcement of the new licensing for
> QT, I don't see licensing as an issue anymore.
The problem with a Gtk wrapper is that all the failings I mentioned
still exist, just with the added overhead of the wrappers.
>
> I will say that if the focus is on getting existing Linux/Unix
> developers to develop GUI apps for Linux on a traditional OpenSource
> GPL model, then GTK+/Gnome is the way to go, but if there is any
> hope to have developers who have focused on NT/Win9x to port their
> applications or develop new ones for Linux, QT looks a lot more like
> what they would be used to using than GTK+/Gnome.
This is the problem. Normally GPL or GNU stuff is well written and well
designed. To have to choose between GPL or LGPL and QT's license due to
poor technology is bad.
It is clear these guys had a prejudice toward C++ and didn't even
consider it. C++, on the whole, can be a disgusting environment,
however, when its feature set is used in moderation, in essence as a 'C'
with classes, it can be a better C.
Craig Kelley
> That's the thing isn't it. I do not think the Gtk is a well designed
> environment. I shudder to use it. Gnome, is not good enough for
> professional quality work. It is clear that the code was written by
> competent people, but, the architecture is misguided.
Where, exactly?
My first Gnome app was up and running in hours -- and I have only
casually dabbled with gtk. I love the design, it is very well
thought-out and no so abstract that it hurts. It is particularly
suited to mapping onto other languages.
I love GNOME. It provides *real* services for easy programming.
--
The wheel is turning but the hamster is dead.
Craig Kelley -- kell...@isu.edu
http://www.isu.edu/~kellcrai finger i...@inconnu.isu.edu for PGP block
Craig Kelley
[snip about gtk and GNOME]
> It is clear these guys had a prejudice toward C++ and didn't even
> consider it. C++, on the whole, can be a disgusting environment,
> however, when its feature set is used in moderation, in essence as a 'C'
> with classes, it can be a better C.
So? Use KDE then. (or help make gtk-- better)
Navindra Umanee
> I love GNOME. It provides *real* services for easy programming.
KDE/Qt has no *real* services? Something is missing perhaps?
Navindra Umanee
> So it is a rock and a hard place, QT is better architecture but not GPL,
> Gnome is GPL but poor architecture.
Arthur
> That's the thing isn't it. I do not think the Gtk is a well designed
> environment. I shudder to use it. Gnome, is not good enough for
> professional quality work. It is clear that the code was written by
> competent people, but, the architecture is misguided.
> I do not want to use QT because I believe the underlying environment in
> an OS should be open and free. Paid for by professional dues,
> contribution or ancillary services.
> So it is a rock and a hard place, QT is better architecture but not GPL,
> Gnome is GPL but poor architecture.
I haven't really tried to write anything that was 'Gnome' or 'KDE',
but I have used both GTK and Qt, and I think you're wrong on both
counts. I really think the Qt license issues have been resolved -
I don't see a problem with writing free software with Qt, and in
fact I'm using it now and like it very much.
OTOH, I have used Gtk. I have some minor complaints, but
if I wasn't using C++, I'd be happy to use Gtk. I basically
agree with your original comment to the extent I think Gtk
would be cleaner if written in C++, but I think that's a
minority view. The majority of Gtk users are happier to
have it in C.
Architecturally I think both Gtk and Qt are very nicely done.
Licensing, IMHO, is a non-issue. Both are well-documented
and the source is easy enough to follow. Performance is
fine. Conceptually they're similar enough that you can
switch between them fairly easily.
Arthur
Arthur
> J. Mark Brooks wrote:
> > My position is that the choice of GTK+ or QT is going to be determined
> > ultimately by the language you choose to use to do your programming.
> > I have heard generally very positive things about both libraries, but
> > QT was unquestionably developed from the ground up as a C++ GUI
> > library. I've not had the opportunity to use GTK--, and perhaps there
> > is someone who has who can comment on its utility in comparison to
> > straight GTK+ or QT. With the announcement of the new licensing for
> > QT, I don't see licensing as an issue anymore.
> The problem with a Gtk wrapper is that all the failings I mentioned
> still exist, just with the added overhead of the wrappers.
The reason I avoided the wrappers is at the time I was
using Gtk it was hard enough to keep up with new Gtk
releases. On top of that, you'd also have the problem
of synchronizing the wrapper release to the Gtk release,
and Gtk-- wasn't keeping pace with Gtk at all. IMHO, it
would be simpler to use Gtk+ just as it is, even in a
C++ program. Uglier, but simpler.
Arthur
perr...@my-dejanews.com
mlw <ma...@mohawksoft.com> wrote:
> I'm sorry, but, I have to vent here.
>
> I LOVE the idea of Gnome. I think open OS and operating environments are
> the right way to go for the future of computers. Free and standard roads
> helped allow the automobile industry to thrive.
Ok.
> I want to use Gnome,
> but, the more I look at the Gtk, I shake my head and say "What were they
> thinking?"
You don't have to mess at all with Gtk internals just to use Gnome. Even as an
application developer you don't need to mess with the vast majorit of the Gtk
internals.
> It is clear that C++ would have made the whole thing much
> easier to implement, much more efficient, and more fault tolerant.
That's not clear.
> The paranoid type checking code that is necessary on almost every call
> is unnecessary with C++.
Application developers can eliminate active type checking by #define
GTK_NO_CHECK_CASTS, after their program is fully debugged if they think it's
a performance issue/
> Implementing virtual functions in structure
> memory is very inefficient when a large number of classes are
> instanciated.
How are virtual functions implemented in C++ object code? Effectively the same
way.
> Data corruption can lead to untraceable program errors
> because the virtual tables in the structures are not in read-only
> memory.
The way Gtk+ is designed application developers have no reason to access
virtual functions tables. I'm not even sure if there's a way they can access
them.
And you are completely ignoring Gtk's signal handling mechanism, which is
tied to it's virtual function system. So when you call gtk_signal_connect(),
you are actually adding another handler to a virtual function. This makes the
signal mechanism very flexible.
> Very thin (2 lines) C wrappers would have made external linkage
> easy for non-C languages.
That would be backwards
> As I look through files like gtktypeustils.c, I think to myself I'd fire
> they guy who designed this.
Good! he'd get a better job for a more decent employer for more money!
A Gtk application developer has no need to be reading anywhere beyond
gtktypeustils.h
> This is not a religious troll.
I'm starting to wonder...
> I am a firm believer in the right tool
> for the job. C++ has many many flaws, and I am very careful not to use
> many of its dubious features, but, this is the one thing that C++ does
> really well. Using C for this is a bone headed move. Why the olympian
> effort in avoiding it?
If you don't like the way Gtk is designed, try Qt. If you don't like the Qt
license, check out
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
and pick one you like. Otherwise, write your own toolkit. Lashing out at Gtk
developers, saying they "should have" won't accomplish anything. You've been
involved with OSS long enough to know that.
Perry
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
perr...@my-dejanews.com
jmbr...@jmbrooks.net wrote:
> My impression is that the "real" reason that C/Objective C
> was chose for GTK+ is that GTK+/Gnome relies heavily on the GNUStep
> project, which is derived from NextSTEP.
Dead wrong!! GTK+/Gnome has no reliance on, or affiliation with the GNUStep
project or Next. Nor is GTK+ in Objective C, although I think there's a
binding.
> With the announcement of the new licensing for
> QT, I don't see licensing as an issue anymore.
Unless you want to write closed source apps or private apps for your company.
> I will say that if the focus is on getting existing Linux/Unix
> developers to develop GUI apps for Linux on a traditional OpenSource
> GPL model, then GTK+/Gnome is the way to go, but if there is any
> hope to have developers who have focused on NT/Win9x to port their
> applications or develop new ones for Linux, QT looks a lot more like
> what they would be used to using than GTK+/Gnome.
Or maybe Gtk--. I don't know, I've never developed on NT/Win9x, so I wouldn't
know which would be more similar.
Craig Kelley
> > I love GNOME. It provides *real* services for easy programming.
>
> KDE/Qt has no *real* services? Something is missing perhaps?
Oh, not at all. I didn't say anything about KDE. I even used KDE as
my desktop for a year (up until GNOME-0.98 -- which was a better
release than 1.0, but anyway.....)
Craig Kelley
> Dead wrong!! GTK+/Gnome has no reliance on, or affiliation with the GNUStep
> project or Next. Nor is GTK+ in Objective C, although I think there's a
> binding.
Actually, both guile and objective C are used throughout.
Python is also used a bit in the standard distribution.
> Or maybe Gtk--. I don't know, I've never developed on NT/Win9x, so I wouldn't
> know which would be more similar.
I have. I'll take something as bad as Xforms over MFC (and I have done
that!).
Craig Kelley
> You don't have to mess at all with Gtk internals just to use
> Gnome. Even as an application developer you don't need to mess with
> the vast majorit of the Gtk internals.
Ummm, have you ever written a GNOME application?
It is heavily gtk, and you had better understand it before you start
programming for GNOME (at least there is documentation for GTK and a
tutorial -- GNOME is basically "look at the current source" right now).
In fact, most (all?) GNOME calls resemble or *are* GTK calls.
[snip]
Craig Kelley
> > my desktop for a year (up until GNOME-0.98 -- which was a better
> > release than 1.0, but anyway.....)
>
> FWIW, I gave GNOME 1.0 a shot. It was a painful install even though I
> was using precompiled binaries and I'm too not happy about the
> stability (the two could be related). Is the help documentation
> missing? I can't seem to access any by pressing any of the Help
> buttons. gmc can't do root window icons without a GNOME window
> manager. Can I add a delay to the panel menus? They pop up a bit too
> fast.
You need to install the RPMs in the noarch/ folder (includes documentation
and audio files).
I don't know if you can add a delay. Try changing your GTK theme
to something like Gradient (gtk.themes.org) and it will slow it
down a bit. :)
Craig Kelley
> In article <m1g17ic...@inconnu.isu.edu>,
> Craig Kelley <i...@inconnu.isu.edu> wrote:
> > perr...@my-dejanews.com writes:
> >
> > > You don't have to mess at all with Gtk internals just to use
> ^^^^^^^^^
> > > Gnome. Even as an application developer you don't need to mess with
> > > the vast majorit of the Gtk internals.
> ^^^^^^^^^
>
> Internals!! I am talking about the library internals. Do you have to
> mess with glibc internals to write an app that uses glibc. Do you
> have to understand kernel internals to make system calls. No.
Mea culpa. I misunderstood your claim.
[snip]
> Considering I had no gui programming experience before starting this app I
> think it attests to your point that gtk/gnome provides an easy application
> framework.
The only fault (so far), and where mlw may have a point, is in
debugging the GTK_ cast macros. It gives you a line inside the gtk
source file where something happened, and so one must either
extrapolate what when wrong or dig into the internals of it.
It doesn't bother me.
[snip]
perr...@my-dejanews.com
> > project or Next. Nor is GTK+ in Objective C, although I think there's a
> > binding.
>
> Actually, both guile and objective C are used throughout.
>
> Python is also used a bit in the standard distribution.
They may be, thru bindings, but only for some of the applications. I've been
periodically compiling the core libraries glib, Gtk+, Imlib, ORBit, and
gnome-libs from CVS on a development machine they are all in C.
Navindra Umanee
> Navindra Umanee <navi...@cs.mcgill.ca> writes:
>
>> > I love GNOME. It provides *real* services for easy programming.
>>
>> KDE/Qt has no *real* services? Something is missing perhaps?
>
> Oh, not at all. I didn't say anything about KDE. I even used KDE as
Okay. :) I misinterpreted the emphasis on "real".
> my desktop for a year (up until GNOME-0.98 -- which was a better
> release than 1.0, but anyway.....)
FWIW, I gave GNOME 1.0 a shot. It was a painful install even though I
was using precompiled binaries and I'm too not happy about the
stability (the two could be related). Is the help documentation
missing? I can't seem to access any by pressing any of the Help
buttons. gmc can't do root window icons without a GNOME window
manager. Can I add a delay to the panel menus? They pop up a bit too
fast.
Metal theme is q00l though and at least Wanda The Fish works.
Navin.
Navindra Umanee
> manager.
This is false. The icons appear when I click on the entry in the
tasklist. Some weird interaction betweem KWM and gmc, I suppose.
-N.
perr...@my-dejanews.com
^^^^^^^^^
> > Gnome. Even as an application developer you don't need to mess with
> > the vast majorit of the Gtk internals.
^^^^^^^^^
Internals!! I am talking about the library internals. Do you have to mess with
glibc internals to write an app that uses glibc. Do you have to understand
kernel internals to make system calls. No.
You don't need to mess with how functions are implemented in files like
gtktypeutils.c, gtkmarshal.c etc. etc., unless you are 1) wanting to
contribute to the gtk+ team or 2) acedemically interested in how the guts of
library works.
To use an API (Application Programming *Interface*), you need to know the
*interface*, not the internals. So for gtk+ you should be reading the header
files for various widgets, and occasionally a source file when you need to
understand more about a public method. But you shouldn't mess with private
methods. And you don't need to read gtktypeutils.c, even if you are writing
your own widget.
>
> Ummm, have you ever written a GNOME application?
Yes.
http://www.open-systems.com/gtksamba.html
It will compile for either gtk-only or gnome, depending on what ./configure
detects on your system. I will probably drop gtk-only support in the next
release since Gnome 1.0 is out.
I am currently working on a guru widget that I will use to assist users in
setting up complex Samba configurations such as NT domains, encrypted
passwords, WINS, etc., as the existing guru widget in libgnomeui is not
flexible enough. Lately though, I've been bogged down lately by two graduate
courses plus a full time job. I hope to get a release out over soring break,
but my girlfriend wants some time with me. Oh well.
Anyways, I've had over 10,000 people have download the sources since I've
realeased it. Plus it's been put on debian (potato) by a debian developer,
plus a contributor is packaging an rpm for it uploading it to redhat contribs
(on an old version of gtk though).
Considering I had no gui programming experience before starting this app I
think it attests to your point that gtk/gnome provides an easy application
framework.
I've got alot more work to do, though. Hopefully I'll get it done this summer.
> It is heavily gtk, and you had better understand it before you start
> programming for GNOME (at least there is documentation for GTK and a
> tutorial -- GNOME is basically "look at the current source" right now).
Yes, I've been thru many Gtk/Gnome source files. I've even installed lxr on my
local CVS tree to make it easier to browse it. But I've never read
gtktypeutils.c until mlw mentioned it today. And that's what I was responding
to.
> In fact, most (all?) GNOME calls resemble or *are* GTK calls.
Yes. Same is true for KDE/Qt.
David M. Cook
>That's the thing isn't it. I do not think the Gtk is a well designed
>environment.
Do you have any specifics?
I quite like Gtk. I've used it mostly from Python, though.
Just so you know where I'm coming from, I loathe C++, though I would use it
if I had to. IMO, most people that are bullish on C++ are unaware of better
designed languages (no, I'm not talking about mediocre junk like Java). The
only advantage (though it's a big one) of C++ is that it has more market
support.
With several C++ wrappers for Gtk to choose from, I'm not sure why you care
that the underlying libraries are compiled C. If you really object to C,
you should get the X folks to rewrite Xlib.
Dave Cook
David M. Cook
>Actually, both guile and objective C are used throughout.
They are used a bit, not "throughout". A search through the GNOME 1.0 RPMS
shows that gnumeric and some games depend on guile. I don't see any objc
dependencies, but I believe that the printer config app is written in objc.
>Python is also used a bit in the standard distribution.
I don't know of any pygnome apps that come with the distribution, though the
pygnome modules are now included.
Dave Cook
mlw
>
> In article <36E143C6...@mohawksoft.com>,
> mlw <ma...@mohawksoft.com> wrote:
> > I'm sorry, but, I have to vent here.
> >
> > I LOVE the idea of Gnome. I think open OS and operating environments are
> > the right way to go for the future of computers. Free and standard roads
> > helped allow the automobile industry to thrive.
>
> Ok.
>
> > I want to use Gnome,
> > but, the more I look at the Gtk, I shake my head and say "What were they
> > thinking?"
>
> application developer you don't need to mess with the vast majorit of the Gtk
> internals.
You do if you want to write a program that does something.
>
> > It is clear that C++ would have made the whole thing much
> > easier to implement, much more efficient, and more fault tolerant.
>
> That's not clear.
Sure it is. All the type checking required comes from having an
entrypoint not attached to the object.
>
> > The paranoid type checking code that is necessary on almost every call
> > is unnecessary with C++.
>
> Application developers can eliminate active type checking by #define
> GTK_NO_CHECK_CASTS, after their program is fully debugged if they think it's
> a performance issue/
I'm not sure about this, I will have to take a second look. But removing
the safety for efficiency does not answer the fact that C++ would have
both.
>
> > Implementing virtual functions in structure
> > memory is very inefficient when a large number of classes are
> > instanciated.
>
> How are virtual functions implemented in C++ object code? Effectively the same
> way.
I C++ virtual tables are implemented on a class basis, not an object
basis. If you 1000 object of type foo, you have only one foo virtual
table.
>
> > Data corruption can lead to untraceable program errors
> > because the virtual tables in the structures are not in read-only
> > memory.
>
> The way Gtk+ is designed application developers have no reason to access
> virtual functions tables. I'm not even sure if there's a way they can access
> them.
Anyone can scribble over the structures, they are allocated in
read-write memory. An uninitialized pointer or wrong pointer can blast
away at your vtables without causing a fault. Ouch!
>
> And you are completely ignoring Gtk's signal handling mechanism, which is
> tied to it's virtual function system. So when you call gtk_signal_connect(),
> you are actually adding another handler to a virtual function. This makes the
> signal mechanism very flexible.
Yes, but again, problematic. Don't get me wrong, taking the offset from
the start of an object to the function entry point is cool, but, I can
see less savvy developers really screwing things up.
>
> > Very thin (2 lines) C wrappers would have made external linkage
> > easy for non-C languages.
>
> That would be backwards
If the library were developed in C++, and had 'C' wrappers, it would be
more efficient and easier to use/implement.
>
> > As I look through files like gtktypeustils.c, I think to myself I'd fire
> > they guy who designed this.
>
> Good! he'd get a better job for a more decent employer for more money!
My reference would be: "Competent, really bright, but needs more
exposure to alternative technologies."
> A Gtk application developer has no need to be reading anywhere beyond
> gtktypeustils.h
>
> > This is not a religious troll.
>
> I'm starting to wonder...
It really isn't a troll. I just think that the Gtk would be better
written in C++. I haven't heard any one put forth a rational for a C
implementation that is based on any awareness of C++.
In essence, C++ can be used as a 'C' with classes and can be very
efficient. Just having a .cpp at the end of the file does not give the
compiler brain damage. It is when you 'push the envelope' so to speak,
with C++ features, like templates, that programs get bloated.
As long as the class hierarchy is simple enough, with logical limits on
inheritance, C++ rocks.
> > I am a firm believer in the right tool
> > for the job. C++ has many many flaws, and I am very careful not to use
> > many of its dubious features, but, this is the one thing that C++ does
> > really well. Using C for this is a bone headed move. Why the olympian
> > effort in avoiding it?
>
> If you don't like the way Gtk is designed, try Qt. If you don't like the Qt
> license, check out
I have tried Qt, I like it. However, I sympathize with the Gnome effort
and wish it were different.
>
> http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
>
> and pick one you like. Otherwise, write your own toolkit. Lashing out at Gtk
> developers, saying they "should have" won't accomplish anything. You've been
> involved with OSS long enough to know that.
I have been toying with my own toolkit, but, that is a waste of
resources. Unfortunately, Gtk has that "See, I don't need no stinken
C++' feel to it.
Mark Metson
>
> http://www.troll.no/qpl/
>
I do not see what is the difference between the QPL
and the GPL / GLPL ? What does it buy to use the QPL
in place of one or other of those? More hits for their
websie one day when the QPL becomes more widespread
than the GPL ? I mean whats the point? The distinction?
David M. Cook
>It really isn't a troll. I just think that the Gtk would be better
>written in C++. I haven't heard any one put forth a rational for a C
>implementation that is based on any awareness of C++.
I still don't understand what your objection to using a C++ wrapper is.
This is not even an issue on other platforms where that is the norm (C++
wrapper over a C API.)
Dave Cook
Arthur
> >written in C++. I haven't heard any one put forth a rational for a C
> >implementation that is based on any awareness of C++.
>
> This is not even an issue on other platforms where that is the norm (C++
> wrapper over a C API.)
Specifically for GTK, at the time I used it the Gtk--
wrappers were incomplete, GTK was changing rapidly,
and the wrappers weren't keeping up. The situation may
have changed - I'm not following GTK closely anymore.
While I found Gtk very easy to use, Gtk-- looked
relatively difficult to me, especially from the
standpoint of extending it or deriving new widgets.
It seemed it would be a lot more work to go back
into Gtk C code and make changes and then carry
that forward to a C++ wrapper with any consistency.
It appeared simpler to mix the Gtk C code with
my own C++, but that makes for a somewhat ugly
design and eliminates what I think are the advantages
for me in programming in C++.
Speaking as someone who does a lot of C++, Gtk
would have been a lot cleaner for me if written
in C++. I realize that's a minority view and I
realize Gtk was not written to meet my specific
needs. I don't mean this as a criticism of Gtk,
but there really isn't any reason it couldn't
have been written in C++ with C wrappers. C
programmers seem to find that an abhorent
idea - C++ programmers are just as unhappy
with the reverse.
Mostly I'm happy the Gtk developers made a
choice and stuck with it, rather than endlessly
debating the issue and not producing any code
at all. I still benefit from Gimp and all of
the other apps written with Gtk. Obviously
the way Gtk is written hasn't hindered its
use - I just have different preferences.
I doubt that I'll ever write code specifically
for KDE or GNOME, so the choice of widget sets
isn't that important to me on that basis. I
like Gtk but I like Qt just as well, and I
think I get better C++ code by using it instead
of Gtk.
Arthur
David M. Cook
>Specifically for GTK, at the time I used it the Gtk--
>wrappers were incomplete, GTK was changing rapidly,
>and the wrappers weren't keeping up. The situation may
>have changed - I'm not following GTK closely anymore.
Gtk-- has pretty much caught up, so this is not an issue now. I haven't
tried Gtk--, so I can't comment on the rest of your post.
Dave Cook
perr...@my-dejanews.com
mlw <ma...@mohawksoft.com> wrote:
> perr...@my-dejanews.com wrote:
> >
> > In article <36E143C6...@mohawksoft.com>,
> > mlw <ma...@mohawksoft.com> wrote:
> > > I'm sorry, but, I have to vent here.
> > >
> > > I LOVE the idea of Gnome. I think open OS and operating environments are
> > > the right way to go for the future of computers. Free and standard roads
> > > helped allow the automobile industry to thrive.
> >
> > Ok.
> >
> > > I want to use Gnome,
> > > but, the more I look at the Gtk, I shake my head and say "What were they
> > > thinking?"
> >
> > You don't have to mess at all with Gtk internals just to use Gnome. Even as
an
> > application developer you don't need to mess with the vast majorit of the
Gtk
> > internals.
>
> You do if you want to write a program that does something.
Well I have, and I haven't had to go thru gtktypeutils.c. You don't have to go
that deeply just to write apps. To use an API (Application Programming
*Interface*), you need to know the *interface*, not the internals. Do you have
to understand kernel internals to make system calls. No.
> >
> > > It is clear that C++ would have made the whole thing much
> > > easier to implement, much more efficient, and more fault tolerant.
> >
> > That's not clear.
>
> Sure it is. All the type checking required comes from having an
> entrypoint not attached to the object.
You can turn the checking off after your program is debugged if you want to.
It's not needed.
> >
> > > The paranoid type checking code that is necessary on almost every call
> > > is unnecessary with C++.
> >
> > Application developers can eliminate active type checking by #define
> > GTK_NO_CHECK_CASTS, after their program is fully debugged if they think it's
> > a performance issue/
>
> I'm not sure about this, I will have to take a second look. But removing
> the safety for efficiency does not answer the fact that C++ would have
> both.
True, but I said *after* debugging. So if you think the effect is significant,
turn it off for stable releases of your app.
>
> >
> > > Implementing virtual functions in structure
> > > memory is very inefficient when a large number of classes are
> > > instanciated.
> >
> > How are virtual functions implemented in C++ object code? Effectively the
same
> > way.
>
> I C++ virtual tables are implemented on a class basis, not an object
> basis. If you 1000 object of type foo, you have only one foo virtual
> table.
So does Gtk. Look at a header file for widget. The ObjectClass table is
separate. Only once instance is made when the first instance of the class is
created. You can see that if you walk thru what happens when a widget is
created. Serveral internal functions, and the class_init function, are called
only once for each object when the fisrt instance of the object is created.
> >
> > > Data corruption can lead to untraceable program errors
> > > because the virtual tables in the structures are not in read-only
> > > memory.
> >
> > The way Gtk+ is designed application developers have no reason to access
> > virtual functions tables. I'm not even sure if there's a way they can access
> > them.
>
> Anyone can scribble over the structures, they are allocated in
> read-write memory. An uninitialized pointer or wrong pointer can blast
> away at your vtables without causing a fault. Ouch!
And the likelyhood of that happeniing is??? Hasn't happened to me yet.
> >
> > And you are completely ignoring Gtk's signal handling mechanism, which is
> > tied to it's virtual function system. So when you call gtk_signal_connect(),
> > you are actually adding another handler to a virtual function. This makes
the
> > signal mechanism very flexible.
>
> Yes, but again, problematic. Don't get me wrong, taking the offset from
> the start of an object to the function entry point is cool,
Hah?? What offset??
> but, I can
> see less savvy developers really screwing things up.
How?? Whats so hard about gtk_signal_connect()?
> >
> > > Very thin (2 lines) C wrappers would have made external linkage
> > > easy for non-C languages.
> >
> > That would be backwards
>
> If the library were developed in C++, and had 'C' wrappers, it would be
> more efficient and easier to use/implement.
Prove it. Generally, C++ is considered less efficient than C.
> >
> > > As I look through files like gtktypeustils.c, I think to myself I'd fire
> > > they guy who designed this.
> >
> > Good! he'd get a better job for a more decent employer for more money!
>
> My reference would be: "Competent, really bright, but needs more
> exposure to alternative technologies."
He wouldn't use your reference. He just give the guy a copy of the gimp and
gnome say it uses my toolkit. The interviewer would never read a line of his
code.
> > A Gtk application developer has no need to be reading anywhere beyond
> > gtktypeustils.h
> >
> > > This is not a religious troll.
> >
> > I'm starting to wonder...
>
> It really isn't a troll. I just think that the Gtk would be better
> written in C++. I haven't heard any one put forth a rational for a C
> implementation that is based on any awareness of C++.
They have, and it's a tired overdone debate. Some people differ with it and
they always will. That's why we have choice in the OSS world.
[snip]
perr...@my-dejanews.com
Craig Kelley <i...@inconnu.isu.edu> wrote:
>
> The only fault (so far), and where mlw may have a point, is in
> debugging the GTK_ cast macros. It gives you a line inside the gtk
> source file where something happened, and so one must either
> extrapolate what when wrong or dig into the internals of it.
Ah..now I see, perhaps that's why mlw was nosing around in gtktypeutils.c.
When you get one of those errors, it means one of your casts was invalid.
Nosing around it gtktypeutils.c wont tell you where the bad cast was in your
code. But you can allways run gdb to find out exectly where it occured in the
context your code.
o r c e l l . p o r t l a n d . o r . u s
Mark Metson <ma...@knotwork.com> wrote:
>Navindra Umanee wrote:
>>
>> http://www.troll.no/qpl/
>>
>
>I do not see what is the difference between the QPL
>and the GPL / GLPL ?
I'd suppose the QPL explicitly gives you the right
to buy out of the licensing terms if you wish to
use a QPL'ed product for an object-code-only product.
____
david parsons \bi/ And it probably doesn't have all the
\/ political commentary enbedded in it.
Donovan Rebbechi
>Navindra Umanee wrote:
>>
>> http://www.troll.no/qpl/
>>
>
>I do not see what is the difference between the QPL
>in place of one or other of those? More hits for their
>websie one day when the QPL becomes more widespread
>than the GPL ? I mean whats the point? The distinction?
The main restriction is that with QT, you can buy your way out of
releasing the source ( I mean, the troll guys have to eat ... )
with the GPL, you can't use the code without releasing the source
(unlike the LGPL which allows you to link proprietry apps to it )
Unfortunately, the QPL still seems to have this silly restriction that
you have to release the pristine official QT source , and can only release
modifications in the form of patches, etc.
What I am unclear about is this: can you distribute a binary RPM that is
built from a modified source tree if you source RPM contains the
original source tree plus your patch ? ( I mean, can you release a
binary that is not the original troll version as long as you include
their source + your patch ? )
--
Donovan Rebbechi <elf...@pegasus.rutgers.edu>
http://pegasus.rutgers.edu/~elflord/
Web designer for Independence -- Linux for the Masses
http://www.independence.seul.org/
Karl Nelson
:> I've picked up the brand new New Riders book on developing Linux
:> applications with GTK+ and GDK. The author, Eric Harlow, has this
:> to say about the choice of C over C++:
:>
:> "Deriving widgets from each other seems to call out for the use of
:> C++ in writing GTK+. C was chose for GTK+ for several reasons. C
:> is the primary language for developers on Linux. C is also more
:> portable than C++ is and has been standardized longer. C++ is only
:> now becoming standardized, and not all C++ compilers work on the
:> same set of code. When GTK+ was started, C++ standardization was
:> still a pipe dream. C++ has come a long way, but it still has some
:> problems working across multiple compilers on multiple platforms."
:> He then makes a vague reference to the GTK-- C++ wrapper project
:> for GTK+.
: This is gibberish by someone ignorant of C++. C++ has been around,
: standard enough for real projects for almost 10 years. The things that
: these guys are doing could have been done with CFront and still compile
: today.
That is not pure gibberish. As one of the authors of the the gtk--
widget set I can tell you that C++ is at this time still not
anywhere close to being a standard. Despite the publication of
the standard, the level of support varies wildly from one compiler
to the next. This is clearly the case you can see between Qt and
Gtk--. Qt started earlier and had to use a metacompiler to support the
signal/slot model. We started later and used templates. However,
no all compilers can support our system. For example, we are now
dropping support for gcc 2.7.2.
:> I see the foregoing explanation as being somewhat contradictory. The
:> clear indication is that C was chosen because existing Linux developers
:> use C. However, it then talks about standardization issues across
:> platforms. My impression is that the "real" reason that C/Objective C
:> was chose for GTK+ is that GTK+/Gnome relies heavily on the GNUStep
:> project, which is derived from NextSTEP.
:>
:> My position is that the choice of GTK+ or QT is going to be determined
:> ultimately by the language you choose to use to do your programming.
:> I have heard generally very positive things about both libraries, but
:> QT was unquestionably developed from the ground up as a C++ GUI
:> library. I've not had the opportunity to use GTK--, and perhaps there
:> is someone who has who can comment on its utility in comparison to
:> straight GTK+ or QT.
The utility of Gtk-- is about equal to that of gtk+ at this point.
It is actually much easier to derive a new widget in gtk-- than
gtk+ because all of the C++ mechanisms are now working.
There are a few know bugs in the coverage. Namely, the gtk+ virtual
function system is incompatible with C++. This has resulted in
bad behavior on signal calls that have a return code. However, this
problem is being addressed at the gtk+ level.
As to the utility compared to Qt, that is a harder problem. The
gtk+ toolset is still young and have not developed to good printer,
canvas, drawing tool integration. Thus there are many different
interfaces for the different parts. Qt seeks to provide portablity
without STL. So comparing Qt and gtk-- is a hard thing.
Gtk-- seeks to have no dependencies (within the user code) and Qt
seeks to provide all the tools the user needs. If you feel your
widget set should provide all your tools then you will find gtk--
inadequite. If you want to bridge a good number of tools together,
you may find Qt's types confining. This is a philosophical and
not a technical issue.
:> With the announcement of the new licensing for
:> QT, I don't see licensing as an issue anymore.
: The problem with a Gtk wrapper is that all the failings I mentioned
: still exist, just with the added overhead of the wrappers.
Actaully that would be largely incorrect. The typechecking in
Gtk+ is insignificant to the overhead of supporting execeptions in
C++. It has been well noted that Qt runs much faster when compiled
without exceptions. However, C++ is properly expected to handle
exceptions properly, so removing that support is dangerous.
Second, implementation has more to do with the final output speed.
For example, people have done comparisions between Gtk+ and Qt on
the basis of speed and found Gtk+ (signals) to be faster. This means that
even with a wrapper, gtk+ would likely be faster. In fact gtk--
uses a proxy scheme that accelerates signals by avoiding the gtk+ system
unless the receiver of the signal is a gtk object. Thus our signals
emit even faster.
In most cases the wrapper reverts to nothing more than a single
function call. Since we are talking about a widget set and not
a tight interloop, an extra function call is insignificant compared
to the time it takes for X commands to get to the screen.
--Karl
Gtk-- Contributor
Karl Nelson
: mlw wrote:
:
:
:> The problem with a Gtk wrapper is that all the failings I mentioned
:> still exist, just with the added overhead of the wrappers.
: The reason I avoided the wrappers is at the time I was
: using Gtk it was hard enough to keep up with new Gtk
: releases. On top of that, you'd also have the problem
: of synchronizing the wrapper release to the Gtk release,
: and Gtk-- wasn't keeping pace with Gtk at all. IMHO, it
: would be simpler to use Gtk+ just as it is, even in a
: C++ program. Uglier, but simpler.
Gtk-- is now currently in sync with Gtk+. Further, if
you are trying to keep up with the Gtk+ cvs then you
are either one of the people working on gtk+ or very foolish.
The gtk+ development tree moves very fast. For all but
the few doing work on it, it should be avoided.
As for gtk+ in C++ being simpler, I would expect that statement
not to be true. The gtk+ signal system does not connect to
well to a C++ object. Therefore, you must add static callback
points to connect to your classes. Then when one of those objects
is deleted you have to handle that as well. Basically, if you
are really doing good solid C++, you would have to rewrite good
chunks of gtk-- to use C++ without constrains. Several people
have told me as such.
Then again YMMV. You are always free to go your own way.
If you do find major problems with the Gtk-- system please
mail us. We are happy to hear about it.
--Karl
Gtk-- Contributor
mlw
I agree, the fringe areas of C++ are questionable, but, in my post - the
notion of 'C' with classes has been very stable for some time. The GTK
could well have been done with C++ as 'C' with classes, and been much
easier to implement and use.
>
> :> With the announcement of the new licensing for
> :> QT, I don't see licensing as an issue anymore.
>
> : The problem with a Gtk wrapper is that all the failings I mentioned
> : still exist, just with the added overhead of the wrappers.
>
> Actaully that would be largely incorrect. The typechecking in
> Gtk+ is insignificant to the overhead of supporting execeptions in
> C++. It has been well noted that Qt runs much faster when compiled
> without exceptions. However, C++ is properly expected to handle
> exceptions properly, so removing that support is dangerous.
Again, I use C++ to the extent that it is a 'C' with classes and tight
syntax checking. Exception handling kills performance only when you use
try/catch blocks, not on normal function implementation. If you put
try/catch blocks in every function, of course your code will be slow.
>
> Second, implementation has more to do with the final output speed.
> For example, people have done comparisions between Gtk+ and Qt on
> the basis of speed and found Gtk+ (signals) to be faster. This means that
> even with a wrapper, gtk+ would likely be faster. In fact gtk--
> uses a proxy scheme that accelerates signals by avoiding the gtk+ system
> unless the receiver of the signal is a gtk object. Thus our signals
> emit even faster.
I have not looked at Qt, but, if it uses exceptions as a normal error
return path they screwed up. Exceptions are just that, places where
exceptional circumstances are taken care of. All too often, developers
get lazy and use exception handling as a normal error return path. Duh!
no wonder C++ gets a bad rep.
>
> In most cases the wrapper reverts to nothing more than a single
> function call. Since we are talking about a widget set and not
> a tight interloop, an extra function call is insignificant compared
> to the time it takes for X commands to get to the screen.
My argument is that the Gtk should not have been written in C, period. I
know people are going to take this as a personal insult, but, it is not
intended to be. It is a professional critique of a technology by someone
with over 15 years of professional software development. We may disagre
and we can debate it, but, it is not an insult.
Karl Nelson
: Karl Nelson wrote:
:> That is not pure gibberish. As one of the authors of the the gtk--
:> widget set I can tell you that C++ is at this time still not
:> anywhere close to being a standard. Despite the publication of
:> the standard, the level of support varies wildly from one compiler
:> to the next. This is clearly the case you can see between Qt and
:> Gtk--. Qt started earlier and had to use a metacompiler to support the
:> signal/slot model. We started later and used templates. However,
:> no all compilers can support our system. For example, we are now
:> dropping support for gcc 2.7.2.
: I agree, the fringe areas of C++ are questionable, but, in my post - the
: notion of 'C' with classes has been very stable for some time. The GTK
: could well have been done with C++ as 'C' with classes, and been much
: easier to implement and use.
Templates which are a requirement for the type checking you are
discussing are definately still a fringe area. If you are just
trying to look at the concept of C++ style classes, then you
will find that it can be done in C with only a small ammount of
difficulty. That is hardly a huge gain for the pain that C++ libraries
cause.
Other things that I have found to be faulty ammoungst compilers
include typedefs in classes, templates in classes, inlines in templates,
namespaces, mutable support, template copy constructors, template
friends, template ambiguity, exception handling, STL string and list
class ambiguities and portable name mangling.
I work with C++ all the time and have no bias against it. These
just happen to be the limitations of current compilers.
:> Actaully that would be largely incorrect. The typechecking in
:> Gtk+ is insignificant to the overhead of supporting execeptions in
:> C++. It has been well noted that Qt runs much faster when compiled
:> without exceptions. However, C++ is properly expected to handle
:> exceptions properly, so removing that support is dangerous.
: Again, I use C++ to the extent that it is a 'C' with classes and tight
: syntax checking. Exception handling kills performance only when you use
: try/catch blocks, not on normal function implementation. If you put
: try/catch blocks in every function, of course your code will be slow.
If you haven't read the book More Effective C++ by Meyers, I would
suggest you go pick up a copy. There is a good discussion of the
cost of compiler features and what you have to pay for in using
C++. The heart of this is that exceptions is NOT a pay as you go
proposition. For all but the most advanced compilers you must
have exception deallocation blocks after each function block. This
is incase you get an exceptions and happens regardless of whether
a single try/catch block appears anywhere in your code. The estimated
slow down caused by this is given as 5-10% slower on identically
code. (This is a YMMV thing, I have seen C++ code run faster than
identical C code, but then again I have also seen the opposite.)
:> Second, implementation has more to do with the final output speed.
:> For example, people have done comparisions between Gtk+ and Qt on
:> the basis of speed and found Gtk+ (signals) to be faster. This means that
:> even with a wrapper, gtk+ would likely be faster. In fact gtk--
:> uses a proxy scheme that accelerates signals by avoiding the gtk+ system
:> unless the receiver of the signal is a gtk object. Thus our signals
:> emit even faster.
: I have not looked at Qt, but, if it uses exceptions as a normal error
: return path they screwed up. Exceptions are just that, places where
: exceptional circumstances are taken care of. All too often, developers
: get lazy and use exception handling as a normal error return path. Duh!
: no wonder C++ gets a bad rep.
I have not personally looked at the code of Qt for legal reasons.
But I can guess that they implemented using string comparisions and
table operatations. This technique although very flexible is slow.
But then again we are talking about a widget kit so speed is only
important if the user notices it.
If you want to see a signal/slot technique that does not use this
type of technique (uses direct template binding) check out the
Gtk-- source code or the new signal/slot library Libsigc++ located
as modules in the gnome cvs tree.
cvs -d :pserver:anon...@anoncvs.gnome.org:/cvs/gnome co libsigc++
(This code is intended for general use not just widget sets.)
:> In most cases the wrapper reverts to nothing more than a single
:> function call. Since we are talking about a widget set and not
:> a tight interloop, an extra function call is insignificant compared
:> to the time it takes for X commands to get to the screen.
: My argument is that the Gtk should not have been written in C, period. I
: know people are going to take this as a personal insult, but, it is not
: intended to be. It is a professional critique of a technology by someone
: with over 15 years of professional software development. We may disagre
: and we can debate it, but, it is not an insult.
It is not an insult, but it is definately debatable. C is the
lowest common denominator of all languages. If they
were intending to have maximum portablity then they probably made
the right decision.
--Karl
Gtk-- Contributor
mlw
>
> mlw <ma...@mohawksoft.com> wrote:
> : Karl Nelson wrote:
> :> That is not pure gibberish. As one of the authors of the the gtk--
> :> widget set I can tell you that C++ is at this time still not
> :> anywhere close to being a standard. Despite the publication of
> :> the standard, the level of support varies wildly from one compiler
> :> to the next. This is clearly the case you can see between Qt and
> :> Gtk--. Qt started earlier and had to use a metacompiler to support the
> :> signal/slot model. We started later and used templates. However,
> :> no all compilers can support our system. For example, we are now
> :> dropping support for gcc 2.7.2.
>
> : I agree, the fringe areas of C++ are questionable, but, in my post - the
> : notion of 'C' with classes has been very stable for some time. The GTK
> : could well have been done with C++ as 'C' with classes, and been much
> : easier to implement and use.
>
> Templates which are a requirement for the type checking you are
> discussing are definately still a fringe area. If you are just
> trying to look at the concept of C++ style classes, then you
> will find that it can be done in C with only a small ammount of
> difficulty. That is hardly a huge gain for the pain that C++ libraries
> cause.
Why on earth would templates be required in C++ if the GTK can be
implemented in 'C'?
>
> Other things that I have found to be faulty ammoungst compilers
> include typedefs in classes, templates in classes, inlines in templates,
> namespaces, mutable support, template copy constructors, template
> friends, template ambiguity, exception handling, STL string and list
> class ambiguities and portable name mangling.
Name mangling is not an issue when a C wrapper is used. I do not use and
do not recommend templates if you want your code to portable. The
features you are talking about are outside the "C with classes"
argument.
>
> I work with C++ all the time and have no bias against it. These
> just happen to be the limitations of current compilers.
The fringe areas of C++, are yes, unreliable. The notion of "C with
classes" is, and has been, reliable.
>
> :> Actaully that would be largely incorrect. The typechecking in
> :> Gtk+ is insignificant to the overhead of supporting execeptions in
> :> C++. It has been well noted that Qt runs much faster when compiled
> :> without exceptions. However, C++ is properly expected to handle
> :> exceptions properly, so removing that support is dangerous.
>
> : Again, I use C++ to the extent that it is a 'C' with classes and tight
> : syntax checking. Exception handling kills performance only when you use
> : try/catch blocks, not on normal function implementation. If you put
> : try/catch blocks in every function, of course your code will be slow.
>
> If you haven't read the book More Effective C++ by Meyers, I would
> suggest you go pick up a copy. There is a good discussion of the
> cost of compiler features and what you have to pay for in using
> C++. The heart of this is that exceptions is NOT a pay as you go
> proposition. For all but the most advanced compilers you must
> have exception deallocation blocks after each function block. This
> is incase you get an exceptions and happens regardless of whether
> a single try/catch block appears anywhere in your code. The estimated
> slow down caused by this is given as 5-10% slower on identically
> code. (This is a YMMV thing, I have seen C++ code run faster than
> identical C code, but then again I have also seen the opposite.)
I don't read programming books anymore. I have yet to see one in the
last 5 years that wasn't much more than a rewording of online docs or
the language spec. The only answer is dump the code and take a look. I
don't agree with you.
>
> :> Second, implementation has more to do with the final output speed.
> :> For example, people have done comparisions between Gtk+ and Qt on
> :> the basis of speed and found Gtk+ (signals) to be faster. This means that
> :> even with a wrapper, gtk+ would likely be faster. In fact gtk--
> :> uses a proxy scheme that accelerates signals by avoiding the gtk+ system
> :> unless the receiver of the signal is a gtk object. Thus our signals
> :> emit even faster.
>
> : I have not looked at Qt, but, if it uses exceptions as a normal error
> : return path they screwed up. Exceptions are just that, places where
> : exceptional circumstances are taken care of. All too often, developers
> : get lazy and use exception handling as a normal error return path. Duh!
> : no wonder C++ gets a bad rep.
>
> I have not personally looked at the code of Qt for legal reasons.
> But I can guess that they implemented using string comparisions and
> table operatations. This technique although very flexible is slow.
> But then again we are talking about a widget kit so speed is only
> important if the user notices it.
This is speculation, don't bother.
>
> :> In most cases the wrapper reverts to nothing more than a single
> :> function call. Since we are talking about a widget set and not
> :> a tight interloop, an extra function call is insignificant compared
> :> to the time it takes for X commands to get to the screen.
>
> : My argument is that the Gtk should not have been written in C, period. I
> : know people are going to take this as a personal insult, but, it is not
> : intended to be. It is a professional critique of a technology by someone
> : with over 15 years of professional software development. We may disagre
> : and we can debate it, but, it is not an insult.
>
> It is not an insult, but it is definately debatable. C is the
> lowest common denominator of all languages. If they
> were intending to have maximum portablity then they probably made
> the right decision.
Again, I disagree.
David M. Cook
>My argument is that the Gtk should not have been written in C, period.
There's really no point in arguing about it's implementation at this late
date. Are you arguing that those who are using it now are misguided?
>intended to be. It is a professional critique of a technology by someone
>with over 15 years of professional software development.
So you have to tools to do more than critique.
Dave Cook
Karl Nelson
:> : notion of 'C' with classes has been very stable for some time. The GTK
:> : could well have been done with C++ as 'C' with classes, and been much
:> : easier to implement and use.
:>
:> Templates which are a requirement for the type checking you are
:> discussing are definately still a fringe area. If you are just
:> trying to look at the concept of C++ style classes, then you
:> will find that it can be done in C with only a small ammount of
:> difficulty. That is hardly a huge gain for the pain that C++ libraries
:> cause.
: Why on earth would templates be required in C++ if the GTK can be
: implemented in 'C'?
You said that you wanted to get away from the runtime type
checking being done by GTK. That would require templates.
If you want to still to runtime type checking, yes you can
do gtk in C++. However, the gains of strong type checking
are completely lost.
: Name mangling is not an issue when a C wrapper is used. I do not use and
: do not recommend templates if you want your code to portable. The
: features you are talking about are outside the "C with classes"
: argument.
But they are well within the realm of what do you want from
a language for GTK to get the benifits of C++.
:> If you haven't read the book More Effective C++ by Meyers, I would
:> suggest you go pick up a copy. There is a good discussion of the
:> cost of compiler features and what you have to pay for in using
:> C++. The heart of this is that exceptions is NOT a pay as you go
:> proposition. For all but the most advanced compilers you must
:> have exception deallocation blocks after each function block. This
:> is incase you get an exceptions and happens regardless of whether
:> a single try/catch block appears anywhere in your code. The estimated
:> slow down caused by this is given as 5-10% slower on identically
:> code. (This is a YMMV thing, I have seen C++ code run faster than
:> identical C code, but then again I have also seen the opposite.)
: I don't read programming books anymore. I have yet to see one in the
: last 5 years that wasn't much more than a rewording of online docs or
: the language spec. The only answer is dump the code and take a look. I
: don't agree with you.
I do not believe myself such an expert as to out right dismiss
the experts in the field. Most books seem to be for the MicroSoft
platform and are water down piles of dung. That does not make all
books watered down piles of dung. MEC++ is a collection of mail
posts from the internet on a variety of C++ subjects.
--Karl
Gtk-- Contributor
Matthias Warkus
..and mlw <ma...@mohawksoft.com> wrote:
[schnibble]
> This is speculation, don't bother.
> Again, I disagree.
Now this is the way to make mlw go non-linear. Interesting enough...
[BTW, the bulk of the quoting in your posting was unnecessary.]
mawa
--
Sometimes Usenet makes me feel like a crossbreed of Don Giovanni and
the Sorcerer's Apprentice; while around me something I created is
making all kinds of mess, I want to yell "Enough! Enough!" and wait
for the devil to get me. -- mawa
mlw
>
> On Tue, 09 Mar 1999 15:49:35 +0000, mlw <ma...@mohawksoft.com> wrote:
>
> >My argument is that the Gtk should not have been written in C, period.
>
> There's really no point in arguing about it's implementation at this late
> date. Are you arguing that those who are using it now are misguided?
I am saying, for me, I can use neither GNOME nor KDE, as the basis for
Linux work. KDE because the troll tech license is a sham, and because
the GNOME designed is IMHO questionable.
>
> >intended to be. It is a professional critique of a technology by someone
> >with over 15 years of professional software development.
>
> So you have to tools to do more than critique.
I have the tools, I have the equipment, I even have a bunch of machines
with which to test, but, I have a kid I expect to send to college in 11
years, Mortgage, an ex-wife, and a whole bunch of other obligations. I
tried to start a driver project and couldn't get any serious volunteers.
I would, absolutely, design and work on a Linux app framework if I can
get a serious team together. I can do not it all by myself in a usable
time frame.
If I could get a good, solid, team together, I would re-write a gtk 1.2
as a C++ framework with 'C' wrappers. It shouldn't take more than 6 mos
with a serious group of nerds (Using the GTK as a basis). Lets face it
though, no one is going to volunteer for that kind of work in that kind
of time.
Besides, I would also re-write LGPL as an unambiguous 'Mohawk Library
Public License' that makes it absolutely clear that the library can be
distributed with Linux, unmodified and free. Commercial applications are
free to use it as long as they do not modify it. Ironically Commercial
software is an important factor in a free operating system, sometimes we
must get our free hands dirty to do what we want to do.
Yes, my biggest sorrow is that I would not use the gtk due to what I
call design flaws for production code, and Qt is not LGPL, this leaves,
IMHO, Linux between a rock and a hard place as these are the two
technologies that are competing for the desktop.
perr...@my-dejanews.com
mlw <ma...@mohawksoft.com> wrote:
> David M. Cook wrote:
> >
> > On Tue, 09 Mar 1999 15:49:35 +0000, mlw <ma...@mohawksoft.com> wrote:
> >
> > >My argument is that the Gtk should not have been written in C, period.
> >
> > There's really no point in arguing about it's implementation at this late
> > date. Are you arguing that those who are using it now are misguided?
>
> I am saying, for me, I can use neither GNOME nor KDE, as the basis for
> Linux work. KDE because the troll tech license is a sham, and because
> the GNOME designed is IMHO questionable.
Well...Gnome works for me...as a application framework.
> >
> > >intended to be. It is a professional critique of a technology by someone
> > >with over 15 years of professional software development.
> >
> > So you have to tools to do more than critique.
>
> I have the tools, I have the equipment, I even have a bunch of machines
> with which to test, but, I have a kid I expect to send to college in 11
> years, Mortgage, an ex-wife, and a whole bunch of other obligations.
So do many KDE and Gnome developers.
> I
> tried to start a driver project and couldn't get any serious volunteers.
I've heard to get a good open source project going you should put out some
code first. Then try to get volunteers after the code draws interest.
> I would, absolutely, design and work on a Linux app framework if I can
> get a serious team together. I can do not it all by myself in a usable
> time frame.
See above.
> If I could get a good, solid, team together, I would re-write a gtk 1.2
> as a C++ framework with 'C' wrappers. It shouldn't take more than 6 mos
> with a serious group of nerds (Using the GTK as a basis). Lets face it
> though, no one is going to volunteer for that kind of work in that kind
> of time.
See above. Go for it.
> Besides, I would also re-write LGPL as an unambiguous 'Mohawk Library
> Public License' that makes it absolutely clear that the library can be
> distributed with Linux, unmodified and free.
^^^^^^^^^^ ? ^^^^
Unambiguous????
I always thought free software meant you are free to modify it. I'm free to
modify GPL'd and LGPL'd code.
> Commercial applications are
> free to use it as long as they do not modify it.
Uh hum. I can freely modify LGPL'd libraries *and* write closed source apps
with that modified library, as long as I make the modified library itself
available under LGPL.
I don't think your 'Mohawk Library Public License' even comes close to OSS
guidelines.
> Ironically Commercial
> software is an important factor in a free operating system, sometimes we
> must get our free hands dirty to do what we want to do.
That's why Gtk/Gnome are LGPL'd.
> Yes, my biggest sorrow is that I would not use the gtk due to what I
> call design flaws for production code, and Qt is not LGPL, this leaves,
> IMHO, Linux between a rock and a hard place as these are the two
> technologies that are competing for the desktop.
>
What gtk+ has in what you call design flaws plus what Qt has in license flaws
together doesn't compare to the design and licensing flaws of the competition
in Redmond.
David M. Cook
>If I could get a good, solid, team together, I would re-write a gtk 1.2
>as a C++ framework with 'C' wrappers. It shouldn't take more than 6 mos
It's certainly doable. I read something about plans to rewrite Perl in C++,
so there may be precedence for this sort of thing.
I think it would be better to wait until GNOME matures before embarking on
such a project. At that time people may be more comfortable with C++ as the
basis for the library.
>Yes, my biggest sorrow is that I would not use the gtk due to what I
>call design flaws for production code, and Qt is not LGPL, [...]
How do you get around these problems on the NT side?
Dave Cook
mlw
like. Unless I can demonstrate an overall cost reduction by using a
third party library, I do not. With Windows, the GUI code is part of the
OS, the customer already has it.
With Qt, I would have to pay for a development license to write a
commercial program that uses a library my customer may already have or
can acquire.
Christopher Browne
>return path they screwed up. Exceptions are just that, places where
>exceptional circumstances are taken care of. All too often, developers
>get lazy and use exception handling as a normal error return path. Duh!
>no wonder C++ gets a bad rep.
[Call me dumb...]
Isn't the intent that exception handling is intended to represent a way
of more cleanly handling errors?
It is possible to write bad code using *any* abstraction; exceptions
seem to be designed to deal with "exceptions," of which errors are
certainly a variety.
>> In most cases the wrapper reverts to nothing more than a single
>> function call. Since we are talking about a widget set and not
>> a tight interloop, an extra function call is insignificant compared
>> to the time it takes for X commands to get to the screen.
>
>My argument is that the Gtk should not have been written in C, period. I
>know people are going to take this as a personal insult, but, it is not
>intended to be. It is a professional critique of a technology by someone
>with over 15 years of professional software development. We may disagre
>and we can debate it, but, it is not an insult.
Once you integrate it with C++-specific functionality, that makes it
harder to map it onto other languages that have different abstractions.
C has the set of abstractions that are provided by system calls in the
underlying OS; the correspondence of abstractions between C and the
interfaces represent very nearly an identity. This has the direct
result that function calls and data structures in C can be connected
quite directly to any language/system that runs on Linux and UNIX-like
systems.
The interfacing primitives C provides may be "lower level" than you
want; that doesn't diminish the fact that they are there.
If you want more powerful primitives, then perhaps it's getting time to
start defining facilities using CORBA, which intentionally provides
bindings to many languages. I don't have a problem with that.
By the way, am I misreading you in my assumption that the only
alternative to C would be C++?
--
Linux is obsolete
(Andrew Tanenbaum)
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/corba.html>
mlw
>
> On Tue, 09 Mar 1999 15:49:35 +0000, mlw <ma...@mohawksoft.com> wrote:
> >I have not looked at Qt, but, if it uses exceptions as a normal error
> >return path they screwed up. Exceptions are just that, places where
> >exceptional circumstances are taken care of. All too often, developers
> >get lazy and use exception handling as a normal error return path. Duh!
> >no wonder C++ gets a bad rep.
>
> [Call me dumb...]
>
> Isn't the intent that exception handling is intended to represent a way
> of more cleanly handling errors?
Exception handling is designed to handle hard errors, similar to the
notion of a floating point exception, soft errors or logic error should
be handled by the code.
>
> It is possible to write bad code using *any* abstraction; exceptions
> seem to be designed to deal with "exceptions," of which errors are
> certainly a variety.
Passing a bad parameter should not cause an exception, the function
should return an error.
>
> >> In most cases the wrapper reverts to nothing more than a single
> >> function call. Since we are talking about a widget set and not
> >> a tight interloop, an extra function call is insignificant compared
> >> to the time it takes for X commands to get to the screen.
> >
> >My argument is that the Gtk should not have been written in C, period. I
> >know people are going to take this as a personal insult, but, it is not
> >intended to be. It is a professional critique of a technology by someone
> >with over 15 years of professional software development. We may disagre
> >and we can debate it, but, it is not an insult.
>
> Once you integrate it with C++-specific functionality, that makes it
> harder to map it onto other languages that have different abstractions.
A simple one line C wrapper takes care of all that. The ease of
development one gets from using C++ to handle a class based development,
over C, easily makes up for a wrapper.
>
> C has the set of abstractions that are provided by system calls in the
> underlying OS; the correspondence of abstractions between C and the
> interfaces represent very nearly an identity. This has the direct
> result that function calls and data structures in C can be connected
> quite directly to any language/system that runs on Linux and UNIX-like
> systems.
>
> The interfacing primitives C provides may be "lower level" than you
> want; that doesn't diminish the fact that they are there.
I like 'C' but for something like the Gtk, C++ is a better way to go.
besides, C++ is a superset of 'C' just because you have a .cpp at the
end of the file does not mean that it is going to compile different with
the same options.
>
> If you want more powerful primitives, then perhaps it's getting time to
> start defining facilities using CORBA, which intentionally provides
> bindings to many languages. I don't have a problem with that.
I don't know what this has to do with the Gtk discussion.
>
> By the way, am I misreading you in my assumption that the only
> alternative to C would be C++?
For something like the Gtk, yes. For a general purpose application, no.
> --
> Linux is obsolete
> (Andrew Tanenbaum)
> cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/corba.html>
--
Navindra Umanee
>> It is possible to write bad code using *any* abstraction; exceptions
>> seem to be designed to deal with "exceptions," of which errors are
>> certainly a variety.
>
> Passing a bad parameter should not cause an exception, the function
> should return an error.
divide(4, 0), 0 being the bad parameter.
How better to indicate an error than throwing a DivideByZeroException?
Are you saying one should do something lame like setting errno?
-N.
--
"These download files are in Microsoft Word 6.0 format. After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft website]
< http://www.cs.mcgill.ca/~navindra/editors/ >
Craig Kelley
> I am saying, for me, I can use neither GNOME nor KDE, as the basis for
> Linux work. KDE because the troll tech license is a sham, and because
> the GNOME designed is IMHO questionable.
The GNOME design, if I understand you correctly, is not
"questionable", but the language it was written in is. Correct?
What, exactly, do you not like about GTK--?
I just sounds to me like you do not want second-class access to the
graphics libraries, and you would rather let the C programmers have to
deal with it.
What if you finish your port of GTK in C++, and there is negligable
difference in speed? What is your motivation here? What do you want
to fix?
-Craig (the C programmer who likes GTK)
--
The wheel is turning but the hamster is dead.
Craig Kelley -- kell...@isu.edu
http://www.isu.edu/~kellcrai finger i...@inconnu.isu.edu for PGP block
mlw
>
> It was the Tue, 09 Mar 1999 18:45:49 +0000...
> ..and mlw <ma...@mohawksoft.com> wrote:
> [schnibble]
> > Again, I disagree.
>
> Now this is the way to make mlw go non-linear. Interesting enough...
>
> [BTW, the bulk of the quoting in your posting was unnecessary.]
What do you mean "non-linear?"
I'm never quite sure how much ot how little to quite, that last one was
a judgment call.
mlw
>
> mlw <ma...@mohawksoft.com> writes:
>
> > I am saying, for me, I can use neither GNOME nor KDE, as the basis for
> > Linux work. KDE because the troll tech license is a sham, and because
> > the GNOME designed is IMHO questionable.
>
> The GNOME design, if I understand you correctly, is not
> "questionable", but the language it was written in is. Correct?
>
> What, exactly, do you not like about GTK--?
Putting a C++ class wrapper on top of the roll-your-own class library is
silly. Why did someone create a class hierarchy in 'C?' (This is
theatrical, and we've been through this already several times)
>
> I just sounds to me like you do not want second-class access to the
> graphics libraries, and you would rather let the C programmers have to
> deal with it.
It is a poor design, and using a C++ wrapper on top of a C classes to
fix a bad design is still a bad design.
>
> What if you finish your port of GTK in C++, and there is negligable
> difference in speed? What is your motivation here? What do you want
> to fix?
Speed and size are not the only measure of code quality. The skill level
required to maintain it. The amount of attention to detail required to
make changes. There are lots of measurements, speed and size are usually
negligible between C and C++ with similar implementations.
>
> -Craig (the C programmer who likes GTK)
From a purely 'C' perspective yes, the GTK is cool. It was a lot of work
and a lot of design to do what they did in C. However, it is a futile
prospect to do something "cool" in code when equivalent results can be
obtained by mundane.
Navindra Umanee
> I would, absolutely, design and work on a Linux app framework if I can
> get a serious team together. I can do not it all by myself in a usable
> time frame.
You don't like GNUStep either? Don't know how far they've progressed
though. http://www.gnustep.org/.
mlw
>
> mlw <ma...@mohawksoft.com> wrote:
> >> It is possible to write bad code using *any* abstraction; exceptions
> >> seem to be designed to deal with "exceptions," of which errors are
> >> certainly a variety.
> >
> > Passing a bad parameter should not cause an exception, the function
> > should return an error.
>
> divide(4, 0), 0 being the bad parameter.
>
> How better to indicate an error than throwing a DivideByZeroException?
> Are you saying one should do something lame like setting errno?
>
> --
> "These download files are in Microsoft Word 6.0 format. After unzipping,
> these files can be viewed in any text editor, including all versions of
> Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft website]
> < http://www.cs.mcgill.ca/~navindra/editors/ >
Actually a divide by zero is a hardware exception and to check before a
divide is patented. (or so I have been informed)
I'm not talking about hard exceptions, I am talking about things like:
void obj:funct(int param)
{
if((param < MIN_PARAM) || (param > MAX_PARAM))
throw 0;
// Do something here
}
The above practice is my biggest complaint about C++ guys. I see it all
the time and it pisses me off. Nothing makes code harder to follow or
slower than all the try/catch blockes required implement this kind of
programming.
Christopher Browne
>Christopher Browne wrote:
>>
>> On Tue, 09 Mar 1999 15:49:35 +0000, mlw <ma...@mohawksoft.com> wrote:
>> >I have not looked at Qt, but, if it uses exceptions as a normal error
>> >return path they screwed up. Exceptions are just that, places where
>> >exceptional circumstances are taken care of. All too often, developers
>> >get lazy and use exception handling as a normal error return path. Duh!
>> >no wonder C++ gets a bad rep.
>>
>> [Call me dumb...]
>>
>> Isn't the intent that exception handling is intended to represent a way
>> of more cleanly handling errors?
>
>Exception handling is designed to handle hard errors, similar to the
>notion of a floating point exception, soft errors or logic error should
>be handled by the code.
So in other words we need to have *two* exception handling systems:
a) One, provided by the language environment, that is to be exclusively
used for "hard" errors, and
b) Another, that every programmer has to recreate from scratch in their
applications, to handle "less hard" errors.
Seems silly to me to for programmers have to implement another exception
system if C++ already provides one.
This certainly doesn't agree with what I see in Java, Python, Eiffel,
PL/SQL, or Scheme's exception handling systems; they seem quite happy
having "user-defined" exceptions that sit at the same level as 'system'
exceptions.
If as you seem to be indicating, C++'s exception handling system "breaks
down" when used for user-defined exceptions, then that Really Sucks.
>> It is possible to write bad code using *any* abstraction; exceptions
>> seem to be designed to deal with "exceptions," of which errors are
>> certainly a variety.
>
>Passing a bad parameter should not cause an exception, the function
>should return an error.
Do you mean:
a) A continuation?,
b) An error code?
or some other return value (some sort of structure?) that I'm not
thinking of?
>> If you want more powerful primitives, then perhaps it's getting time to
>> start defining facilities using CORBA, which intentionally provides
>> bindings to many languages. I don't have a problem with that.
>
>I don't know what this has to do with the Gtk discussion.
The goal of GTK is to provide a GUI library that provides bindings to
many languages in a nondiscriminatory way.
Representing those bindings in IDL would certainly represent a nice
nondiscriminatory way, which is arguably neither true for C-oriented
bindings nor for C++-oriented bindings.
>> By the way, am I misreading you in my assumption that the only
>> alternative to C would be C++?
>
>For something like the Gtk, yes. For a general purpose application,
>no.
Ah. GTk is a general purpose *library,* and hence C/C++ are the only
choices. Unlike *applications,* as distinct from libraries, where
"anything goes."
--
Linux is obsolete
(Andrew Tanenbaum)
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/langc.html>
Christopher Browne
>Matthias Warkus wrote:
>>
>> It was the Tue, 09 Mar 1999 18:45:49 +0000...
>> ..and mlw <ma...@mohawksoft.com> wrote:
>> [schnibble]
>> > Again, I disagree.
>>
>> Now this is the way to make mlw go non-linear. Interesting enough...
>>
>> [BTW, the bulk of the quoting in your posting was unnecessary.]
>
>What do you mean "non-linear?"
>
>I'm never quite sure how much ot how little to quite, that last one was
>a judgment call.
The term "ballistic" is usually thought to describe when things start
taking parabolic trajectories; since the Earth is a sphere, and may be
treated as a point source from a gravitational point of view, it is more
correct to consider that ballistic trajectories are actually elliptical,
but since the eccentricity is normally *extremely* high, calling it a
parabola is usually a near-enough-approximation.
In any case, whether parabola, ellipse, or hyperbola :-), these are all
nonlinear curves that fairly much resemble the path taken by an object
that "goes ballistic."
And the term "goes ballistic" is a fairly common English idiom having to
do with someone starting what hillbillies might term an "extreme hissy
fit."
--
Linux is obsolete
(Andrew Tanenbaum)
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
Bart Vanhauwaert
:> "Deriving widgets from each other seems to call out for the use of
:> C++ in writing GTK+. C was chose for GTK+ for several reasons. C
:> is the primary language for developers on Linux. C is also more
:> portable than C++ is and has been standardized longer. C++ is only
:> now becoming standardized, and not all C++ compilers work on the
:> same set of code. When GTK+ was started, C++ standardization was
:> still a pipe dream. C++ has come a long way, but it still has some
:> problems working across multiple compilers on multiple platforms."
:> He then makes a vague reference to the GTK-- C++ wrapper project
:> for GTK+.
: This is gibberish by someone ignorant of C++. C++ has been around,
: standard enough for real projects for almost 10 years. The things that
: these guys are doing could have been done with CFront and still compile
: today.
The problem was not C++, it was the C++ compiler of the free software
world at that point. egcs wasn't there and frankly, g++ sucks
big hairy balls through very thin straws
when writing more than 100 lines of C++ code.
That and of course, another, there is a very strong anti-C++
sentiment in the free software world. There is a lot of conservatism
as I see it. Too bad because C++ is really enjoyable. And if you're
well versed in it, there is no problem using the more advanced stuff
like exceptions, templates, RTTI and namespaces. And of course there is
the killer advantage of the STL...
: It is clear these guys had a prejudice toward C++ and didn't even
: consider it. C++, on the whole, can be a disgusting environment,
: however, when its feature set is used in moderation, in essence as a 'C'
: with classes, it can be a better C.
What's the problem with the more advanced features? If there is a
logical need for it, and the programmer can handle it?
cu bart
--
__
| Linux also needs a Grock or a Krock , Like in Yosemite.
mlw
>
> On Wed, 10 Mar 1999 22:48:57 +0000, mlw <ma...@mohawksoft.com> wrote:
> >Matthias Warkus wrote:
> >>
> >> It was the Tue, 09 Mar 1999 18:45:49 +0000...
> >> ..and mlw <ma...@mohawksoft.com> wrote:
> >> [schnibble]
> >> > Again, I disagree.
> >>
> >> Now this is the way to make mlw go non-linear. Interesting enough...
> >>
> >> [BTW, the bulk of the quoting in your posting was unnecessary.]
> >
> >What do you mean "non-linear?"
> >
> >I'm never quite sure how much ot how little to quite, that last one was
> >a judgment call.
>
> The term "ballistic" is usually thought to describe when things start
> taking parabolic trajectories; since the Earth is a sphere, and may be
> treated as a point source from a gravitational point of view, it is more
> correct to consider that ballistic trajectories are actually elliptical,
> but since the eccentricity is normally *extremely* high, calling it a
> parabola is usually a near-enough-approximation.
>
> In any case, whether parabola, ellipse, or hyperbola :-), these are all
> nonlinear curves that fairly much resemble the path taken by an object
> that "goes ballistic."
>
> And the term "goes ballistic" is a fairly common English idiom having to
> do with someone starting what hillbillies might term an "extreme hissy
> fit."
I know what "non-linear" means, but, I do not know what he was referring
too.
Bart Vanhauwaert
: If you haven't read the book More Effective C++ by Meyers, I would
: suggest you go pick up a copy. There is a good discussion of the
: cost of compiler features and what you have to pay for in using
: C++. The heart of this is that exceptions is NOT a pay as you go
: proposition. For all but the most advanced compilers you must
: have exception deallocation blocks after each function block. This
: is incase you get an exceptions and happens regardless of whether
: a single try/catch block appears anywhere in your code. The estimated
: slow down caused by this is given as 5-10% slower on identically
: code. (This is a YMMV thing, I have seen C++ code run faster than
: identical C code, but then again I have also seen the opposite.)
In case you haven't noticed : that book, however good it is (it _IS_),
is from 1996, hence outdated.
: It is not an insult, but it is definately debatable. C is the
: lowest common denominator of all languages. If they
: were intending to have maximum portablity then they probably made
: the right decision.
Too bad they screwed that maximum portability again with gnome :(
Bart Vanhauwaert
: I don't read programming books anymore. I have yet to see one in the
: last 5 years that wasn't much more than a rewording of online docs or
: the language spec. The only answer is dump the code and take a look. I
: don't agree with you.
You have some serieus reading ahead. For C++ alone, you need
Effective and More Effective C++ from Meyers. You also need
the 3th Edition of Stroustroup's book on C++ (to understand
why you shouldn't limit yourself to C with classes now
the compilers support the use of the newer features!).
Also Rumminations on C++ from Koenig was a fun read.
Note also : the C++ standard is _NOT_ available online (you can
get a pdf for $18) and it sure is not a good source for C++
programming, you need at least some knowledgeable person
annotating things, which currently isn't available
(Stroustroup is rumoured to bring out something like this)
Bart Vanhauwaert
: I am saying, for me, I can use neither GNOME nor KDE, as the basis for
: Linux work. KDE because the troll tech license is a sham, and because
: the GNOME designed is IMHO questionable.
I'd love to see some of the work done at mohawksoft under a Qt license.
cu bart - food for thought
mlw
> What's the problem with the more advanced features? If there is a
> logical need for it, and the programmer can handle it?
>
> cu bart
My problem with the advanced features of C++ are that they do not work
the same way on different environments. Templates bloat code, and
exceptions try/catch blocks littered about the code in place of real
error checking makes for a bad environment.
However, a C with classes is cool.
Navindra Umanee
> Christopher Browne wrote:
>>
>> On Wed, 10 Mar 1999 22:48:57 +0000, mlw <ma...@mohawksoft.com> wrote:
>> >Matthias Warkus wrote:
>> >>
>> >> It was the Tue, 09 Mar 1999 18:45:49 +0000...
>> >> ..and mlw <ma...@mohawksoft.com> wrote:
>> >> [schnibble]
>> >> > Again, I disagree.
>> >>
>> >> Now this is the way to make mlw go non-linear. Interesting enough...
>> >>
>> >> [BTW, the bulk of the quoting in your posting was unnecessary.]
[deletia]
>
> I know what "non-linear" means, but, I do not know what he was referring
> too.
It seems that mawa may be learning the ways of the force from jedi.
-N. (ie, "me neither")
Christopher B. Browne
>> >> seem to be designed to deal with "exceptions," of which errors are
>> >> certainly a variety.
>> >
>> > Passing a bad parameter should not cause an exception, the function
>> > should return an error.
>>
>>
>> How better to indicate an error than throwing a DivideByZeroException?
>> Are you saying one should do something lame like setting errno?
>>
>divide is patented. (or so I have been informed)
Hum? I wrote code doing *that* close to 20 years ago in Atari BASIC.
>I'm not talking about hard exceptions, I am talking about things like:
>
>void obj:funct(int param)
>{
> if((param < MIN_PARAM) || (param > MAX_PARAM))
> throw 0;
> // Do something here
>}
>
>The above practice is my biggest complaint about C++ guys. I see it all
>the time and it pisses me off. Nothing makes code harder to follow or
>slower than all the try/catch blockes required implement this kind of
>programming.
Ah. Presumably the lack of catch/throw in C makes it superior in that
it forces people to structure their code better in order to catch
errors, um, right?
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
cbbr...@hex.net - "What have you contributed to free software today?..."
David M. Cook
>When you purchase the compiler, you are free to distribute anything you
I was more interested in how you got around the design problems (of which I
only know by reputation).
Dave Cook
Troy Baer
mlw> Craig Kelley wrote:
>> What, exactly, do you not like about GTK--?
mlw> Putting a C++ class wrapper on top of the roll-your-own class library is
mlw> silly. Why did someone create a class hierarchy in 'C?' (This is
mlw> theatrical, and we've been through this already several times)
Has it ever crossed your mind that maybe, just maybe, C++ isn't the
answer to everything?
>>
>> I just sounds to me like you do not want second-class access to the
>> graphics libraries, and you would rather let the C programmers have to
>> deal with it.
mlw> It is a poor design, and using a C++ wrapper on top of a C classes to
mlw> fix a bad design is still a bad design.
OK then, here's your project: Make a wrapper for a C++ GUI library
that binds to at least *two* of the following languages:
Fortran-90 (yes Virginia, people still program in Fortran)
Perl
Python
Scheme
Tcl
Damn near impossible, isn't it? (That's not even a worst case
scenario... Imagine trying to bind a C++ library to strict
Fortran-77, which can't do dynamic memory allocation or hierarchical
data structures.) I only know of only *one* C++ library that can
claim this (vtk), and it doesn't handle the (IMHO) most interesting
case of Fortran-90. OTOH, C libraries pass this test easily; GTK+ has
bindings to at least three of the above languages.
One of the reasons GTK+ was written in C is that it can be easily
bound into other languages without playing nightmarish and nonportable
linker tricks to get around C++'s name mangling. Not all of us want
to write GUI code in C++. If you consider that a bad design, then
perhaps you should move on to a different widget set.
--Troy
--
Troy Baer, MS(AAE) I may have wasted all those years;
tb...@columbus.rr.com They're not worth their time in tears.
http://home.columbus.rr.com/tbaer/ I may have spent too long in darkness,
Linux: hex, bugs, and rock'n'roll. In the warmth of my fears. --Dream Theater
Navindra Umanee
> OK then, here's your project: Make a wrapper for a C++ GUI library
> that binds to at least *two* of the following languages:
>
> Fortran-90 (yes Virginia, people still program in Fortran)
> Perl
> Python
> Scheme
> Tcl
Check. Qt has bindings for Perl and Python.
-N.
David Z. Maze
mlw> Actually a divide by zero is a hardware exception and to check
mlw> before a divide is patented. (or so I have been informed)
In practice, a divide-by-zero should be treated just like any other
something-is-wrong exception. (Example: take your obj:funct() method
and change the test to if (param == 0) throw 0; Is this any different?)
mlw> void obj:funct(int param)
mlw> {
mlw> if((param < MIN_PARAM) || (param > MAX_PARAM))
mlw> throw 0;
mlw> // Do something here
mlw> }
mlw>
mlw> The above practice is my biggest complaint about C++ guys. I see
mlw> it all the time and it pisses me off. Nothing makes code harder
mlw> to follow or slower than all the try/catch blockes required
mlw> implement this kind of programming.
What, then, is the Right Thing To Do (TM) with, say, an array class?
Returning an error value rather than throwing an exception leads to
rather disgusting and error-prone code in the caller. OTOH, using
exceptions can also lead to some ugly code (I've seen this in Java
quite a bit). It's a trade-off, really.
(What, also, is TRTTD with a divide-by-zero exception? Should this be
handled using C++ exceptions in a C++ program? A Unix signal? Always
call abort()?)
--
David Maze dm...@mit.edu http://donut.mit.edu/dmaze/
"Hey, Doug, do you mind if I push the Emergency Booth Self-Destruct Button?"
"Oh, sure, Dave, whatever...you _do_ know what that does, right?"
o r c e l l . p o r t l a n d . o r . u s
Bart Vanhauwaert <ja...@jafshome.gv.kotnet.org> wrote:
>That and of course, another, there is a very strong anti-C++
>sentiment in the free software world. There is a lot of conservatism
>as I see it.
If conservatism means `expecting your code to keep working',
well, yeah, there might be some conservatism.
>Too bad because C++ is really enjoyable. And if you're
>well versed in it, there is no problem using the more advanced stuff
>like exceptions, templates, RTTI and namespaces. And of course there is
>the killer advantage of the STL...
What killer advantage? The advantage of being able to make denser
and more unreadable spaghetti code?
I wrote a large wad of a commercial product in C++ a few years back
(1997, to be precise), used g++ to compile it and gcc to link it,
because it didn't use any of the spaghetti inducing misfeatures of
C++. This product has been cancelled, so the company decided to
Open Source(tm)(c)(r) it and I went back and tried to rebuild it
with egcs because this company had switched to a Modern! Object!
Oriented! C++ antiviral scanner that would not compile under g++
(or egcs, for that matter.) I quickly discovered that egcs
promiscuously drops catch and throw into binaries, thus making
them unlinkable against standard libc.
I'm taking C++ off my resume. I'm not going to claim proficiency
in any language that has Ada envy.
____
david parsons \bi/ C++ == Ada done by religious cultists.
\/
mlw
>
> mlw <ma...@mohawksoft.com> wrote:
> : I don't read programming books anymore. I have yet to see one in the
> : last 5 years that wasn't much more than a rewording of online docs or
> : the language spec. The only answer is dump the code and take a look. I
> : don't agree with you.
>
> You have some serieus reading ahead. For C++ alone, you need
> Effective and More Effective C++ from Meyers. You also need
> the 3th Edition of Stroustroup's book on C++ (to understand
> why you shouldn't limit yourself to C with classes now
> the compilers support the use of the newer features!).
> Also Rumminations on C++ from Koenig was a fun read.
I don't think I would get a book named "Effective C++" I have been using
it for a very long time, and use it quite effectively. I have designed
products that have been delivered on time an ahead of budget with a very
low bug count. I have been bitten by its flaws too. C++ is an excellent
language when used carefully. I know how to develop software. As for
Stroustrup, I consider his book the language spec the same a the
venerable K&R book on C.
The biggest difference between C and C++ is that C has a very
deterministic 1:1 relationship between the source and the produced
object. It is possible to have a solid understanding of what the
compiler is doing in one screen of information. C++ can be like this if
you are careful. This is how I use C++. I have seen projects where
operators have been overloaded, multiple inheritance used, and one can't
tell from a specific screen, what the compiler would do without having
all the parent classes drawn out in a tree, and operators listed, even
then you would have to have a very fine understanding of the nuances of
the language to figure it out.
Just as a nail-gun can be used to nail your hand to a board, it can
still save man-weeks when building a house. Just because a tool requires
care and thought, does not men it should not be used.
mlw
>
> >>>>> "mlw" == mlw <ma...@mohawksoft.com> writes:
>
> mlw> Craig Kelley wrote:
> >> What, exactly, do you not like about GTK--?
>
> mlw> Putting a C++ class wrapper on top of the roll-your-own class library is
> mlw> silly. Why did someone create a class hierarchy in 'C?' (This is
> mlw> theatrical, and we've been through this already several times)
>
> Has it ever crossed your mind that maybe, just maybe, C++ isn't the
> answer to everything?
I never even hinted at a suggestion that it was. I merely said, quite
accurately, that the GTK should have been written in C++ because a
roll-your-own class library in 'C' is stupid. It has been for at least 4
years.
>
> >>
> >> I just sounds to me like you do not want second-class access to the
> >> graphics libraries, and you would rather let the C programmers have to
> >> deal with it.
>
> mlw> It is a poor design, and using a C++ wrapper on top of a C classes to
> mlw> fix a bad design is still a bad design.
>
> OK then, here's your project: Make a wrapper for a C++ GUI library
> that binds to at least *two* of the following languages:
>
> Fortran-90 (yes Virginia, people still program in Fortran)
> Perl
> Python
> Scheme
> Tcl
>
> Damn near impossible, isn't it?
No, the same as C
> (That's not even a worst case
> scenario... Imagine trying to bind a C++ library to strict
> Fortran-77, which can't do dynamic memory allocation or hierarchical
> data structures.) I only know of only *one* C++ library that can
> claim this (vtk), and it doesn't handle the (IMHO) most interesting
> case of Fortran-90. OTOH, C libraries pass this test easily; GTK+ has
> bindings to at least three of the above languages.
This is just as easy in C++ as it is in C. C++ is a superset of C. If
something can be done in C, it can be done in C++. Period. If you even
think that there are things that you can do in C that can't be done with
C++ you don't know what you are talking about.
>
> One of the reasons GTK+ was written in C is that it can be easily
> bound into other languages without playing nightmarish and nonportable
> linker tricks to get around C++'s name mangling. Not all of us want
> to write GUI code in C++. If you consider that a bad design, then
> perhaps you should move on to a different widget set.
If this is the reason the Gtk was written in 'C' then they made a huge
mistake because they did not research the options, and made decisions
based on ignorance.
mlw
>
> On Thu, 11 Mar 1999 01:04:00 +0000, mlw <ma...@mohawksoft.com> posted:
> >Navindra Umanee wrote:
> >>
> >> mlw <ma...@mohawksoft.com> wrote:
> >> >> It is possible to write bad code using *any* abstraction; exceptions
> >> >> seem to be designed to deal with "exceptions," of which errors are
> >> >> certainly a variety.
> >> >
> >> > Passing a bad parameter should not cause an exception, the function
> >> > should return an error.
> >>
> >> divide(4, 0), 0 being the bad parameter.
> >>
> >> How better to indicate an error than throwing a DivideByZeroException?
> >> Are you saying one should do something lame like setting errno?
> >>
> >divide is patented. (or so I have been informed)
>
If you can prove that the Free Software foundation may like to speak to
you.
>
> >I'm not talking about hard exceptions, I am talking about things like:
> >
> >void obj:funct(int param)
> >{
> > if((param < MIN_PARAM) || (param > MAX_PARAM))
> > throw 0;
> > // Do something here
> >}
> >
> >The above practice is my biggest complaint about C++ guys. I see it all
> >the time and it pisses me off. Nothing makes code harder to follow or
> >slower than all the try/catch blockes required implement this kind of
> >programming.
>
> Ah. Presumably the lack of catch/throw in C makes it superior in that
> it forces people to structure their code better in order to catch
> errors, um, right?
In some ways, yes, absolutely. If people thought more about the
structure of the code they write, applications would not such as much as
they do today.
IMHO try/catch blocks are like beer. I love beer, but, too much beer is
not a healthy thing. Knowing that moderation is an important concept
does not mean you don't like something. Have a beer. And if you ever see
a 6' tall guy, that looks like a football player wearing a leather
jacket, driving a supped up Firebird, with a Linux sticker on it, buy
him a good tall stout. It is probably me.
Craig Kelley
> C++ is a superset of C. If something can be done in C, it can be
> done in C++. Period. If you even think that there are things that
> you can do in C that can't be done with C++ you don't know what you
> are talking about.
And the other side of the argument is: One can build a C++ compiler
by using C, so anything that can be done in C++ can also be done in
C.
I believe that the GTK folks have made a good, object-oriented design
which is very extensible (and I *still* haven't heard any good reasons
why they should have done it in C++).
> > One of the reasons GTK+ was written in C is that it can be easily
> > bound into other languages without playing nightmarish and nonportable
> > linker tricks to get around C++'s name mangling. Not all of us want
> > to write GUI code in C++. If you consider that a bad design, then
> > perhaps you should move on to a different widget set.
>
> If this is the reason the Gtk was written in 'C' then they made a huge
> mistake because they did not research the options, and made decisions
> based on ignorance.
That, and there are more C programmers than C++ programmers, the
authors liked C better, C is better supported on multiple
architectures, and C is quicker.
It really is a matter of taste. I can see where event-driven
programming leads to an OO design -- they just chose to implement
their own OO system with an iterative language.
Craig Kelley
> > -Craig (the C programmer who likes GTK)
>
> From a purely 'C' perspective yes, the GTK is cool. It was a lot of work
> and a lot of design to do what they did in C. However, it is a futile
> prospect to do something "cool" in code when equivalent results can be
> obtained by mundane.
Remember that they started GTK back in 1996.
Open Source C++ compilers were not a reality.
Tim Smith
>That is not pure gibberish. As one of the authors of the the gtk--
>widget set I can tell you that C++ is at this time still not
>anywhere close to being a standard. Despite the publication of
>the standard, the level of support varies wildly from one compiler
>to the next. This is clearly the case you can see between Qt and
If you just stick to the C-like part of C++ for the most part, only going
beyond that to use simple classes, constructors, destructors, and perhaps
a string class, you'll get code that is highly portable among C++ compilers.
You can even throw in simple use of STL and remain highly portable.
--Tim Smith
David M. Cook
wrote:
>Check. Qt has bindings for Perl and Python.
Well that's 2 out of the 15 or so that Gtk supports.
Perl and Python have similar object models that may make them easier to
interface to C++ libraries.
Dave Cook
o r c e l l . p o r t l a n d . o r . u s
David M. Cook <dave...@home.com> wrote:
>On Thu, 11 Mar 1999 18:24:59 GMT, Navindra Umanee <navi...@cs.mcgill.ca>
>wrote:
>
>>Check. Qt has bindings for Perl and Python.
>
>Well that's 2 out of the 15 or so that Gtk supports.
That wasn't the question, though.
____
david parsons \bi/ If you've got C bindings, you've pretty much won.
\/
mlw
>
> mlw <ma...@mohawksoft.com> writes:
>
> > C++ is a superset of C. If something can be done in C, it can be
> > done in C++. Period. If you even think that there are things that
> > you can do in C that can't be done with C++ you don't know what you
> > are talking about.
>
> And the other side of the argument is: One can build a C++ compiler
> by using C, so anything that can be done in C++ can also be done in
> C.
Please, that is a stupid argument. Yea, sure it all gets compiled down
to assembly anyway so what is the point of'C?' C++ provides language
constructs that are not present in C. Cutting out a ton of the code that
would be needed to be written. That is the purpose of a computer
language. C++ provides a lot of OOP features while retaining the
capacity to have a direct correspondence between source and object.
>
> I believe that the GTK folks have made a good, object-oriented design
> which is very extensible (and I *still* haven't heard any good reasons
> why they should have done it in C++).
The reasons they should have used C++:
VTables in C++ are in read-only memory and are not subject to random
memory writes. (bugs)
The class specifier is much more flexible than a simple struct and
imposes no implementation overhead.
A C++ compiler will produce the same object code a C compiler will
produce with the same source. (name mangling aside)
Using the class specifier in C++ would have been a more standard, more
maintainable implementation of the class hierarchy.
I have been down the roll-your-own class path many times, it is a stupid
fight. C++ provides all the facilities that are required to implement a
moderately complex class hierarchy, well.
C++ classes would have been more efficient than what is in the Gtk.
C++ would be less error prone and require fewer castings.
>
> > > One of the reasons GTK+ was written in C is that it can be easily
> > > bound into other languages without playing nightmarish and nonportable
> > > linker tricks to get around C++'s name mangling. Not all of us want
> > > to write GUI code in C++. If you consider that a bad design, then
> > > perhaps you should move on to a different widget set.
> >
> > If this is the reason the Gtk was written in 'C' then they made a huge
> > mistake because they did not research the options, and made decisions
> > based on ignorance.
>
> That, and there are more C programmers than C++ programmers, the
> authors liked C better, C is better supported on multiple
> architectures, and C is quicker.
The number of C/C++ programmers is a matter of professional growth.
They may have liked 'C' better, but that is not a 'technical' decision,
it is an emotional decision.
Name one platform to which Gnome would ported that could not claim a C++
compiler.
C code compiled with a C++ compiler is virtually identical to that
produced by a standard C compiler.
>
> It really is a matter of taste. I can see where event-driven
> programming leads to an OO design -- they just chose to implement
> their own OO system with an iterative language.
I beg to differ. I have yet to see one rational reason why C was the
correct choice, when there are numerous reasons why C++ would have been
better suited to the task.
mlw
Here here!!!
mlw
>
> mlw <ma...@mohawksoft.com> writes:
> mlw> Actually a divide by zero is a hardware exception and to check
> mlw> before a divide is patented. (or so I have been informed)
>
> In practice, a divide-by-zero should be treated just like any other
> something-is-wrong exception. (Example: take your obj:funct() method
> and change the test to if (param == 0) throw 0; Is this any different?)
>
> mlw> void obj:funct(int param)
> mlw> {
> mlw> if((param < MIN_PARAM) || (param > MAX_PARAM))
> mlw> throw 0;
> mlw> // Do something here
> mlw> }
> mlw>
> mlw> The above practice is my biggest complaint about C++ guys. I see
> mlw> it all the time and it pisses me off. Nothing makes code harder
> mlw> to follow or slower than all the try/catch blockes required
> mlw> implement this kind of programming.
>
> What, then, is the Right Thing To Do (TM) with, say, an array class?
> Returning an error value rather than throwing an exception leads to
> rather disgusting and error-prone code in the caller. OTOH, using
> exceptions can also lead to some ugly code (I've seen this in Java
> quite a bit). It's a trade-off, really.
Sometimes software is not a beauty pageant. Good code is sometimes not
pretty. try/catch blocks are pretty, but, they have a cost. They take up
a lot of stack space and have a big performance hit. Sometimes speed and
efficiency is THE issue, image manipulation routines and numerical
processing libraries require fast function calling.
Karl Nelson
: Karl Nelson <kene...@ece.ucdavis.edu> wrote:
: In case you haven't noticed : that book, however good it is (it _IS_),
: is from 1996, hence outdated.
Yep, I have other books but none do as good of job explaining the
ins and outs of C++ in that way. I do take the figures with a
grain of salt as they are definitely a bit stale. On the other hand
not everyone has the latest compilers. I am sure the average is at
least two years old (unless you are bleeding edge kind of guy like me.)
So figures from a 3 year old book about compilers in place today,
aren't entirely out of place.
: : It is not an insult, but it is definately debatable. C is the
: : lowest common denominator of all languages. If they
: : were intending to have maximum portablity then they probably made
: : the right decision.
: Too bad they screwed that maximum portability again with gnome :(
I am not sure what you mean here. Can you explain a bit more?
--Karl
Gtk-- Contributor
Craig Kelley
> > > C++ is a superset of C. If something can be done in C, it can be
> > > done in C++. Period. If you even think that there are things that
> > > you can do in C that can't be done with C++ you don't know what you
> > > are talking about.
> >
> > And the other side of the argument is: One can build a C++ compiler
> > by using C, so anything that can be done in C++ can also be done in
> > C.
>
> Please, that is a stupid argument. Yea, sure it all gets compiled down
> to assembly anyway so what is the point of'C?' C++ provides language
> constructs that are not present in C. Cutting out a ton of the code that
> would be needed to be written. That is the purpose of a computer
> language. C++ provides a lot of OOP features while retaining the
> capacity to have a direct correspondence between source and object.
Then by that same argument, using C++ for a project, simply because it
is a superset of C, is stupid.
> The reasons they should have used C++:
> VTables in C++ are in read-only memory and are not subject to random
> memory writes. (bugs)
Those same bugs are more likely to trigger protection faults [hence,
this isn't very significant], but I can see your point.
> The class specifier is much more flexible than a simple struct and
> imposes no implementation overhead.
A struct is only as complicated as you want it to be.
> A C++ compiler will produce the same object code a C compiler will
> produce with the same source. (name mangling aside)
Not really an advantage.
> Using the class specifier in C++ would have been a more standard, more
> maintainable implementation of the class hierarchy.
More standard: for C++, yes
More maintainable: This can't be proven true or false because it is
all a matter of taste. If you have many C programmers then perhaps an
object abstraction would be easier to maintain. Don't forget that GTK
started in 1996 and the C++ world was no garden (not to mention the
free C++ compilers of the time).
> I have been down the roll-your-own class path many times, it is a stupid
> fight. C++ provides all the facilities that are required to implement a
> moderately complex class hierarchy, well.
Yes, in 1999 I can see your point here.
> C++ classes would have been more efficient than what is in the Gtk.
If you are refering to type-checking, did you know that you can
disable that after your code is debugged? This 'efficiency' will
probably be eaten up by slower code from free C++ compilers (although
the only way to prove this is to write GTK in C++ -- all the way down
to Glib and GDK).
> C++ would be less error prone and require fewer castings.
By less error prone, you are refering to your first comment?
Yes there would be fewer castings, but GTK uses macros to do this (and
so that future implementations don't break your source).
> > That, and there are more C programmers than C++ programmers, the
> > authors liked C better, C is better supported on multiple
> > architectures, and C is quicker.
>
> The number of C/C++ programmers is a matter of professional growth.
> They may have liked 'C' better, but that is not a 'technical' decision,
> it is an emotional decision.
> Name one platform to which Gnome would ported that could not claim a C++
> compiler.
> C code compiled with a C++ compiler is virtually identical to that
> produced by a standard C compiler.
Go back to 1996, when the decision was made.
> > It really is a matter of taste. I can see where event-driven
> > programming leads to an OO design -- they just chose to implement
> > their own OO system with an iterative language.
>
> I beg to differ. I have yet to see one rational reason why C was the
> correct choice, when there are numerous reasons why C++ would have been
> better suited to the task.
Perhaps if they were starting from scratch *today*.
Simon Kinahan
> I agree, the fringe areas of C++ are questionable, but, in my post - the
> notion of 'C' with classes has been very stable for some time. The GTK
> could well have been done with C++ as 'C' with classes, and been much
> easier to implement and use.
The trouble is that both templates and exceptions have been 'fringe areas'
of C++ for four years now, and many compilers still differ on how to
implement them. Some compilers cannot even agree on what:
for (int i = 0;i<n;i++) {
}
does, or indeed whether it is allowed.
The notion of C with classes is fraught with difficulties and
inconsistencies, which C++ and Objective C took different approaches to.
The C++ approach, trying to create a language like C in spirit but with OO
features, eventually seems to have required the addition at least of
templates to solve the problems presented by the non-rooted class
hierarchy.
Whether and how to use C++ depends on what you want to gain by using an OO
language. If you want decreased development times and greater potential for
code reuse the 'C with classes' approach to C++ sucks very badly. This
isn't intended as a personal issue, its just that I've never come across a
C++ project with effective reuse of classes, whereas Smalltalk and (to a
lesser extent) Java projects almost take it for granted. The only advantage
to using C++ like this is that it is a 'better C'.
If you use templates (and preferable the STL), and exceptions in your code,
you may be faster development than in C (I think the jury is still out),
but you can kiss portability goodbye. This is, of course, why Qt uses that
meta-compiler thing.
Given what Gtk+ was meant to do, that is to be a portable open widget set
for X-based platforms, they would have had to use C++ as 'C with classes'.
As I say above, the benefits of this are pretty marginal, and I agree that
they are not sufficient to justify the possible portability pitfalls of
using C++.
> I have not looked at Qt, but, if it uses exceptions as a normal error
> return path they screwed up. Exceptions are just that, places where
> exceptional circumstances are taken care of. All too often, developers
> get lazy and use exception handling as a normal error return path. Duh!
> no wonder C++ gets a bad rep.
If you examine the use of exceptions in other languages, you will find that
it is common to use exceptions as the normal error return path. They are
much neater and provide much more readable code than using the return value
(which is better used for returning something useful). C++ exception
handling is error prone, and (until recently) not checked. It is slow, in
fact typically C++ implementations handle exceptions slower than some Java
JIT environments. I'm not sure why this is, but I think I heard it is
something to do with trying to handle code written without the expectation
of exceptions.
> My argument is that the Gtk should not have been written in C, period. I
> know people are going to take this as a personal insult, but, it is not
> intended to be.
Thats fine, but I do not think you've done much to justify it. You seem to
be relying on C++'s image as being more 'modern' and 'the way forward'.
What do you think the Gtk+ developers would actually have gained for
themselves or their users by writing in C++ ? As I explained above, I think
the answer is very little.
Simon
mlw
>
> mlw <ma...@mohawksoft.com> writes:
>
> > > > C++ is a superset of C. If something can be done in C, it can be
> > > > done in C++. Period. If you even think that there are things that
> > > > you can do in C that can't be done with C++ you don't know what you
> > > > are talking about.
> > >
> > > And the other side of the argument is: One can build a C++ compiler
> > > by using C, so anything that can be done in C++ can also be done in
> > > C.
> >
> > Please, that is a stupid argument. Yea, sure it all gets compiled down
> > to assembly anyway so what is the point of'C?' C++ provides language
> > constructs that are not present in C. Cutting out a ton of the code that
> > would be needed to be written. That is the purpose of a computer
> > language. C++ provides a lot of OOP features while retaining the
> > capacity to have a direct correspondence between source and object.
>
> Then by that same argument, using C++ for a project, simply because it
> is a superset of C, is stupid.
No because with C++ you can use classes, and in C you can not. IMHO
class is a huge advantage with C++ over C. And that is what this whole
discussion is about. The Gtk would have been better, etc. with C++
classes than the stupid roll-your-own classes used by the Gtk
developers.
>
> > The reasons they should have used C++:
> > VTables in C++ are in read-only memory and are not subject to random
> > memory writes. (bugs)
>
> Those same bugs are more likely to trigger protection faults [hence,
> this isn't very significant], but I can see your point.
I have done the roll-your-own class thing before. Stray pointers that
are not zero and do not cause a dump, are usually left over pointers
values on the stack left uninitialized upon function entry. In C, where
pointers are passed around all the time, I would say that is about 5% of
the time that initialized pointers point to user data. read/write
function pointers that get overwritten with crap are very hard to find.
It usually disorients debuggers.
>
> > The class specifier is much more flexible than a simple struct and
> > imposes no implementation overhead.
>
> A struct is only as complicated as you want it to be.
A struct is very simple. a class is a much more powerful implementation.
>
> > A C++ compiler will produce the same object code a C compiler will
> > produce with the same source. (name mangling aside)
>
> Not really an advantage.
The point is that it is not a disadvantage.
>
> > Using the class specifier in C++ would have been a more standard, more
> > maintainable implementation of the class hierarchy.
>
> More standard: for C++, yes
> More maintainable: This can't be proven true or false because it is
> all a matter of taste. If you have many C programmers then perhaps an
> object abstraction would be easier to maintain. Don't forget that GTK
> started in 1996 and the C++ world was no garden (not to mention the
> free C++ compilers of the time).
Not true at all, C++ has been very usable as a C with classes for a very
long time, at least 4 years. The real issues are things like templates
and exceptions which I try not to use because they tend to bloat and
slow code.
>
> > I have been down the roll-your-own class path many times, it is a stupid
> > fight. C++ provides all the facilities that are required to implement a
> > moderately complex class hierarchy, well.
>
> Yes, in 1999 I can see your point here.
No, for at least 4 years.
>
> > C++ classes would have been more efficient than what is in the Gtk.
>
> If you are refering to type-checking, did you know that you can
> disable that after your code is debugged? This 'efficiency' will
> probably be eaten up by slower code from free C++ compilers (although
> the only way to prove this is to write GTK in C++ -- all the way down
> to Glib and GDK).
>
Why do people insist that C++ is generally slow? It is only slow if you
put the things that make it slow in the code. Otherwise it is equivalent
to C. Using it as a C with classes, is not slow.
> > C++ would be less error prone and require fewer castings.
>
> By less error prone, you are refering to your first comment?
Yes and the fact that pointers to the functions are carried around with
the class. So a function call like fubar->funct(...) has built in error
checking at compile time where as funct( (FUBAR *) fubar, ...) depends
on error checking at runtime. If, as you said, you compile that out, you
can easily get hosed.
>
> Yes there would be fewer castings, but GTK uses macros to do this (and
> so that future implementations don't break your source).
In C++ this would not be an issue.
>
> > > That, and there are more C programmers than C++ programmers, the
> > > authors liked C better, C is better supported on multiple
> > > architectures, and C is quicker.
> >
> > The number of C/C++ programmers is a matter of professional growth.
> > They may have liked 'C' better, but that is not a 'technical' decision,
> > it is an emotional decision.
> > Name one platform to which Gnome would ported that could not claim a C++
> > compiler.
> > C code compiled with a C++ compiler is virtually identical to that
> > produced by a standard C compiler.
>
> Go back to 1996, when the decision was made.
In 1996, it was still the best decision.
>
> > > It really is a matter of taste. I can see where event-driven
> > > programming leads to an OO design -- they just chose to implement
> > > their own OO system with an iterative language.
> >
> > I beg to differ. I have yet to see one rational reason why C was the
> > correct choice, when there are numerous reasons why C++ would have been
> > better suited to the task.
>
> Perhaps if they were starting from scratch *today*.
No, even in 1996 C++ was the better choice.
mlw
>
> mlw wrote:
> > I agree, the fringe areas of C++ are questionable, but, in my post - the
> > notion of 'C' with classes has been very stable for some time. The GTK
> > could well have been done with C++ as 'C' with classes, and been much
> > easier to implement and use.
>
> The trouble is that both templates and exceptions have been 'fringe areas'
> of C++ for four years now, and many compilers still differ on how to
> implement them. Some compilers cannot even agree on what:
>
> for (int i = 0;i<n;i++) {
> }
>
> does, or indeed whether it is allowed.
>
is not allowed in C it is not an issue.
> The notion of C with classes is fraught with difficulties and
> inconsistencies, which C++ and Objective C took different approaches to.
> The C++ approach, trying to create a language like C in spirit but with OO
> features, eventually seems to have required the addition at least of
> templates to solve the problems presented by the non-rooted class
> hierarchy.
What are you talking about? A class is simply a struct with features
people have been trying to hack in C for a long time. Templates are just
a way of writing a class that can operate on various datatypes.
>
> Whether and how to use C++ depends on what you want to gain by using an OO
> language. If you want decreased development times and greater potential for
> code reuse the 'C with classes' approach to C++ sucks very badly. This
> isn't intended as a personal issue, its just that I've never come across a
> C++ project with effective reuse of classes, whereas Smalltalk and (to a
> lesser extent) Java projects almost take it for granted. The only advantage
> to using C++ like this is that it is a 'better C'.
I do not have any experience that reinforces this statement. Everything
I have done in the last 5 years proves this wrong. C++ as a better C
with classes is the ONLY way IMHO to write C code.
>
> If you use templates (and preferable the STL), and exceptions in your code,
> you may be faster development than in C (I think the jury is still out),
> but you can kiss portability goodbye. This is, of course, why Qt uses that
> meta-compiler thing.
I haven't looked at the Qt code, I have a thing against looking at
proprietary stuff. Templates and exceptions are badly implemented in C++
and should be used in moderation if at all.
>
> Given what Gtk+ was meant to do, that is to be a portable open widget set
> for X-based platforms, they would have had to use C++ as 'C with classes'.
> As I say above, the benefits of this are pretty marginal, and I agree that
> they are not sufficient to justify the possible portability pitfalls of
> using C++.
Marginal? The way the class system was designed is a disaster. C++ would
have allowed them to be done sooner and it would have been easier to
use. C++ does classes, C does not. To do classes in C, when C++ is
available is just dumb.
>
> > I have not looked at Qt, but, if it uses exceptions as a normal error
> > return path they screwed up. Exceptions are just that, places where
> > exceptional circumstances are taken care of. All too often, developers
> > get lazy and use exception handling as a normal error return path. Duh!
> > no wonder C++ gets a bad rep.
>
> If you examine the use of exceptions in other languages, you will find that
> it is common to use exceptions as the normal error return path. They are
> much neater and provide much more readable code than using the return value
> (which is better used for returning something useful). C++ exception
> handling is error prone, and (until recently) not checked. It is slow, in
> fact typically C++ implementations handle exceptions slower than some Java
> JIT environments. I'm not sure why this is, but I think I heard it is
> something to do with trying to handle code written without the expectation
> of exceptions.
Unless there is CPU and OS provisions for exceptions, they are horrible
to implement. Exception handling with stack unwinding is a big problem
for portable code. Stay away. Templates are code bloat.
>
> > My argument is that the Gtk should not have been written in C, period. I
> > know people are going to take this as a personal insult, but, it is not
> > intended to be.
>
> Thats fine, but I do not think you've done much to justify it. You seem to
> be relying on C++'s image as being more 'modern' and 'the way forward'.
> What do you think the Gtk+ developers would actually have gained for
> themselves or their users by writing in C++ ? As I explained above, I think
> the answer is very little.
Simply using class instead of struct is enough to justify it.
Christopher Browne
>I do not have any experience that reinforces this statement. Everything
>I have done in the last 5 years proves this wrong. C++ as a better C
>with classes is the ONLY way IMHO to write C code.
- Using Emacs to type in C code is a way to write C code.
- Using vi "" "" is a way to write C code.
- Using Stalin to turn Scheme into C code is a way to write C code.
- Using Glade to build a GUI, generating XML, that is then generated
into C, is a way to write C code.
- Using Imperial Software's builder package to generate Motif GUI along
with C, Java, or C++ code, is a way to write C code.
Feel free to hold strong opinions.
Unless you have made the kinds of intellectual contributions to the
programming world that make you a "name," then you're going to have a
tough time convincing people that you're right. People are skeptical
enough when Bjarne Stroustrup makes assertions; you'll have to provide
stronger evidence than you have in order to convince skeptics.
>> If you use templates (and preferable the STL), and exceptions in your code,
>> you may be faster development than in C (I think the jury is still out),
>> but you can kiss portability goodbye. This is, of course, why Qt uses that
>> meta-compiler thing.
>
>I haven't looked at the Qt code, I have a thing against looking at
>proprietary stuff. Templates and exceptions are badly implemented in C++
>and should be used in moderation if at all.
The fact that Qt *needs* to resort to a "meta-compiler" troubles me more
than a little; that adds to the separation between the code that one
writes and the code that one runs.
The fact that it has taken so many years for implementations of
templates and exceptions to "settle down" is certainly a bad sign. I
remember hearing about them being pretty scary features a good five
years ago, and things don't seem to have changed much.
>>Given what Gtk+ was meant to do, that is to be a portable open widget
>>set for X-based platforms, they would have had to use C++ as 'C with
>>classes'. As I say above, the benefits of this are pretty marginal, and
>>I agree that they are not sufficient to justify the possible portability
>>pitfalls of using C++.
>Marginal? The way the class system was designed is a disaster. C++ would
>have allowed them to be done sooner and it would have been easier to
>use. C++ does classes, C does not. To do classes in C, when C++ is
>available is just dumb.
What do you mean, "The way the class system was designed is a
disaster."
Is that:
a) C's lack of the identical functionality to C++ is a disaster?
If so, *C isn't C++.* It was designed before C++, and it is not
reasonable to regard this as a "disaster."
b) C++'s class system design is a disaster?
I can't see that you mean *that,* if you are so promoting the use of
C++ because of classes.
c) GTk's lack of use of C++ classes is a disaster?
This seems to be the most reasonable interpretation of what you said,
and it is also not a fair assessment.
When GTk was written, *G++* was a "disaster." When building a library
for use with free software, it wasn't reasonable to design anything to
use the features of a compiler that wasn't in good shape. GCC was
stable, and had been so for *years.* G++ was not, and had been thus for
*years.*
It's not clear that GCC (including C/C++) has worked its way out of the
"hole;" it is now more than a year since the last GCC release, and there
is no clear evidence of anything new forthcoming. EGCS is a separate
development stream, and there seems to be some troubles in the
interactions thereof. (Note the release and rapid de-release of glibc
2.1...)
>>Thats fine, but I do not think you've done much to justify it. You seem
>>to be relying on C++'s image as being more 'modern' and 'the way
>>forward'. What do you think the Gtk+ developers would actually have
>>gained for themselves or their users by writing in C++ ? As I explained
>>above, I think the answer is very little.
>Simply using class instead of struct is enough to justify it.
That's not justification; that's a bald assertion that isn't justified
without further evidence.
--
Wow! Windows now can do everything using shared library DLLs, just
like Multics did back in the 1960s! Maybe someday they'll discover
separate processes and pipes, which came out in the 1970s!
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/langc.html>
Scott Johnston
Craig Kelley <i...@inconnu.isu.edu> wrote:
> Don't forget that GTK started in 1996 and the C++ world was no garden
> (not to mention the free C++ compilers of the time).
I've been doing Unix/X11 C++ GUI development using exclusively free
compilers since 1990. The interplay between Cygnus and the FSF has
made it a bumpy road. But all it took was constant vigilance with
resolving compile time problems, getting very familiar with "g++ -E"
and nm. Having all the source made it possible. I can't recall a
single compiler introduced run-time error.
That, and Per Bothner, the unsung hero of free C++, who guided his
implementation of iostreams into and out of the belly of libg++, to
libstdc++ where it lives happily today.
Scott Johnston
Vectaport Inc.
http://www.vectaport.com
Navindra Umanee
> : Too bad they screwed that maximum portability again with gnome :(
>
> I am not sure what you mean here. Can you explain a bit more?
He's probably implying that GNOME is not as portable as it should have
been despite using GTK. I wouldn't know, but I've seen folks running
FreeBSD complain.
Bart Vanhauwaert
: The biggest difference between C and C++ is that C has a very
: deterministic 1:1 relationship between the source and the produced
Wether there is a deterministic 1:& relationship between the source
and the produced object is entirely up to the compiler (at least
in C's case).
And if it where, I wouldn't consider that to be the biggest
difference between C and C++ (it isn't).
: object. It is possible to have a solid understanding of what the
: compiler is doing in one screen of information. C++ can be like this if
Are you making sense here? (ok, this is .advocacy, shouldn't expect
that, but still).
: you are careful. This is how I use C++. I have seen projects where
Great, now you are contradicting yourself, because the biggest
difference isn't there if you are careful.
: operators have been overloaded, multiple inheritance used, and one can't
: tell from a specific screen, what the compiler would do without having
: all the parent classes drawn out in a tree, and operators listed, even
: then you would have to have a very fine understanding of the nuances of
: the language to figure it out.
That's entirely up to the style of the programmer. I could easily provide
you with C programs where it isn't at all possible to have
'a solid understanding of what the compiler is doing in one screen'.
Just as I can provide C++ programs using operator overloading,
multiple inheritance, plentyfull of templates salted with a bit
of STL, which are perfectly clear to anyone knowing C++.
: Just as a nail-gun can be used to nail your hand to a board, it can
: still save man-weeks when building a house. Just because a tool requires
: care and thought, does not men it should not be used.
What is your point? Because you can hurt yourself with a nailgun,
don't use the nailgun? Great advice for children, but not for the
professsional wanting to get the job done. Let me remind you that you
started this discussion stating that one should use C++ as C with classes.
cu bart
--
__
| Linux also needs a Grock or a Krock , Like in Yosemite.
Bart Vanhauwaert
:>Too bad because C++ is really enjoyable. And if you're
:>well versed in it, there is no problem using the more advanced stuff
:>like exceptions, templates, RTTI and namespaces. And of course there is
:>the killer advantage of the STL...
: What killer advantage? The advantage of being able to make denser
: and more unreadable spaghetti code?
The advantage of not having to rewrite code to handle linked lists,
arrays, and simple algoritms over and over again (and have them
type safe of course). Where you get the spaghetti code idea from
I just don't know.
: I wrote a large wad of a commercial product in C++ a few years back
: (1997, to be precise), used g++ to compile it and gcc to link it,
: because it didn't use any of the spaghetti inducing misfeatures of
: C++. This product has been cancelled, so the company decided to
: Open Source(tm)(c)(r) it and I went back and tried to rebuild it
: with egcs because this company had switched to a Modern! Object!
: Oriented! C++ antiviral scanner that would not compile under g++
: (or egcs, for that matter.) I quickly discovered that egcs
: promiscuously drops catch and throw into binaries, thus making
: them unlinkable against standard libc.
O great. Bring up a specific compiler problem, when discussing a
language. And even a problem in an open source environment where you
can fix anything you want. (Don't bother, because it already has
been 'fixed').
Navindra Umanee
> interface to C++ libraries.
Okay, I'll profess my ignorance: What do you mean by "object model"?
I checked my Stroustup book and it doesn't have "object model" in the
index.
Thanks,
Navin.
Donal K. Fellows
David Z. Maze <dm...@donut.mit.edu> wrote:
> (What, also, is TRTTD with a divide-by-zero exception? Should this be
> handled using C++ exceptions in a C++ program? A Unix signal? Always
> call abort()?)
TRTTD is to return either +inf, -inf, or NaN depending on what was
being divided. Using IEEE math, that is.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
Department of Computer Science, University of Manchester, U.K. +44-161-275-6137
--
"And remember, evidence is nothing." - Stacy Strock <sp...@adisfwb.com>
Donal K. Fellows
Bart Vanhauwaert <ja...@jafshome.gv.kotnet.org> wrote:
> O great. Bring up a specific compiler problem, when discussing a
> language. And even a problem in an open source environment where you
> can fix anything you want. (Don't bother, because it already has
> been 'fixed').
Great, so you're suggesting that when someone is starting a *major*
Free Software project they should make sure that it can only be
properly compiled vith Visual C++?
The flamefest over Qt would be as nothing in comparison.
o r c e l l . p o r t l a n d . o r . u s
Bart Vanhauwaert <ja...@jafshome.gv.kotnet.org> wrote:
>O great. Bring up a specific compiler problem, when discussing a
>language. And even a problem in an open source environment where you
>can fix anything you want. (Don't bother, because it already has
>been 'fixed').
Why bother? When the C++ compilers of today get debugged the C++
standards committees will have gone on and designed another batch of
incompatable things into the language. And then to stay up to date
with the language, I'd get the option, once again, to either switch
to Microsoft Windows or deal with a dozen naive implementations in
gcc before they got it right.
These days, I'm just hoping that egcs has a compiler switch that
tells the c++ frontend that this code will be linked against libc
and nothing but libc. In the future, I'll think about using
Perl, because there's no illusion that Perl will stay the same
from one dot release to the next.
____
david parsons \bi/ If I wanted catch and throw, I'd ask for catch and
\/ throw.
o r c e l l . p o r t l a n d . o r . u s
Bart Vanhauwaert <ja...@jafshome.gv.kotnet.org> wrote:
>o wrote:
>:>O great. Bring up a specific compiler problem, when discussing a
>:>language. And even a problem in an open source environment where you
>:>can fix anything you want. (Don't bother, because it already has
>:>been 'fixed').
>: Why bother? When the C++ compilers of today get debugged the C++
>: standards committees will have gone on and designed another batch of
>: incompatable things into the language. And then to stay up to date
>
>freeze for at least 5 years now.
>
>: with the language, I'd get the option, once again, to either switch
>: to Microsoft Windows or deal with a dozen naive implementations in
>: gcc before they got it right.
>
>get it right. You sound rather insulting the hard (and good) work of
>a bunch of experts working on the C++ side of egcs. Yes, a good C++
>is hard, never said it wasn't, but after all, all major components
>are (were hard). You've lived the early days of the Linux kernel,
Yes.
>you've lived the numerous X bugs,
No.
>you've had the gcc pre 2.0 and
No.
>you've 'done' glibc or early libc,
I don't have the vaguest idea what you're talking about here.
>use lesstiff for mozilla.
No.
What's your point? Is it that because I use Linux I should attempt
to use it as a development platform, but that I should attain
hacking nirvana by following the code of the week club?
I don't think so.
____
david parsons \bi/ C++ can be a pretty spiffy language. Too bad it
\/ comes with C++ fanatics.
Bart Vanhauwaert
:>O great. Bring up a specific compiler problem, when discussing a
:>language. And even a problem in an open source environment where you
:>can fix anything you want. (Don't bother, because it already has
:>been 'fixed').
: Why bother? When the C++ compilers of today get debugged the C++
: standards committees will have gone on and designed another batch of
: incompatable things into the language. And then to stay up to date
You should inform yourself of the ISO regulations. There is a standards
freeze for at least 5 years now.
: with the language, I'd get the option, once again, to either switch
: to Microsoft Windows or deal with a dozen naive implementations in
: gcc before they got it right.
gcc is a C compiler. egcs is your C++ compiler of choice and they _do_
get it right. You sound rather insulting the hard (and good) work of
a bunch of experts working on the C++ side of egcs. Yes, a good C++
is hard, never said it wasn't, but after all, all major components
are (were hard). You've lived the early days of the Linux kernel,
you've lived the numerous X bugs, you've had the gcc pre 2.0 and
you've 'done' glibc or early libc, use lesstiff for mozilla.
These were all hard projects, have there flaws and have had their
bugs and difficulties, despite the many talented people working on them.
cu bart
Kevin Brown
>In article <921117230.873420@marvin>,
>Bart Vanhauwaert <ja...@jafshome.gv.kotnet.org> wrote:
>
>>That and of course, another, there is a very strong anti-C++
>>sentiment in the free software world. There is a lot of conservatism
>>as I see it.
>
> If conservatism means `expecting your code to keep working',
> well, yeah, there might be some conservatism.
>
>>Too bad because C++ is really enjoyable. And if you're
>>well versed in it, there is no problem using the more advanced stuff
>>like exceptions, templates, RTTI and namespaces. And of course there is
>>the killer advantage of the STL...
>
> What killer advantage? The advantage of being able to make denser
> and more unreadable spaghetti code?
>
> (1997, to be precise), used g++ to compile it and gcc to link it,
> because it didn't use any of the spaghetti inducing misfeatures of
> C++. This product has been cancelled, so the company decided to
> Open Source(tm)(c)(r) it and I went back and tried to rebuild it
> with egcs because this company had switched to a Modern! Object!
> Oriented! C++ antiviral scanner that would not compile under g++
> (or egcs, for that matter.) I quickly discovered that egcs
> promiscuously drops catch and throw into binaries, thus making
> them unlinkable against standard libc.
This appears to have been fixed (ermm...that is, they provide a way of
turning off exceptions and leaving them on doesn't appear to affect the
linkage of the program), at least for the simple case. The following
code compiles with egcs (1.3.0a-14) and links against standard libc
without any problems. Note that if you *really* don't want exceptions,
though, you have to use -fno-exceptions:
[kevin@dimwit /tmp]$ egcs -c foo.C
[kevin@dimwit /tmp]$ egcs -o foo foo.o
[kevin@dimwit /tmp]$ ls -l foo
-rwxrwxr-x 1 kevin kevin 77292 Mar 21 00:49 foo
[kevin@dimwit /tmp]$ ldd foo
libc.so.6 => /lib/libc.so.6 (0x40006000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
[kevin@dimwit /tmp]$ nm foo | grep throw
08049414 T __sjpopnthrow
08049308 T __sjthrow
08049724 T __throw
08049be0 T __throw_bad_cast
08049c34 T __throw_bad_typeid
080492b8 T __throw_type_match
0804ada0 T __throw_type_match_rtti
[kevin@dimwit /tmp]$ egcs -fno-exceptions -c foo.C
[kevin@dimwit /tmp]$ egcs -o foo foo.o
[kevin@dimwit /tmp]$ ls -l foo
-rwxrwxr-x 1 kevin kevin 27248 Mar 21 00:50 foo
[kevin@dimwit /tmp]$ ldd foo
libc.so.6 => /lib/libc.so.6 (0x40006000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
[kevin@dimwit /tmp]$ nm foo | grep throw
[kevin@dimwit /tmp]$ cat foo.C
#include <stdio.h>
class foo
{
private:
int x;
int y;
public:
foo();
~foo();
void print(void);
};
foo::foo(void)
{
x = 1;
y = 2;
}
foo::~foo(void)
{
printf ("foo: Goodbye, cruel world!\n");
}
void foo::print(void)
{
printf ("x = %d, y = %d\n", x, y);
}
int main (int argc, char *argv[])
{
foo x;
x.print();
}
[kevin@dimwit /tmp]$