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