This is a list of things I would like to see added to the C++ standard.
Currently, when you create a class inherited from another class, there's no way of saying "this virtual function is implementing the equivalent virtual function in the base class". If there is such a virtual function in the base class, then it is dynamically bound to it, but if there isn't such virtual function in the base class, you will be simply creating a new virtual function.
This has caused me problems in practice. In big projects it may sometimes happen that the names or parameter lists of virtual functions are changed. If the declaration of any virtual function is changed, the same virtual function must naturally be changed in all the derived classes accordingly.
The problem is that the compiler is of no help here. Even if the declaration of the virtual function in the base class is changed, the program will still compile without even a warning even though there may be some derived function where it was not changed accordingly. This may happen with a function which is seldom called and it may be hard to find with a quick test. It may only start to show symptoms much later, possibly even after publication, which would be quite bad.
The solution to this problem would be simple: Make it possible to say "this virtual function implements the same function in the base class". If there was no such function in the base class, issue an error (or at the very least a warning).
There are (currently) basically two ways of implementing a reference-counting smart pointer:
The advantage of method 1 is that it works with any type of dynamically allocated object, without imposing any requirements for it. Its disadvantage is that it consumes quite some memory for such a simple thing as a reference counting integer. The size of the smart pointer itself is also the size of two pointers instead of one. It's also a bit unsafe in certain situations (for example giving the same regular pointer to two different smart pointers will go unnoticed when done, but will cause a malfunction later).
The advantage of method 2 is that it's more efficient than method 1: The size of the smart pointer is the size of a regular pointer, and it doesn't require any extra memory (besides the reference count on the object). It's also a bit safer than the first method (eg. giving the same pointer to two different smart pointers is ok). Its disadvantage is that it requires the integral member variable in the object and thus it doesn't work on existing types which do not have such a variable.
The problems could be solved if C++ supported reference-counted pointers natively. This is one possible way to implement this idea:
shared MyObject* ptr1 = shared_new MyObject; // Ok
shared MyObject* ptr2 = ptr1; // Ok
MyObject* ptr3 = ptr1; // Error
shared MyObject* ptr4 = new MyObject; // Error
MyObject obj1;
shared MyObject* ptr5 = &obj1; // Error
/* Assume we have previously declared:
void func1(shared MyObject*);
void func2(MyObject*);
*/
func1(ptr1); // Ok
func1(&obj1); // Error
func2(ptr1); // Error
func2(reinterpret_cast<MyObject*>(ptr1)); // Ok (dangerous, but valid)
func2((MyObject*)(ptr1)); // Error. C-style casting is not valid
What shared_new would do is that it allocates
sizeof(MyObject)+sizeof(size_t) bytes of memory (instead of
just sizeof(MyObject) bytes, like the regular new),
and then this extra space is used by the shared pointer types as the
reference count.
A shared pointer has the same size as a regular pointer and has all the same advantages as the method 2 described earlier. The advantage of this is that it would work with all types, even existing ones which do not know anything about shared pointers and reference counters.
When a class is well designed you usually don't need to create a copy constructor and assignment operator for it explicitly because the implicit ones suffice. This is usually the case when you only have elementary types (not pointers nor references) and STL-style data containers (which all have their own copy constructors and assignment operators implemented) as member variables. Sometimes you can simply forbid copying and assignment as an easy solution.
However, there are cases where you just must implement a working copy constructor and assignment operator, and there just isn't any way around it. Usually this happens when the class has allocated memory for itself at the end of a pointer.
However, there are also other cases where there's no way around it. This is a typical example:
class SomeClass
{
std::list<Point> points;
std::list<Point>::iterator currentPoint;
...
};
Let's assume that this class handles a list of objects (in this case
instances of type Point) and maintains an iterator to the
object being currently handled, and this currently handled object must
be remembered for longer than the duration of any of the member functions.
By default this iterator could point to points.end().
If this class must be copied then there's simply no way around it:
A copy constructor and an assignment operator must be implemented.
If not, then currentPoint in the copy will point to the original
list, not the copied one, and a severe malfunction will follow (for example,
making the comparison (currentPoint == points.end()) will not
work correctly even if it works in the original class instance).
Creating a copy constructor and an assignment operator is almost always a tedious task, and an error-prone one. One big problem is that once you have an explicit copy constructor and assignment operator, you must remember to add every new member variable to them. It very easily happens that some time in the future you add a new member variable and forget to add it to the copy constructor and assignment operator functions, and then erratic behavior may follow (because the copy will not be in all ways identical to the original).
It would be of great help if it was possible to somehow call the implicit copy constructor and assignment operator created by the compiler from your explicit ones. This way you could first call the implicit one and then you only have to "manually" copy the members which truely need it (in the example above it would be the iterator).
This way if you add new member variables in the future (ones which can be copied implicitly without problems) they will automatically be copied, lessening the chances for bugs.
C++ supports operator overloading, which can be used for making a class
behave like an elementary type (ie. like an int,
double, etc). For example, you could create a complex number
class which behaves exactly like regular floating point numbers, with all
the same operators.
The problem is that if you want to make a class which behaves exactly
like, for example, a double, you have to implement all
the operators supported by double by hand. Each single one.
It would be nice if it would be possible to "inherit" a class from an elementary type. The class would receive the elementary type as member variable (or some way of accessing it) and implicitly all the operators related to it. The implicit implementations of these operator functions would execute the regular operation on the elementary type, but the user could override any of them by implementing that specific operator function himself (in a similar way as eg. default constructors vs. user-specified constructors work).
Inadverted recursive inclusion can cause lots of erratic behavior from the
compiler. Code which has been compiling for weeks might suddenly start giving
compiler errors even though it has not been touched in a long time, all
because of an innocuous-looking "#include" which was added in
a seemingly unrelated file.
Recursive inclusion is basically never needed in practical C++ program. Detecting recursive inclusion is quite trivial for a compiler to do. Would issuing a warning be too much to ask?
C was developed in 1972. That's over 30 years ago. And they still haven't added to it, nor to C++, one simple thing: Binary literals. There are decimal, octal and hexadecimal literals, but not binary ones. I can't even begin to comprehend the reason for this.
Let's assume you want the third and fourth least significant bits of an
integer value. Which one is clearer: "a & 12",
"a & 0x0C", or
"a & 0b1100"?
Virtual functions can be re-implemented in a derived class. What this causes is that each time that virtual function is called for a derived object (even if it happens through a base type reference/pointer) the derived class implementation, and only that one, is called.
Most of the time this is ok and desirable. However, it's not uncommon
to have a situation where the base class implementation actually does
something important which must be executed. The usual solution to this is to
simply document the usage of the base class like "if you implement this
virtual function, always remember to call the base class function in your
implementation with BaseClass::theFunction()."
It would be much easier and a lot less error-prone if there was a way of telling to the compiler "this virtual function must always be called even if a derived class has re-implemented it". Usually the base class version of the function should be called before the derived class version, but sometimes it may be necessary to call it after. Perhaps there could be options for both cases (even though the before case would IMO be more important). This would nicely work with pure virtual functions too.
Another situation where this is also useful is when making an "in-between" class between a base class and a derived class which filters, logs or does something similar to the information passed between the base class and the derived class. In this situation it would be very handy if the implementation of the virtual function in this "in-between" class was automatically called before the derived implementation is.
Of course this would require a mechanism by which the base class can "pass" the (possibly modified) data to the virtual function of the derived class. Or, put simpler, a way for the base class function to call the equivalent derived class function (if it exists).
It would sometimes be useful if typedef wasn't just a
preprocessor alias but instead it really created a new type (or perhaps
have some different keyword for creating new types like this). Sometimes
it may be useful to, for example, overload a function based on typedeffed
types, even if internally they use the same type.
Of course it's an interesting question whether a type created with typedef (or whichever keyword is used) should have an implicit conversion to the type from which it was created.
This compiler rule might work: In case of ambiguity, prefer the function which takes the type directly. Only if there's no such function try with an implicit cast to the type from which it was created.
It would be nice if they fixed this problem:
#include <map>
struct A { ... };
struct Comp { bool operator()(const A&, const A&) const { ... } };
int main()
{
std::map<A, int, Comp> theMap(Comp());
A a;
theMap[a] = 5;
}
(Can't see what the problem is? Well, my point exactly.)
I don't see any reason why you are forced to write
"#include <iostream>" when you eg. want to use
std::cout.
What the compiler can do is that when it finds something like
"std::cout", it first looks if that name has been defined
anywhere. If it has been, then it just uses that definition and that's it.
However, if it hasn't been defined anywhere then it can use an internal
lookup table from which it can check if that name has been defined in
the standard library (something highly likely because of the namespace
prefix). If it finds that it is indeed defined in a standard library, it
could then just implicitly #include that library automatically,
without the user having to do it explicitly.
Some may argue that this might cause problems if
"using namespace std;" and then "cout"
is used. I don't know why that would cause a problem, but even if it did,
this feature could be limited to situations where the "std::"
prefix is explicitly used. Using that prefix would be a kind of hint to
the compiler which says "look for this symbol in the standard libraries".
This shouldn't even make compiling slower because the compiler can use precompiled headers or whatever optimizations.
Assume that, for example, you are writing a template function which takes a data container and, for example, adds some data to it.
Before adding the data, though, it would be nice if you could make a
reserve() call to the data container, for efficiency reasons.
Naturally the call should only be made if the data container has such a
member function, else it should be skipped.
When instantiating the template function the compiler sees the entire declaration of the container class. Thus it wouldn't be a technical problem for it to conditionally compile a piece of code depending on whether the container class contains a member function with a certain signature or not. It would simply be a question of offering the necessary syntax for the programmer (who is writing the template function).
It would be nice if C++ offered such a syntax.
(Technically speaking this would be compile-time introspection. Some programming languages offer runtime introspection, ie. determining at runtime whether an object contains a member function with a given signature. However, in C++ it would be enough (and significantly more efficient) to have compile-time introspection.)
(Unless I'm mistaken, the concepts feature of C++0x might have allowed doing something like this, but doing this using them would probably have required some code repetition in a similar way as specializing a template does. However, concepts will not be included in the next standard after all, so no such luck there.)