bwh@charybdis.prl.ufl.edu (Brian Hook) writes:

>In article <george.770995943@gm.dev.com> george@gm.dev.com (George Mitchell) writes:

>>   extern "C" char *strcpy (char *to, char *from);

>>   ...
>>    (void) strcpy (from: charPtr1, to: charPtr2);
>>   ...

>Well, the big problem with this (off the top of my head), is that parsing
>for the compiler would be a bit more problematical.  But, more importantly,
>it would break almost all existing code today that didn't have interface
>and implementation parameters named identically:

Sorry!  I didn't make my example clear enough.  The line beginning
"extern" is supposed to be the interface declaration in string.h.
The other line is just a call to the routine somewhere.  The names in
the call would indeed have to match up with the names in the interface
declaration, but there's no need for the names in the interface
declaration to match up with the names in the implementation --
so long as the function's signature it correct.

>Here's another question...what is the casting the return of "strcpy()" to
>void supposed to do?  Do some compilers flag a warning if you don't grab or
>check the return value of functions that return a value?

Leftover habit from dealing with an extremely anal-retentive "lint".
It would indeed complain if you just threw away a return value.

>+---------------------------------------------------------------------+
>| Brian Hook            | Specializing in real-time 3D graphics       |
>| Box 90315             |---------------------------------------------|
>| Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
>+- "Style distinguishes excellence from accomplishment" - J. Coplien -|

-- George Mitchell (george@gm.dev.com)

In article <2sofn8$4n0@engnews2.Eng.Sun.COM>, clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:
|> In article 770665780@orion.oac.uci.edu, affrunti@orion.oac.uci.edu (Bob Affrunti) writes:
|> >Why do default arguments have to follow the required arguments?
|> >
|> >Why couldn't you have something like:
|> >
|> >class Mine
|> >{
|> >public:
|> > int aFunction( int arg1=1, int arg2, int arg3=1, int arg4 );
|> >};
|> >Mine x;
|> >x.aFunction( ,2,,4 );
|>
|> This belongs in the FAQ list.
|>
|> There is no technical reason why it could not be allowed. As explained
|> in the ARM, it was considered too error-prone. For example, if you
|> accidently type an extra comma, you can get a bug that is very hard to
|> find. As it is, you get a syntax error.

Perhaps I shouldn't post this without first finding a copy of the ARM but:
doesn't the keyword "default" already exist in the language?

Why not x.aFunction( default, 2, default, 4);

I'm sure that this has been debated before, but this "error-prone" arguement
just doesn't seem to hold water, IMHO.

--
                    David P. Whipp.            <whipp@roborough.gpsemi.com>
Not speaking for:   -------------------------------------------------------
 G.E.C. Plessey     Due to transcription and transmission errors, the views
 Semiconductors     expressed here may not reflect even  my  own  opinions!

In article <CqzJzq.5C6@lincoln.gpsemi.com> whipp@roborough.gpsemi.com (David Whipp.) writes:
> I'm sure that this has been debated before, but this "error-prone" arguement
> just doesn't seem to hold water, IMHO.

Why not?  Part of a language's desirable traits is minimizing unintential
user error, and this is something that C++ is good about (to some extent).
As much static (compile time) type checking and what not is built into the
language as is possible, but a great degree of flexibility is still allowed
(hence casting, etc.).

For a feature to be added not only does it have to be useful to a great
majority of users, I would also say that it must be relatively
non-error-prone.

Default arguments interspersed in a function parameter list don't seem to
offer much, and DEFINITELY seem to be way too error prone.  In my (limited)
experience I've noticed that if you give a user a language feature, they'll
overuse because of its novelty or just to prove that they understand it.

Witness operator overloading, which to me is GREATLY overused (but then
again, we all have our own opinions).

Brian




--
+---------------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics       |
| Box 90315             |---------------------------------------------|
| Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
+- "Style distinguishes excellence from accomplishment" - J. Coplien -|

whipp@roborough.gpsemi.com (David Whipp.) writes:

>In article <2sofn8$4n0@engnews2.Eng.Sun.COM>, clamage@taumet.Eng.Sun.COM (Steve Clamage) writes:
>|> In article 770665780@orion.oac.uci.edu, affrunti@orion.oac.uci.edu (Bob Affrunti) writes:
>|> >Why do default arguments have to follow the required arguments?

What I've always hoped to see is to specify arguments by the name of
the formal parameters, viz.:

extern "C" char *strcpy (char *to, char *from);

...
 (void) strcpy (from: charPtr1, to: charPtr2);
...

(Although I didn't use default arguments here, you can see how they
would fit into this scheme.)

-- George Mitchell (george@gm.dev.com)

In article <george.770995943@gm.dev.com> george@gm.dev.com (George Mitchell) writes:

>   What I've always hoped to see is to specify arguments by the name of
>   the formal parameters, viz.:

>   extern "C" char *strcpy (char *to, char *from);

>   ...
>    (void) strcpy (from: charPtr1, to: charPtr2);
>   ...

Well, the big problem with this (off the top of my head), is that parsing
for the compiler would be a bit more problematical.  But, more importantly,
it would break almost all existing code today that didn't have interface
and implementation parameters named identically:

// string.h

char *strcpy( char *dst, const char *src );

// string.cpp

char *strcpy( char *d, const char *s )
{
  ...
};

A LOT of code is like this.  I mean oodles and oodles...

Here's another question...what is the casting the return of "strcpy()" to
void supposed to do?  Do some compilers flag a warning if you don't grab or
check the return value of functions that return a value?

Brian

--
+---------------------------------------------------------------------+
| Brian Hook            | Specializing in real-time 3D graphics       |
| Box 90315             |---------------------------------------------|
| Gainesville, FL 32607 | bwh@prl.ufl.edu                             |
+- "Style distinguishes excellence from accomplishment" - J. Coplien -|

In article 770665780@orion.oac.uci.edu, affrunti@orion.oac.uci.edu (Bob Affrunti) writes:
>Why do default arguments have to follow the required arguments?
>
>Why couldn't you have something like:
>
>class Mine
>{
>public:
> int aFunction( int arg1=1, int arg2, int arg3=1, int arg4 );
>};
>Mine x;
>x.aFunction( ,2,,4 );

This belongs in the FAQ list.

There is no technical reason why it could not be allowed. As explained
in the ARM, it was considered too error-prone. For example, if you
accidently type an extra comma, you can get a bug that is very hard to
find. As it is, you get a syntax error.

Let me anticipate the next question: what about named arguments in
function calls, as Ada has:

 foo(length=12, width=13, depth=14); // call, not prototype

This would allow you to omit the args which already have the right
defaults, with no extra commas.

This second question has been the subject of no fewer than three proposals
to the C++ Committee. It turns out the interactions with function
overloading are severe, and you wind up with many more opportunities
for ambiguous calls than the language already provides, in exchange
for little extra utility.

You can simulate named arguments, especially for class member functions:

class X {
 ...
 X& length(int i) { length_ = i; return *this; }
 X& width(int i)  { width_  = i; return *this; }
 X& depth(int i)  { depth_  = i; return *this; }
};

X x;
x.length(12).width(13).depth(14); // simulation of named args in func call

So instead of lots of parameters to one function, write several smaller
functions with fewer parameters.
---
Steve Clamage, stephen.clamage@eng.sun.com