Now, this might become somewhat rant-and-rave-ish, highly off-topic and
asbestos underpants are highly recommended.

You have been warned :-)

On Fri, 23 Nov 2001, Guillaume Laurent wrote:
> Any mildly complex C++ program will bend of break this rule in one way or
> another.

Why? Because of existing libraries (of which you'll notice that STL does
none of this "nonsense") has made it status quo or because it is
impossible?

> The "new it, delete it" rule isn't something you should enforce
> for the sake of it, it's an indication to help you making less mistakes.

Yes, and Qt won't let me enforce it, and I keep making mistakes. :-)

> But if the language can get you rid of the burden of a stupid task (which
> it should in the first place), what's the problem ?

	!moc.part_of?(C++)

> Ob-Ruby : would you prefer it if Ruby wasn't a GCed language ? Of course
> not.

You haven't tried running Ruby programs of some size under low memory
constraints, have you? To your question, no I prefer Ruby being GC'ed, but
that isn't an "of course" thing any more than "new it, delete it" is a
moral mantra.

> So there you have C++ turned into an "almost GCed" language... May be
> te "almost" can puzzle you, but frankly I'll take every bit of help I can
> get.

The Qt widget parenting ownership (dunno about Qt3 on this subject,
maybe it has improved), is far from delivering "almost GC",
but makes predicting destruction sequences about as much a gambling
activity as with GC. Destruction sequences is of alot more importance in
C++ than in Ruby.

[snip me on destructor sequence bugs]
> I can't answer on this one, as I never had such problems with Qt.

For the sake of argument, lets assume that my co-worker and I were idiots
when we wrote code that seg-faulted due to destructor sequence
dependancies. Now, the Qt parent widget ownership helps us idiots by
removing one common error (memory leaks) and introduces a less frequent,
but harder to figure out bug (destructor sequence bugs).
	Just when something is idiot-proof, someone makes a better class
of idiot. :-)


> In practice it's just a couple more lines in your Makefile (or you just
> don't see it at all if you use qmake or KDE's autoconf stuff).

Its not that its a practical problem, it just gets my "spidey senses
tingling." Code smell. Asymmetry. You know, those bad esoteric qualities
that Ruby doesn't have any of.

> This is where you're wrong : it's not a crutch, it's a pair of jet-powered
> boots.

I'd prefer a Jet-powered backpack (or wheelchair) if my leg(s) were
broken. (Ok, ok, Qt has a lot of nice things, but signals and slots aren't
what they should be flaunting.)

> Ob-Ruby again : what I liked in Ruby compared to Perl is that it uses plain
> words where Perl uses cryptic operators or constructions. Likewise, I
> prefer to see "slots" and "signal", rather than "some special template
> declaration".

But you wouldn't see that! The beauty(?) of C++ templates is that you
won't see much of the "special template declaration" gibberish when you
use it, provided that some C++ template guru made the templates and that
your compiler isn't broken.

> Beyond all standard compliance consideration, it's just plain
> more readable.

.... only given the broken status of certain compilers. Have you looked at
the wonderful magic done in the Boost libraries? ( www.boost.org ) The
usage of their templates are quite readable. (thou their definitions may
be somewhat more of a brain-twister. )

I'm afraid I still mostly agree with Al Stevens on the critique of Qt. But
I hope we can agree to disagree before I dig myself into a hole and end up
sweating over C++ to prove points instead of nice Ruby code that I want to
write...  ;-)

-- 
<[ Kent Dahl ]>================<[ http://www.stud.ntnu.no/~kentda/ ]>
  )____(stud.techn.;ind.?k.data)||(softwareDeveloper.at(Trustix))_(
 /"Opinions expressed are mine and not those of my Employer,      "\
( "the University, my girlfriend, stray cats, banana fruitflies,  " )
 \"nor the frontal lobe of my left cerebral hemisphere.           "/