Gabriel Dos Reis wrote:

> richard@ex-parrot.com (Richard Smith) writes:
>
> | If it mandated the use of void, it would have removed a
> | great many of the more common ambiguities between function
> | declarations and object declarations.  In the current
> | language, if I write
> |
> |   int x( int() );
> |
> | I have declared a function, x, taking one argument of type
> | int(*)(), and returning an int.  I don't find this behaviour
> | particularly intuitive.
>
> Then, be explicit about type issues.

My point is that the language doesn't make this particularly
easy.  Suppose I'm writing a template where T is template
parameter, and I want to default construct a variable of
type T, what is the obvious thing to write?

  T t;

Except this doesn't call the default constructor if T is an
int or similar.  So, instead I try

  T t = T();

but this breaks if T is non-copyable.  So next I try

  T t();

But now, I find I've just declared a function returning a T
and taking no arguments.  Attempting to disambiguate this
using the "auto" keyword will also fail.

If I'm feeling adventurous, I might even try to bind a
temporary to a const reference to extend its lifetime,

  T const& t = T();

... before discovering that as the temporary is an rvalue it
may get copied.

It's a very simple thing to want to do, yet the language as
it stands make it very difficult to do.  Had the use of void
to specify functions with no arguments been retained, the
syntax

  T t();

would have been free to have default constructed an object
of type T.

I appreciate it's too late to solve this (at least in this
way), but this is not the point I was making.  My point was
that in retrospect I think it was a mistake.

> If you asked me, I would tell that having to use special keyword to
> mark a place "there is nothing", instead or writing nothing hurts
> my intuition.

However, I expect the majority (though perhaps decreasingly
so) of C++ programmers come from a C background, and are
used to using void to mean this.  When I first learnt C, I
didn't find it particularly counter-intuitive.  Many
situations both in computing and real-life require you to
explicitly say nothing rather than just leaving a blank and
hoping it is correctly interpreted.  People understand 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                       ]

void foo (void) { }


void bar1 (int a) { return; }
void bar2 (int b) { return bar1(29); } //This is allowed.

int main ()
{
  bar2(34);
  foo ();
  foo (bar2(33)); //Compiler complains here.
}


The reason wht I'm asking this is because, I want to dispatch on whether
an (say) iterator is of a certain type during construction of an object,
and example will make the idea more clearer.


template <class t>
struct foo {
t iter;
//Now, t is an iterator (say), such that if its category is _param then, it
can be constructed by parameters to its ctor, however, if its category is
_default, then it has to be default constructed.


foo (int a): iter (a) { }
//Now, if iter is not default onstructible, it will give an error.
//So, I was thinking on these lines:

void _aux_construct (int a, _default) { return; }
int _aux_construct (int a, _param) { return a; }

//Then, in the ctor, do something like this:
foo (int a): iter (_aux_construct (a, typename
iterator_traits<t>::iterator_category()) { }
//Assume iterator_category can be 1 of these 2 types only.
};

So, this way, if _param is the iterator_category, then the function with a
void return value will be called, otherwise, the non-void return valued
function will be called.



Regards,
-Dhruv.






---
[ 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                       ]

"Dhruv" wrote:
> void foo (void) { }

This means that you are passing no parameters to foo, not that you are
passing a "void" type parameter.

>
>
> void bar1 (int a) { return; }
> void bar2 (int b) { return bar1(29); } //This is allowed.
>
> int main ()
> {
>   bar2(34);
>   foo ();
>   foo (bar2(33)); //Compiler complains here.

You are passing a parameter to foo.

> }
>
>
> The reason wht I'm asking this is because, I want to dispatch on
> whether an (say) iterator is of a certain type during construction of
> an object, and example will make the idea more clearer.

---
[ 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                       ]

Dhruv wrote:

> void foo (void) { }
>
> void bar1 (int a) { return; }
> void bar2 (int b) { return bar1(29); } //This is allowed.
>
> int main ()
> {
>   bar2(34);
>   foo ();
>   foo (bar2(33)); //Compiler complains here.
> }

foo is not a function that takes one argument of type void,
it is a function that takes zero arguments.

> template <class t>
> struct foo {
> t iter;
> //Now, t is an iterator (say), such that if its category is _param then, it
> can be constructed by parameters to its ctor, however, if its category is
> _default, then it has to be default constructed.

I assume by _default you mean forward_iterator_tag.
ForwardIterator, BiDirectionalIterators and
RandomAccessIterators are the only Standard-defined
iterator concepts that can be default constructed.

> foo (int a): iter (a) { }
> //Now, if iter is not default onstructible, it will give an error.

Why will it?  You are not default constructing it, you are
constructing it from an integer.  I doubt you'll find may
iterators that are constructible from an integer.

> //So, I was thinking on these lines:
> void _aux_construct (int a, _default) { return; }
> int _aux_construct (int a, _param) { return a; }

You should make the functions return an iterator

  Iter _aux_construct(int a, _default) { return Iter(); }
  Iter _aux_construct(int a, _param)   { return Iter(a); }

> //Then, in the ctor, do something like this:
> foo (int a): iter (_aux_construct (a, typename
> iterator_traits<t>::iterator_category()) { }
> //Assume iterator_category can be 1 of these 2 types only.

I think you've fundamentally missed they point of
iterator categories.  If the iterator is a forward iterator
or better, you can default construct it.  If it is not, you
are *very* unlikely to be able to construct it from an
integer.

--
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 Thu, 24 Jul 2003 02:13:08 +0000, Richard Smith wrote:

> Dhruv wrote:
>
>> void foo (void) { }
>>
>> void bar1 (int a) { return; }
>> void bar2 (int b) { return bar1(29); } //This is allowed.
>>
>> int main ()
>> {
>>   bar2(34);
>>   foo ();
>>   foo (bar2(33)); //Compiler complains here.
>> }
>
> foo is not a function that takes one argument of type void,
> it is a function that takes zero arguments.
>


Yes, but when you have a function returning a void (say foo), and another
function that also returns void, (say bar), then you can do something like
this for foo's return:

void bar () { return; }
void foo () { return bar(); }

This doesn't seem to be consistent with the fact that you cannot pass it as a
parameter, like this:

foo (bar());

That's what I was getting at.



>> template <class t>
>> struct foo {
>> t iter;
>> //Now, t is an iterator (say), such that if its category is _param then, it
>> can be constructed by parameters to its ctor, however, if its category is
>> _default, then it has to be default constructed.
>
> I assume by _default you mean forward_iterator_tag.
> ForwardIterator, BiDirectionalIterators and
> RandomAccessIterators are the only Standard-defined
> iterator concepts that can be default constructed.
>
Sorry about that, assume that iterator is not the standard
iterator. I gave that eg. because it fitted well with what I was
trying to get at. What I meant was that there is some class which has a
certain typedef called (say iterator_category), and if that category is:
default, we can default construct an object of that class, otherwise if it
is param, we can not. So, if we try to default construct a non-default
constructible obejct, it will give a compile time error. right, so I was
trying to dispatch on whether default is calss_name::iterator_category. If
so, then default construct it, and if it's param, construct it with a
parameter. So, if what I said (which is probably illegal, about passing
void parameters to a function that does not accept anthing) was correct,
then it would work right?



>> foo (int a): iter (a) { }
>> //Now, if iter is not default onstructible, it will give an error.
>
> Why will it?  You are not default constructing it, you are
> constructing it from an integer.  I doubt you'll find may
> iterators that are constructible from an integer.
>
>> //So, I was thinking on these lines:
>> void _aux_construct (int a, _default) { return; }
>> int _aux_construct (int a, _param) { return a; }
>
> You should make the functions return an iterator
>
>   Iter _aux_construct(int a, _default) { return Iter(); }
>   Iter _aux_construct(int a, _param)   { return Iter(a); }
>
>> //Then, in the ctor, do something like this:
>> foo (int a): iter (_aux_construct (a, typename
>> iterator_traits<t>::iterator_category()) { }
>> //Assume iterator_category can be 1 of these 2 types only.
>
> I think you've fundamentally missed they point of
> iterator categories.  If the iterator is a forward iterator
> or better, you can default construct it.  If it is not, you
> are *very* unlikely to be able to construct it from an
> integer.
>

Regards,
-Dhruv.






---
[ 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 <pan.2003.07.24.06.29.41.25688@gmx.net>, Dhruv
<dhruvbird@gmx.net> writes
>Yes, but when you have a function returning a void (say foo), and another
>function that also returns void, (say bar), then you can do something like
>this for foo's return:
>
>void bar () { return; }
>void foo () { return bar(); }
>
>This doesn't seem to be consistent with the fact that you cannot pass it as a
>parameter, like this:
>
>foo (bar());
>
>That's what I was getting at.
>
Just because the same word is used in each case does not mean it means
the same thing. In C++ all functions have return values. We have a
special incomplete type called void that is used to signify that the
return form a function is irrelevant and cannot be used. It is useful to
allow that objects of this incomplete type to be returned.

Now absolutely separately C had a problem with the syntax of
declarations which meant that it needed a way to make explicit the
absence of parameters in a function declaration as distinct from an
unknown number of parameters of unknown types. It recycled void for this
purpose. The keyword void has overloaded meanings. In most contexts it
means a special incomplete and incompletable type. However in the
context of a function parameter list it means there are none. Were it
not for compatibility with C void for a parameter list would not exist.
C++ does not have the problem C has with an older function declaration
syntax.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

""Dhruv"" <dhruvbird@gmx.net> wrote in message news:pan.2003.07.24.06.29.41.25688@gmx.net...
=
>
> Yes, but when you have a function returning a void (say foo), and another
> function that also returns void, (say bar), then you can do something like
> this for foo's return:
>
> void bar () { return; }
> void foo () { return bar(); }
>
> This doesn't seem to be consistent with the fact that you cannot pass it as a
> parameter, like this:
>
> foo (bar());
>
> That's what I was getting at.
>
>
The return void is a special case kludge.

The meaning of a single void parameter is also a special meaning.

They just don't match.   Sorry, the language doesn't do that.   The return
statement is one fo the few places that allows you to actually use a void
valued expression.   As has been pointed out to you there is a difference
between a function taking no arguments and one taking an argument of
type void.   The former does NOT exist in the 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.jamesd.demon.co.uk/csc/faq.html                       ]

Dhruv wrote:

> void bar () { return; }
> void foo () { return bar(); }
>
> This doesn't seem to be consistent with the fact that you cannot pass it
> as a parameter,

Why? The void result is matched with a return of void, this fits. But there
are no void parameters. The syntax (void) means () and exists only for
compatibility with C.

If a function doesn't take parameters, it expresses this by taking no
parameters, because there can be any number of parameters, including 0.
OTOH if a function doesn't want to return anything, it expresses this by
returning void, because there must be exactly one result. So void is used
only in results, not in parameters - there is already no symmetry.

--
   __("<         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                       ]

richard@ex-parrot.com (Richard Smith) wrote in message news:<Pine.LNX.4.55.0307232355070.14460@sphinx.mythic-beasts.com>...
> Dhruv wrote:
>
> > void foo (void) { }
> >
> > void bar1 (int a) { return; }
> > void bar2 (int b) { return bar1(29); } //This is allowed.
> >
> > int main ()
> > {
> >   bar2(34);
> >   foo ();
> >   foo (bar2(33)); //Compiler complains here.
> > }
>
> foo is not a function that takes one argument of type void,
> it is a function that takes zero arguments.

A good reason, if ever one was needed, to avoid the misleading style
of function declaration displayed in the first line of the above
quoted text.

Cheers,
Nicola Musatti

---
[ 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 <pan.2003.07.24.06.29.41.25688@gmx.net>, "Dhruv" wrote:
<snip>
> ...when you have a function returning a void (say foo), and another
> function that also returns void, (say bar), then you can do something like
> this for foo's return:
>
> void bar () { return; }
> void foo () { return bar(); }
>
> This doesn't seem to be consistent with the fact that you cannot pass it as a
> parameter, like this:
>
> foo (bar());
>
> That's what I was getting at.

The inconsistency is not in the treatment of the void type but in
the meaning of the keyword "void".

Every function has exactly one return value, and since C++ doesn't
distinguish subroutines from functions, this is allowed to have void
type.  The same allowance is unnecessary for parameters, because it
is perfectly permissible for a function to have zero parameters.
The special meaning of "void" as a parameter list is defined for
compatibility with C, where an empty parameter list means something
different.  (This special meaning wasn't much liked when it was
introduced to C, but it seems to be a necessary evil.)

---
[ 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 <3f2025be$0$39667$9a6e19ea@news.newshosting.com>,
 on Fri, 25 Jul 2003 01:28:10 +0000 (UTC),
 ron@sensor.com ("Ron Natalie") wrote:

> ""Dhruv"" <dhruvbird@gmx.net> wrote in message
> news:pan.2003.07.24.06.29.41.25688@gmx.net...
> >
> > Yes, but when you have a function returning a void (say foo), and another
> > function that also returns void, (say bar), then you can do something like
> > this for foo's return:
> >
> > void bar () { return; }
> > void foo () { return bar(); }
> >
> > This doesn't seem to be consistent with the fact that you cannot
> > pass it as a parameter, like this:
> >
> > foo (bar());
> >
> > That's what I was getting at.
> >
> >
> The return void is a special case kludge.

It could be argued that what you describe as a "kludge" (I don't
consider it to be so) actully removes a special case, since it means
that, for any type T, the form:

   T f1();
   T f2() { return f1(); }

is valid.

> The meaning of a single void parameter is also a special meaning.

Which is inherited from C - and *this* special meaning is the real kludge.

> They just don't match.  Sorry, the language doesn't do that.  The
> return statement is one fo the few places that allows you to actually
> use a void valued expression.  As has been pointed out to you there is
> a difference between a function taking no arguments and one taking an
> argument of type void.  The former does NOT exist in the language.

I agree with everything here except the use of the word "former" in the
last sentence. s/former/latter/.

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

""Dhruv"" <dhruvbird@gmx.net> wrote in message news:pan.2003.07.23.16.46.44.513727@gmx.net...
>

>   foo (bar2(33)); //Compiler complains here.

A function with a single parameter type of void takes no arguments.
It does not take a single argument of type void.  It's not legal to put
any sort of expression there (void valued or otherwise).

There was a special dispensation given to return in void functions
but thats not the general situation with voids.



---
[ 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                       ]

Hi,

your declaration of a void-signature is C-style. In C++ means an empty
signature: No argument(s), please! In C an empty signature-decl. contains a
hidden ellipse "..." (view from C++) - many parameters can be placed. To
avoid this in C - declare a void-signature. This isn't required in C++. An
empty signature in C++ contains a void by default (view from C).

Regards, Hans.


---
[ 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 Thu, 24 Jul 2003 02:12:45 +0000, Edward Diener wrote:

> "Dhruv" wrote:
>> void foo (void) { }
>
> This means that you are passing no parameters to foo, not that you are
> passing a "void" type parameter.
>

Yes, but when you have a function returning a void (say foo), and another
function that also returns void, (say bar), then you can do something like
this for foo's return:

void bar () { return; }
void foo () { return bar(); }

This doesn't seem to be consistent with the fact that you cannot pass it as a
parameter, like this:

foo (bar());

That's what I was getting at.


Regards,
-Dhruv.





---
[ 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                       ]

Francis Glassborow wrote:

> Were it
> not for compatibility with C void for a parameter list would not exist.
> C++ does not have the problem C has with an older function declaration
> syntax.

I think it is a great shame that C++ allows an empty
parameter list to mean a function that takes no arguments.
If it mandated the use of void, it would have removed a
great many of the more common ambiguities between function
declarations and object declarations.  In the current
language, if I write

  int x( int() );

I have declared a function, x, taking one argument of type
int(*)(), and returning an int.  I don't find this behaviour
particularly intuitive.  If functions with no arguments had
to have an explicit void in their argument list, then
perhaps this could be "correctly" resolved as a object
declaration and

  int x( int(void) );

or, better still,

  int x( int(*)(void) );

required as the function declaration.

--
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                       ]

In article <3f2025be$0$39667$9a6e19ea@news.newshosting.com>, Ron Natalie
<ron@sensor.com> writes
>They just don't match.   Sorry, the language doesn't do that.   The return
>statement is one fo the few places that allows you to actually use a void
>valued expression.   As has been pointed out to you there is a difference
>between a function taking no arguments and one taking an argument of
>type void.   The former does NOT exist in the language.

That seems exactly 180 degrees out. There are no functions with void
parameters in C++. C had a problem with both return types and parameters
because the C function declaration defaulted to return int and an
unspecified parameter list. The void keyword was used as a hack for
both. In a way both uses could be considered as meaning 'there isn't
one'. As far as C is concerned it is just an academic exercise. For C++
two things make a difference. The first is common use of delegation and
the second is templates. The latter is probably the more important.
However in neither case does it make any sense to interpret the optional
void meaning that there are no parameters as if it were a parameter:

f(g(x));
can easily be written as:
g(x), f(x);

and neither templates nor delegation techniques would get any advantage.
However this is not the case with returns. Without the special rule we
would have to have two forms for delegation:

f(){ return g();} // f & g have the same non-void return type
f(){ g();}  // f & g have void return type

For delegation it is just a mild pain but for templates it becomes much
more of a nuisance hence the allowance of the special case.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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" <ron@sensor.com> wrote...
> [...] As has been pointed out to you there is a difference
> between a function taking no arguments and one taking an argument of
> type void.   The former does NOT exist in the language.

The _latter_ does not exist, actually.

Victor


---
[ 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                       ]

Ok, thanks eveyone for all the input :-)

-Dhruv.






---
[ 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) writes:

| Francis Glassborow wrote:
|
| > Were it
| > not for compatibility with C void for a parameter list would not exist.
| > C++ does not have the problem C has with an older function declaration
| > syntax.
|
| I think it is a great shame that C++ allows an empty
| parameter list to mean a function that takes no arguments.

Hmm, I guess "shame" is in the eyes of the beholder.
>From D&E, page 41:

    C with Classes introduced the notation f(void) for a function f
    that takes no arguments as a contrast to f() that in C declares a
    function that can take any number of arguments of any type without
    any type check.  My users soon convinced me, however, that the
    f(void) notation wasn't elegant, and that having functions
    declared f() accept arguments wasn't intuitive.  Consequently, the
    result of the experiment was to have f() mean a function that
    takes no arguments, as any novice would expect.  It took support
    from both Doug McIlroy and Dennis Richie for me to build up the
    courage to make this break from C.  Only after they used the word
    /abomination/ about f(void) did I dare give f() the obvious meaning.

| If it mandated the use of void, it would have removed a
| great many of the more common ambiguities between function
| declarations and object declarations.  In the current
| language, if I write
|
|   int x( int() );
|
| I have declared a function, x, taking one argument of type
| int(*)(), and returning an int.  I don't find this behaviour
| particularly intuitive.

Then, be explicit about type issues.

If you asked me, I would tell that having to use special keyword to
mark a place "there is nothing", instead or writing nothing hurts
my intuition.

This line is left blank.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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                       ]

hfp@epost.de ("Hans Pabst") wrote in message news:<bfo4r8$fl390$1@ID-104408.news.uni-berlin.de>...
> Hi,
>
> your declaration of a void-signature is C-style. In C++ means an empty
> signature: No argument(s), please! In C an empty signature-decl. contains a
> hidden ellipse "..." (view from C++) - many parameters can be placed.

In C a function declared as int f() is not quite the same as int
f(...), even ignoring the fact that an ellipsis requires that there be
at least one named argument prior to the ellipsis. A function declared
with no parameter list can be called with any list of arguments you
wish, but the promoted types of those arguments much be compatible
with the actual types of the parameters used in the function
definition. In contrast, for a function declared with an ellipsis  the
corresponding function definition must also have an ellipsis, at the
same location.

There were older versions of C, where it was quite acceptable to call
a function with a different number of arguments than there were
parameters in the function definition. That worked perfectly well, as
long as the called function never accessed more arguments than had
actually been passed to it by the calling function. However, such code
now has undefined behavior.

---
[ 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                       ]