Empty arguments

[Agent Mulder]

Hi group,
Almost 3 weeks ago I posted a short question here and in comp.std.c++
and I got exactly 1 respons, from Kevin Goodsell. He said he didn't want
it. I post it here again, this time in a thread named 'Empty arguments', because
that is what I got from you. Can you spare a minute and try to see my point?

struct Room
{
Room(bool a=true,bool b=true,bool c=true):Chair(a),Table(b),Bed(c){}
bool Chair,Table,Bed;
};
int main()
{
Room bedroom; //chair, table, bed
Room living(,,false); //no bed in the living
Room guestroom(,false,); //chair, bed, no table, no running water
Room toilet(,false,false); //no table, no bed
return 0;
}

The defective use of arguments above is a trivial case. I fill my
Windows structs in a function call and give a default value to each
formal argument. I want to apply a more elaborate use of default
arguments, but I am hindered by the fact that C++ does not allow
empty arguments.

Empty arguments would enable you to have one constructor or function
for whatever number and combination of arguments. You must only fill
in the non-default values and seperate them with the appropriate
number of comma's.

The semantics of this code is easily understood but the syntax is not
allowed in C++. The Annotated C++ Reference Manual:

<ARM 8.2.6>
It was felt that having empty arguments significant was not
only too subtle, but seriously decreased the opportunities
for detecting errors; an extra comma in an argument list is
not an unusual result of bad typing or sloppy editing.
</>

I don't agree on it being too subtle. It's only a matter of
counting comma's. I do feel a little offended however that the
language anticipates on my sloppy typing. There is a real need
for more flexible default arguments. The reasons not to have
them are not convincing enough.
-----------

Why does nobody fire up his typewriter, think about something
annoying for a moment and type

YOU WON'T GET IT MULDER!!! IT'S TOO F#@%ING SIMPLE !!!!

or something along those lines. It will be better than non-existant replies
till now.

Thank you,

-X

[Attila Feher]

Agent Mulder wrote:

Hi group,
Almost 3 weeks ago I posted a short question here and in comp.std.c++
and I got exactly 1 respons, from Kevin Goodsell. He said he didn't
want
it. I post it here again, this time in a thread named 'Empty
arguments', because that is what I got from you. Can you spare a
minute and try to see my point?

struct Room
{
Room(bool a=true,bool b=true,bool c=true):Chair(a),Table(b),Bed(c){}
bool Chair,Table,Bed;
};
int main()
{
Room bedroom; //chair, table, bed
Room living(,,false); //no bed in the living
Room guestroom(,false,); //chair, bed, no table, no running
water
Room toilet(,false,false); //no table, no bed
return 0;
}

The defective use of arguments above is a trivial case. I fill my
Windows structs in a function call and give a default value to each
formal argument. I want to apply a more elaborate use of default
arguments, but I am hindered by the fact that C++ does not allow
empty arguments.

Empty arguments would enable you to have one constructor or function
for whatever number and combination of arguments. You must only fill
in the non-default values and seperate them with the appropriate
number of comma's.

The semantics of this code is easily understood but the syntax is not
allowed in C++. The Annotated C++ Reference Manual:

<ARM 8.2.6>
It was felt that having empty arguments significant was not
only too subtle, but seriously decreased the opportunities
for detecting errors; an extra comma in an argument list is
not an unusual result of bad typing or sloppy editing.
</>

I don't agree on it being too subtle. It's only a matter of
counting comma's. I do feel a little offended however that the
language anticipates on my sloppy typing. There is a real need
for more flexible default arguments. The reasons not to have
them are not convincing enough.
-----------
You don't understand it, that is OK. But this is exactly the point why
empty arguments are not allowed. Since in a function having many arguments
with defaults 5 commas and a value and 4 commas and a value could end up be
both correct for the compiler, but not for runtime. And finding that error
is subtle.

BTW if you are frustrated by the way Microsoft defines their Windows
structure... well, you will need to complain there.
Why does nobody fire up his typewriter, think about something
annoying for a moment and type

YOU WON'T GET IT MULDER!!! IT'S TOO F#@%ING SIMPLE !!!!

or something along those lines. It will be better than non-existant
replies till now.

As far as I see you gave got all replies you have payed for.

--
Attila aka WW

[Gianni Mariani]

Agent Mulder wrote:

Hi group,
Almost 3 weeks ago I posted a short question here and in comp.std.c++
and I got exactly 1 respons, from Kevin Goodsell. He said he didn't want
it. I post it here again, this time in a thread named 'Empty arguments', because
that is what I got from you. Can you spare a minute and try to see my point?

Donated a minute.

I don't believe that extensions to default arguments will provide any
further readability or significant reduced complexity of new code.

Instead of making the standard more difficult for programmers to
understand, I'd rather see it become simpler.

I'll also echo the point on typos.

[Agent Mulder]

<Gianni Mariani>

I don't believe that extensions to default arguments will provide any
further readability or significant reduced complexity of new code.
Instead of making the standard more difficult for programmers to
understand, I'd rather see it become simpler.

</>

You don't have to use it. And you can easily wrap up the uglies like
this:

void ugly(int a=0,bool b=true,char c='D',string d="Hello World"){}
void ugly(string a){ugly(,,,a);}

and use it like this

ugly("Goodbye World");

The comma counting part is confusing, that's true. There are
only three comma's in the argument list of the first version of
ugly. The syntax of C++ allows you to skip the comma's when
no actual arguments follow. Comma's before an override are
significant, of course.

There is a possible ambiguity looming, but it might get cornered
by syntax like this:

ugly(int,bool,char,"Farewell");

-X

[Jerry Coffin]

In article <bl**********@news4.tilbu1.nb.home.nl>,
mb*******************@home.nl says...

[ ... ]

The semantics of this code is easily understood but the syntax is not
allowed in C++. The Annotated C++ Reference Manual:

You don't get it Mulder. This newsgroup is devoted to discussing how to
use the language the way it is defined now. If you want to discuss how
you think it should be defined, that's topical in comp.std.c++, but NOT
here.

Personally, I think trying to bring it up there is pretty much beating a
dead horse -- it's clearly been considered and rejected and it appears
that you have very little to say about why it was rejected other than "I
disagree". While you're certainly welcome to disagree, it doesn't (by
itself) make a very convincing argument.

I doubt that you could convince the committee on this one with much
short of concrete evidence. Just for example, if you were grab the
sources to gcc and modify it to accept the syntax you want, and then do
a study showing that using it reduced source code size by X% and bug
rates by Y%, then you'd at least give them a real reason to reconsider
the decision. I realize that you're probably more interested in using
compilers than (re)writing them, but that's how life goes sometimes --
if you really think it's worth fighting for, you can fight for it;
otherwise, you can live with it the way it is.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Agent Mulder]

<Jerry Coffin>

Just for example, if you were grab the
sources to gcc and modify it to accept the syntax you want, and then do
a study showing that using it reduced source code size by X% and bug
rates by Y%, then you'd at least give them a real reason to reconsider
the decision.

</>

I don't understand what you mean, but making empty arguments
significant won't break a single line of code, both written and
compiled. Some uncompilable code could jump into life, though.

-X

[Jerry Coffin]

In article <bl**********@news1.tilbu1.nb.home.nl>,
mb*******************@home.nl says...

[ ... ]

I don't understand what you mean,

Which part of "off-topic" are you having trouble with?

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jack Klein]

On Mon, 29 Sep 2003 19:33:23 +0200, "Agent Mulder"
<mb*******************@home.nl> wrote in comp.lang.c++:

<Jerry Coffin>

Just for example, if you were grab the
sources to gcc and modify it to accept the syntax you want, and then do
a study showing that using it reduced source code size by X% and bug
rates by Y%, then you'd at least give them a real reason to reconsider
the decision.

</>

I don't understand what you mean, but making empty arguments
significant won't break a single line of code, both written and
compiled. Some uncompilable code could jump into life, though.

-X

There are either an infinite or near-infinite number (I don't have the
time to count them) of possible changes to the C++ language that won't
break a single line of code. That in itself does not in the least
justify adding anything at all to the language.

This has been proposed before, and bypassed before, on the grounds
that it adds little utility at the expense of increasing the chance
for errors.

The simple fact that you disagree and want this feature is absolutely
meaningless. You are free to stomp your foot or hold your breath
until you turn blue if you don't get your what you want, but that also
in itself does not justify adding anything to the language.

So here are three simple tips:

1. Take this to a group where it is topical, such as the already
suggested comp.std.c++, and out of here where it is not.

2. Understand that you are only expressing one point of view about an
issue that has many different points of view. The fact that a
language change will not break any existing conforming code is a plus,
but what is the cost to the implementor? Many of the members of
language standards committees are compiler vendors. They will not
vote for additions that are expensive to implement unless there is a
significant amount of popular support from their customers, the
programmers.

3. Standards committees tend to give much more weight to language
proposals where they are available as extensions in one or more
existing implementations to demonstrate the utility and workability of
the extension. If you feel that strongly about it, get involved in an
open source project like g++ and see if you can convince them to let
you add it to their compiler.

But whatever you do, stop whining about it here. You'll just get
yourself plonked if you keep it up.

--
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++ ftp://snurse-l.org/pub/acllc-c++/faq

[Tom]

"Agent Mulder" <mb******@home.nl> wrote:

Almost 3 weeks ago I posted a short question here and in comp.std.c++
and I got exactly 1 respons, from Kevin Goodsell. He said he didn't want
it. I post it here again, this time in a thread named 'Empty arguments',
because
that is what I got from you. Can you spare a minute and try to see my point?

struct Room
{
Room(bool a=true,bool b=true,bool c=true):Chair(a),Table(b),Bed(c){}
bool Chair,Table,Bed;
};
int main()
{
Room bedroom; //chair, table, bed
Room living(,,false); //no bed in the living
Room guestroom(,false,); //chair, bed, no table, no running water
Room toilet(,false,false); //no table, no bed
return 0;
}

The defective use of arguments above is a trivial case. I fill my
Windows structs in a function call and give a default value to each
formal argument. I want to apply a more elaborate use of default
arguments, but I am hindered by the fact that C++ does not allow
empty arguments.

Empty arguments would enable you to have one constructor or function
for whatever number and combination of arguments. You must only fill
in the non-default values and seperate them with the appropriate
number of comma's.
[snip]
Why does nobody fire up his typewriter, think about something
annoying for a moment and type

YOU WON'T GET IT MULDER!!! IT'S TOO F#@%ING SIMPLE !!!!

or something along those lines. It will be better than non-existant replies
till now.

You know, Mr. Troll, last time you raised this topic, I told you to
find a copy of Stroustrup's Design and Evolution of C++. I'm
suggesting that to you again. Specifically, turn to Section 6.5.1 and
6.5.1.1 (pages 153-157), and read about the proposal to add keyword
arguments, which were proposed to address the problem you think needs
solving, why that addition to the language was rejected and - and this
is the important part - how you can achieve the functionality you
apparently desire, although not with your syntax.

Best regards,

Tom

[Agent Mulder]

<Tom>
you can achieve the functionality you apparently desire, although not with your syntax.
</Tom>

Hi Tom, you tireless trollhunter (is it because hairs grow between my toes?).
The syntax, 'my' syntax, is essential. Let me quote from the Annotated C++
Reference Manual again, this time with some more context:
<ARM 8.2.6>

The declaration

point (int = 3, int = 4);

declares a function that can be called with zero, one, or two arguments of type
int. It may be called in any of these ways:

point(1,2); point(1); point();

The last two calls are equivalent to point(1,4) and point(3,4), respectively.

The point function could equivalently have been declared like this:

point(int,int);
point(int, int = 4);
point(int = 3, int);

but not like this:

point(int,int);
point(
int = 3, //error: default argument not at end
int
);
point(int, int = 4);

or like this:

point(int,int);
point(int, int = 4);
point(
int = 3,
int = 4 //error: redefinition of default argument

C++ prohibits the obvious call syntax and semantics for calling point() given a
default value for only the first argument, which would be

point(,3); //syntax error

It was felt that having empty arguments significant was not
only too subtle, but seriously decreased the opportunities
for detecting errors; an extra comma in an argument list is
not an unusual result of bad typing or sloppy editing.

</ARM 8.2.6>

See my point? The syntax is essential for what I want. The reasons in
the ARM not to have it are very weak indeed. I hold my breath till it is
added to the language ;-)

-X

[Tom]

"Agent Mulder" <mb******@home.nl> wrote:

<Tom>
you can achieve the functionality you apparently desire, although not with
your syntax.
</Tom>

Hi Tom, you tireless trollhunter (is it because hairs grow between my toes?).
Hmm... touche.
The syntax, 'my' syntax, is essential.
"essential"? As in indispensible? No it isn't, because one can
accomplish what you want without your syntax. Perhaps you mean
"convenient." And my point is that Stroustrup suggests a reasonably
convenient way not to have to include all the default arguments -
which I take it is what you are after. And Stroustrup's specific
example is a call to an MS Windows window display function that
includes lots of arguments, with respect to most of which one usually
doesn't want to change the defaults.
Let me quote from the Annotated C++
Reference Manual again, this time with some more context:
[snip]
It was felt that having empty arguments significant was not
only too subtle, but seriously decreased the opportunities
for detecting errors; an extra comma in an argument list is
not an unusual result of bad typing or sloppy editing.

</ARM 8.2.6>

See my point? The syntax is essential for what I want.
No, I don't. Stroustrup presents in the D&EC++ a convenient way of
accomplishing what you want without changing the language. Without
even trying it or apparently even looking it up, you dismiss it and
say your syntax is "essential."
The reasons in the ARM not to have it are very weak indeed.
One thing one learns when reading D&EC++ is that one of Stroustrup's
primary goals in designing the language was to reduce stupid coding
errors. Strong type safety is merely one way to help achieve that
goal. Not adopting the syntax you suggest is another way to support
the same goal. It is not surprising that the choice was made not to
include the feature you want, especially when one can accomplish the
same thing in a convenient way without increasing the risk of stupid,
and most undetectable, syntax errors through inadvertantly omitted
commas.
I hold my breath till it is added to the language.

Good. Please keep doing so. I would like to say I would hold my
breath until you actually look at D&EC++, but I would undoubtedly
suffocate.

Best regards,

Tom