On 24/07/2015 05:14, T.J. Duchene wrote:
On 7/23/2015 10:41 PM, Isaac Dunham wrote:
Now then, as for Roger's comments, I find them confusing.
[snip]
The C API is overly complex and fragile. You don't want to base your
project on a sandcastle. And the expertise required to use it is
very high. Implementing dynamic typing and manual vtable construction
rather than using C++ which does proper type checking? Just use C++!
C and C++ are both strongly typed, so I am assuming that he must be
referring to GTK using a pointer in C presumably to dynamically handle
function names and data for polymorphism. He can't help it if GTK is
sloppy, but I can't make sense of his grievance either. Type checking is
never C's job, it's his! That is explicit in the design of the
language. Everyone who uses C knows that. C++ is the same for that
matter. Neither language checks your variable data for type.
I'm referring to the *GTK* "C API" here. Not C in general. If I create
a GObject-based "class", either as a subclass of a GTK class or as an
independent class subclassed from the root GObject, I have to *by hand*
construct a virtual call table and *by hand* register all the class and
object construction and release functions, along with the instance and
class structures with the GType type system. This is work which the C++
compiler would have done for me, with no added complexity, and no chance
for me to introduce bugs into the overly complex mess. On top of that,
the C++ class would be completely type-safe in all respects where the
GType system requires allmost all type safety to be discarded to
implement polymorphism.
The C++ compiler objectively does a better job here. It's simpler,
quicker to write, safer, easier to refactor. And when I've done a full
conversion of GObject-based C code to C++, the C++ compiler has picked
up on real bugs which the C compiler hadn't picked up on (because the
type information had been deliberately cast away). GTK+ programs can be
riddled with bugs, without the developer being any the wiser in the
absence of compiler diagnostics.
I've always noted the GTK code tends to leak. If programmers with
experience can't be bothered to clean up after themselves, I'm glad GTK
is dying off.
It's really not so much "can't be bothered" as much as it's very
difficult to manage all the manual reference counting. In C++ with
GTKmm it's all handled with smartpointers, making it impossible to screw
up. In regular C++ you have unique_ptr, shared_ptr etc. to do it for
you as well.
The main point of my original post and in the above comments isn't that
GTK+ and C can't work. They can. It's that the effort required to
achieve a bug-free program is absurdly high, and in practice it's not
even possible to verify that your code is actually bug free, and this is
a problem that becomes increasingly intractable as the program size and
complexity increases. This is because the underlying unwritten
assumption is that "the programmer will be perfect and not make
mistakes". It's quite obvious that no programmer is perfect, even great
programmers make mistakes. The contrast with C++ is that the assuption
here is that the compiler will shoulder the burden and will fail to
compile if there are any mistakes, since the presence of strong typing,
RAII and smartpointers will guarantee correctness. This too also has
its limits, but put it this way: I haven't had a memory leak in C++ code
in a decade due to the use of shared_ptr, and this isn't something I can
say for my GTK+ C code, or GTK+ C code in general.
In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively.
[snip]
That's somewhat true, but if you write C++ code PROPERLY - i.e. make
sure you references are clean, resources released, and you aren't
leaving any hanging exceptions, what he is claiming is pretty much a
non-issue in the context of any OOP language. A C++ compiler is no more
mysterious that any of the other OOP crap we are forced to endure. C++
code is simply not as robust as C. You can mitigate a lot of the
annoyance; like exceptions that cause premature exits - but you are
never really rid of it.
This is not what I meant.
The sentence above should read "you have to be an expert in C++ compiler
internals just to be able to understand and use [the GTK/GObject type
system] effectively". I'm referring to the fact that you have to
construct GObject virtual call tables by hand, something which the C++
compiler does for you, and which a C++ programmer doesn't in fact need
to care about (it being an internal implementation detail of the
compiler's code generation). That is to say, to effectively use a C
library you have to be more familiar with the internal details of C++
than most C++ programmers, and for absolutely zero benefit.
I think a lot of GTK's problems could be solved if it were rewritten to
take advantage of C11, but I don't see that happening. I doubt Gnome
has enough people willing to do it.
Honestly, I thought many years ago its only chance of a future was to
move the implmentation into the GTKmm bindings and make that the primary
implementation rather than a thin wrapper. But that's clearly not going
to happen. The deficiencies of C and objects and polymorphism in C are
at the root of why GTK+ has endemic quality and complexity problems, and
why its use has become so vanishingly small. But the core developers
are unwilling to acknowledge this reality.
Regards,
Roger
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
