Gtk and C++, again.

조회수 39회
읽지 않은 첫 메시지로 건너뛰기

mlw

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
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. 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
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.
--
"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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
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+.

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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
Navindra Umanee wrote:
>
> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
J. Mark Brooks wrote:
>
> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
mlw <ma...@mohawksoft.com> writes:

> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
mlw <ma...@mohawksoft.com> writes:

[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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
Craig Kelley <i...@inconnu.isu.edu> wrote:
> I love GNOME. It provides *real* services for easy programming.

KDE/Qt has no *real* services? Something is missing perhaps?

Navindra Umanee

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
mlw <ma...@mohawksoft.com> wrote:
> So it is a rock and a hard place, QT is better architecture but not GPL,
> Gnome is GPL but poor architecture.

http://www.troll.no/qpl/

Arthur

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
mlw wrote:

> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
mlw wrote:

> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
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.

> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
In article <slrn7e2mmd....@pm1-20.gso.infi.net>,

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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
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
my desktop for a year (up until GNOME-0.98 -- which was a better
release than 1.0, but anyway.....)

Craig Kelley

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
perr...@my-dejanews.com writes:

> 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
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.

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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
Navindra Umanee <navi...@cs.mcgill.ca> writes:

> > 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

읽지 않음,
1999. 3. 6. 오전 3:00:0099. 3. 6.
받는사람
perr...@my-dejanews.com writes:

> 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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
In article <m1iucec...@inconnu.isu.edu>,

Craig Kelley <i...@inconnu.isu.edu> wrote:
> perr...@my-dejanews.com writes:
>
> > 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.

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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
Craig Kelley <i...@inconnu.isu.edu> wrote:
> 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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
> buttons. gmc can't do root window icons without a GNOME window
> 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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
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.

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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
On Sat, 06 Mar 1999 17:58:30 +0000, mlw <ma...@mohawksoft.com> wrote:

>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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
On 06 Mar 1999 17:17:04 -0700, Craig Kelley <i...@inconnu.isu.edu> wrote:

>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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
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.

>
> > 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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
Navindra Umanee wrote:
>
> 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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
On Sun, 07 Mar 1999 03:49:07 +0000, mlw <ma...@mohawksoft.com> wrote:

>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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
David M. Cook wrote:
>
> On Sun, 07 Mar 1999 03:49:07 +0000, mlw <ma...@mohawksoft.com> wrote:
>
> >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.)

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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
On Sun, 07 Mar 1999 00:59:40 -0800, Arthur <afr...@usa.net> wrote:

>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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
In article <36E1F733...@mohawksoft.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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
In article <m1678dk...@inconnu.isu.edu>,
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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
In article <36E1FD09...@knotwork.com>,

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

읽지 않음,
1999. 3. 7. 오전 3:00:0099. 3. 7.
받는사람
On Sun, 07 Mar 1999 00:14:01 -0400, Mark Metson wrote:
>Navindra Umanee wrote:
>>
>> 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?

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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
mlw <ma...@mohawksoft.com> wrote:
: J. Mark Brooks wrote:
:>
:> 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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
Arthur <afr...@usa.net> wrote:
: 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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람

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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
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.

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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
Karl Nelson wrote:
>
> 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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
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?

>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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
mlw <ma...@mohawksoft.com> wrote:
: Karl Nelson 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.
:>
:> 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

읽지 않음,
1999. 3. 9. 오전 3:00:0099. 3. 9.
받는사람
It was the Tue, 09 Mar 1999 18:45:49 +0000...
..and mlw <ma...@mohawksoft.com> wrote:
[schnibble]

> This is speculation, don't bother.
[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.]

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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
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.

>
> >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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
In article <36E5F49B...@mohawksoft.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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
On Wed, 10 Mar 1999 04:27:07 +0000, mlw <ma...@mohawksoft.com> wrote:


>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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
When you purchase the compiler, you are free to distribute anything you
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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
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?

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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
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.


>
> 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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
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?

-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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
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--?

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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
Matthias Warkus wrote:
>
> It was the Tue, 09 Mar 1999 18:45:49 +0000...
> ..and mlw <ma...@mohawksoft.com> wrote:
> [schnibble]
> > This is speculation, don't bother.
> [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

읽지 않음,
1999. 3. 10. 오전 3:00:0099. 3. 10.
받는사람
Craig Kelley wrote:
>
> 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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.
받는사람
mlw <ma...@mohawksoft.com> wrote:
> 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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.
받는사람
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?
>
> -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/ >

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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.
받는사람
On Wed, 10 Mar 1999 15:04:19 +0000, mlw <ma...@mohawksoft.com> wrote:
>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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.
받는사람
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]
>> > This is speculation, don't bother.
>> [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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.
받는사람
mlw <ma...@mohawksoft.com> wrote:
:> "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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.
받는사람
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]
> >> > This is speculation, don't bother.
> >> [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

읽지 않음,
1999. 3. 11. 오전 3:00:0099. 3. 11.