Re: Why C++ is vastly superior to C
William Ahern <william@wilbur.25thandclement.com> wrote:
Proper ordering of resource mangement in C also gets you the majority of
these benefits, a result not of language features but of good programming
habits. Comparing poor resource management in C with good resource
management in C++ is comparing apples to oranges. If programmers were so
inept at tracking memory anyhow, they'd be best in a GCd environment. If
they feel the impulse to allocate dynamic strings randomly where ever it
suits them, then they're begging for leaks, and really should be using a GCd
language, whether in C or C++. If they properly order allocation of these
resources, then the gap between C and C++ becomes quite small; maybe not
small enough, but perhaps for other considerations to move to the forefront.
You can achieve something similar to C++'s RAII in C within one single
function if you carefully follow certain coding conventions (which, as
said, are completely unnecessary in C++). The problem is that it's not
at all uncommon that resource handling spans beyond the scope of one
single function.
In C++ you mostly don't have to worry. Basically, if you never use
'new' nor pointers in your own code, you are usually on safe grounds, even
if you are dealing with dynamically allocated memory, and even if you are
passing objects handling this memory around at will.
The simplest example is a function returning resources that it allocated
itself. This immediately breaks encapsulation in C, as it transfers the
burden of freeing that resource to the caller. Of course you can do this
in C++ as well, but that would generally be a mistake, as the language
offers the tools to retain the encapsulation even when the resource
allocation outlives the function where it was done. Just as a simple
example:
std::string gimmeTheString()
{
std::string line;
std::getline(std::cin, line);
// Or any other dynamic string building routine you can imagine.
return line;
}
Encapsulation is preserved because the calling code doesn't need to
worry about how the dynamically allocated string will be deleted. When the
return value goes out of scope, it will be done automatically.
The lack of RAII in C causes resource management responsibility
trasferral, and thus breaking encapsulation. The above function equivalent
in C would require the calling code to be careful about the returned
string.
And that was just one of the simplest cases where resource allocation
can outlive the scope where the allocation was done. It can get
significantly more complex than that, with deeply nested shared containers
and other such situations which do happen in practice. The set of
programming conventions you need for safe code in C++ is significantly
smaller than the set of programming conventions necessary in C. The more
complicated the situation, the larger the difference.
That is one of the main reasons why I would consider it nightmarish if I
had to develop a large and complex project in C.
RAII becomes even more important in generic programming. If you want a
function or class to support more than one data type (regardless of
whether only one such type will be used at a time in the entire program,
or whether the same code could be used with several different types within
the same program), automatic resource management becomes quite essential.
Basic (non-pointer) types don't need any resource management because they
can be handled by-value. Structs and classes may need them because they
may be encapsulating allocated resources within them. However, in C++ you
don't have to take this into account in your generic code, which is what
makes it so great.
[I'll refrain from commenting on the obscene nested containers example as
I'm sure it made you cringe as well.]
It was just a one-liner demonstration. It was not intended to be an
actual real-life example.
In real code you can, however, end up with deeply nested containers,
even if more indirectly. Typically you will have a class that has data
containers as members, and instances of this class may be used in a
container (which itself might be a member of another class, and so on).
This isn't even a rare happenstance.