Syntactic sugar in C/C++

I have been looking into Ruby and find its keywords "until" and "unless" very interesting. So I thought 开发者_如何学JAVAwhat was a good way to add similar keywords into C/C++. This is what I came up with:

#define until(x)    while(!(x))
#define unless(x)   if(!(x))

I am looking for some suggestions on this. Can anyone suggest a better alternative?

Here is an example of a program that I wrote to illustrate what I intended to do:

#include <stdio.h>
#include <stdlib.h>

#define until(x)    while(!(x))
#define unless(x)   if(!(x))

unsigned int factorial(unsigned int n) {
    unsigned int fact=1, i;
    until ( n==0 )
        fact *= n--;
    return fact;    
}

int main(int argc, char*argv[]) {
    unless (argc==2)
        puts("Usage: fact <num>");
    else {
        int n = atoi(argv[1]);
        if (n<0)
            puts("please give +ve number");
        else
            printf("factorial(%u) = %u\n",n,factorial(n));
    }
    return 0;
}

It would be great if you could point me to some references for similar tricks that can be employed in C or C++.

Can anyone suggest a better alternative?

Yes. Don't do this at all. Just use the while and if statements directly.

When you're programming in C or C++, program in C or C++. While until and unless might be used frequently and idiomatic in some languages, they are not in C or C++.

The way you did it seems to me the correct way to do it, if you're going to do it at all. Because the expansion of the macro is so similar to what you'd expect[1], I think it's valid to make the macro look like syntax (), rather than the usually recommended SCARY_UPPERCASE_MACROS() which are used to show that this code doesn't follow usual syntax and you should only use it carefully.

[1] The only flaw being the inability to declare variables, which is unlikely anyway, and likely to produce an error in the right place when used incorrectly, rather than doing something weird.

Furthermore, even small increases in readability are important, so being able to say until ( instead of while (! really does make it easier to read many loops. If the ending condition is more easily thought of as an exceptional condition (regardless of whether it is or not) writing the loop that way round makes it easier to read. So even though it is only syntactic sugar, I think there's reason to consider it.

However I don't think it's worth it. The benefit is small, since most programmers are used to reading if (! and the cost is real: Anyone reading the code will have to check whether this a macro, or a custom compiler, and whether or no it does what they think. And it may misleadingly make you think you can do things like i=5 unless xxxx;. Such little improvements, if widespread, would fragment the language, so often it's best to do things the standard way, and adopt improvements slowly.

However, it can be done well: the entirety of boost and tr1, especially the stuff done with templates to look like extensions to the library, involves extending C++ in various ways, many of which aren't adopted as they didn't seem worth it, but many of which have small or very widespread take-up because they made real improvements.

This reminded me of something I have seen in someone's code:

#define R return;

Besides, making the code hard to comprehend, you increase maintenance costs.

I suggest it would be better not use them.

You cannot use them in Ruby style as

`printf("hello,world") unless(a>0);`

is illegal.

And it would be more difficult for C programmers to understand the code. Meanwhile the extra macro could be a problem.

If you're going to define macros, it's good practise to make them look really ugly. In particular, they should be all-capitals, and have some kind of prefix. This is because there is no namespacing and no coordination with the type system or overload resolution of C++.

So if your macro was called BIGYAN_UNNECESSARY_MACRO_UNTIL then it would be not quite "beyond the pale".

If you want to extend C++ with new looping constructs, consider investigating lambdas in C++0x, where you could allow:

until([&] { return finished; }, [&] 
{
    // do stuff
});

It's not perfect, but it's better than macros.

I don't think your macros are bad in particular if they are used only in your own code base. This article might be interesting for you. That being said, I see some downsides in your macros when we use them in C++.
For example, we cannot write as:

until (T* p = f(x)) ...
unless (T* p = f(x)) ...

on the other hand, we can write as:

while (T* p = f(x)) ...
if (T* p = f(x)) ...

As for unless, if we define it as:

#define unless(x) if (x) {} else

then we can write unless (T* p = f(x)) .... However, in this case we cannot add else clause after it.

Good syntax sugar example (IMHO):

struct Foo {
    void bar() {}
};
typedef std::vector<Foo*> FooVector;
typedef boost::ptr_vector<Foo> FooPtrVector;

FooVector v1;
for (FooVector::iterator it = v1.begin(); it != v1.end(); ++it)
    (*it)->bar(); // ugly

FooPtrVector v2;
for (FooPtrVector::iterator it = v2.begin(); it != v2.end(); ++it)
    it->bar(); // nice

Look at how boost foreach is done.

The header defines BOOST_FOREACH (the ugly, prefixed macro). You can

#define foreach BOOST_FOREACH

in you .cpp files in order to have cleaner code. You should not do it in your .h files however and use the ugly BOOST_FOREACH instead.

Now, here is a set of “functional-programming-ish” macros for “convenient” IF THEN ELSE expressions (because ?: is ugly):

#define IF(x) (x) ?
#define ELSE :

now

int x = IF(y==0) 1
        ELSE IF(y<0) 2*y
        ELSE 3*y;

desugarises into:

int x = (y==0) ? 1 : (y<0) ? 2*y : 3*y;

As peoples said, adding those word do not really offer a useful syntactic sugar, because the cost to read a while ( or a if (! is small, all C developers are used to, and using such macro you'll scary most of the C developers. Also, making a language look like an other isn't a good idea.

BUT, syntactic sugar matters. As already stated, in C++, boost add lot's of syntactic sugar through templates, and the stl also provide Somme sugar (for example, std::make_pair(a, b) is a syntactic sugar for std::pair<decltype(a), decltype(b)>(a, b).

As a language improve, both functionalities and syntactic sugar are added to improve readability, writability, and efficiency of developers. For example, with the C++11 spec, the "for (elements in datastructure)" was added (see below), and also the "auto" keyword which allow a week inference of types (I say weak because you need to type a lot's of types at a lots of places where the type is actually 'obvious' and redundant).

Also, in haskell, using monads without the do notation (syntactic sugar) would be a real pain, and no-one would be using them1.

An example without syntactic sugar:

//C++ < 11
std::vector<int> v;
v.push_back(3);
v.push_back(7);
v.push_back(9);
v.push_back(12);
for (std::vector<int>::iterator it = v.begin();
     it != v.end();
     it++)
{
    std::cout << *it << std::endl;
}

And with syntactic sugar:

//C++ >= 11
std::vector<int> v {3, 7, 9, 12};

for (auto elm : v)
{
    std::cout << elm << std::endl;
}

A bit more readable, no?

An haskell example for the IO monad (from HaskellWiki) :

f :: IO String
f =
  ask "What's your name ?" >>= \name ->
  putStrLn "Write something." >>= \_ ->
  getLine >>= \string ->
  putStrLn ("Hello " ++ name ++ " you wrote " ++ string) >>= \_ ->
  return name

g :: IO String    
g = do
  name <- ask "What's your name ?"
  putStrLn "Write something."
  string <- getLine
  putStrLn ("Hello " ++ name ++ " you wrote " ++ string)
  return name

Here is a link to ideone : http://ideone.com/v9BqiZ

1: Actually, the language is more flexible than C++ and allow creating operators (for example &^, +., :+:, ...), so we could imagine that someone would quickly introduce syntactic sugar again :).

Well you could do it, but make sure that it's not in the source file. I reccomend taking the CoffeeScript approach to JavaScript without the optimization generation.

Just in general you should write your language but export, give, and have the transpiled code as if you would have written it in C with extreme compatability.

Try looking into awk and make it transpile all files with ending .cugar on save or something similar. :)

Good luck.