On 24/07/2015 23:24, T.J. Duchene wrote:
>
>
> On 7/24/2015 5:03 AM, Didier Kryn wrote:
>>

>>     Hey T.J., you seem to contradict yourself when saying "C and C++
>> are strongly typed" and "Type checking is never C's job." :-)

>>

>>     Actually, yes, C and C++ are typed, but weakly. They silently do
>> type conversion in pretty much every instruction. One assumes the
>> programmers knows it and takes care...

>
> I stand corrected. You are quite right, it is "weakly" typed. I assume
> that everyone could figure out what I meant anyway. It's been a long
> time since language theory. I think the error came from spending too
> much time reading about languages like C#. Even Einstein made major
> errors, so at least I am in good company.

This really only applies to the grandfathered-in C numeric types subset
of C++. As soon as you use or own types (or wrap the primitives), you
have control over the conversions and can define your own policies.

> Yes, encapsulation in scope is a good thing, but much of that can be
> achieved in other ways without using objects. When you take languages
> like C++, while the language itself is standardized, the name mangling
> that the compilers introduce is not standardized at all. That makes
> prepackaged libraries and sometimes linking questionable unless you are
> using the same version and compiler. It is enough of a problem every
> version of Linux recommends not updating your installation piecemeal (eg
> if I update XFCE, I better recompile everything that is linked to XFCE -
> even if everything is backward compatible).

While this was historically the case, this hasn't been true for GCC for
many years. The ABI has been stable for all of the 4.x series, and it's
unbroken in 5.x (though 5.x does introduce a C++11 ABI in parallel).
I've been producing C++ shared libraries since GCC 3.x times, and have
yet to run into any breaking problems.

> Microsoft got around it
> somewhat by using their COM specification.

To an extent. But if you want to actually expose a C++ interface in a
DLL you're stuck--every Visual Studio version breaks the ABI by having a
new runtime and no compatibility guarantees. The PE-COFF binary format
is so dated it's basically unusable for C++ interfaces (try freely using
templated class members, which works fine on ELF and Mach-O platforms).

> The major reason I object to OOP is exceptions. They make it impossible
> to write code with 100% predictable exit points. When code can exit at
> any point above and below your own, that means that things can leak.
> "Add a garbage collector," you might say. What happens when the
> collector has a flaw and you do not know about it? Leak again.

Exceptions are not really related to OOP though; you can use them
without OOP being involved. With modern C++ and RAII, code is made
exception-safe by releasing resources in destructors so leaks are not
possible. Before RAII and memory management techniques such as
shared_ptr and unique_ptr became commonplace, leaks and exception-unsafe
code was quite commonplace, but that's now a rarity except in legacy code.

>>      I imagine the reason why Glib was written in C is because binding
>> to other languages is easier with C than C++.

>>
> I expect so. C is fairly straightforward.

This was certainly the original intent. But having used the bindings,
my experience was that they were of wildly variable quality, had varying
degrees of wrapper coverage, and some were not exactly usable. All in
all, the number of production quality bindings could be counted on one
hand with some fingers to spare. Maybe it's improved since I last looked.

Regards,
Roger