On 7/25/2015 5:26 AM, Roger Leigh wrote:
>
> In C++ this simply doesn't happen; upcasting is completely
> transparent, downcasting with dynamic_cast is completely safe. This
> can lead to long standing latent bugs in the codebase that are well
> hidden.

What you describe is the result of poor design and bad casting, not a
failing of the C language, in my opinion. I agree with you that C has
faults, it is hardly a perfect language. There aren't any perfect
languages. My main distaste for C++ comes from the fact that like most
OOP languages, you are saddled with embedded language features, like
exceptions, even if you do not use them. This really violates the
standing principle of "paying for only what you use." Dynamic
casting/RTTI comes with a cost and is not without its critics. Even
Bjorne Stroustrup did not include it in the original C++ spec because he
felt it could be misused. I think mainly though that those problems
with GTK can be solved with better programming practices and compiler
warnings, rather than resorting to RTTI.

We could discuss the virtues or lack of virtue for RTTI and not get
anywhere, so I think it will be best to simply agree that GTK has sloppy
code that needs improvement. That we can both agree on without complaint.

>
> OOP can certainly be overused where other approaches would be more
> appropriate, but in the general case it provides many concrete
> benefits, so long as you don't try to do polymorphism in C.

I think we can agree to disagree.  =)  Before C11, I would have agreed 
with you that the  "polymorphism argument"  was valid, but I think that 
C11 renders a most of that advantage a moot point.    In my opinion, C11 
_Generics wipes most of that advantage out.
On the whole, I consider the industry wide "love affair" with OOP to be 
a mistake, but a mistake we can learn from.  Much of what you describe 
as liking - polymorphism and cast checking can be done outside of OOP.   
I  consider OOP  massively overused and the costs have to be weighed 
against the benefits.

> Absolutely not. All the code is completely exception safe and will
> not leak if exceptions are thrown. That's what RAII and smartpointers
> take care of. Running under valgrind shows zero leaks with exceptions
> being thrown all over the place. Exception handling can be
> *completely robust* when you use modern C++ techniques.
>

Another point where we must depart in agreement, I'm afraid.

To be clear, I'm not doubting your skills, or that you can write
reasonable code that does not leak under foreseeable conditions. I am
criticizing OOP in general. In theory, all OOP code is exception safe.
In practice, they are not.

Setting aside everything else, we all work in the real world. In the
real world code, exceptions *can* cause leaks because you suddenly have
unpredictable exit points at runtime once you get the code out in the
world. What I am saying is that the mechanism itself generates
uncertainty. Unless you catch all exceptions, you cannot possibly
predict every exception that might be thrown. You can certainly try,
but 100% exception safe code is not an easy task. The cost of exceptions
outweighs the benefits in my opinion. You are depending on everyone
else to be as studious as you, and as we both know, that is not the
case. I feel it is a bad programming model.

I have nothing personally against smartpointers other than the
performance hit you inevitably take, and that it gives the luxury of
lazy. So it becomes a question of can I clean up my own pointers or
not? Usually, the answer is yes.