Wow, that's a hideous abuse of the preprocessor.

None of those really seem necessary (or helpful) and some seem like incredibly bad ideas.

Your out and in macros, will make your code look very strange. If you want to print an item it will look like out foo, which really doesn't make sense syntactically. out(foo) or out << foo would make sense, but out foo doesn't look like C++ at all. And if you want to print two items, it would look like out foo << bar, which just looks totally incosistent.

Your first loop macro are pretty pointless with x not being a macro parameter. Having to insert the value you want by hand kind of defeats the purpose of having a macro (and even if x were a parameter, that's still not really something you need a macro for).

Your second loop macro is just completely pointless. If x is zero or positive, the loop won't run at all. And if x is negative, the loop will run forever (or more correctly it will invoke undefined behavior (signed integer overflow) that might result in an infinite loop - or not). Either way it's not useful.

So I figured I'd post it for others, even though a lot of the programmers probably already have this list.

Well, I guess I didn't have that list... I think that I will now add it to my list of horrible things that YOU SHOULD NOT DO with MACROs.

Try This - http://widera.com.pl/macro-set.html

In this article we try to abuse the preprocessor so much that C++ no longer looks like C++.

#include <iostream>

#define also ,
#define stop ;
#define begin {
#define end }
#define args(x) (x)
#define scalar int
#define letter char
#define ref(x) x*
#define seq(x, n) x[n]
#define start main
#define print std::cout <<
#define nl << std::endl
#define from(x) = x;
#define to(x) i < x; i++)
#define repeat_with(x) for (int x
#define index(a, i) a[i]

scalar start args(scalar count also ref(letter) seq(args,))
begin
    repeat_with(i) from(0) to(count)
    begin
        print index(args, i) nl stop
    end
end

I find that nobody really uses preprocessor properly (aside from include statements of course). In fact they can almost always be removed completely since most IDEs have solid search/replace functionality (which is basically all that the define statement is). It is a lot faster to notice that you are typing a few things repeatedly, plug in an identifier for it (I usually use invalid C++ syntax) then find and replace. Here is an example for a char by char hello world program:

source:

int main()
{
    //~1~~2~//copy and paste this 12 times!
    ~1~h~2~
    ~1~e~2~
    ~1~l~2~
    ~1~l~2~
    ~1~o~2~
    ~1~ ~2~
    ~1~w~2~
    ~1~o~2~
    ~1~r~2~
    ~1~l~2~
    ~1~d~2~
    return 0;
}

Then you just hit CTRL-R (typical short-cut for replace) and type in replace ~1~ with cout<<' and replace ~2~ with '; These are even more versatile in many ways than a preprocessor because they have no ties to syntax at all!

I do notice that find-replace lacks that functional ability of macros however... but MS Word has a sick find and replace (it can be function and self modifying!) it should not be too long before such search capabilies are made standard on most IDEs.

In gereral it's a really bad idea to use macros with very short names, like n. It removes the posibility of ever using that symbol as a variable name in your code. I think it's generally a good idea to try and use longish upper-case names for macros.

Additionally, if you're not careful (as Deceptikon showed) it's really easy to make your code pretty much unreadable using too many macros. Making a macro to replace std::cin << is largely pointless, it doesn't really save you that much, but adds loads of confusion for anyone trying to (literally) decypher your code.

On the point of the loop macro. Obviously, this is a pointless, terrible implementation of this idea. However, if you want a reasonably good macro for doing this, then you could use BOOST_FOREACH to do a much better job.

#define can be useful for doing OS/architecture/configuration dependent stuff. For instance, VC++ requires exporting of DLLs if you want to use them in a different dll, but gcc does this by default:

#ifdef __GNUC__
    #define DLL_EXPORT
#else
    #define DLL_EXPORT __declspec( dllexport )
#endif

Then you can define functions that you want exporting in VC++ as

DLL_EXPORT void myFunc();

Obviously, you'd need much better compiler detection than shown here, but it's just an example :o)

Lotta hate here .. i guess the author of the thread didn't realize didn't realize "stuck-in-the-mud" can mean other things besides the irrational zealots of a certain politcian.
In engineering we once got things done .. now we gotta be sure we don't offend the immature and neurotic.

Lotta hate here

Calling statements like "that's a bad idea" hateful is a tad dramatic, don't you think?

In engineering we once got things done .. now we gotta be sure we don't offend the immature and neurotic.

Nobody's offended (or at least I'm not - I suppose I can't really speak for the other people participating in the thread (though I've surely seen no indication that they're offended)). We're just explaining why, in our estimation, the macros suggested by the OP are bad ideas.

If the worry that you might get (mostly) constructive feedback on your code is what's keeping you from getting things done these days, then ... honestly I don't really know how to finish this sentence.