 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Ben Hutchings
Guest
|
 Posted: Sat Apr 22, 2006 3:06 am Post subject: Defect Report: Definition of void parameter list differs fro |
 |
|
[ Note: Forwarded to C++ Committee. -sdc ]
The standard says this about the void parameter list:
"The parameter list (void) is equivalent to the empty parameter list."
(8.3.5 [dcl.fct] paragraph 2)
The C99 standard apparently says something slightly different, though
I'm afraid I'm quoting from a draft here:
"The special case of an unnamed parameter of type void as the only
item in the list specifies that the function has no parameters."
(6.7.5.3 paragraph 10)
If I understand these correctly, this means a C compiler must take
type aliases into account before checking for the special case whereas
a C++ compiler must not.
Comeau C++ in strict mode follows the C++ standard in this regard, as
does the development version of g++ (which will become 4.2), though
older versions of g++ follow the C standard. During testing of the
new version in Debian, we found that this change broke a C++ program
that uses the OpenAL library, one of whose headers used a type alias
for void in a function parameter list.
Given that this special case only exists in C++ for compatibility with
C, it seems to be a defect in the standard that it is defined slightly
differently.
Ben.
--
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
- Carolyn Scheppner
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
SuperKoko
Guest
|
| Posted: Sat Apr 22, 2006 5:06 pm Post subject: Re: Defect Report: Definition of void parameter list differs |
|
|
Ben Hutchings wrote:
| Quote: | [ Note: Forwarded to C++ Committee. -sdc ]
The standard says this about the void parameter list:
"The parameter list (void) is equivalent to the empty parameter list."
(8.3.5 [dcl.fct] paragraph 2)
The C++ standard seems to be pretty clear here : type aliases are |
forbidden.
| Quote: | The C99 standard apparently says something slightly different, though
I'm afraid I'm quoting from a draft here:
"The special case of an unnamed parameter of type void as the only
item in the list specifies that the function has no parameters."
(6.7.5.3 paragraph 10)
If I understand these correctly, this means a C compiler must take
type aliases into account before checking for the special case whereas
a C++ compiler must not.
I read a bit the C99 standard, and reading 6.7.7 (Type definitions), |
and searching whole text for "void type" seems to confirm that a
typedef for the void type, is a void type.
For example 6.5.4-2 (Cast operators) says that:
"Unless the type name specifies a void type, the type name shall
specify qualified or
unqualified scalar type and the operand shall have scalar type."
So, I am pretty sure you are right : An alias is allowed.
| Quote: | Comeau C++ in strict mode follows the C++ standard in this regard, as
does the development version of g++ (which will become 4.2), though
older versions of g++ follow the C standard. During testing of the
new version in Debian, we found that this change broke a C++ program
that uses the OpenAL library, one of whose headers used a type alias
for void in a function parameter list.
I tried Comeau C99 online, in strict mode, and it seems to interpret it |
as incorrect C too:
typedef void VOID;
void f(VOID)
{
}
int main()
{
f();
}
| Quote: | Given that this special case only exists in C++ for compatibility with
C, it seems to be a defect in the standard that it is defined slightly
differently.
Yes, it looks like a defect in the C++ standard. |
The obvious resolution would be to adopt the C99 rule, since that stuff
is only here for backward compatibility... So, it's better being fully
compatible.
What I don't like, is the fact that C99 seems to interpret differently
the C99 standard from us (Me, and you).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
SuperKoko
Guest
|
| Posted: Sun Apr 23, 2006 5:06 am Post subject: Re: Defect Report: Definition of void parameter list differs |
|
|
Ben Hutchings wrote:
| Quote: | [ Note: Forwarded to C++ Committee. -sdc ]
The standard says this about the void parameter list:
"The parameter list (void) is equivalent to the empty parameter list."
(8.3.5 [dcl.fct] paragraph 2)
The C++ standard seems to be pretty clear here : type aliases are |
forbidden.
| Quote: | The C99 standard apparently says something slightly different, though
I'm afraid I'm quoting from a draft here:
"The special case of an unnamed parameter of type void as the only
item in the list specifies that the function has no parameters."
(6.7.5.3 paragraph 10)
If I understand these correctly, this means a C compiler must take
type aliases into account before checking for the special case whereas
a C++ compiler must not.
I read a bit the C99 standard, and reading 6.7.7 (Type definitions), |
and searching whole text for "void type" seems to confirm that a
typedef for the void type, is a void type.
For example 6.5.4-2 (Cast operators) says that:
"Unless the type name specifies a void type, the type name shall
specify qualified or
unqualified scalar type and the operand shall have scalar type."
So, I am pretty sure you are right : An alias is allowed.
| Quote: | Comeau C++ in strict mode follows the C++ standard in this regard, as
does the development version of g++ (which will become 4.2), though
older versions of g++ follow the C standard. During testing of the
new version in Debian, we found that this change broke a C++ program
that uses the OpenAL library, one of whose headers used a type alias
for void in a function parameter list.
I tried Comeau C99 online, in strict mode, and it seems to interpret it |
as incorrect C too:
typedef void VOID;
void f(VOID)
{
}
int main()
{
f();
}
| Quote: | Given that this special case only exists in C++ for compatibility with
C, it seems to be a defect in the standard that it is defined slightly
differently.
Yes, it looks like a defect in the C++ standard. |
The obvious resolution would be to adopt the C99 rule, since that stuff
is only here for backward compatibility... So, it's better being fully
compatible.
What I don't like, is the fact that Comeau seems to interpret
differently the C99 standard from us (Me, and you).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Andrew Koenig
Guest
|
| Posted: Mon Apr 24, 2006 4:06 pm Post subject: Re: Defect Report: Definition of void parameter list differs |
|
|
"Ben Hutchings" <ben-public-nospam (AT) decadentplace (DOT) org.uk> wrote in message
news:20060422000539.GB6357 (AT) decadentplace (DOT) org.uk...
| Quote: | [ Note: Forwarded to C++ Committee. -sdc ]
The standard says this about the void parameter list:
"The parameter list (void) is equivalent to the empty parameter list."
(8.3.5 [dcl.fct] paragraph 2)
|
Personally, I think it is unfortunate that C defined void to have magical
properties, and I'd hate to compound the misfortune by requiring that the
number of parameters in
int f(T);
depend on the definition of T--especially if T is a template parameter.
Here is one way that I imagine could resolve these issues in principle,
though I doubt it's feasible in practice.
Make void into a real type. An object of type void contains only a single
value, written as (). An empty function argument also generates a void
value.
Void values can be assigned and copied just like any others. All six
relational operators are defined, with ==, <=, and >= returning true and the
others returning false.
There is no longer any such thing as a function without parameters. If you
define
int f() { return 42; }
that function takes a single parameter of type void. When you call it as
f(), the empty argument also has type void. If you write
int f(void) { return 42; }
or even
int f(void foo) { return 42; }
the meaning is exactly the same.
One advantage of this notion is that set<T> starts to look an awful lot like
map<T,void>, a fact that would surely make library implementation easier.
Unfortunatly, I suspect that this idea has too many compatibility problems
to be feasible at this point.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
SuperKoko
Guest
|
| Posted: Sat Apr 29, 2006 9:06 pm Post subject: Re: Defect Report: Definition of void parameter list differs |
|
|
Andrew Koenig wrote:
| Quote: | "Ben Hutchings" <ben-public-nospam (AT) decadentplace (DOT) org.uk> wrote in message
news:20060422000539.GB6357 (AT) decadentplace (DOT) org.uk...
[ Note: Forwarded to C++ Committee. -sdc ]
The standard says this about the void parameter list:
"The parameter list (void) is equivalent to the empty parameter list."
(8.3.5 [dcl.fct] paragraph 2)
Personally, I think it is unfortunate that C defined void to have magical
properties, and I'd hate to compound the misfortune by requiring that the
number of parameters in
int f(T);
depend on the definition of T--especially if T is a template parameter.
I agree that it is ugly. |
If T, is a typedef, I think that it is not a real problem, since its
type is usually explicit enough.
For instance the VOID type used in the Win32 API is a typedef for void.
And, the Win32 API, uses, at several places, declarations with a (VOID)
parameter list.
For templates, it seems to be a greater problem. But, since the void
type is not assignable, nor instanciable and is very particular. I
can't think of a template that would "work" with the void type...
Indeed, "int f(T)" where T is a void type, is currently ill-formed. So,
accepting the C rule, would just make ill-formed programs,
well-formed... And, in the case of templates, it would probably not
make the program well-formed, because of other problems of void.
My point, is that the C approach, is only ugly for the mind... It'll
not be a practical problem.
On the other side, an incompatibility between C and C++ has concrete
consequences.
And, you probably know that there are much worse context-dependent
semantics, with new.
template <class T>
T* CreateT()
{
return new T;
}
int main() {
typedef char U[42];
U* p=CreateT<U>(); // Beware it returns a char*, not a char(*)[42]
// And you must call delete[] to free it, not delete!
// Fortunately, the compiler will catch, at compile-time, the invalid
conversion from char* to char(*)[42]
}
On the other side, since arrays have no copy-constructor, nor
copy-assignment operator, they can't be used as a normal type...
Fortunately boost::array has none of these problems.
| Quote: | Here is one way that I imagine could resolve these issues in principle,
though I doubt it's feasible in practice.
Make void into a real type. An object of type void contains only a single
value, written as (). An empty function argument also generates a void
value.
Void values can be assigned and copied just like any others. All six
relational operators are defined, with ==, <=, and >= returning true and the
others returning false.
There is no longer any such thing as a function without parameters. If you
define
int f() { return 42; }
that function takes a single parameter of type void. When you call it as
f(), the empty argument also has type void. If you write
int f(void) { return 42; }
or even
int f(void foo) { return 42; }
the meaning is exactly the same.
One advantage of this notion is that set<T> starts to look an awful lot like
map<T,void>, a fact that would surely make library implementation easier.
|
Yes, the idea is pretty, and would be probably useful in templates.
IMHO, it would simplify the language specification, since void would
not be a "special syntax", eveywhere it is used.
Historically, the void type became more and more like another type.
Initially, C had no void type.
Then, the void type has been introduced for return values.
I don't know exactly, when void in typedef appeared... Probably, at the
same time than typedef.
Early C++, introduced void*, and the C comitee borrowed it for the 1989
standard.
With templates, the need for a "copy-constructor" for void, became
obvious.
I mean that:
void g();
void f() {return g();}
Were not allowed in old C and C++ compilers.
| Quote: | Unfortunatly, I suspect that this idea has too many compatibility problems
to be feasible at this point.
I don't think it will introduce any incompatibility. |
However, I'm pretty sure that it would induce many new bugs, in
beginners' code, since ill-formed constructs would become well-defined.
But, any language change needs a strong motivation... Here, the benefit
is probably not negligible, but I'm not sure it is sufficient.
The main motivation I see, is that it would make evolve C++ toward a
cleaner language.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
