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
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng