I accept that many of the features are to maintain backwards compatibility with C, without which, probably no-one would use the language. But I am talking ideals here. Examples... The 'this' pointer shouldn't be a pointer, it should be a const reference, but sadly it was added to the language before references were. The 'string' class should probably be part of the language, not something you have to #include. Templates are a mess: their purpose and usefulness is amazing, and gives you logical flexibility beyond that offered by Java etc, but the implementation is hideous, barely more than a glorified preprocessor, increasing compile times often by an order of magnitude... having to show private members in header files is an annoyance to those who wish to distribute libraries with headers without divulging their intellectual property details... is there no way of separating it out so that interface and implementation can be in different places, or alter the compiling/linking process to facilitate this as in Java?
2) Ok, a serious suggestion now: the 'with' keyword. Some of you will be familiar with 'with' (heh) from experiences using every other modern language, but for those who aren't, here's a quick example:
class Object
{
int property1;
string property2;
};
Object list[10];
// Iterate through the list and set up each object
for (int i=0; i < 10; ++i)
{
with (list)
{
property1 = rand() * 10;
property2 = "nothing yet";
}
}
</pre>
It simply acts as a shorthand to save you having to access an object explicitly. Just as being in a member function block will allow implicit consideration of the 'this' pointer when resolving identifier names, being within a 'with' block will consider the object specified in the with block's parameter.
3) Properties: see how Visual C++ and C++ Builder implement these: essentially allowing you to map a Get() and Set() function to a member variable, which is called appropriately depending on whether that variable is used as an RValue or an LValue… it simply cuts down on calling code… perhaps it could be claimed that it obscures the purpose, but then again, so can operator overloading. It does allow for full encapsulation of variables without it -looking- like it is encapsulated… a win for the interface designers, I believe.
It is a feature worth -considering- if nothing else.
Example:
<pre>
class Object
{
public:
property(get=GetValue, put=SetValue) int value;
private:
void SetValue(int x) { if (value > 0) value = x; else value = 0 }
int GetValue() { return value;}
};
Object test;
test.value = 50; // value is set to 50
cout << test.value; // shows 50
test.value = -45; // illegal value, SetValue stores 0
cout << test.value; // shows 0
</pre>
Another example would be to able to do this:
property(get=GetValue, put=void/null/const) int value;
(The standard people would choose the most appropriate keyword: I don't particularly care which.)
The effect would be to allow read access to that variable through the public interface, but not write access. It would throw up a 'value is not an LValue' error, just like writing to a const variable, except by private members of the class it belongs to. This would clean up all those classes we must have done where there are lots of Get() functions, but no Set() functions (eg. the constructor is responsible for all such changes). The implementation would need more thought than I have given it though due to the potential ambiguities between modifying it from inside the class (not via the Set function) and outside the class (via the Set function). If that could be resolved though, it could be useful.
Comments?
Edited by - Kylotan on 8/10/00 7:44:57 AM 
My games use lots of both, especially all the templates in the STL.
