Re: [anjuta-devel] Sharing code between Nemiver and Anjuta

[Hubert Figuière <hub figuiere net>]

On 26/06/13 04:59 PM, Sébastien Granjoux wrote:

[...]

> GCC is using only libc.

GCC is a compiler.

> Anjuta uses GLib which provide much more
> functions, including a lots of container objects without the need of STL.

It think if we do the intersection of what Glib provide and what STL
provide, there is little in common. Also Glib provide stuff that is not
needed when you use STL because STL relies on C++, and STL provide type
safe container and generic algorithm that make glib look like assembly
language.

And one doesn't exclude the other, if you use C++.  Glib is more the
support library for Gtk+ than a library for generic programming like the
Standard C++ Library (née STL).

In the end, neither is required. G++ even offer the option to not use
the Standard C++ Library. Just that today it doesn't make sense to not
use it.

[...]

> > Hmmh, actually, not exactly.  We are using Gtk+, yes, but only through
> > Gtkmm. I am not pushing for Gtkmm for religious reasons.  Rather, it's
> > ultimately to have a code base that crashes and leaks less, without
> > having to spend "big" amounts of time doing testing.
>
> Yes, I see you use only Gtk+ not the whole GObject platform.  I
> understand your point but, just out of curiosity, why do you use gtkmm
> instead of Qt if you think C++ is much better?

I think the question if heavily wrong as in both case it is a C++
toolkit. The use of Gtkmm isn't mandatory, even in C++, there are a few
examples like AbiWord, LibreOffice or Firefox that use Gtk, but not
Gtkmm and that are written in C++.

The question is why using Gtk instead of Qt, and I think it goes along
why using Gnome instead of KDE. I'm sure that if Nemiver was written
using Qt, you wouldn't even be discussing the integration.

Gtkmm alievate lot of the pain of using Gtk in a C++ code base, but it
brings in its layer.

> I have the impression that gtkmm has less maintenance than Gtk+ and you
> need a few additional conversion to pass some data.

It follows the Gtk+ release and get the new APIs as they come. What
makes you thinkg it has less maintenance. It does not as much
maintenance as it is only wrapping APIs, not writing a toolkit.

> Moreover, why do you rely on a library, Gtk+, written using C and so
> having more crashes and leaks? Do you think that are much more resource
> on Gtk+ to do all tests?

I think you totally missed the point here. It is not about Gtk+ written
in C with lot of crashes and leaks. It is about user code that is harder
to write without crashes and leaks. Gtkmm solve most of these issues
rather intelligently using C++ main features, notably the RAII paradigm,
templates and typesafe signal handling.

[...]

> On the other hand,
> compiling C++ takes more time and GLib is doing quite a lots of checks
> at run time.

How about you write everything in Python or Javascript. Everything is
checked at runtime....

I personally rather have the compiler tell me there is an error than
discover eons later the error because it is a seldom used code path. And
having the compiler check once when you compiler doesn't preclude from
checking at runtime. But most of the runtime check are no longer needed.
Strong typing (C++) vs weaker typing (C). Even without using C++ you
could compile plain C code using the C++ compiler and find a lot of bug
by fixing compiler errors and warnings. Been there, done that.


> > And having that, while sitting on the giant shoulders of
> > C, in such a way that you can just copy-paste code from C code bases,
> > compile it and use is w/o *needing* to wrap feels like another silver
> > bullet.  And of course, we can rely on a mature and versatile
> > toolchain these days.
>
> Yes, but C is even better in this regards and the toolchain is more mature.

The maturity level is the same C or C++. It is 2013, not 1995. We have
TWO free software compilers with a very close support of the language
standards and good code generation. GCC on one side and clang/llvm on
the other side. That's maturity.

> Another option is vala, the toolchain is no very mature, but I think
> it's easier to write than C++.

The fact that you even suggest it.... ok I see the bait right here.

> Then gobject introspection provide this advantage to quite common
> languages like javascript or Python. And if you want to write code
> faster, I think it's a much better option than C++.

*sigh*
Run faster? Debug faster?


> > Yeah.  Assuming we can devise a library for the stuff you guys find
> > worthwile, if there is value for Nemiver to use that library, I'd be
> > glad to have a library external to Nemiver, that Nemiver depends on.
> > Anjuta could then depend on that same library, too.
>
> Good but it's not very useful for Anjuta unless people from Nemiver work
> on this library which has to be in C. Are you willing to program or fix
> bugs in C for a library used by Nemiver? GDL by example?

May I remind WHO was the first to propose this? I think Dodji had
explored the idea a long time ago, and reached the conclusion to not bother.

You came back propose the idea, patches welcome™ (not speaking for
Dodji, but my unnderstanding here is that he does not have the time or
motivation to do the work that way, but he is absolutely not against
accepting a contribution - I wouldn't either if I was him)

[..]

> > Yes, I am not a fan of GObject at the application development level
> > because the macro soup that comes with it makes it too error prone,
> > leading to a more crashy user experience than I'd like to accommodate.
>
> Obviously there is much less type checks are compile time but there are
> quite a lots of checks are run time, it makes the code a bit slower but
> it allows to detect most issues.

See above for my comment about runtime vs compile-time checks. It detect
"most issues" when you are about to execute them. Sorry, when your END
USER is about to run through them. That mean the person that can fix
them doesn't necessarily hit them. This should be at least the second
line of defense, not the first as you argue.


> Boilerplate code is a bit annoying to write but it could be partially
> generated (Anjuta do it) and it is quite straight forward, I don't think
> it leads to more bugs. One advantage is that you can see it, while in
> C++ this code mostly exist but is generated by the compiler directly in
> assembler.

No. You see it. That's what C++ is about. Object oriented programming,
with a language that specifiy the object orientation.

I can't read the soup that is GObject source code, with all the macros
and others. I can read the C++ code quite well.

[...]


> > I am not interested in consuming GObject at the application level in
> > Nemiver because from where I sit today, and seeing all the advantages
> > we are experiences from using a C++ interface like IDebugger, I hardly
> > see any value in going back to something as low level as GObject.
> > I'd like to hear opinions that would proved me wrong, though.
>
> I see GObject at a higher level that C++ object, it provides much more
> features and is quite close to object in dynamic languages. I think it
> has some advantages compared to C++:
>
> * No need for bindings for using GObject libraries.

Nor is it needed in C++. AbiWord, LibreOffice, Firefox all use Gtk+
directly, as well as other C libraries.

[...]

> On your side, you already have wrappers to use GObject in C++ and you
> use them for GDL and Gtk+

You seem to misunderstand here how Gtkmm works.

[...]

> By the way, I think std::string is a quite good example. Indeed
> comparing to pure C which has a quite limited support for strings, and
> in particular doesn't take care of allocating the memory, std::string is
> a big improvement. Now comparing to Glib string functions and string
> object, std::string cannot handled UTF8, 

Yes it can. There are plenty of scenarios where std::string a completely
capable of dealing with UTF-8. Much like with a C string (char *)

> miss printf format string, case
> insensitive compare, strip spaces, escape characters... In fact,
> std::string is so good that I think every C++ library has written its
> own string class.

Ahaha. Not since the 2000... And that was because of people's aversion
to the STL or others.
Also you can use std::string, pass its C-string to anything from Glib
(or other string library that takes C-string).

> So it's nice to have std::string but it's no really
> comparable to GLib, you need something else to compete.

Glib::ustring? It is a wrapper around std::string btw, with some
features needed to deal with Unicode characters, the backend encoding
being UTF-8. It also provide "compose" which provide format like features.

I don't see where the issue is here. Nemiver is already a Gtkmm
application, so there is already these, wrapped in Glibmm or not.

I myself tend to use boost for dealing with strings. (hint: it is just a
set of utilities, including boost::format, that deal with std::string)

BTW it is hard to compete with RAII that you don't have in C. Memory
leak with std::string (or Glib::ustring) ? Pretty hard to achieve. Can't
say that much with all the glib function that return a pointer on which
you have to call g_free().

[...]

> I understand your point but it makes the code of Nemiver more difficult
> to share as it forces people to use C++.

You asked.

To me it look like the same consensus: "C++ is dirty, it suck, I don't
know it. Let's do some more DIY to implement stuff C++ already provides."

And I find that trying to convince seasoned developers that they
shouldn't be using C++ but use C is in pretty bad taste, even more when
none of your arguments are valid.


Hub