Skip navigation.

exploreopera

| Help

Sign up | Help

A Cure to C++

Programming languages are user interfaces, too!

avatar

Named Parameter syntax for C++ ?

See http://en.wikipedia.org/wiki/Named_parameter
How could this very nice feature from Objective-C be integrated in harmony with C/C++/C#/java syntax? Well, at least arguments should be in the round brackets of an argument list.

Assume you have a function with multiple arguments.

void foo(string message="", int min_index=0, int max_index=10) {
  ..
}


In a function call you want to refer to the arguments by name, to avoid mistakes in the ordering, and to reduce the number of redundant arguments that are necessary.

The straightforward approach would use the '=' operator - but this causes problems. Using ':' should work better.

int main() {
  ..
  int n=10;
  foo(message = "helloworld");  // problem: possible ambiguity with assignment operator!!
  foo(message: "helloworld", max_index: n);  // should work, looks clean.
  ..
  // which also allows more freedom in ordering
  foo(
    min_index: 0,
    max_index: n,
    message:   "helloworld"
  );
}


That's it. Looks quite nice to me, even more logical than the syntax in Objective-C. And it doesn't interfere with anything in existing C++/java/whatever.

Read more...

avatar

Exit Tunnels for Long Loops

I know you all don't want to see labels and jumps. My claim is, it really makes sense here.

The situation: Your algorithm requires a long and heavily nested control loop, with different exit conditions requiring different finishing steps.

Common solutions would be
  • to handle the finishing steps in conditional blocks inside the loops
  • to keep track of how the loop has been left with a variable in function scope (that will be queried to decide which finishing steps are to be applied)
  • to put the finishing commands into little helper functions.
Neither of these are helpful for readable code: Having more code in the loop makes it difficult to grasp the repeated mechanic. With extra variables it's usually hard to keep an overview of how these will affect the finishing steps. And scrolling to some external helper functions is not what you want either.

This is the new mechanic that I imagine:

..
for(...) {
  ..
  if(..) goto :exit_A("division by zero");
  if(..) goto :exit_B();
}
..
:exit_A(char* result) {
  ..  // conditional finishing steps
}
:exit_B() {
  ..  // conditional finishing steps
}

The exit tunnels are conditional pieces of code that can be executed directly after the loop, depending on how it is left. After the tunnel block, the control flow continues at the right paranthesis ending the block.

The parameters of the break statement are only visible within the exit tunnel.

Read more...

July 2008
MTWTFSS
June 2008August 2008
123456
78910111213
14151617181920
21222324252627
28293031