Language features: Rants and wishes

Every time the google code jam approaches I ponder the idea of making a preprocessor of sorts to be able to "use my own language" in the qualification rounds. But then I notice that there is little time left. Either way, these are things I really wish I could use during contests, without losing the good powerful things such as the STL that c++ has, of course.

Loops in general blow
For loops are such basic construction blocks that you always use yet in c++ and many other languages they are so messed up and limited...

Look at this:
for(int i=0; i<4; i++) {
}

What is wrong with that? You may ask. Well, note how you type the variable i three times. Were the guys at the C council of standards really unable to ponder about "once and only once"? I am just saying... making funny bugs and wasting at least 3 seconds finding out you mistyped one of the three instances of the variable and put j instead of i gets very old.

It is not just the possibility of bugs or having to type things multiple times. I sometimes wish the language didn't expect me to code something as common as a walk from 0 to 6 having to do so many manual things like the comparison function and the increments... I once dreamed of something like this:

for( 0 <= i < 4) {}


Imagine that, it is clearly saying that you will repeat the operations for numbers from 0 to 3. You can control bounds being exclusive or not. And it is very expressive. Of course, it is not perfect and I am not saying it is. But I actually implemented this in a custom language I wrote for Warcraft 3 map making. And it was so cute... Anyway, serious languages have solutions of their own, like python's range() function. A lot of these solutions are better than what C, C++ and Java offer in this regards.

The other day, I pondered about loops that need you to iterate through pairs or tuples of many variables. Imagine you could just do this, in a single loop.

for (1 <= a < b < c < n) {


Sounds fun.

Solution?
- Switch to python , some other language? Not very viable in most contests. And well, I do like C++ better than other languages overall. I really like the STL during contests, so this is not so easy.
- MACROS. This is what a lot of C++ coders in high positions do. They for example have a FOR(v,n) macro that implements for (int v=0; v<n; v++). This fixes the issue with having to type the same variable thrice but it introduces the issue of using macros and making your code look uglier.
- Give up and live with it.

Lack of a for each construct
I covered this before when I explained why I use the for_each #define. It is still quite lame to have to use a #define for this.

Just something, I just found out c++11 kind of implements this. http://en.wikipedia.org/wiki/C%2B%2B11#Range-based_for-loop

Lack of var
Something c++11 (or c++0x) does well is add the auto keyword. It will work like this:

map< pair<int,int>, string > thesupermap 
auto q = thesupermap.begin(); 
//get it? This is the equivalent of the good oldie 
// map<pair<int,int>, string>::iterator q = thesupermap.begin() 
 

This should be of great value to anyone who has attempted to use the STL and has not gone insane in the process.

But there is a problem. Why call it auto? I wish it was named var, like in some other language. It seems they just wanted to recycle a keyword instead of adding a new one.

The lack of this feature really hurts. The good news is that it is probably already possible to use it in the google code jam, shall you get a compiler that supports the new c++ specification. The bad thing is that it is less likely in topcoder. Which uses a C++ compiler from the stone age and is likely to ever update the language versions.

Solution?
- Use c++11, if possible.
- Use a #define. Like in the case of for_each, the typeof() macro can help. The problem is that the syntax of declaring a variable will look like this: var(q, s); instead of auto q = s;
- Live with it.
- Lobby g++ to implement c++11 fully, then lobby topcoder to use the new g++ version.

I miss <?, >?, <?= and >?=
These are operators that do operations so basic that it is hard to believe that after gcc invented them, they decided to deprecate them instead of lobby the c++0x council to make them global standards.

Explanation : (5 <? 3) returns 3. That's right, it gets the minimum of two numbers. >? the maximum and, even nicer: x <?= 5 is the same as x = min(x, 5).

Something good about the old g++ version in TopCoder is that this obscure feature is still supported. The bad thing is that it is not a standard, and later compilers removed the features. So I had to stop using it.

There was so much potential in this. Surely, it causes confusion, but that is only because it is a rare feature. I am sure that if *= was not a standard everybody would get very confused about finding code that says x *= 4.

I would have made them better though. Let them do what std::min and std::max do. So, for example, imagine you could do this:

string s[5] = {"aab", "bbc", "xxx", "h", "lxa" }; 
string lex = s[1]; 
for (1 <= i < 5) { 
    lex <?= s[i]; 
} 
 

To find the lexicographically smallest of 5 strings...

Solution?
- Use old g++ versions. Good luck with that. Codeforces does not support this. And in recent ubuntu versions, for example, gcc 4.0 is not in the repositories.
- Live with it.

Native bignum support
Easy, I wish you could just do (big x = "3483389483893382929284349493839338") and then use x in all sort of operations.

Solution?
- Switch to another language. But not Java because their bignum support does not do this. A lot of languages can do this, some without even asking... (Which is not a good thing, if instead of overflow your program suddenly gets magnitudes slower)
- Really, if you can use non-standard libraries just get gmp and do a typedef.
- If you can't use libraries, well... live with it.

I really wish c++11 implemented this, but it won't. Surely you can code your own big nums, but not so much, and in fact there is such a plethora of optimizations and aspects that it is better to use a well-tested wheel rather than make your own. Plus bignums in contests are the archetypical Fake difficulty stunt.


.begin(), .end() ad nauseum
Speaking of using the STL and going insane in the process. If there is something that is really broken about it, is that you have to do (v.begin(), v.end()) so many times... Once again, this is an explicit attack against "once and only once".

Solution?
- Live with it.
- Coders tend to make an ALL(v) #define that translates to v.begin(), v.end(). Once again, it fixes one problem and introduces another.

Stupid !@#~% long long
I hate having to type long twice. I really do. Specially because there is a pointless "long" type that does the same as "int". c++11 does nothing to fix this.

I have resorted to using a define in my code that fixes this, and once again introduces tons of other issues.