On 7/24/2015 3:57 AM, Roger Leigh wrote:
First, thank you for the reply, Roger. I supremely appreciate it.
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.
Yes, I figured it was something along those lines. As I mentioned in a
previous email, my experience with GTK has been mercifully small. I can
certainly understand why you would get annoyed. I'm something of a C
aficionado so using pointers to do this does not bother me, but that
said, it is very to make a mistake.
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.
I apologize for the confusion on my part. I see what you meant. When
people say the phrase "type-safe" in relation to C/C++ I'm left to wonder.
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.
That is true to some degree. I don't agree entirely. It really depends
on the compiler and what settings are being used. GCC is not the
world's greatest compiler by any stretch of the imagination, and there
are a lot of extraordinarily lazy FOSS programmers who ignore warnings,
and do not initialize variables before using them. No one can blame you
for disliking the fact that GTK tends to leak references (at least from
warnings I seen on the console) when using Linux. That's entirely out
of your hands. If I had to critique GTK based on what little you have
told me, I'd say it was probably a bad design, trying to force OOP in C.
That is not to say that OOP cannot be done in C, but as a programming
paradigm, I personally feel that OOP is a very flawed idea. I've been
programming for a long time, and to be perfectly honest, I have seen
very few cases where OOP methodology actually makes things "better".
There are some nice features, but I don't buy the whole idea as actually
making software development easier. I'd sacrifice most of those features
in a heartbeat not to have to deal with exceptions.
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 is not to say that I have anything against bounds checks, and
strong typing - both of which I think are a good idea. I'm old
fashioned but I have always felt that saddling a compiler with
babysitting a programmer 24/7 is a bad idea. More often that not, it
creates uncertainty, poor performance, random memory leaks, bad coding
practices, and ridiculously complex language constructs - all in the
name of trying to do the job that the human should be doing in the first
place, with proper and rigorous training.
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.
I would qualify that statement by saying you have not had a leak as
long as an exception was not generated.
Take care!
T.J.
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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
