Falk Tannh   user wrote:
>
> Dave Boyle wrote:
> > I was just making the point that you have made in your paragraph
> > above.  Even if void (denoting an empty parameter list) hadn't been
> > imported into C++ in order to maintain compatiblity with C, it ought
> > to have been brought across for exactly the reason you state.
> >
> > void func(void)
> >
> > uses void in a consistent manner whereas
> Not really - the return type of 'func' is 'void'; but 'func' takes
> /no parameters/, rather than /one parameter of type 'void'/.
>
> Thus, 'void func(void)' is to me not consistent with 'void func(int)'.

However, func does not return /one parameter of type 'void'/,
but it returns /nothing/. 'void' here means absence of value.
So I don't see any inconsistency in 'void func(void)'.

--
Seungbeom Kim

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Seungbeom Kim wrote:
> Falk Tannh   user wrote:
>>
>> Dave Boyle wrote:
>> > I was just making the point that you have made in your paragraph
>> > above.  Even if void (denoting an empty parameter list) hadn't been
>> > imported into C++ in order to maintain compatiblity with C, it ought
>> > to have been brought across for exactly the reason you state.
>> >
>> > void func(void)
>> >
>> > uses void in a consistent manner whereas
>> Not really - the return type of 'func' is 'void'; but 'func' takes
>> /no parameters/, rather than /one parameter of type 'void'/.
>>
>> Thus, 'void func(void)' is to me not consistent with 'void func(int)'.
>
> However, func does not return /one parameter of type 'void'/,
> but it returns /nothing/. 'void' here means absence of value.
> So I don't see any inconsistency in 'void func(void)'.

No, it's not inconsistent, but really it *should* be inconsistent.
The syntax allows for the arbitrary number of parameter types by
requiring delimiters and separators, so an empty list is parseable
without ambiguity.  However, it requires exactly one return type
whereas it is possible to have no return value at all, so there is a
need for a placeholder for the return type.  Of course C did use to
allow the omission of the return type from function declarations,
though defaulting to int rather than void.  That only works if there
is some other syntactic cue in the function declarations to indicate
that they are declarations and not function calls, which seems error-
prone.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

I was hoping to reply to an earlier post on the abovementioned,
nonetheless, I was not able to do so.

In any event, I'm trying to understand the


class
{
private:

public:
  FOO();
  void DoASpecialThing( void );
};

The method DoASpecialThing has the void parameter to indicated that
the function takes no arguments.   Trying to illustrate to a colleague
that this is a "C-ism" with which he replys 'not really'.

Now as I understand it.
In C
----------------------------
void DoASpecialThing();  meant void DoASpecialThing ( .. );  which
meant a method taking unspecified number of arguments.  So far so
good?

Now that's a problem for the case where the method takes no arguments.
 To alleviate that in C you'd do void DoASpecialThing( void );

In C++
----------------------------
No arguments means void DoASpecialThing();.   Plain and simple.

For an unspecified number of arguments in C++ I do just that
void DoASpecialThing ( .. );  correct?


Bottom line.  The 'void' in a parameter list for methods is a 'carry
over' for compability with C.

There's this issue of ellipses (ie. "( .. )") which I'm not following.
Of course, where in the standard is this sort of thing highlighted?

Thanks in advance.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"ma740988" <ma740988@pegasus.cc.ucf.edu> wrote in message news:a5ae824.0402170558.4d8f485@posting.google.com...

> In C
> ----------------------------
> void DoASpecialThing();  meant void DoASpecialThing ( .. );  which
> meant a method taking unspecified number of arguments.  So far so
> good?

It means a function taking an unspecified number of arguments.   However
    void DoSomething(...);
and
    void DoSomething();
mean different things even in C.   The ... says that the C function takes a
variable number of argumets via the stdarg macros.   The () says the function
arguments are unknown.   The actual fucntion definition may use stdarg or
it may have some subset of the allowable fixed argument lists.

> For an unspecified number of arguments in C++ I do just that
> void DoASpecialThing ( .. );  correct?

You can do a variable number of arguments with ... (Three dots).

However there is NO C++ concept quite equivelent to the C loosey-goosey
empty function declaration.

>
> Bottom line.  The 'void' in a parameter list for methods is a 'carry
> over' for compability with C.
>
That is true.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 18 Feb 2004 15:41:24 +0000 (UTC), ron@sensor.com ("Ron
Natalie") wrote in comp.std.c++:

>
> "ma740988" <ma740988@pegasus.cc.ucf.edu> wrote in message news:a5ae824.0402170558.4d8f485@posting.google.com...
>
> > In C
> > ----------------------------
> > void DoASpecialThing();  meant void DoASpecialThing ( .. );  which
> > meant a method taking unspecified number of arguments.  So far so
> > good?
>
> It means a function taking an unspecified number of arguments.   However
>     void DoSomething(...);
> and
>     void DoSomething();
> mean different things even in C.   The ... says that the C function takes a
> variable number of argumets via the stdarg macros.   The () says the function
> arguments are unknown.   The actual fucntion definition may use stdarg or
> it may have some subset of the allowable fixed argument lists.

Yes and no as far as C is concerned.  If DoSomething() is a variadic
function, it may indeed appear in a declaration with empty
parentheses, but there must also be a true prototype in scope before
it is called.

If a function has only a non-prototype declaration in scope at the
point where it is called, it is implicitly declared as accepting a
fixed but unspecified number of arguments of unspecified types from
the subset of types that result from the default argument promotions.

If the caller passes arguments that, after default promotions, match
the number and types the function actually accepts, the behavior is
defined.  If the number and/or types in the call do not match the
actual definition of the function, the behavior is undefined.

However, if a variadic function is called with only a non-prototype
declaration in scope, the behavior is undefined, period.  Even if the
number and types of arguments match.

This is not merely a legalistic standard issue.  Many compilers use a
different, and more efficient, argument passing sequence for
non-variadic functions than they must, by necessity, use for variadic
ones.

> > For an unspecified number of arguments in C++ I do just that
> > void DoASpecialThing ( .. );  correct?
>
> You can do a variable number of arguments with ... (Three dots).
>
> However there is NO C++ concept quite equivelent to the C loosey-goosey
> empty function declaration.

Unfortunately, for backwards compatibility, even the latest C standard
still allows function to be called with only a non-prototype
declaration in scope, although the restrictions above still apply.

> > Bottom line.  The 'void' in a parameter list for methods is a 'carry
> > over' for compability with C.
> >
> That is true.

...and there is absolutely nothing wrong with it in C++, other then
the esthetic dislike by Bjarne and (perhaps many) others.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie wrote:

> "ma740988" <ma740988@pegasus.cc.ucf.edu> wrote:
>>In C
>>----------------------------
>>void DoASpecialThing();  meant void DoASpecialThing ( .. );  which
>>meant a method taking unspecified number of arguments.  So far so
>>good?
>
>
> It means a function taking an unspecified number of arguments.   However
>     void DoSomething(...);
> and
>     void DoSomething();
> mean different things even in C.

As shown, the three dots mean 'error' in C; they must follow at least
one argument of known type:

 void DoSomething(int x, ...);

--
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

ma740988@pegasus.cc.ucf.edu (ma740988) wrote in message news:<a5ae824.0402170558.4d8f485@posting.google.com>...
> I was hoping to reply to an earlier post on the abovementioned,
> nonetheless, I was not able to do so.
>
> In any event, I'm trying to understand the
>
>
> class
> {
> private:
>
> public:
>   FOO();
>   void DoASpecialThing( void );
> };
>
> The method DoASpecialThing has the void parameter to indicated that
> the function takes no arguments.   Trying to illustrate to a colleague
> that this is a "C-ism" with which he replys 'not really'.
>
> Now as I understand it.
> In C
> ----------------------------
> void DoASpecialThing();  meant void DoASpecialThing ( .. );  which
> meant a method taking unspecified number of arguments.  So far so
> good?

Not quite. In C, there's difference between functions with no argument
list, and functions with an argument list that ends in an ellipsis
"...".

When a function is called using an expression with a function type
that has no argument list, the number of arguments it is called with
must match exactly the number of parameters in the function
definition, and the promoted types of arguments must be compatible
with the types of the corresponding parameters. The function
definition must not use an ellipsis. In practice, the undefined
behavior of such a mis-match is benign on may systems: missing
arguments don't cause problems, as long the called function makes no
attempt to access the corresponding parameters.. Excess arguments were
ignored. However, you should not count on that.

A function declared with an ellipsis can be called with any number of
arguments that is greater than or equal to the number of explicitly
listed parameters in the declaration. The corresponding function
definition must have a compatible declaration, which basically means
that it must have the same number of explicitly specified parameters,
and corresponding parameters must have compatible types, and it must
also end in an ellipsis after the last parameter.

> Now that's a problem for the case where the method takes no arguments.
>  To alleviate that in C you'd do void DoASpecialThing( void );

It's not a problem, as such. It simply serves the same purpose as any
other prototype, to enforceably document the function interface. K&R
style function declarations made no distinction between functions with
undeclared interfaces, and functions with an interface that takes no
arguments. Since standard C had to continue supporting K&R style
declarations, it couldn't treat an empty argument list as an explicit
prototype for a function taking no arguments. For C++, the decision
was made to make prototypes mandatory, so for C++, that argument no
longer applies.

> In C++
> ----------------------------
> No arguments means void DoASpecialThing();.   Plain and simple.
>
> For an unspecified number of arguments in C++ I do just that
> void DoASpecialThing ( .. );  correct?
>
>
> Bottom line.  The 'void' in a parameter list for methods is a 'carry
> over' for compability with C.

That part's correct. It's provided only for compatibility with
ANSI/ISO C.

> There's this issue of ellipses (ie. "( .. )") which I'm not following.
> Of course, where in the standard is this sort of thing highlighted?

Search through the standard for "ellipsis" - the effects of using them
are scattered in several different places. However, the main thing you
need to look at is the C standard, in section 7.15, which describes
<stdarg.h>, and the C++ standard, in section 18.7p3, which describes
some subtle adjustments to that description for C++.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

ma740988@pegasus.cc.ucf.edu (ma740988) wrote in message news:<a5ae824.0402170558.4d8f485@posting.google.com>...
> I was hoping to reply to an earlier post on the abovementioned,
> nonetheless, I was not able to do so.
>
> In any event, I'm trying to understand the
>
>
> class

You've forgotten to give the class a name.  The only time that a class
needn't be named is when it is used to declare a variable of that
type, e.g.

  class { /* ... */ } foo;

(And that isn't a particularly useful construct.)

> {
> private:
>
> public:
>   FOO();

Is this supposed to be a constructor?  If not, the function needs a
return type, e.g.

   int FOO();

C used to have (until 1999) "implicit int" which meant that in the
absense of a  return type, int was assumed.  C no longer has this and
C++ never has had.

>   void DoASpecialThing( void );
> };
>
> The method DoASpecialThing has the void parameter to indicated that
> the function takes no arguments.   Trying to illustrate to a colleague
> that this is a "C-ism" with which he replys 'not really'.

It's a "C-ish" in the same way that delimiting the arguments with
parentheses is a "C-ish" and using a semicolon to mark the end of a
statement or declaration is a "C-ish".  C++ is derived from C and many
things are the same in both languages.  This use of void is one such
use.

> Now as I understand it.
> In C
> ----------------------------
> void DoASpecialThing();  meant void DoASpecialThing ( .. );  which
> meant a method taking unspecified number of arguments.  So far so
> good?

This is broadly correct, although there are a number of errors in the
details.  First the ellipsis has three dots, not two.  Second, a
function cannot be declared (in C) with an ellipsis as its only
parameter: there must be at least one argument before it.  Thus,

  void foo(int x, ...);

is legal, but

  void foo(...);

is not.  Third, a function declared to be variadic (that is, having an
ellipsis as a parameter) has prototype; a function with an empty
argument list is unprototyped.  This affects what subsequent
redeclarations are allowed, and possibly the calling convention used.
An unprototyped function takes an unknown number of arguments; a
variadic function takes an arbitrary number of arguments: these are
not the same thing.

> Now that's a problem for the case where the method takes no arguments.
>  To alleviate that in C you'd do void DoASpecialThing( void );

I wouldn't say a "problem", or, if it is, it's a frequently
encountered problem.  It's the difference between absence of knowledge
(e.g. void foo()) and knowledge of absence (e.g. void foo(void)).

> In C++
> ----------------------------
> No arguments means void DoASpecialThing();.   Plain and simple.

I think you have your cause and effect confused.  "void
DoASpecialThing();" means it no arguments; no arguments *can* be
written "void DoASpecialThing();" but it needn't.

> For an unspecified number of arguments in C++ I do just that
> void DoASpecialThing ( .. );  correct?

Well... you *can* write that, it's legal syntax (at least, it is if
you spell your ellipsis correctly).  There are two problems, though:
you can't pass POD-types through the ellipsis, and you can't access
the arguments passed in if the ellipsis is the first parameter.

> Bottom line.  The 'void' in a parameter list for methods is a 'carry
> over' for compability with C.

Yes, you could look at it like that.  Or you could think of it the
other way round: that "void foo();" in C++ is a gratuitous
incompatibility with C.  The latter is closer to my opinion.

> There's this issue of ellipses (ie. "( .. )")
> which I'm not following.

Which issue in particular?

> Of course, where in the standard is this sort of thing highlighted?

Which aspect in particular?

C++98/8.3.5 deals with the syntax for function declarations, and
including the use of the ellipsis.

C99/6.7.5.3 is the comparable clause for C.

C++98/C.1.6/1 talks about compability problems between C and C++ due
to unprototyped functions.

C99/7.15 talks about a mechanism for accessing arguments passed to
variadic functions.

C++98/18.7/3 does the same by reference to the comparable passage
(C90/4.8) in the previous version of the C standard (C90).

--
Richard Smith

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0402180822.7526ee44@posting.google.com>...
> When a function is called using an expression with a function type
> that has no argument list, the number of arguments it is called with
> must match exactly the number of parameters in the function
> definition, and the promoted types of arguments must be compatible
> with the types of the corresponding parameters.

Surely "... the promoted types of arguments must be compatible with
the _promoted_ types of the corresponding parameters".

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

<snip>
>
> > Bottom line.  The 'void' in a parameter list for methods is a 'carry
> > over' for compability with C.
>
> Yes, you could look at it like that.  Or you could think of it the
> other way round: that "void foo();" in C++ is a gratuitous
> incompatibility with C.  The latter is closer to my opinion.
>
<snip>

Would it not also be fair to say that had void not been carried over
for compatibility reasons then it should be brought across anyway so
that specifying that a function takes no parameters and a function
returns no parameters can be done in a consistant manner?

Cheers,

Dave

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

algrant@myrealbox.com (Al Grant) wrote in message news:<5765b025.0402200038.4de1138e@posting.google.com>...
> kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0402180822.7526ee44@posting.google.com>...
> > When a function is called using an expression with a function type
> > that has no argument list, the number of arguments it is called with
> > must match exactly the number of parameters in the function
> > definition, and the promoted types of arguments must be compatible
> > with the types of the corresponding parameters.
>
> Surely "... the promoted types of arguments must be compatible with
> the _promoted_ types of the corresponding parameters".

Only if the function is defined without a prototype. If it is defined
with a prototype, they must be compatible with the actual parameter
type. See the C standard, section 6.5.2.2p6. One of the advantages of
C++ is that it doesn't have to worry about that distinction, since
both the function call and the function definition are required to be
based upon function prototypes.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

david.boyle@ed.tadpole.com (Dave Boyle) wrote in message news:<30e6e0a8.0402200448.4d4f22cb@posting.google.com>...
> <snip>
> >
> > > Bottom line.  The 'void' in a parameter list for methods is a 'carry
> > > over' for compability with C.
> >
> > Yes, you could look at it like that.  Or you could think of it the
> > other way round: that "void foo();" in C++ is a gratuitous
> > incompatibility with C.  The latter is closer to my opinion.
> >
> <snip>
>
> Would it not also be fair to say that had void not been carried over
> for compatibility reasons then it should be brought across anyway so
> that specifying that a function takes no parameters and a function
> returns no parameters can be done in a consistant manner?

I think you misunderstood me, perhaps because I phrased it poorly.
When I said that C++'s "void foo();" is a gratuitous incompatbility
with C, I was referring to the omission of void in the parameter list.
 In this respect, C is perfectly consistent: a function that returns
nothing is specified to return "void", and a function that takes no
arguments is specified to (explicitly) take "void".

There are two reasons why I think C++ was wrong to allow the omission
of void in the parameter list.  The first is compatibility: I might
very well have a C90 header that declares a function:

   void foo();

A C++ compiler will see this and think it means foo takes no
arguments.  In fact, it means foo takes an unspecified number of
arguments.  Far better, in my opinion, to give an error message.

Secondly, many of the function declaration / object declaration
ambiguities stem from this.  Take the following example given by Herb
Sutter in GotW #75:

  deque<string> coll3( istream_iterator<string>( cin ),
                       istream_iterator<string>() );

The problem here is that the second argument can be parsed as a type:
namely, a function returning an istream_iterator<string> and taking no
arguments.  This means that the statement can be parsed either as an
object definition or as a function declaration, and the Standard
mandates the latter choice.

If C++ had not allowed the omission of void, the second argument could
not be parsed as a parameter declaration and would instead be parsed
as an expression, and the whole statement would be interpreted as an
object definition as was no doubt intended.

Anyway, it's all water under the bridge now.  Right or wrong, the
decision to allow the omission of the explicit void parameter has been
made and me must live with it.

--
Richard Smith

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 23 Feb 2004 00:32:35 -0600, Richard Smith wrote:

> In this respect, C is perfectly consistent: a function that returns
> nothing is specified to return "void", and a function that takes no
> arguments is specified to (explicitly) take "void".

I disagree. A function has a single result (which may be void, which
models lack of useful result) but an arbitrary number of parameters
(where it's not necessary to use void to specify none).

In particular you can't call a function of void arguments with the result
of a function of void result as argument.

> Secondly, many of the function declaration / object declaration
> ambiguities stem from this.  Take the following example given by Herb
> Sutter in GotW #75:
>
>   deque<string> coll3( istream_iterator<string>( cin ),
>                        istream_iterator<string>() );

Removing empty function parameters doesn't remove such ambiguities.
It removes this example, but replacing () by (ident) is as ambiguous
as now.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Marcin 'Qrczak' Kowalczyk wrote:
> On Mon, 23 Feb 2004 00:32:35 -0600, Richard Smith wrote:
>
> > Secondly, many of the function declaration / object declaration
> > ambiguities stem from this.  Take the following example given by Herb
> > Sutter in GotW #75:
> >
> >   deque<string> coll3( istream_iterator<string>( cin ),
> >                        istream_iterator<string>() );
>
> Removing empty function parameters doesn't remove such ambiguities.
> It removes this example, but replacing () by (ident) is as ambiguous
> as now.

Indeed so; however I only said that it removed many of the
ambiguities.  In my experience, many such ambiguities that you see do
have at least one empty argument list and so would be resolved.

Anyway, as I said before, it's too late to change this.

--
Richard Smith

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

richard@ex-parrot.com (Richard Smith) wrote in message news:<1a0929fa.0402180825.2113e3cc@posting.google.com>...
> ma740988@pegasus.cc.ucf.edu (ma740988) wrote in message news:<a5ae824.0402170558.4d8f485@posting.google.com>...
..
> > Bottom line.  The 'void' in a parameter list for methods is a 'carry
> > over' for compability with C.
>
> Yes, you could look at it like that.  Or you could think of it the
> other way round: that "void foo();" in C++ is a gratuitous
> incompatibility with C.  The latter is closer to my opinion.

It is an incompatibility, but there's nothing gratuitous about it.
With prototypes being mandatory in C++ (as they would ideally have
been from the beginning in C), an empty argument list is the most
natural way to express the absence of any parameters. This was a
well-motivated design choice. You might argue whether it was the right
choice, but it wasn't gratuitous.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

<snip>

> I think you misunderstood me, perhaps because I phrased it poorly.
> When I said that C++'s "void foo();" is a gratuitous incompatbility
> with C, I was referring to the omission of void in the parameter list.
>  In this respect, C is perfectly consistent: a function that returns
> nothing is specified to return "void", and a function that takes no
> arguments is specified to (explicitly) take "void".

We may well be talking at cross-purposes but I'm pretty sure we're
saying similar things!

I was just making the point that you have made in your paragraph
above.  Even if void (denoting an empty parameter list) hadn't been
imported into C++ in order to maintain compatiblity with C, it ought
to have been brought across for exactly the reason you state.

void func(void)

uses void in a consistent manner whereas

void func()

does not.

<snip>

> Anyway, it's all water under the bridge now.  Right or wrong, the
> decision to allow the omission of the explicit void parameter has been
> made and me must live with it.

This is true, but wrt the OP, he should note that there are (arguably)
reasons other than compatibility for allowing void to denote "no
parameters" within C++.

Cheers,

Dave

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Marcin 'Qrczak' Kowalczyk wrote:
>
> In particular you can't call a function of void arguments with the result
> of a function of void result as argument.

Oh, indeed; given "void test(void);" it can 'return' the result of
a void function, but it cannot take the result of a void function.
I didn't notice this difference; why do we have it?

--
Seungbeom Kim

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 23 Feb 2004 22:48:05 -0600, Seungbeom Kim wrote:

>> In particular you can't call a function of void arguments with the result
>> of a function of void result as argument.
>
> Oh, indeed; given "void test(void);" it can 'return' the result of
> a void function, but it cannot take the result of a void function.
> I didn't notice this difference; why do we have it?

Because such function doesn't take a void argument. It takes no arguments

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <403A4688.ED6348D6@bawi.org>, Seungbeom Kim
<musiphil@bawi.org> writes
>Marcin 'Qrczak' Kowalczyk wrote:
>>
>> In particular you can't call a function of void arguments with the result
>> of a function of void result as argument.
>
>Oh, indeed; given "void test(void);" it can 'return' the result of
>a void function, but it cannot take the result of a void function.
>I didn't notice this difference; why do we have it?

Because the return case was added for the benefit of generic code (it
allows delegation to be coded the same way for all return types). There
is no benefit (for generic code) in extending this any further and we
did not want to touch the type system any further without both good
reason and a great deal of thought.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <30e6e0a8.0402231000.2d5c8d4f@posting.google.com>, Dave Boyle
<david.boyle@ed.tadpole.com> writes
>I was just making the point that you have made in your paragraph
>above.  Even if void (denoting an empty parameter list) hadn't been
>imported into C++ in order to maintain compatiblity with C, it ought
>to have been brought across for exactly the reason you state.
>
>void func(void)
>
>uses void in a consistent manner whereas

debatable. void is a type (albeit an uncompleted one) in both C and C++.
That is fine for the first use, it allows us to hack together procedures
by allowing a never used return value of an incomplete type. However the
second case declares a parameter of type void. We could hack that as
well but it requires a much greater hack in C++ than in C because of the
existence of overloading. Anyway it is water under the bridge because
C++ is, in this respect, as it is.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Boyle wrote:
> I was just making the point that you have made in your paragraph
> above.  Even if void (denoting an empty parameter list) hadn't been
> imported into C++ in order to maintain compatiblity with C, it ought
> to have been brought across for exactly the reason you state.
>
> void func(void)
>
> uses void in a consistent manner whereas
Not really - the return type of 'func' is 'void'; but 'func' takes
/no parameters/, rather than /one parameter of type 'void'/.

Thus, 'void func(void)' is to me not consistent with 'void func(int)'.

Otherwise, why shouldn't we allow functions like 'void func(int, void)'?

To me it rather seems that C makes an inconsistent usage of the 'void'
keyword in this manner, which is historically explainable by the fact
that K&R C didn't require function declarations with parameter lists
prior to using the function - a sloppiness that BS chose to correct in C++.

>
> void func()
>
> does not.

Falk

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]