Re: Article on possible improvements to C++
* sfuerst:
On Nov 19, 4:52 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* sfuerst:
Hello, I've written an article athttp://locklessinc.com/articles/10_problems_with_c++/
that is unfortunately way too long to post here, detailing ten
perceived problems with C++, together with some possible solutions.
The list kind of looks like the typical one brought up by novices,
He he, it certainly does. :-)
But kudos (speling?) to you for writing it up.
For that can both help you and help many others.
complaining about things like exceptions and multiple inheritance.
However, the actual issues discussed tend to be more subtle and low-
level than what you are probably thinking. In particular, none of the
"problems" are complaints about the existence of features, just on
their current syntax, or typical underlying implementation.
The 10 problems are:
1) The "new" keyword.
OK, there's much wrong.
First, "Unfortunately, the new keyword doesn't allow [...] an override." is
wrong. You override the allocation aspect by defining operator new (and/or
operator new[], which is the allocation function, which can be overridden per
class as well as overriding the global default (where, to boot, you can override
the action taken on allocation failure via set_new_handler). And you can
"override" the initialization action by defining suitable constructors.
I think you've missed the point. In other languages, people are able
to globally override memory allocation. This is done for debugging:
To find a memory leak, you can store the file and line of the
allocation call, and see where the allocations that are never freed
come from. Another use is profiling: What sized allocations are your
program repeatedly allocating and freeing? Perhaps the use of some
other allocator other than the default could improve performance.
With C++, you can use the placement new syntax to pass extra
information to an overridden new routine. The problem is that there
is no way to globally cause this to happen, without manually editing
every single call to new in your program.
You can just use a macro.
Check out e.g. Microsoft's MFC.
Ugh, I never thought I'd direct *anyone* to MFC, but it does this. There was by
the way an infamous bug related to that macro. They'd originally forgotten to
define placement delete, thus leaking memory when exceptions occurred in debug
builds...
(You can override
individual classes, no problem... but the only available global
overrides are operator new(size_t) and operator new[](size_t), and
these don't let you access the file and line number you need.)
If new was some sort of operator instead of a keyword, and used
brackets to surround the type, then it would be possible to use a
macro to do this. Unfortunately, this isn't the case.
i.e We'd like to do something like:
#ifdef DEBUG_ALLOCATIONS
#define new(T) new(T, __FILE__, __line__)
#endif
You're homing in on one of the solutions, yes. :-)
[snip]
Also, it's wrong that it's impossible to initialize an array in other ways than
using a default constructor.
For example,
std::vector<int> a( 42, 999 );
This isn't an array. This is a vector, but I think you know that.
You don't use delete[] with a vector... (Unless you have an array of
vectors. :-P )
The example just shows that you can construct elements of an array any way you
wish. There's nothing magical about std::vector. It's just a class that you can
define yourself.
[snip]
Third, this is wrong: "Similarly, destructing an array with the delete[]
operator is inefficient.". delete[] is designed for maximal efficiency. The
trade-offs made to achieve that efficiency, in particular that the programmer
must supply the knowledge of whether it's delete or delete[] (just in order to
save a byte or two of memory!) is a problem, but the efficiency is not. :-)
The problem with delete[] is that it exists. You use "delete" with
everything else. Why should arrays be special? Special cases are the
very definition of non-orthogonality.
That's the "byte or two" I mentioned in the quote.
The basic argument is that if you have an array, you probably know its
size. (vector<> certainly does.) If you don't know its size, then
your code probably has a latent buffer overflow problem, and is highly
likely to be buggy elsewhere. Therefore, there should be no problem
passing that size to some deletion routine when you need to
deconstruct the objects in that array. Of course this would totally
break backwards compatibility... but the whole point of exploring
these things is to look at what is possible if we allow that.
Think about a zero-terminated string, and functions like
char const* dup( char const* s )
{
return strcpy( new char[strlen(s)+1], s );
}
That's about "knowing the size", often, as here, you don't even know the size
specified at allocation, but would have to obtain it by e.g. using strlen.
Cheers & hth.,
- Alf