EduardoS (no@spam.com) on 8/27/09 wrote:
---------------------------
>>Anything "could" be done in C++. C++ is a toolbox full of tools intended
>>for a craftsman, not an apprentice. It contains tools that allow you to write
>>safer code with less effort than could ever be accomplished with Java, for example
>
>Here I can't agree with you, not all resources are allocated at the begining of
>a call to be released on the end of it, some objects have a longer lifespan and,
>if they leak, the resources only will be released on an app restart.

Note that the lifetime of local variables is determined by the block they are in, not the routine.

Acquiring a resource at a location other than the beginning of a routine is trivial, you just acquire it when you actually want it. To release the resource at a location other than the end of the routine, simply put the acquisition in a block, with the end of the block at the point where it needs to be released.

Think of it like a C# "using" statement without the using part.

The key thing is that to make sure all resources are managed using the RAII idiom. The easiest way to do that is to have resource management classes that implement the idiom themselves, like ifstream et al. Then you don't have to worry about it in the application code at all.

The difficulty in C++ is that due to backwards compatibility with C there are often two interfaces you can use to acquire resources, the old C-style interfaces that require manual management and the C++ classes that use RAII. If you use the C interfaces then you need to use things like scopeguard to implement RAII.

>Finding the source of a leak may be complex, very complex, finding routines without
>a finally may be boring, but much simpler, you can ask to a trainee.

The problem is that the finally code will be much more complex and the quantity of housekeeping code itself imposes a complexity burden. Noticing that the finally forgets to check if a particular resource was acquired and then relinquishes it correctly is non-trivial. It also gets complicated when you have different levels of nesting in the routine and some resources that would naturally be acquired within a particular block have to have a variable at the routine level to record whether the resource was actually acquired or not so the finally has access to it -- unless you have multiple finally's, making things even more complex.

>C++ doesn't really enforce it, it provide tools but you may not use them and write
>crap, if there isn't an warning "some idiot didn't followed the guidlines" it becames hard to keep it safe.

It would be nice to declare particular APIs deprecated and have the compiler warn you if they were used, yes.

I have seen tools that enforce coding guidelines but I'm not sure how thorough they are or how well they work.

>Often when talking to old C++ programmers about how unsafe such a program may be
>for 24/7 operation I heard a lot of "It don't happen to me", "All guys that work
>with me are very experienced and don't do those stupid things" and so but still,
>the C++ apps leak and crash, reading Richard's previous post I found he lives in
>the same wrold as me where enforcing rules is more difficult than it looks like,
>congrats to you and your team for apparently doing a better job, but admit, you
>got one or other #GPF from time to time ;)

The reason we became so obsessed with writing robust code was a project we did about ten years ago where we used our technology to implement a factory control system in Japan that ran 24/7. We did not have the hardware here to even test the code, and we got helpful bug reports from the Japanese like "It stopped".

The two things we learnt from that experience were (1) you really need access to enough hardware that you can actually run the program and test it, and (2) if you want your program to run continuously a month without an error then you need to pay attention to the details.

We moved away from those types of systems after a few years (we found it's far more lucrative to write off-the-shelf software that you can sell lots of copies of than to spent two years working on a custom system that you sell a handful of unless you charge more than people are willing to pay) but our current generation of software is still built on the same library and although we've traded off some attention to detail for development speed, there was still a time a year or so after we first started selling our current software where every bug we knew of in the code we had found and users were unaware of them. Even now, most of the feedback from customers is in the form of feature requests rather than actual bugs.

>I have seem a lot of people talking on how good C++/CLI should be with all those
>features, but see few people other than me using it, it's painful, having so many
>features doesn't help the day to day at all, MS recommends not mixing native and
>CLR code for performance reasons, I can say not mixing them is a good idea from
>a maintability point of view too and, if you are going to use only CLR you are better
>with C# wich have a simple and shorter syntax, oh, why it exists and why I use it,
>and don't know how many reasons MS had, the only reason to use it for me is when
>I need to integrate existing code, ironically the cases where I have to mix native and CLR...

I'm inclined to agree. I think it's good that they went to the trouble of supporting C++ on CLI, but we have no interest in moving away from native code.

>Yet about the subset choosen, the "standard" way of doing thinks like polymorphism
>is the unsafe way while the safe way requires templates and a not so small syntatic
>burden, that's a invite to do things wrong, it's the oposite of C# in wich generally
>it's easy and obvious to the the safe thing while the unsafe have a lot of syntatic salt.

I think C# has learnt a lot from C++ and Java. I've only looked at it in passing (my wife uses it for her work) and while I'm less familiar with it than I am with Java, they seem to have taken a step back from the dogmatism of Java and incorporated what they could that made sense from both. If I was writing the sort of code that my wife does, I'd consider using it rather than C++, largely because of the lower syntactic burden for database and web-oriented stuff.