By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,948 Members | 1,213 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,948 IT Pros & Developers. It's quick & easy.

Could anybody explain this macro for me?

P: n/a
#define D(y...) (const int []) {y}

My understand is that D is taking in a various length parameter y
which is an array of const int. Am I right?

Thanks.
Nov 12 '08 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On Nov 13, 12:46*pm, "webinfin...@gmail.com" <webinfin...@gmail.com>
wrote:
#define D(y...) (const int []) {y}

My understand is that D is taking in a various length parameter y
which is an array of const int. Am I right?
This is a syntax error. Are you sure you transcribed
it correctly?
Nov 13 '08 #2

P: n/a
Old Wolf wrote:
On Nov 13, 12:46 pm, "webinfin...@gmail.com" <webinfin...@gmail.com>
wrote:
>#define D(y...) (const int []) {y}

My understand is that D is taking in a various length parameter y
which is an array of const int. Am I right?

This is a syntax error. Are you sure you transcribed
it correctly?
To me it looks like a variadic macro from the newer C standard, not
yet in the C++ standard.
Nov 13 '08 #3

P: n/a
we*********@gmail.com wrote:
#define D(y...) (const int []) {y}

My understand is that D is taking in a various length parameter y
which is an array of const int. Am I right?
Try c.l.c, this looks like C99.

--
Ian Collins
Nov 13 '08 #4

P: n/a
On Nov 12, 7:06*pm, Ian Collins <ian-n...@hotmail.comwrote:
webinfin...@gmail.com wrote:
#define D(y...) (const int []) {y}
My understand is that D is taking in a various length parameter y
which is an array of const int. Am I right?

Try c.l.c, this looks like C99.

--
Ian Collins
That's not any C99 syntax I know of, either. C99 provides __VA_ARG__
for variadic macros.

Nov 13 '08 #5

P: n/a
On Nov 13, 1:28 am, Juha Nieminen <nos...@thanks.invalidwrote:
Old Wolf wrote:
On Nov 13, 12:46 pm, "webinfin...@gmail.com" <webinfin...@gmail.com>
wrote:
#define D(y...) (const int []) {y}
My understand is that D is taking in a various length
parameter y which is an array of const int. Am I right?
This is a syntax error. Are you sure you transcribed it
correctly?
To me it looks like a variadic macro from the newer C
standard, not yet in the C++ standard.
There are actually two things in the above which cause syntax
errors in current C++. The first is that it is a variadic
macro, which is legal in C99 and will be legal in the next
version of C++. The second is that when expanded, this results
in a compound literal. Again, C99, but not current C++; in this
case, I know that the next version will extend the
initialization syntax, but I'm not sure whether the extension
will look exactly like a compound literal in C or not.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Nov 13 '08 #6

P: n/a
On Nov 13, 11:04*pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 13, 1:28 am, Juha Nieminen <nos...@thanks.invalidwrote:
Old Wolf wrote:
On Nov 13, 12:46 pm, "webinfin...@gmail.com" <webinfin...@gmail.com>
>
>#define D(y...) (const int []) {y}

There are actually two things in the above which cause syntax
errors in current C++. *The first is that it is a variadic
macro, which is legal in C99 and will be legal in the next
version of C++. *
Variadic macros in C99 look like:

#define D(y, ...)

i.e. the ellipsis is separated from the other
arguments by a comma (with optional whitespace).

The ellipsis directly following the argument
name, isn't in any C standard. (Another poster
suggests that it's a GCC extension).

Nov 15 '08 #7

P: n/a
On Nov 15, 5:04*am, Old Wolf <oldw...@inspire.net.nzwrote:
On Nov 13, 11:04*pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 13, 1:28 am, Juha Nieminen <nos...@thanks.invalidwrote:
Old Wolf wrote:
On Nov 13, 12:46 pm, "webinfin...@gmail.com" <webinfin...@gmail.com>
#define D(y...) (const int []) {y}
There are actually two things in the above which cause syntax
errors in current C++. *The first is that it is a variadic
macro, which is legal in C99 and will be legal in the next
version of C++. *
Variadic macros in C99 look like:
* #define D(y, ...)
i.e. the ellipsis is separated from the other
arguments by a comma (with optional whitespace).
So I see. I wonder why they didn't support the form without the
comma, as they do in function declarations. Shocking lack of
orthogonality.

(Historically, the comma wasn't allowed in function
declarations; the syntax was exactly that of a natural language,
where you would never write "a, b, ..." but always "a, b...".
When C adopted this syntax from C++, the C committee decided to
allow the syntax with the comma as well; I'm not sure what their
reasoning was, but I also find it more appealing, separating the
.... from the preceding argument. But not enough more appealing
to have justified changing or extending the existing
specification; if it were a new invention, I'd define it with
the comma, but since it wasn't, and isn't, I don't think that
there was, or is, sufficient justification to add the form with
the comma.)
The ellipsis directly following the argument name, isn't in
any C standard. (Another poster suggests that it's a GCC
extension).
Might be. I would certainly expect that most implementations
supporting vararg templates support it (except maybe in their
strictest modes), much like they support a final comma in an
enum list. There is absolutely no reason not to be orthogonal
here (and I would consider this a defect in the C standard).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Nov 15 '08 #8

P: n/a
Old Wolf wrote:
The ellipsis directly following the argument
name, isn't in any C standard. (Another poster
suggests that it's a GCC extension).
Straight from the horse's mouth:

http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
Nov 15 '08 #9

P: n/a
On Nov 15, 11:00*pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 15, 5:04*am, Old Wolf <oldw...@inspire.net.nzwrote:
The ellipsis directly following the argument name, isn't in
any C standard. (Another poster suggests that it's a GCC
extension).

Might be. *I would certainly expect that most implementations
supporting vararg templates support it (except maybe in their
strictest modes), much like they support a final comma in an
enum list. *There is absolutely no reason not to be orthogonal
here (and I would consider this a defect in the C standard).
Well, the gcc-3.4.4 I have here, running in
standard mode, just gives 'parse error' for:

int foo(int x...) { }

I've never encountered this form (without the
comma), and I usually do read the list of
extensions in compiler documentation when using
a new compiler. Obviously you have more experience
with compilers than I do though!
Nov 15 '08 #10

P: n/a
On Nov 15, 11:21*pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Nov 15, 11:00*pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 15, 5:04*am, Old Wolf <oldw...@inspire.net.nzwrote:
The ellipsis directly following the argument name, isn't in
any C standard. (Another poster suggests that it's a GCC
extension).
Might be. *I would certainly expect that most
implementations supporting vararg templates support it
(except maybe in their strictest modes), much like they
support a final comma in an enum list. *There is absolutely
no reason not to be orthogonal here (and I would consider
this a defect in the C standard).
Well, the gcc-3.4.4 I have here, running in standard mode,
just gives 'parse error' for:
* int foo(int x...) { }
All I get for it in 4.2.1 (the only version I have available
here) is:
varargs.cc:8: warning: control reaches end of non-void function
That's compiled with
g++ -std=c++98 -pedantic -ffor-scope -fno-gnu-keywords -foperator-
names -pipe -Wall -W -Wno-sign-compare -Wno-deprecated -Wno-non-
virtual-dtor -Wpointer-arith -Wno-unused -Wno-switch -Wno-missing-
braces -Wno-long-long -static-libgcc -ggdb3 -D_GLIBCXX_CONCEPT_CHECKS -
D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
(my standard options).
I've never encountered this form (without the comma), and I
usually do read the list of extensions in compiler
documentation when using a new compiler. Obviously you have
more experience with compilers than I do though!
Not so much compilers. According to the first edition of _The
C++ Programming Language__ (1986), the comma isn't legal.
According to the C90 or the C++98 standard, it is optional.
I've never seen a compiler that didn't accept it either way, but
then, I don't think I'd have noticed if it didn't; I can't
remember ever actually using varargs in C++.

Since both are required by the standard, I wouldn't expect to
find support for both mentionned in the compiler documentation.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nov 16 '08 #11

P: n/a
On Nov 16, 12:56*pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 15, 11:21*pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Nov 15, 11:00*pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 15, 5:04*am, Old Wolf <oldw...@inspire.net.nzwrote:
The ellipsis directly following the argument name, isn't in
any C standard. (Another poster suggests that it's a GCC
extension).
Might be. *I would certainly expect that most
implementations supporting vararg templates support it
(except maybe in their strictest modes), much like they
support a final comma in an enum list. *There is absolutely
no reason not to be orthogonal here (and I would consider
this a defect in the C standard).
Well, the gcc-3.4.4 I have here, running in standard mode,
just gives 'parse error' for:
* int foo(int x...) { }

All I get for it in 4.2.1 (the only version I have available
here) is:
* * varargs.cc:8: warning: control reaches end of non-void function
That's compiled with
* * g++ -std=c++98 -pedantic -ffor-scope -fno-gnu-keywords -foperator-
names -pipe -Wall -W -Wno-sign-compare -Wno-deprecated -Wno-non-
virtual-dtor -Wpointer-arith -Wno-unused -Wno-switch -Wno-missing-
braces -Wno-long-long -static-libgcc -ggdb3 -D_GLIBCXX_CONCEPT_CHECKS -
D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
(my standard options).
I've never encountered this form (without the comma), and I
usually do read the list of extensions in compiler
documentation when using a new compiler. Obviously you have
more experience with compilers than I do though!

Not so much compilers. *According to the first edition of _The
C++ Programming Language__ (1986), the comma isn't legal.
According to the C90 or the C++98 standard, it is optional.
I've never seen a compiler that didn't accept it either way, but
then, I don't think I'd have noticed if it didn't; I can't
remember ever actually using varargs in C++.

Since both are required by the standard, I wouldn't expect to
find support for both mentionned in the compiler documentation.
I tried on another machine with gcc 4.0.1 .
g++ allows int foo(int x...) , gcc gives 'syntax error'.

I checked in C99 again and the grammar specification
doesn't seem to permit int foo(int x...) , the
relevant bits are:

direct-declarator:
direct-declarator ( parameter-type-list )
[snip]

parameter-type-list:
parameter-list
parameter-list , ...

Are you sure C90 allowed it?
Nov 16 '08 #12

P: n/a
On Nov 16, 11:53 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Nov 16, 12:56 pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 15, 11:21 pm, Old Wolf <oldw...@inspire.net.nzwrote:
On Nov 15, 11:00 pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 15, 5:04 am, Old Wolf <oldw...@inspire.net.nzwrote:
The ellipsis directly following the argument name, isn't in
any C standard. (Another poster suggests that it's a GCC
extension).
Might be. I would certainly expect that most
implementations supporting vararg templates support it
(except maybe in their strictest modes), much like they
support a final comma in an enum list. There is absolutely
no reason not to be orthogonal here (and I would consider
this a defect in the C standard).
Well, the gcc-3.4.4 I have here, running in standard mode,
just gives 'parse error' for:
int foo(int x...) { }
All I get for it in 4.2.1 (the only version I have available
here) is:
varargs.cc:8: warning: control reaches end of non-void function
That's compiled with
g++ -std=c++98 -pedantic -ffor-scope -fno-gnu-keywords -foperator-
names -pipe -Wall -W -Wno-sign-compare -Wno-deprecated -Wno-non-
virtual-dtor -Wpointer-arith -Wno-unused -Wno-switch -Wno-missing-
braces -Wno-long-long -static-libgcc -ggdb3 -D_GLIBCXX_CONCEPT_CHECKS -
D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
(my standard options).
I've never encountered this form (without the comma), and
I usually do read the list of extensions in compiler
documentation when using a new compiler. Obviously you
have more experience with compilers than I do though!
Not so much compilers. According to the first edition of
_The C++ Programming Language__ (1986), the comma isn't
legal. According to the C90 or the C++98 standard, it is
optional. I've never seen a compiler that didn't accept it
either way, but then, I don't think I'd have noticed if it
didn't; I can't remember ever actually using varargs in C++.
Since both are required by the standard, I wouldn't expect
to find support for both mentionned in the compiler
documentation.
I tried on another machine with gcc 4.0.1 .
g++ allows int foo(int x...) , gcc gives 'syntax error'.
I checked in C99 again and the grammar specification
doesn't seem to permit int foo(int x...) , the
relevant bits are:
direct-declarator:
direct-declarator ( parameter-type-list )
[snip]
parameter-type-list:
parameter-list
parameter-list , ...
Are you sure C90 allowed it?
I'll check tonight (my only copy of C90 is at home), if I
remember it, but if C99 doesn't allow it, it's highly unlikely
that C90 did; the C committee is even stricter about not
breaking existing code that is the C++ committee. (And I was
sure that C99 also allowed it, but I can't find what made me
think that in the standard.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Nov 17 '08 #13

This discussion thread is closed

Replies have been disabled for this discussion.