macro passed wrong number of arguments

[Martin Magnusson]

I'm using a matrix and vector library, that won't compile. When
running g++ I get the error message "macro "minor" passed 5 arguments,
but takes just 1"

The definition of "minor" looks like below, and it takes 3 arguments.
All calls to minor that I have found in the code also pass it three
arguments, so I really don't understand this error.

Does anything look suspicious with the following definition, or must
it be that there is some other definition of minor with a different
number of arguments somewhere?

template <int N, typename T>
T minor(const Vector<N,Vector<N,T> >& in, int row, int col) //ERROR
{
Vector<N-1,Vector<N-1,T> > tmp;
int dst_row, dst_col;
dst_row = 0;
for (int src_row = 0; src_row < N; src_row++) {
if (src_row == row) continue;
dst_col = 0;
for (int src_col = 0; src_col < N; src_col++) {
if (src_col == col) continue;
tmp[dst_row][dst_col] = in[src_row][src_col];
dst_col++;
}
dst_row++;
}
return det(tmp);
}



Thanks
/ martin

 

[John Harrison]

I'm using a matrix and vector library, that won't compile. When
running g++ I get the error message "macro "minor" passed 5 arguments,
but takes just 1"

The definition of "minor" looks like below, and it takes 3 arguments.
All calls to minor that I have found in the code also pass it three
arguments, so I really don't understand this error.

Does anything look suspicious with the following definition, or must
it be that there is some other definition of minor with a different
number of arguments somewhere?

template <int N, typename T>
T minor(const Vector<N,Vector<N,T> >& in, int row, int col) //ERROR
{

Yes, somewhere is defined a macro called minor (which takes one argument).
Look at the number of commas on the above line (four of them), therefore the
compiler thinks this is a macro invokation with five arguments.

This is a good example of why macros are evil, *especially* when they are
given common names like minor.

Find out who wrote that macro and shoot them (or at least sack them).

john

 

[Rolf Magnus]

This is a good example of why macros are evil, *especially* when they
are given common names like minor.

And if you really have to write macros, write them (and _nothing_ else)
in all uppercase letters. It reduces the likelyness for name clashes
and it immediately shows that it's a macro.

 

[Martin Magnusson]

Find out who wrote that macro and shoot them (or at least sack them).

I'm using Cygwin, and the file /usr/include/sys/sysmacros.h has the
following definitions:

#ifdef __CYGWIN_USE_BIG_TYPES__
#define major(dev) ((int)(((dev) >> 16) & 0xffff))
#define minor(dev) ((int)((dev) & 0xffff))
#define makedev(major, minor) (((major) << 16) | ((minor) & 0xffff))
#else
#define major(dev) ((int)(((dev) >> 8) & 0xff))
#define minor(dev) ((int)((dev) & 0xff))
#define makedev(major, minor) (((major) << 8) | ((minor) & 0xff))
#endif

So this was the culprit. Weird that the Cygwin developers would define
such macros. (I wonder what they are for).

 

[red floyd]

I'm using Cygwin, and the file /usr/include/sys/sysmacros.h has the
following definitions:

#ifdef __CYGWIN_USE_BIG_TYPES__
#define major(dev) ((int)(((dev) >> 16) & 0xffff))
#define minor(dev) ((int)((dev) & 0xffff))
#define makedev(major, minor) (((major) << 16) | ((minor) & 0xffff))
#else
#define major(dev) ((int)(((dev) >> 8) & 0xff))
#define minor(dev) ((int)((dev) & 0xff))
#define makedev(major, minor) (((major) << 8) | ((minor) & 0xff))
#endif

So this was the culprit. Weird that the Cygwin developers would define
such macros. (I wonder what they are for).

They're used for device drivers. In *nix, a device is identified by a
major number and a minor number. In practice, the device number is a
single int. So major and minor are macros that split the dev number out
into its components.

The cygwin guys should have either all capped them (they didn't for
historical reasons), or provided some #ifdef so you could turn them off.