what is the meaning of this macros?

[swapnil_paranja]

1>
define xbooluninit ((xbool) 0x81);

2>
define log(what) logout(0,what);

[jonnin]

the first makes a constant expression -- from the name i would expect to see
xbool somevar = xbooluninit;

the second creates a new function from an old to hide the first parameter, which the
programmer always wants to be zero. I disagree with this programming style, all you save is a zero after creating chaos.

[Danny]

the first makes a constant expression -- from the name i would expect to see
xbool somevar = xbooluninit;

the second creates a new function from an old to hide the first parameter, which the
programmer always wants to be zero. I disagree with this programming style, all you save is a zero after creating chaos.

Both macros are hideous. The former can be expressed as a const, or enum with less likelihood of introducing bugs. Both, btw, incur at least one bug: they have a semicolon at the end, which is a serious problem if you use them inside an expression. As for the latter macro, overloading and default argument values are a much, much better option.

[musicalmike235]

This code compiles and runs using the borland commandline compiler

#include <iostream>

#define STARTOFPROGRAM int main() {
#define ENDOFPROGRAM return 0; }

#define BEGIN {
#define END }

#define STARTOFARGS (
#define ENDOFARGS );

#define ENDOFSTATEMENT ;

#define MAKEVAR(type, name, value) type name=value;

using namespace std;

void print(int i)
BEGIN

cout << i;

END

STARTOFPROGRAM

MAKEVAR(int, i, 0);
print STARTOFARGS i ENDOFARGS

ENDOFPROGRAM

[jonnin]

Some not quite bright person has tried to make c look more like pascal, instead of learning the correct way to program. Throw this code away as soon as you can!

[Danny]

I think it compiles and runs with any C++ compiler but that's not the point. This codfe is horrific. I don't want to start preaching why it's awfully terrirble. As jonnin said, just throw it out of the window. Even Pascal programmers wouldn't bear it.

[jonnin]

There are a lot of things you CAN do that work just fine. Ive posted this before, but this is an example of how bad a short program can be. You have to run it to see what it does. Which makes the point: just because you can do something, and just because it works, does not mean its acceptable.

typedef double stype ;
void ss(stype *list , const int size)
{
stype temp;
int i, j, dx=0;
int harr[] = {0, 1,10,53,105,542,1047,6239,16256,56720,134096,
579823,1000000,5430201,999999999 };
while(size/2 > harr[++dx]);
for(dx--;dx;dx--) {
const int hdx = harr[dx];
for( i = hdx, temp = list[i]; i< size; temp = list[++i])
{
for(j = i; (j >= hdx) && (list[j-hdx] > temp);
list[j] = list[j-hdx], j -= hdx);
list[j] = temp;
}
}
}

[Danny]

And mroe generally speaking: that's what characterizes bugs. The code comiles and links just fine, but that certainly doesn't guarantee that it's correct, stable or reliable.

[musicalmike235]

Some not quite bright person has tried to make c look more like pascal, instead of learning the correct way to program. Throw this code away as soon as you can!

I can throw it away now if you like. Trust me, I write code the correct way, I just posted this code to entertain readers. And also, trust me, there are worse ways to write code, for example, one person wrote a bunch of macros to make it so he could program in c using ebonics.