Re: [gtkmm] the future of gtkmm

[Ian Michell <ian michell hanzi co uk>]

Matthew Walton wrote:

> Paul Grenyer wrote:
>
> > Hi
> >
> >
> > > That's not an uncommon opinion, but the fact is that C++ is far from 
> > > bullet-proof. If GNOME was going to change language entirely, I 
> > > don't think it would actually be a good idea to use C++, it just 
> > > doesn't offer enough of an improvement. It would have to be 
> > > something garbage collected I think.
> >
> >
> >
> > We're probably going to have to agree to disagree over this, but...
> >
> > No language is bullet proof, but C++ offers a significant improvement 
> > over C. I actually feel that garbage collection is a bad thing and 
> > toally unnecessary.
>
>
> Certainly, C++ is better than C, but I'm not convinced it's better 
> enough that porting the entirety of a large C-based platform (such as 
> GNOME) to it would be a good idea. It's still extremely possible to 
> write incredibly stupid code in C++, and some of it's incredibly hard 
> to debug.
>
> Not, perhaps, that some other languages offer easy debugging either, 
> but there is something very demoralising about repeatedly getting 
> 'segmentation fault'.
>
> > The main disadvantage is that you cannot determine at what point the 
> > object is destroyed. Also, the same behavoir with deterministic 
> > delete can be achieved using smart points and code can be wirtten in 
> > such a way as to force users of a class to use smart pointers.
>
>
> As gtkmm exhibits. Smartpointers are something I've not really looked 
> into properly yet - I suspect perhaps that if I tried using them at 
> work I'd get taken out and shot. We still seem half stuck in C most 
> days :-( Of course, my ideal would actually be some kind of language 
> like the not-yet-finalised Perl 6... but compiling to code that 
> competes with C++ in terms of sheer speed. It remains to be seen how 
> fast Perl 6 will actually be, but I doubt it can be as fast as that. A 
> shame, but I guess that's just physics for you.
>
> > If you are an ACCU (www.accu.org) member read my article in the 
> > latest overload. If you are not, join, it's the best £25 you'll ever 
> > spend as a developer. I'll try and get my article onto my webiste for 
> > everyone else.
>
>
> I'm not a member. Looks interesting though.
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
C++ is a very hard language to debug in certain circumstances, but in 
the end an object orientated language is a lot more managable than a 
structured language like C. Garbage collection is a good thing though, 
as much as I am a C++ junkie, I would prefer to write quick and nasty 
apps in a managed language like Java or in a scripting language like 
python or php. Don't forget (and this is important) that a lot of the 
developers we are trying to reach are not at the same level as most 
Kernel/Gnome/GTK/KDE developers and would be better suited in using a 
language that provides features like garbage collection to write 
applications. Lets leave the low level stuff to the guys who want that 
little extra control, where you can optimize right down to the hardware 
level with C/C++ and let the rest use a managed and/or scripting language.

Although C/C++ is vastly superiour to any scripting or managed language 
that I have seen, I would tend to say that they have a big advantage 
over a C/C++ program in the sense that it is a lot easier to make a big 
fuck up in C/C++. Believe me I know, when I first started out with C/C++ 
I lost count of the segmentation faults and memory leaks, something of 
which every C/C++ developer is familiar with. No matter how good you 
are, you will never get over this problem, unless of course we have an 
API that handles it for us, in which case THAT DEFEATS THE POINT I JUST 
MADE. :-P

Anyways that my 2p

Ian