Topic: proposal: using default parameters
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 17 Feb 2003 17:18:26 +0000 (UTC) Raw View
allan_w@my-dejanews.com (Allan W) wrote in message > For five defaults, we needed 10 lines of boilerplate code (with this
> particular coding style -- it could just as easily have been 25).
Exactly 31 (2^5-1).
Daniel.
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 17 Feb 2003 17:20:14 +0000 (UTC) Raw View
----Message to moderator:
I made a mistake in previous message to the same poster. Please, if
possible, ignore the previous one. Thanks
--------------------------end
allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0302131525.5bbb9f2b@posting.google.com>...
> francis.glassborow@ntlworld.com (Francis Glassborow) asked:
> > Can anyone provide a clear justification for not supporting explicit
> > defaulting of parameters?
> For five defaults, we needed 10 lines of boilerplate code (with this
> particular coding style -- it could just as easily have been 25).
That assuming 5 functions.
But, actually, there are 31 additional functions (2^5-1) for accepting
all the combinations when you want to specify a subset of the
parameter values.
That would grow to 62 with such style, and easily grow to 93.
Daniel.
---
[ 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 ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Fri, 14 Feb 2003 06:37:10 +0000 (UTC) Raw View
francis.glassborow@ntlworld.com (Francis Glassborow) asked:
> Can anyone provide a clear justification for not supporting explicit
> defaulting of parameters?
I can point out that fewer lines of code are normally less
error-prone than more lines of code.
// First arg required, other 5 default to zero
void uses_defaults(int a, int b=0, int c=0, int d=0, int e=0, int f=0);
...
int foo1() { uses_defaults(1,2,3); }
// First arg required, other 5 have overloads that default to zero
void uses_forwards(int a, int b, int c, int d, int e, int f);
inline void uses_forwards(int a, int b, int c, int d, int e)
{ uses_forwards(a,b,c,d,e,0); }
inline void uses_forwards(int a, int b, int c, int d)
{ uses_forwards(a,b,c,d,0,0); }
inline void uses_forwards(int a, int b, int c)
{ uses_forwards(a,b,c,0,0,0); }
inline void uses_forwards(int a, int b)
{ uses_forwards(a,b,0,0,0,0); }
inline void uses_forwards(int a)
{ uses_forwards(a,0,0,0,0,0); }
...
int foo2() { uses_forwards(1,2,3); }
For five defaults, we needed 10 lines of boilerplate code (with this
particular coding style -- it could just as easily have been 25).
Boilerplate code should be eliminated whenever possible -- if not by
the language, then by templates, or code generators, or whatever else.
Just for the fun of it (untested):
// Library template
template<typename R, // Return value
typename A, typename B, typename C, // Six parameter types
typename D, typename E, typename F>
class call6 { // Other CallN functions left as exercises
public:
typedef R (*functype)(A,B,C,D,E,F);
private:
functype func; // The "real" function
// Defaults constructed with functor.
A a; B b; C c; D d; E e; F f;
public:
call6(functype z,A a,B b,C c,D d,E e,F f) : func(z) {}
R operator()(A a,B b,C c,D d,E e,F f) { return func(a,b,c,d,e,f); }
R operator()(A a,B b,C c,D d,E e ) { return func(a,b,c,d,e,f); }
R operator()(A a,B b,C c,D d ) { return func(a,b,c,d,e,f); }
R operator()(A a,B b,C c ) { return func(a,b,c,d,e,f); }
R operator()(A a,B b ) { return func(a,b,c,d,e,f); }
R operator()(A a ) { return func(a,b,c,d,e,f); }
R operator()( ) { return func(a,b,c,d,e,f); }
};
// Prototype for the "real" function.
void uses_template_impl(int a, int b, int c, int d, int e, int f);
// The functor.
call6<void,int,int,int,int,int,int> uses_template(
uses_template_impl, // The name of the "real" function
0,0,0,0,0,0); // Must define defaults for all six args!
...
int foo3() { uses_template(1,2,3); }
---
[ 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 ]
Author: kanze@gabi-soft.de (James Kanze)
Date: Fri, 7 Feb 2003 20:01:12 +0000 (UTC) Raw View
francis.glassborow@ntlworld.com (Francis Glassborow) wrote in message
news:<3jKMuIEyt+P+Ew8x@robinton.demon.co.uk>...
> In article <8c8b368d.0302040712.5e3a096d@posting.google.com>, Randy
> Maddox <rmaddox@isicns.com> writes
> >If anything difficult to understand or possibly subject to misuse
> >should not be part of C++ then the first thing we should get rid of
> >is pointers and manual memory management. That would make C++ a lot
> >safer and easier for beginners, but, oh yeah, I guess it would also
> >make it a lot less useful for a great number of programs.
> I do not understand this. There is absolutely no need for a novice to
> get anywhere near a pointer or manual memory management. Koenig and
> Moo have already demonstrated that and I hope that the book I am
> writing for even greener novices will re-enforce that.
Come now. You can't avoid pointers. String literals convert to a
pointer at the drop of a hat, and opening a file is something that even
a novice might want to do. Not to mention the this pointer.
The question with regards to manual memory management is more subtle.
On my last project, I had pretty much carte blanche, and it was small
enough that I could master the entire code. So I experimented with not
using raw pointers at all, except in special cases like those cited
above. First with boost::shared_ptr, and when that didn't work, with my
own, invasive smart pointer. In the end, I backed out, and reverted to
raw pointers in several instances (e.g. to break cycles). More to the
point, the original project had a very definite policy with regards to
managing lifetimes, and I'm not convinced that my use of smart pointers
was any better. (Globally -- for certain cases, it made the management
significantly easier.)
My experience suggests very strongly that the only automatic memory
management that works is full garbage collection.
I would also argue that lifetime of object issues are important,
regardless of memory management, and must be addressed early. Just
because Java has garbage collection doesn't mean you can ignore lifetime
of object issues. And novices tend to confound the two.
> The only smell of a problem that I have had in writing for novice
> programmers is that you need a C-style string for opening files. As I
> did not want to use c_str() member of string I have resorted to
> wrapper functions that hide the issue until I feel it necessary to
> expose my readers to even the slightest hint of a pointer.
And you don't let them use string literals, or this.
I'm really more or less joking concerning string literals. They may
convert to a pointer, but in well written C++, the programmer never sees
that pointer, as it is immediately passed to a constructor or a function
of string. I don't see how you can avoid this, however.
--
James Kanze mailto:jkanze@caicheuvreux.com
Conseils en informatique orient e objet/
Beratung in objektorientierter Datenverarbeitung
---
[ 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 ]
Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Fri, 7 Feb 2003 20:02:19 +0000 (UTC) Raw View
""Dave Abrahams"" <dave@boost-consulting.com> a crit dans le message news:
b1rmec$bpi$1@bob.news.rcn.net...
> In news:Ijw_9.5138$nD1.1165566@news20.bellglobal.com,
> "Philippe Mori" <philippe_mori@hotmail.com> typed:
>
> > On the other hand, I think that named parameters are a part of
> > the solution... but we should allows them only for specific
> > functions by making it explicit. Thus :
> >
> > a) Named parameters would be usable only when intended
>
> Why? I think I can guess why you'd want that, but I'd rather know for
> sure...
First, I'm not sure if it is a good idea to allows both form all the
time since half the programmer will uses one and the other half
the other and it will complicate the maintenance and readability.
Second, I do not think that named parameters are usefull for all
functions and in some situations we d'ont want to allows arbitrary
order. For example, with the function SetCenter(int x, int y, int z),
do we want to allows someone to call it like that
SetCenter(z : 23, x : 0, y : 29) ?
Finally, if they are allowed only when intended, it will mean that
for existing code when parameters names may not be well chosen
for named parameters (say for example p1, p2, p3,...), we do not
want to allows these names to be used when making a call.
In my opinion, I think that in many situations overload are a better
solution since for many of those API functions with tons of
parameters, there are some depedencies (for ex. a flag must be set
if the third argument is provided or if we provide X coordinate
we should provide Y because we either uses both or none).
But named parameters could be usefull to help reduce the number
of necessary overload and help to give an idea of the meaning of
each arguments at the call site when there is still a bunch of them
even if we have a few overload.
>
> -Dave
>
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
>
>
---
[ 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 ]
Author: pkl@mailme.dk ("Peter Koch Larsen")
Date: Sat, 8 Feb 2003 02:14:18 +0000 (UTC) Raw View
<danielgutson@hotmail.com> skrev i en meddelelse
news:23478c42.0302062212.7d1b326@posting.google.com...
> pkl@mailme.dk ("Peter Koch Larsen") wrote in message news:<3e3feec2$0$177
> > support which is more extensive than what is currently supported. This
> > contradicts my real life experience and when I ask for examples, I get
> > something like void drawCircle( int radious = 1, int centerX = 0, int
> > centerY = 0,Color color = green). This lack of examples (which - if
> > considered off-topic - could be mailed to me directly) and real life
> > experience induces me to believe that the need is not so large.
>
> Dear Peter:
> I already sent the example I mentioned you, but you didn't take a
> look to it.
> The example, if you don't take the time to criticize my style -as well
> as it wasn't intended as a 'style' proposal- was, copy pasting from
> the message at the end of the thread of my dejanews:
>
Sorry - I did not know that those were your examples. Are they from real
code?
> "void SetXX(Color c=green, Flavor f=sweet);
> void SetYY(Color c=red, Flavor f=awful);
> Color calcColor(Flavor f = sweet, int tolerance = 1);
> Flavor calcFlavor(Color c=blue, int tolerance = 1);
I can not comment on these since I do not know the underlying problemdomain.
What struck me as weird is that colors and flavors should have those default
values. Why is blue a logical default place in one location, while it is
green in another and blue a third place.
> void initCharacter(Race = elf, Length hair = Long, Color c = Blonde);
This also looks weird. All races have long, blond hair by default? This
looks to me as if you should have different character classes, one of them
being an elf, and having the elf by default have long, blonde hair. Midgets
could then by default have short, brown hair.
> void setWeapon(WeaponType = sword, Handled = SingleHanded);"
The same comment as for characters applies here. Your examples are not
convincing to me.
>
> If the example of the circle would have been intended for styling, I
> guess you agree that it would like as
> circle.draw(color);
> but, as you of course know, wasn't the main idea.
>
> Continuing with the subject, I'm afraid I don't agree at all with you.
>
> Let's focus in three things:
>
> 1- analyze your other 'alternatives' to my proposal:
> 1.1- forwarding functions
> 1.2 [one] structure as parameter for 'simulating' named params
> (don't rememeber the name of the pattern)
> 2- performance
> 3- a reason for avoiding this proposal as a standard
>
> So, let's deploy them.
>
> 1- alternatives.
>
> 1.1 Forwarding Functions.
> As far as you did not provide the formula of [extra] forwarding
> functions in terms of the number of default parameters, I did it for
> you in order to perform a reach analysis.
> For each function, you have
> extra_functions = 2^default_params - 1
> Following my so requested example above, you would have
> 5*(2^2-1)+2^3-1 = 22 extra functions,
Yes. I do not disagree with you in that many extra functions are required.
What I question is your style. How many of these default values are used in
your program?
> saying 2 lines per forwarding function (1 for the prototype and one
> for the body), we would get about extra 44 LOCs (without blank lines)
> for an 6-functions api, which represents the 88% of the source.
> According to your conclusion that 'more than 3 params my proposal is
> not useful' (as you said in previous msg in this thread), we would get
> 2^n-1, n>3 => n=3+k =>
> 2^(3+k)-1 = 8*(2^k)-1 extra functions for more than 3 default params,
> leaving the conclusion for the reader (min 7 extra functions).
Well. Defaulted functions should be inline and (with my style) only one line
of code each.
Again, I do question your style if your results are meant as "real
life"-examples.
> Another drawback is that this works iif the types are different.
> What about for example
> f(int, int)
> ?
>
> 1.2 Simulating named params with a structure.
>
> a) readability.
> Is my opinion that it is sacrified here (let's analyze performance in
> the next point).
> when you have
> f( fparams().param1(value1).param2(value2).param3(value3))
> we are getting the following implicances:
> * for the reader, the colon is replaced by the dot
> * you get 2*(params+1) extra parenthesis
> * you have to alternate param/value/param/value which provides
> confusion when following the code (when you are familiar with the
> functions, you care about its parameters, you memorize its parameters
> ordered). Not good for following legacy codes, many lines of codes in
> short time and high pressure, my often situation.
The situation You describe (with short time and high pressure) should be
more favorable for my proposal. With all that pressure, the risk of not
remembering the correct parameter order must be more difficult.
> b) extra lines of code.
> As you said, you have about 2*number of params per function. Being a
> bit more accurate, we would get 2+2*number of params if we consider
> the structure declaration and the braces, let's say 2*(params+1).
> Again, in my example above, we would get 6 structures,
>
> 5*(2*3)+2*4 = 38 extra LOCs, about 86% of the source.
Oh - LOC again. I am a bad typist but still manage perhaps 2-3 characters pr
second. So for me its not my typing speed, that determines my productivity.
>
> However, we could still agree that for 'few' number of default
> parameters, the 'defaulting' proposal is preferable.
>
> 2- Performance of 1.2 (structure simulating named params.)
> I'm afraid that your experiment (with VC6, despite it's <quite old>)
> is not reallistic as far as you passed constant expressions (numbers)
> instead of variables or pointers.
> For example, when you have
>
> void something(int a, int b, int c)
> {
> f( f_params().p1(a).p2(b).p3(c) );
> }
>
> does not generate the same code as
> void something(int a, int b, int c)
> {
> f( a, b, c );
> }
Have you tried this? I have - and there is no difference whatsoever with
VC++6 (SP5). What compiler do you use? You should ask your optimizer to
create optimized code, of course. C++ performance sucks if you disable
optimizations (easily a factor of five).
>
> It's something that my VxWorks would complain a little bit for my
> system.
No it would not for there is not any difference in performance.
>
> 3- Finally, the reason you gave for avoiding my proposal as a
> standard:
> <because of problems when passing functions as parameters:
> if you receive a function with prototype
> int (int)
> and you have
> f(int x, double y = 0)
> you won't be able to pass this functions>
No. That is why I would not have default parameters in the first case. My
definition of f would be
int f(int x, double y);
inline int f(int x) { return f(x,0.0); }
> This is **NOT** a problem here, this is a *safe* impediment, as you
> proclaim (and I apply) to the safety cause.
If you can not ignore default parameters then you should not have them in
the first place.
>
> As my FINAL conclusion, I don't agree with your position, but consider
> your feedback very constructive for me, and will include your name in
> the acknowledgements in the proposal.
>
> Thanks Peter.
>
> Sincerely,
> Daniel.
I will not wish you good luck with that proposal: I do not like it very
much. Let me instead wish you happy programming!
Kind regards
Peter
---
[ 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 ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Sat, 8 Feb 2003 04:42:00 +0000 (UTC) Raw View
philippe_mori@hotmail.com ("Philippe Mori") writes:
> ""Dave Abrahams"" <dave@boost-consulting.com> a =E9crit dans le message=
news:
> b1rmec$bpi$1@bob.news.rcn.net...
>> In news:Ijw_9.5138$nD1.1165566@news20.bellglobal.com,
>> "Philippe Mori" <philippe_mori@hotmail.com> typed:
>>
>> > On the other hand, I think that named parameters are a part of
>> > the solution... but we should allows them only for specific
>> > functions by making it explicit. Thus :
>> >
>> > a) Named parameters would be usable only when intended
>>
>> Why? I think I can guess why you'd want that, but I'd rather know for
>> sure...
>
> First, I'm not sure if it is a good idea to allows both form all the
> time since half the programmer will uses one and the other half
> the other and it will complicate the maintenance and readability.
It's easy enough to prohibit it: simply leave the parameter names out
of your function declarations <.0002 wink>
> Second, I do not think that named parameters are usefull for all
> functions and in some situations we d'ont want to allows arbitrary
> order. For example, with the function SetCenter(int x, int y, int z),
> do we want to allows someone to call it like that
> SetCenter(z : 23, x : 0, y : 29) ?
I don't put a lot of value on trying to prevent people from writing
obfuscated code. If they want to do it, they will find a way.
Incidentally, Python programs don't seem to suffer from this kind of
arbitrary parameter reordering or bad use of named parameters. This
is despite the fact that practically all Python functions can be
called either way, even if the author never intended to supply named
parameters.
> Finally, if they are allowed only when intended, it will mean that
> for existing code when parameters names may not be well chosen
> for named parameters (say for example p1, p2, p3,...), we do not
> want to allows these names to be used when making a call.
I would rather have a simple language that re-uses existing syntax to
provide new features than to introduce new syntax for the purpose of
trying to control the quality of peoples' code. Note that this is not
the same thing as access control, which increases encapsulation, or
const-correctness, which catches logic errors. Bad use of named
parameters generally has to be malicious.
> In my opinion, I think that in many situations overload are a better
> solution since for many of those API functions with tons of
> parameters, there are some depedencies (for ex. a flag must be set
> if the third argument is provided or if we provide X coordinate we
> should provide Y because we either uses both or none).
>
> But named parameters could be usefull to help reduce the number
> of necessary overload and help to give an idea of the meaning of
> each arguments at the call site when there is still a bunch of them
> even if we have a few overload.
I agree with all of that.
--=20
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
[ 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 ]
Author: rmaddox@isicns.com (Randy Maddox)
Date: Thu, 6 Feb 2003 15:26:44 +0000 (UTC) Raw View
pkl@mailme.dk ("Peter Koch Larsen") wrote in message news:<3e3feec2$0$177$edfadb0f@dread16.news.tele.dk>...
> "Randy Maddox" <rmaddox@isicns.com> skrev i en meddelelse
> news:8c8b368d.0302040712.5e3a096d@posting.google.com...
> > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> news:<3e3f0166$0$226$edfadb0f@dread16.news.tele.dk>...
> > > <danielgutson@hotmail.com> skrev i en meddelelse
> > > news:23478c42.0302020026.6b4ab89b@posting.google.com...
> > > > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> news:<3e3bc723$0$163$edfadb0f@dread16.news.tele.dk>...
> > > > > <danielgutson@hotmail.com> skrev i en meddelelse
> > > > > news:23478c42.0301300931.55656a54@posting.google.com...
> > > > > > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> > > >
>
> > > > Again, that makes the difference of a good programmer: his decisions
> > > > within the contexts.
> > >
> > > There are programmers out there, who should not be given too much
> leeway:
> > > C++ already encourages writing hard-to-understand programs.
> >
> Take a look at posts in e.g. comp.lang.c++. Many of the problems there arise
> because of a misunderstanding of the language. Take a look at many faulty
> programs in real life: they occured because of misuse of the language, e.g.
> raw pointer that are not always deleted, unsafe C-style casts and other
> dangerous features of C++. Many programmers out there need to be educated.
>
> I love C++ and the power it gives, but see no need to provide a feature,
> that encourages bad programming if that feature does not at the same time
> provide a real benefit. C-style casts are much easier to write than C++
> style casts, but had they not existed already, I would have turned a
> proposal of these casts down. I find a direct analogy to the current
> proposal.
>
> >
> > If anything difficult to understand or possibly subject to misuse
> > should not be part of C++ then the first thing we should get rid of is
> > pointers and manual memory management. That would make C++ a lot
> > safer and easier for beginners, but, oh yeah, I guess it would also
> > make it a lot less useful for a great number of programs. Again, if
> > C++ is too powerful or complex for you, then use a different tool, but
> > don't argue against something potentially very useful, as the proposal
> > in this thread seems to me to be, on the basis that it "can be
> > dangerous in the wrong hands". C++ is not a programmer's nanny and we
> > should fight any attempt to move in that direction.
>
> Pointers and manual memory management does provide us with real benefits;
> this is where your analogy breaks down. As for nannying, I am among those,
> who like being nannied. I like const-correctness, function prototypes and
> the strongly typed language that C++ provides to help me against some of the
> more common programming errors, catching them at runtime. Apparently you are
> not in this group.
Sorry, but that last assumption is totally incorrect. I am very much
in favor of strong type checking, const correctness, and anything that
helps the compiler catch as many potential errors as possible.
Cryptic as they sometimes may be, a compile error is almost always a
heck of a lot easier to figure out and fix than debugging at runtime.
What I was responding to instead was the assertion that:
"There are programmers out there, who should not be given too much
leeway: C++ already encourages writing hard-to-understand programs."
I do agree that not all programmers are at the same level of
competence, but feel that indicates a need for better education rather
than a less powerful tool than C++. And I also feel that while C++
may allow writing hard to understand programs it does not encourage
such. Instead, C++ provides the facilities to allow many different
types of programming tasks to be accomplished in an elegant and
efficient way, and that better education is again the answer to
avoiding hard to understand programs.
If I cut my hand off while using a power saw the fault is not in the
saw, assuming that it has all appropriate safety features, but rather
in my failure to use the tool properly. I am all in favor of
appropriate safety features for dangerously powerful tools, but no
safety feature can absolve the user of the responsibility to use the
tool correctly since no safety feature can protect against misuse,
whether accidental or deliberate.
I will readily grant that there may be a fine line between
"appropriate safety feature" and "nannyism" but when we try to protect
the programmer from his/her own self I believe we have crossed that
line.
Randy.
> Kind regards
> Peter
>
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Fri, 7 Feb 2003 18:31:57 +0000 (UTC) Raw View
pkl@mailme.dk ("Peter Koch Larsen") wrote in message news:<3e3feec2$0$177
> support which is more extensive than what is currently supported. This
> contradicts my real life experience and when I ask for examples, I get
> something like void drawCircle( int radious = 1, int centerX = 0, int
> centerY = 0,Color color = green). This lack of examples (which - if
> considered off-topic - could be mailed to me directly) and real life
> experience induces me to believe that the need is not so large.
Dear Peter:
I already sent the example I mentioned you, but you didn't take a
look to it.
The example, if you don't take the time to criticize my style -as well
as it wasn't intended as a 'style' proposal- was, copy pasting from
the message at the end of the thread of my dejanews:
"void SetXX(Color c=green, Flavor f=sweet);
void SetYY(Color c=red, Flavor f=awful);
Color calcColor(Flavor f = sweet, int tolerance = 1);
Flavor calcFlavor(Color c=blue, int tolerance = 1);
void initCharacter(Race = elf, Length hair = Long, Color c = Blonde);
void setWeapon(WeaponType = sword, Handled = SingleHanded);"
If the example of the circle would have been intended for styling, I
guess you agree that it would like as
circle.draw(color);
but, as you of course know, wasn't the main idea.
Continuing with the subject, I'm afraid I don't agree at all with you.
Let's focus in three things:
1- analyze your other 'alternatives' to my proposal:
1.1- forwarding functions
1.2 [one] structure as parameter for 'simulating' named params
(don't rememeber the name of the pattern)
2- performance
3- a reason for avoiding this proposal as a standard
So, let's deploy them.
1- alternatives.
1.1 Forwarding Functions.
As far as you did not provide the formula of [extra] forwarding
functions in terms of the number of default parameters, I did it for
you in order to perform a reach analysis.
For each function, you have
extra_functions = 2^default_params - 1
Following my so requested example above, you would have
5*(2^2-1)+2^3-1 = 22 extra functions,
saying 2 lines per forwarding function (1 for the prototype and one
for the body), we would get about extra 44 LOCs (without blank lines)
for an 6-functions api, which represents the 88% of the source.
According to your conclusion that 'more than 3 params my proposal is
not useful' (as you said in previous msg in this thread), we would get
2^n-1, n>3 => n=3+k =>
2^(3+k)-1 = 8*(2^k)-1 extra functions for more than 3 default params,
leaving the conclusion for the reader (min 7 extra functions).
Another drawback is that this works iif the types are different.
What about for example
f(int, int)
?
1.2 Simulating named params with a structure.
a) readability.
Is my opinion that it is sacrified here (let's analyze performance in
the next point).
when you have
f( fparams().param1(value1).param2(value2).param3(value3))
we are getting the following implicances:
* for the reader, the colon is replaced by the dot
* you get 2*(params+1) extra parenthesis
* you have to alternate param/value/param/value which provides
confusion when following the code (when you are familiar with the
functions, you care about its parameters, you memorize its parameters
ordered). Not good for following legacy codes, many lines of codes in
short time and high pressure, my often situation.
b) extra lines of code.
As you said, you have about 2*number of params per function. Being a
bit more accurate, we would get 2+2*number of params if we consider
the structure declaration and the braces, let's say 2*(params+1).
Again, in my example above, we would get 6 structures,
5*(2*3)+2*4 = 38 extra LOCs, about 86% of the source.
However, we could still agree that for 'few' number of default
parameters, the 'defaulting' proposal is preferable.
2- Performance of 1.2 (structure simulating named params.)
I'm afraid that your experiment (with VC6, despite it's <quite old>)
is not reallistic as far as you passed constant expressions (numbers)
instead of variables or pointers.
For example, when you have
void something(int a, int b, int c)
{
f( f_params().p1(a).p2(b).p3(c) );
}
does not generate the same code as
void something(int a, int b, int c)
{
f( a, b, c );
}
It's something that my VxWorks would complain a little bit for my
system.
3- Finally, the reason you gave for avoiding my proposal as a
standard:
<because of problems when passing functions as parameters:
if you receive a function with prototype
int (int)
and you have
f(int x, double y = 0)
you won't be able to pass this functions>
This is **NOT** a problem here, this is a *safe* impediment, as you
proclaim (and I apply) to the safety cause.
As my FINAL conclusion, I don't agree with your position, but consider
your feedback very constructive for me, and will include your name in
the acknowledgements in the proposal.
Thanks Peter.
Sincerely,
Daniel.
---
[ 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 ]
Author: eldiener@earthlink.net ("Edward Diener")
Date: Tue, 4 Feb 2003 06:45:32 +0000 (UTC) Raw View
"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uk7gkovgg.fsf@boost-consulting.com...
> eldiener@earthlink.net ("Edward Diener") writes:
>
> > I am not saying this could not or should not be done at some
> > time. But as against this, the original posters solution offers a
> > simple solution to the problem of having to specify a default
> > parameter without worrying about the other defaults. Why not simply
> > add that solution to the language,
> > and then if a named parameter solution also is viable add that also.
>
>
> When was the last time you "simply added a solution" to the language?
> The reason not to is that it's never simple, and it's much harder to
> add a new solution for a problem space already addressed in the
> standard, even if the existing solution is a poor one.
I don't buy this reasoning at all. Claiming that it is easier to create an
entirely new solution rather than adding a simple fix to an already existing
situation simply doesn't have any logical backing behind it. Each situation
has to be taken into account in and of itself. The original post offered a
solution with very few issues that would probably be fairly easy to add to
the language.
> If I see a
> better solution I'm not going to waste energy on an inferior one.
I think some form of named parameters is a "better" solution. But at the
rate at which the standard C++ committee is willing to make serious changes
to the C++ language itself, I will no longer be alive before your "better"
solution is proposed, the syntactical changes and issues worked out even as
you have specified above, and the change actually occurs to solve the
usability problem of specifying values for default parameters.
>
> > Certainly the positional way default parameters are currently
> > specified is not going to be dropped anytime soon ( talk about
> > disrupting a great deal of current code ! ) so why not make that
> > syntax at least more usable for the meantime.
>
> There's no need for an "in the meantime." It'll be at least 5 years
> before we get a new standard. That's plenty of time to solve the
> problem right.
By "in the meantime" I meant following the next official standard in 2008. I
wish you luck in "solving the problem right".
---
[ 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 ]
Author: rmaddox@isicns.com (Randy Maddox)
Date: Tue, 4 Feb 2003 15:29:43 +0000 (UTC) Raw View
pkl@mailme.dk ("Peter Koch Larsen") wrote in message news:<3e3f0166$0$226$edfadb0f@dread16.news.tele.dk>...
> <danielgutson@hotmail.com> skrev i en meddelelse
> news:23478c42.0302020026.6b4ab89b@posting.google.com...
> > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> news:<3e3bc723$0$163$edfadb0f@dread16.news.tele.dk>...
> > > <danielgutson@hotmail.com> skrev i en meddelelse
> > > news:23478c42.0301300931.55656a54@posting.google.com...
> > > > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> >
>
> > Again, that makes the difference of a good programmer: his decisions
> > within the contexts.
>
> There are programmers out there, who should not be given too much leeway:
> C++ already encourages writing hard-to-understand programs.
C++, from its beginning, has always been intended as a general purpose
programming language that supports everything from very low-level
systems and device driver programming to high-level applications. As
such, I must disagree very strongly that "C++ already encourages
writing hard-to-understand programs" and would say instead that C++
provides a programmer with a powerful tool for a large variety of
programming tasks. As with any powerful tool, that power may be
misused, either deliberately or accidentally, but the possibility of
misuse is not a reason to change the tool but rather indicates a need
for appropriate education in how to use the tool.
If C++ is too powerful or complex for your needs, then use a different
tool.
>
>
> > You just cannot avoid the standarization of something because 'it
> > MIGHT be misused'. If not, we could not be hired! :)
>
> I can not talk to you about hiring, but why implement a feature that does
> not really solve anything and can be dangerous in the wrong hands?
>
> Kind regards
> Peter
>
If anything difficult to understand or possibly subject to misuse
should not be part of C++ then the first thing we should get rid of is
pointers and manual memory management. That would make C++ a lot
safer and easier for beginners, but, oh yeah, I guess it would also
make it a lot less useful for a great number of programs. Again, if
C++ is too powerful or complex for you, then use a different tool, but
don't argue against something potentially very useful, as the proposal
in this thread seems to me to be, on the basis that it "can be
dangerous in the wrong hands". C++ is not a programmer's nanny and we
should fight any attempt to move in that direction.
Randy.
---
[ 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 ]
Author: dave@boost-consulting.com ("Dave Abrahams")
Date: Wed, 5 Feb 2003 03:31:42 +0000 (UTC) Raw View
In news:9wH%9.6796$ek4.653424@newsread2.prod.itd.earthlink.net,
"Edward Diener" <eldiener@earthlink.net> typed:
> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:uk7gkovgg.fsf@boost-consulting.com...
> > eldiener@earthlink.net ("Edward Diener") writes:
> >
> > > I am not saying this could not or should not be done at some
> > > time. But as against this, the original posters solution offers a
> > > simple solution to the problem of having to specify a default
> > > parameter without worrying about the other defaults. Why not simply
> > > add that solution to the language,
> > > and then if a named parameter solution also is viable add that also.
> >
> >
> > When was the last time you "simply added a solution" to the language?
> > The reason not to is that it's never simple, and it's much harder to
> > add a new solution for a problem space already addressed in the
> > standard, even if the existing solution is a poor one.
>
> I don't buy this reasoning at all. Claiming that it is easier to create an
> entirely new solution rather than adding a simple fix to an already
existing
> situation
To you it's a "simple fix to an already existing situation." To me it's a
new feature. It will look that way to other people, and they'll wonder
whether it's worth it.
> simply doesn't have any logical backing behind it. Each situation
> has to be taken into account in and of itself. The original post offered a
> solution with very few issues that would probably be fairly easy to add to
> the language.
Maybe after you have spent some time working on the C++ committee you'll
have a better sense of what is and is not easy.
> > If I see a
> > better solution I'm not going to waste energy on an inferior one.
>
> I think some form of named parameters is a "better" solution. But at the
> rate at which the standard C++ committee is willing to make serious
changes
> to the C++ language itself, I will no longer be alive before your "better"
> solution is proposed...
It's already being discussed on the committee's extensions reflector.
> > > Certainly the positional way default parameters are currently
> > > specified is not going to be dropped anytime soon ( talk about
> > > disrupting a great deal of current code ! ) so why not make that
> > > syntax at least more usable for the meantime.
> >
> > There's no need for an "in the meantime." It'll be at least 5 years
> > before we get a new standard. That's plenty of time to solve the
> > problem right.
>
> By "in the meantime" I meant following the next official standard in 2008.
I
> wish you luck in "solving the problem right".
Best of luck to you, too ;-)
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
---
[ 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 ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Thu, 6 Feb 2003 00:53:06 +0000 (UTC) Raw View
In article <8c8b368d.0302040712.5e3a096d@posting.google.com>, Randy
Maddox <rmaddox@isicns.com> writes
>If anything difficult to understand or possibly subject to misuse
>should not be part of C++ then the first thing we should get rid of is
>pointers and manual memory management. That would make C++ a lot
>safer and easier for beginners, but, oh yeah, I guess it would also
>make it a lot less useful for a great number of programs.
I do not understand this. There is absolutely no need for a novice to
get anywhere near a pointer or manual memory management. Koenig and Moo
have already demonstrated that and I hope that the book I am writing for
even greener novices will re-enforce that.
The only smell of a problem that I have had in writing for novice
programmers is that you need a C-style string for opening files. As I
did not want to use c_str() member of string I have resorted to wrapper
functions that hide the issue until I feel it necessary to expose my
readers to even the slightest hint of a pointer.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
---
[ 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 ]
Author: pkl@mailme.dk ("Peter Koch Larsen")
Date: Thu, 6 Feb 2003 00:53:37 +0000 (UTC) Raw View
"Randy Maddox" <rmaddox@isicns.com> skrev i en meddelelse
news:8c8b368d.0302040712.5e3a096d@posting.google.com...
> pkl@mailme.dk ("Peter Koch Larsen") wrote in message
news:<3e3f0166$0$226$edfadb0f@dread16.news.tele.dk>...
> > <danielgutson@hotmail.com> skrev i en meddelelse
> > news:23478c42.0302020026.6b4ab89b@posting.google.com...
> > > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> > news:<3e3bc723$0$163$edfadb0f@dread16.news.tele.dk>...
> > > > <danielgutson@hotmail.com> skrev i en meddelelse
> > > > news:23478c42.0301300931.55656a54@posting.google.com...
> > > > > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> > >
> >
> > > Again, that makes the difference of a good programmer: his decisions
> > > within the contexts.
> >
> > There are programmers out there, who should not be given too much
leeway:
> > C++ already encourages writing hard-to-understand programs.
>
> C++, from its beginning, has always been intended as a general purpose
> programming language that supports everything from very low-level
> systems and device driver programming to high-level applications. As
> such, I must disagree very strongly that "C++ already encourages
> writing hard-to-understand programs" and would say instead that C++
> provides a programmer with a powerful tool for a large variety of
> programming tasks. As with any powerful tool, that power may be
> misused, either deliberately or accidentally, but the possibility of
> misuse is not a reason to change the tool but rather indicates a need
> for appropriate education in how to use the tool.
>
Take a look at posts in e.g. comp.lang.c++. Many of the problems there arise
because of a misunderstanding of the language. Take a look at many faulty
programs in real life: they occured because of misuse of the language, e.g.
raw pointer that are not always deleted, unsafe C-style casts and other
dangerous features of C++. Many programmers out there need to be educated.
I love C++ and the power it gives, but see no need to provide a feature,
that encourages bad programming if that feature does not at the same time
provide a real benefit. C-style casts are much easier to write than C++
style casts, but had they not existed already, I would have turned a
proposal of these casts down. I find a direct analogy to the current
proposal.
> If C++ is too powerful or complex for your needs, then use a different
> tool.
Ah... I only code in BASIC, actually ;-)
>
> >
> >
> > > You just cannot avoid the standarization of something because 'it
> > > MIGHT be misused'. If not, we could not be hired! :)
> >
> > I can not talk to you about hiring, but why implement a feature that
does
> > not really solve anything and can be dangerous in the wrong hands?
> >
> > Kind regards
> > Peter
> >
>
> If anything difficult to understand or possibly subject to misuse
> should not be part of C++ then the first thing we should get rid of is
> pointers and manual memory management. That would make C++ a lot
> safer and easier for beginners, but, oh yeah, I guess it would also
> make it a lot less useful for a great number of programs. Again, if
> C++ is too powerful or complex for you, then use a different tool, but
> don't argue against something potentially very useful, as the proposal
> in this thread seems to me to be, on the basis that it "can be
> dangerous in the wrong hands". C++ is not a programmer's nanny and we
> should fight any attempt to move in that direction.
Pointers and manual memory management does provide us with real benefits;
this is where your analogy breaks down. As for nannying, I am among those,
who like being nannied. I like const-correctness, function prototypes and
the strongly typed language that C++ provides to help me against some of the
more common programming errors, catching them at runtime. Apparently you are
not in this group.
Advocates of the OPs proposal continuously call it "potentially very
useful", arguing that there is a huge demand for default-parameter function
support which is more extensive than what is currently supported. This
contradicts my real life experience and when I ask for examples, I get
something like void drawCircle( int radious = 1, int centerX = 0, int
centerY = 0,Color color = green). This lack of examples (which - if
considered off-topic - could be mailed to me directly) and real life
experience induces me to believe that the need is not so large.
That being said, let me remark that having default parameters can on
occasion be convenient. What you and others have failed to show is that (a)
the need is sufficient to consider a proposal and (b) that the proposed
solution is the correct one. I am highly sceptical on both accounts
Kind regards
Peter
---
[ 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 ]
Author: dave@boost-consulting.com ("Dave Abrahams")
Date: Thu, 6 Feb 2003 00:55:32 +0000 (UTC) Raw View
In news:Ijw_9.5138$nD1.1165566@news20.bellglobal.com,
"Philippe Mori" <philippe_mori@hotmail.com> typed:
> On the other hand, I think that named parameters are a part of
> the solution... but we should allows them only for specific
> functions by making it explicit. Thus :
>
> a) Named parameters would be usable only when intended
Why? I think I can guess why you'd want that, but I'd rather know for
sure...
-Dave
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
---
[ 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 ]
Author: belvis@pacbell.net (Bob Bell)
Date: Thu, 30 Jan 2003 19:12:58 CST Raw View
eldiener@earthlink.net ("Edward Diener") wrote in message news:<jiXZ9.3055$wd2.230414@newsread2.prod.itd.earthlink.net>...
> ""Peter Koch Larsen"" <pkl@mailme.dk> wrote in message
> news:3e37f2ce$0$230$edfadb0f@dread16.news.tele.dk...
> > I am surprised of the fact that default parameters are so popular a theme.
> > In my own experience, I have usually been able to use function overloading
> > where default parameters are convenient. The few places where they are not
> > (mostly in GUI-code), I have used the named parameter idiom and found it
> > most useful. Apart from the clear indication of what parameters are
> > supplied, it is also very easy to put more "meat" in the call whenever the
> > situation should arise.
> > You obviously do not seem to have the same experience and I wonder if I am
> > the minority group here. Which problemdomains have this heavy need for
> > default parameters? I would like to know.
>
> Whether rightly or not, a number of API functions for Windows take a large
> number of parameters, particularly those for GUI calls. Being able to
> specify a number of these as defaults, whether in an application framework
> built around the OS, such as MFC, .NET, VCL etc. or in C++ header files
> implementing the raw API call, and allowing the end caller to just specify
> the changes needed with "default" for the rest, eases the use of such a
> framework and/or the basic API call.
You seem to be saying "the more arguments a function has, the more you
want to use default arguments." However, the more arguments you have,
the less useful the OP's proposal is.
SomeFunction(default, default, default, default, default, default,
1);
Is this really better than putting in all the arguments? How can you
read this and know it is correct without knowing as much as you would
need to know to read and verify this:
SomeFunction(true, "Hello", 3.14, 0, 10, 1, 1, 1);
Oops! Did I make a mistake with the "1" in the first version? Which
position was it meant for? Did I put in enough "defaults?"
> Policy-based template classes may take quite a few clever policies, with
> defaults, to provide maximum flexibility in building the eventual
> instantiated version of the class one wants to use. Being able to just
> specify "default" for the policies in which one has no interest, and a type
> or value for the policies one is interested in changing, would be a
> usability boon for such a template class.
>
> The point is that one does not have to be a big fan of either designing
> functions or template classes with default parameters to see that the
> original poster presented an elegant solution to the problem...
Solution, yes. Elegant, no, for all the reasons Peter has mentioned.
Bob Bell
---
[ 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 ]
Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Fri, 31 Jan 2003 18:26:43 +0000 (UTC) Raw View
>
> You seem to be saying "the more arguments a function has, the more you
> want to use default arguments." However, the more arguments you have,
> the less useful the OP's proposal is.
>
> SomeFunction(default, default, default, default, default, default,
> 1);
>
> Is this really better than putting in all the arguments? How can you
> read this and know it is correct without knowing as much as you would
> need to know to read and verify this:
>
> SomeFunction(true, "Hello", 3.14, 0, 10, 1, 1, 1);
>
> Oops! Did I make a mistake with the "1" in the first version? Which
> position was it meant for? Did I put in enough "defaults?"
>
> [...]
>
> Bob Bell
>
Since using default for many arguments make it less readable
as shown by the example above, I also think that is it not a good
idea to do it that way.
On the other hand, I think that named parameters are a part of
the solution... but we should allows them only for specific
functions by making it explicit. Thus :
a) Named parameters would be usable only when intended
b) It would be possible to uses name to select function
c) If 2 functions have some name in common, we would be
able to prefer the more "specialized" function if the named
arguments of the first function is a subset of the other (note
that it will also depends on which arguments have defaults
and which arguments are named - only possible candidates
are considered and there will be an ambiguity if neither
functions are a best match).
d) Names must match for every prototype
e) We can have unnamed parameters followed by named one
in the same function.
f) Explicit could be used when name must be given (any
remainding parameters should probably be made explicit).
Some examples:
Here I uses .Name for named arguments. It can be something else...
void f(explicit double .x, explicit double .y); // cartesian coord.
void f(explicit double .length, explicit .angle); // polar coord
void f(explicit double .length, explicit .angle_degrees); // polar
coord
f(.x = 20.1, .y = 23.7);
f(.x = 20.1, .y = 23.7);
f(.length = 33.7, .angle = 1.2);
f(.length = 34.7, .angle_degrees = 45.9);
CreateWindow(Window *Parent, const char *.name = 0, .x = 0, .y = 0);
CreateWindow(0);
CreateWindow(MyParent, "Hello World!");
CreateWindow(MyParent, .x = 23, .y = 43);
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Fri, 31 Jan 2003 21:10:29 +0000 (UTC) Raw View
belvis@pacbell.net (Bob Bell) wrote in message news:<c87c1cfb.0301301533.405052ee@posting.google.com>...
> eldiener@earthlink.net ("Edward Diener") wrote in message news:<jiXZ9.3055$wd2.230414@newsread2.prod.itd.earthlink.net>...
> > ""Peter Koch Larsen"" <pkl@mailme.dk> wrote in message
> > news:3e37f2ce$0$230$edfadb0f@dread16.news.tele.dk...
> > > I am surprised of the fact that default parameters are so popular a theme.
> > The point is that one does not have to be a big fan of either designing
> > functions or template classes with default parameters to see that the
> > original poster presented an elegant solution to the problem...
>
> Solution, yes. Elegant, no, for all the reasons Peter has mentioned.
I propose the posters that don't agree this proposal, to explain the
following.
Suppose an API like:
void SetXX(Color c=green, Flavor f=sweet);
void SetYY(Color c=red, Flavor f=awful);
Color calcColor(Flavor f = sweet, int tolerance = 1);
Flavor calcFlavor(Color c=blue, int tolerance = 1);
void initCharacter(Race = elf, Length hair = Long, Color c = Blonde);
void setWeapon(WeaponType = sword, Handled = SingleHanded);
I want to know, given a number of functions n, each with Di default
parameters (i<=n), how many additional structures and forwarding
functions are needed.
Please give me the formula, and let's analyze its growing order.
NumFunc( n, F ), F the vector of the Fi.
Daniel.
---
[ 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 ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Sat, 1 Feb 2003 00:30:41 +0000 (UTC) Raw View
francis.glassborow@ntlworld.com (Francis Glassborow) writes:
> Can anyone provide a clear justification for not
> supporting explicit defaulting of parameters?
If by "explicit defaulting" you mean the use of "default" as a
placeholder, then my only justification (up to you to decide whether
it's clear or not) is that we can and should do better. In an
interface where there are enough parameters that providing the
neccessary overloads is difficult, it will also be difficult to
remember exactly how to use them positionally. Worse, a call like:
calculate_something(p->name, determinant, radius * 2, sqrt(3*bleed_temperature))
has some self-documenting properties, but:
calculate_something(default, default, default, sqrt(3*bleed_temperature))
has very few and is awfully verbose to boot. I think that we ought to
support _named_ function parameters so the above can be written:
foo(threshold : sqrt(3*bleed_temperature))
(or some equivalent syntax). The issue of differing defaults and
differing parameter names has been addressed by Garry Lancaster in
c++std-ext-5485. His approach is IMO elegant and consistent with the
way other parts of C++ work; maybe we can convince him to repeat it
here at comp.std.c++.
--
David Abrahams
dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
---
[ 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 ]
Author: eldiener@earthlink.net ("Edward Diener")
Date: Sat, 1 Feb 2003 07:41:36 +0000 (UTC) Raw View
"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uptqflo1q.fsf@boost-consulting.com...
> francis.glassborow@ntlworld.com (Francis Glassborow) writes:
>
> > Can anyone provide a clear justification for not
> > supporting explicit defaulting of parameters?
>
> If by "explicit defaulting" you mean the use of "default" as a
> placeholder, then my only justification (up to you to decide whether
> it's clear or not) is that we can and should do better. In an
> interface where there are enough parameters that providing the
> neccessary overloads is difficult, it will also be difficult to
> remember exactly how to use them positionally. Worse, a call like:
>
> calculate_something(p->name, determinant, radius * 2,
sqrt(3*bleed_temperature))
>
> has some self-documenting properties, but:
>
> calculate_something(default, default, default,
sqrt(3*bleed_temperature))
>
> has very few and is awfully verbose to boot. I think that we ought to
> support _named_ function parameters so the above can be written:
>
> foo(threshold : sqrt(3*bleed_temperature))
I think the first of the three examples is the most verbose, not the second.
Granted the last is the least verbose.
Why does the third have more self-documentation than the second example.
Aside from saying that the parameter given has something to do with a
"threshold" value because of the use of a named parameter, it gives just as
little information as the previous example regarding anything else. In fact
it may be seen to have less self-documentation since it doesn't imply that
there are other parameters to foo for which defaults have been chosen, in
other words it makes it seem as if foo is a function which takes a single
parameter whereas with the second I know that calculate_something takes four
parameters and I am specifying the first three as the defaults.
But this is all very much splitting hairs. I have nothing conceptually
against named parameters but they provide a number of problems which must
first be answered before they are implemented:
1) Where are the names provided ?
2) Wherever the names are provided, must they be consistent for every
declaration of the function ?
3) Are named parameters allowed for all parameters or only default
parameters ?
4) Can named parameters be mixed in any sequence with unnamed parameters ?
5) What is the scope of the names of named parameters and how do these names
interract with other identifiers in C++ which have the same names ?
And on and on with, I am sure more careful decisions to be made in how to
specify and use them. I am not saying this could not or should not be done
at some time. But as against this, the original posters solution offers a
simple solution to the problem of having to specify a default parameter
without worrying about the other defaults. Why not simply add that solution
to the language, and then if a named parameter solution also is viable add
that also. Certainly the positional way default parameters are currently
specified is not going to be dropped anytime soon ( talk about disrupting a
great deal of current code ! ) so why not make that syntax at least more
usable for the meantime.
---
[ 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 ]
Author: pkl@mailme.dk ("Peter Koch Larsen")
Date: Sat, 1 Feb 2003 20:46:31 +0000 (UTC) Raw View
<danielgutson@hotmail.com> skrev i en meddelelse
news:23478c42.0301300931.55656a54@posting.google.com...
> pkl@mailme.dk ("Peter Koch Larsen") wrote in message
news:<3e37eae9$0$241$edfadb0f@dread16.news.tele.dk>...
> > ""Edward Diener"" <eldiener@earthlink.net> skrev i en meddelelse
>
> some few comments from me:
>
> > feature. I dismiss it because my solution (which - as I believe I stated
is
> > not my original idea but a commonly known idiom) already solves the
problem
> > in a better way. If there are many parameters to a function, the
position in
>
> better: in which sense? You are stating a condition "If there are many
> parameters...", do you mean IN THAT situation? what about the rest?
In the situation, where there are many parameters (in my experience, this
means more than three or perhaps four), the named parameter idiom is the
only good solution.
> How many forwarding functions do you need in function of the number of
> parameters?
With three parameters i do in the worst case need seven forwarding functions
(one empty, three with one parameter and three with two parameters). I admit
that this is too many in my taste
>
>
> > the function-definition is not easy to remember and the named parameter
is a
> > better choice. Allowing a proposal that significanty reduces the
readability
> > of the code is not the way to go.
>
> Please, tell me why
>
> f(default, 1)
>
> is worse readably than your proposal.
Is f(default,1) the one with a default int and an explicit real or is it the
one with a default real and an explicit int? This is the problem I am trying
to avoid.
>
> >
> > My statements were simple:
> > *) default parameters should be avoided.
>
> why?
Because of problems with passing the function as a parameter and in
template-code.
>
> > *) In practical life, there is not much use for the default parameters.
If
>
> please tell me your concept of practical life, which engineering
> domain are you referring to. In the domains I worked the last 3 years,
> that is, geographic information systems, interpreters, wireless
> communications, and digital signal processing, I saw it many many
> times.
>
I have written communication-code and compilers/interpreters too. I have not
have used for any default-naming parameter idiom at all, except for one case
where i have had to configure a serial port where the named parameter idiom
was the best choice. With respect to GIS/DSP I admit of having no experience
at all.
I do not know why our experience w.r.t. default parameters differs so much.
If we talk about windowing software, I have often functions with an
abhorrant number of parameters, often because parameters have not been
packed properly. An example: using four parameters to give an rectangle
instead of one.
> > *) With a decently optimizing compiler, the named parameter idiom is as
> > efficient as the proposed solution.
>
> please tell me which compiler optimization technic are you referring
> to, and why/how it would solve it.
I will not go into a discussion about compiler optimizations, but I am sure
that
(bringing back my previous example) f(fparms().p3(5)) should compile as
efficiently as f(1,2,5). Investigation with my VC++ 6.0 compiler, which is
quite old demonstrated this to be the case (although i had to inline my
struct-based f to call the parameterized one):
// Assembler language output
; 20 : f(fparms().p3(5));
00000 6a 05 push 5
00002 6a 02 push 2
00004 6a 01 push 1
00006 e8 00 00 00 00 call ?f@@YAXHHH@Z ; f
; 21 : f(1,2,5);
0000b 6a 05 push 5
0000d 6a 02 push 2
0000f 6a 01 push 1
00011 e8 00 00 00 00 call ?f@@YAXHHH@Z ; f
00016 83 c4 18 add esp, 24 ; 00000018H
(the f-declarations being:
void f(int i,int j, int k);
// fparms as in my previous post)
inline void f(fparms fp) { f(fp.myp1,fp.myp2,fp.myp3);}
Even if there was a penalty to pay, i would not care too much. My feeling
would be that the performance penalty should be insignificand. Then again,
our experiences seem to differ.
Kind regards
Peter
---
[ 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 ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Mon, 3 Feb 2003 19:56:16 +0000 (UTC) Raw View
eldiener@earthlink.net ("Edward Diener") writes:
> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:uptqflo1q.fsf@boost-consulting.com...
>> francis.glassborow@ntlworld.com (Francis Glassborow) writes:
>>
>> > Can anyone provide a clear justification for not
>> > supporting explicit defaulting of parameters?
>>
>> If by "explicit defaulting" you mean the use of "default" as a
>> placeholder, then my only justification (up to you to decide whether
>> it's clear or not) is that we can and should do better. In an
>> interface where there are enough parameters that providing the
>> neccessary overloads is difficult, it will also be difficult to
>> remember exactly how to use them positionally. Worse, a call like:
>>
>> calculate_something(p->name, determinant, radius * 2,
> sqrt(3*bleed_temperature))
>>
>> has some self-documenting properties, but:
>>
>> calculate_something(default, default, default,
> sqrt(3*bleed_temperature))
>>
>> has very few and is awfully verbose to boot. I think that we ought to
>> support _named_ function parameters so the above can be written:
>>
>> foo(threshold : sqrt(3*bleed_temperature))
>
> I think the first of the three examples is the most verbose, not the second.
> Granted the last is the least verbose.
>
> Why does the third have more self-documentation than the second example.
> Aside from saying that the parameter given has something to do with a
> "threshold" value because of the use of a named parameter,
That's exactly why. You hit the nail on the head.
> it gives just as little information as the previous example
> regarding anything else. In fact it may be seen to have less
> self-documentation since it doesn't imply that there are other
> parameters to foo for which defaults have been chosen, in other
> words it makes it seem as if foo is a function which takes a single
> parameter
It is. It's also a function which takes 4 parameters. No problem.
> whereas with the second I know that calculate_something
> takes four parameters and I am specifying the first three as the
> defaults.
Why does it matter at the call site that there are defaulted
parameters, any more than it would if the same call was available via
overloading?
> But this is all very much splitting hairs. I have nothing conceptually
> against named parameters but they provide a number of problems which must
> first be answered before they are implemented:
>
> 1) Where are the names provided ?
In declarations
> 2) Wherever the names are provided, must they be consistent for every
> declaration of the function ?
No. Anything that can't be interpreted unambiguously causes an error
at the point of the call (Garry Lancaster's idea, not mine).
> 3) Are named parameters allowed for all parameters or only default
> parameters ?
All parameters.
> 4) Can named parameters be mixed in any sequence with unnamed
> parameters ?
Any unnamed parameters must precede any named parameters. The unnamed
parameters are positional.
> 5) What is the scope of the names of named parameters and how do these names
> interract with other identifiers in C++ which have the same names ?
They don't have scope and they don't interact at all. They're just a
way of labeling expressions.
> And on and on with, I am sure more careful decisions to be made in how to
> specify and use them.
I don't think there's very much more to it. It's easy to say "on and
on" without naming specific problems, but that just creates doubt.
IMO all the hard problems other than writing the standard text and
convincing people have been solved.
> I am not saying this could not or should not be done at some
> time. But as against this, the original posters solution offers a
> simple solution to the problem of having to specify a default
> parameter without worrying about the other defaults. Why not simply
> add that solution to the language,
> and then if a named parameter solution also is viable add that also.
When was the last time you "simply added a solution" to the language?
The reason not to is that it's never simple, and it's much harder to
add a new solution for a problem space already addressed in the
standard, even if the existing solution is a poor one. If I see a
better solution I'm not going to waste energy on an inferior one.
> Certainly the positional way default parameters are currently
> specified is not going to be dropped anytime soon ( talk about
> disrupting a great deal of current code ! ) so why not make that
> syntax at least more usable for the meantime.
There's no need for an "in the meantime." It'll be at least 5 years
before we get a new standard. That's plenty of time to solve the
problem right.
-Dave
--
David Abrahams
dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 3 Feb 2003 19:56:54 +0000 (UTC) Raw View
pkl@mailme.dk ("Peter Koch Larsen") wrote in message news:<3e3bc723$0$163$edfadb0f@dread16.news.tele.dk>...
> <danielgutson@hotmail.com> skrev i en meddelelse
> news:23478c42.0301300931.55656a54@posting.google.com...
> > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
> > > in a better way. If there are many parameters to a function, the
> position in
> >
> > better: in which sense? You are stating a condition "If there are many
> > parameters...", do you mean IN THAT situation? what about the rest?
>
> In the situation, where there are many parameters (in my experience, this
So, we can differentiate two situations, in which 'better' points to
one or the other according the case: *few* parameters (few=? <= 3?),
and *many* parameters (>3?).
I still don't know why there is kind of 'exclusiveness' rounding here.
As always, you (as a programmer) sometimes face many idioms/way to do
something.
It should be the decision of the programmer whether to use named
parameters or default parameters.
Again, that makes the difference of a good programmer: his decisions
within the contexts.
> > How many forwarding functions do you need in function of the number of
> > parameters?
> With three parameters i do in the worst case need seven forwarding functions
> (one empty, three with one parameter and three with two parameters). I admit
> that this is too many in my taste
I propose you to show the formula: number of functions/structures in
terms of number of [default] parameters. (warning: I'm not trying to
test you, please don't misunderstand me; I'm just inviting you to show
it to us for analysis purposes only).
If you want, I suggest also to calculate the LOC of the structure in
terms of the number of parameters.
Maybe we could build some analytical criteria for determining WHEN to
use named params., and WHEN to use default params.
> >
> > Please, tell me why
> >
> > f(default, 1)
> >
> > is worse readably than your proposal.
>
> Is f(default,1) the one with a default int and an explicit real or is it the
> one with a default real and an explicit int? This is the problem I am trying
> to avoid.
2 things:
1) there is when <type> apperas. In that case, compiler would
complain, then you must specify
f(default<float>,1)
OR
f(default<int>,1)
and problem solved; named parameter neither solves this. You can use
this explicit typing either for ambiguity solving as well as
readibility.
> > > *) default parameters should be avoided.
> > why?
>
> Because of problems with passing the function as a parameter and in
> template-code.
What problems exactly. Please be specific, and show the contrast with
named parameters example.
>
> I have written communication-code and compilers/interpreters too. I have not
> have used for any default-naming parameter idiom at all, except for one case
> where i have had to configure a serial port where the named parameter idiom
> was the best choice. With respect to GIS/DSP I admit of having no experience
> at all.
> I do not know why our experience w.r.t. default parameters differs so much.
> If we talk about windowing software, I have often functions with an
> abhorrant number of parameters, often because parameters have not been
> packed properly. An example: using four parameters to give an rectangle
> instead of one.
Please see the API example I posted at the end of the thread.
> I will not go into a discussion about compiler optimizations, but I am sure
> that
> (bringing back my previous example) f(fparms().p3(5)) should compile as
> efficiently as f(1,2,5). Investigation with my VC++ 6.0 compiler, which is
> quite old demonstrated this to be the case (although i had to inline my
> struct-based f to call the parameterized one):
>
> // Assembler language output
> ; 20 : f(fparms().p3(5));
You have only one parameter here. What about specifying more than one?
f(fparams().p3(5).p2(1).p4(6);
Another thing is, that as the number of parameters growths, the
readibility decreases.
If we have
f(fparams() .name(value) )
we'll get
STRUCT_NAME+ 2+
(PARAM_NAME+2) extra characters per parameter (2 because of
parenthesis).
You talked about readibility better when 'many' parameters, suppose 5:
5*(NAME+2), let's take an average of 5 characters per parameter name
(being benevolent), and 'fparams()' as the structure's name, you get
44 extra characters inside the function call, do you still think that
readibility is improved?
> Even if there was a penalty to pay, i would not care too much. My feeling
Ok, depending on the situation. Sometimes you do care (as in the
project I'm now, a realtime soft-modem).
Finally, I want to say: WHY these idioms should 'COMPETE'? They should
compete in the mind of the programmer when deciding, but not in the
standard.
You just cannot avoid the standarization of something because 'it
MIGHT be misused'. If not, we could not be hired! :)
Daniel.
---
[ 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 ]
Author: pkl@mailme.dk ("Peter Koch Larsen")
Date: Tue, 4 Feb 2003 06:42:38 +0000 (UTC) Raw View
<danielgutson@hotmail.com> skrev i en meddelelse
news:23478c42.0302020026.6b4ab89b@posting.google.com...
> pkl@mailme.dk ("Peter Koch Larsen") wrote in message
news:<3e3bc723$0$163$edfadb0f@dread16.news.tele.dk>...
> > <danielgutson@hotmail.com> skrev i en meddelelse
> > news:23478c42.0301300931.55656a54@posting.google.com...
> > > pkl@mailme.dk ("Peter Koch Larsen") wrote in message
>
> So, we can differentiate two situations, in which 'better' points to
> one or the other according the case: *few* parameters (few=? <= 3?),
> and *many* parameters (>3?).
Yes - this is the situation.
> I still don't know why there is kind of 'exclusiveness' rounding here.
> As always, you (as a programmer) sometimes face many idioms/way to do
> something.
> It should be the decision of the programmer whether to use named
> parameters or default parameters.
Please remember that we are talking about named parameters in the context of
"named parameter idiom" here - not as in another proposal in comp.std.c++.
If there was a general feeling that default arguments were common, I could
advocate for a solution where distinct naming was used - as in f(p1: 1, p2:
3, p4: 8). My subjective opinion of your proposal has been spelled out
before, and I would never introduce a feature in the language, which would
reduce the readability for the programmer.
> Again, that makes the difference of a good programmer: his decisions
> within the contexts.
There are programmers out there, who should not be given too much leeway:
C++ already encourages writing hard-to-understand programs.
>
> If you want, I suggest also to calculate the LOC of the structure in
> terms of the number of parameters.
About 2* number of parameters. Not a big deal if you consider the rarity of
default parameter functions.
> > > > *) default parameters should be avoided.
> > > why?
> >
> > Because of problems with passing the function as a parameter and in
> > template-code.
>
> What problems exactly. Please be specific, and show the contrast with
> named parameters example.
If you have a function f(double,int i=2), you can not pass that function to
a procedure that expects a f(double). If you - instead of using default
parameters - had to f's, the second being inline void f(double x) {
f(x,1); }, you would not have that problem.
> Please see the API example I posted at the end of the thread.
I saw no such function.
> You have only one parameter here. What about specifying more than one?
; 20 : f(fparms().p3(5).p1(4).p2(8));
00000 6a 05 push 5
00002 6a 08 push 8
00004 6a 04 push 4
00006 e8 00 00 00 00 call ?f@@YAXHHH@Z ; f
(and yes - it also works with a f that takes eight parameters: at least if
you specify one, four or eight of the parameters)
> Another thing is, that as the number of parameters growths, the
> readibility decreases.
> If we have
> f(fparams() .name(value) )
> we'll get
> STRUCT_NAME+ 2+
> (PARAM_NAME+2) extra characters per parameter (2 because of
> parenthesis).
Readability is not related to the length of the code: in that case, we would
restrict ourselves to very short identifiers. What matters is that we can
see which parameters, that are passed as "non-defaults". This is very easy
when you name them.
>
> You talked about readibility better when 'many' parameters, suppose 5:
>
> 5*(NAME+2), let's take an average of 5 characters per parameter name
> (being benevolent), and 'fparams()' as the structure's name, you get
> 44 extra characters inside the function call, do you still think that
> readibility is improved?
Yes. You would have to use 75 characters to call the default version,
provided a typename has (only) five characters.
> Ok, depending on the situation. Sometimes you do care (as in the
> project I'm now, a realtime soft-modem).
Play with your compiler and see what the penalty is. What functions with
default parameters do you call in time-critical code?
>
> Finally, I want to say: WHY these idioms should 'COMPETE'? They should
> compete in the mind of the programmer when deciding, but not in the
> standard.
Although you did fail to provide me with an API-function with many
parameters I did see this example from you (in another post here on
std.c++):
void drawCircle( int radious = 1, int centerX = 0, int centerY = 0,
Color color = green);
If this is your style of having default parameters, I must say that I find
your style unhealthy. My draw would look like:
void draw(const Circle &circle,const Color &color)
(ignoring obvious questions as where it should be drawed, the thickness of
the line and such stuff!)
with NO default parameters. For that function there are no sensible
defaults. Also: why use THREE integer parameters when one Circle parameter
is the appropriate choice?
> You just cannot avoid the standarization of something because 'it
> MIGHT be misused'. If not, we could not be hired! :)
I can not talk to you about hiring, but why implement a feature that does
not really solve anything and can be dangerous in the wrong hands?
Kind regards
Peter
---
[ 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 ]
Author: eldiener@earthlink.net ("Edward Diener")
Date: Tue, 28 Jan 2003 13:08:48 +0000 (UTC) Raw View
"Peter Koch Larsen" <pkl@mailme.dk> wrote in message
news:61c84197.0301270025.4d129e8d@posting.google.com...
> danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message
news:<23478c42.0301242156.5b9e3e89@posting.google.com>...
> > pkl@mailme.dk (Peter Koch Larsen) wrote in message
> > What I state is: C++ already has a [simple] mechanism for default
> > parameters; I just propose to extend it in order to exploit its
> > simplicity and the ability of using it without the 'order'
> > restriction, using an already existent word and with readable impact.
>
> I doubt that your approach will be better. If there is a significand
> number of parameters (more than e.g. 3), my approach is the only
> viable due to the problem of remembering the index of each individual
> parameter. If there is less, often overloading will help you avoid
> having these default parameters in the first place. Your approach
> encourages a bad programming practice which makes the program more
> difficult to read, and that is not the way to go.
The original poster presented a simple solution to an already existing issue
in C++. You present a far more complicated solution and then claim that only
your own solution is viable, and that using default parameters is a bad
programming practice. Rather than solve a problem, you just dismiss it
because you don't like the feature itself.
I would rather see the simple solution implemented and if others, like you,
want to roll your own home-grown solution to the problem I have no problem
with that. But to dismiss a simple and effective solution because you have
decided that the issue should not exist because you don't program that way
is, itself, "not the way to go".
---
[ 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 ]
Author: anthony.williamsNOSPAM@anthonyw.cjb.net (Anthony Williams)
Date: Tue, 28 Jan 2003 21:12:01 +0000 (UTC) Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:
> Given a function accepting more than one parameter with default
> values, the idea is to be able to leave the default parameters 'in the
> middle' and pass values at the end.
>
> EXAMPLE:
> void f( int p1 = 1, int p2 = 2, int p3 = 3);
>
> -> invoke f leaving the default values in p1 and p2, and specify the
> value in p3.
Thomas Becker discusses default function parameters in the February 2003 issue
of CUJ, and proposes a solution similar to that proposed by Peter Koch Larsen
in his response to your post. I will repeat here the alternative
implementation that I suggested to him --- use a forwarding template. On a
good compiler all the checkForXXX functions and the forwarding function itself
will be optimized away. Such a function template probably interacts badly with
overloads since it will generally yield an exact match on the template
parameters, but such is life --- if you want default arguments at non-trailing
positions, you probably don't want overloads too, anyway.
To allow omission of trailing arguments, as for the normal case, you could
provide overloads with fewer arguments, which just forward to the main
function template. e.g.
int foo()
{
return foo(defaultValue(),defaultValue(),defaultValue());
}
template<typename T1>
inline int foo(T1& t1)
{
return foo(t1,defaultValue(),defaultValue());
}
template<typename T1,typename T2>
inline int foo(T1& t1,const T2& t2)
{
return foo(t1,t2,defaultValue());
}
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.
// the code
#include <iostream>
#include <string>
struct DefaultValueType
{};
inline const DefaultValueType& defaultValue()
{
static const DefaultValueType val={};
return val;
}
// Values will be copied or passed by const ref
template<typename T,typename U>
inline U& checkForDefaultVal(U& suppliedArg,const T& /*defVal*/)
{
return suppliedArg;
}
template<typename T>
inline const T& checkForDefaultVal(const DefaultValueType& /*suppliedArg*/,
const T& defVal)
{
return defVal;
}
// references might be non-const
template<typename T,typename U>
inline U& checkForDefaultRef(U& suppliedArg,T& /*defVal*/)
{
return suppliedArg;
}
template<typename T>
inline T& checkForDefaultRef(const DefaultValueType& /*suppliedArg*/,
T& defVal)
{
return defVal;
}
// note non-const ref to i
int fooInternal(int& i,double d,const std::string& s)
{
std::cout<<"i="<<i<<", d="<<d<<", s="<<s<<std::endl;
return ++i;
}
int global=0;
// first param is non-const ref on fooInternal,
// so must be non-const ref with wrapper
template<typename T1,typename T2,typename T3>
inline int foo(T1& t1, const T2& t2,const T3& t3)
{
return fooInternal(checkForDefaultRef(t1,global),
checkForDefaultVal(t2,3.141),
checkForDefaultVal(t3,"hello"));
}
template<typename T1,typename T2,typename T3>
inline int goo(T1& t1, const T2& t2,const T3& t3)
{
return fooInternal(checkForDefaultRef(t1,global),
t2,
checkForDefaultVal(t3,"hello"));
}
int main()
{
int local=10;
foo(defaultValue(),defaultValue(),defaultValue());
foo(local,defaultValue(),defaultValue());
foo(defaultValue(),9.2,defaultValue());
foo(defaultValue(),defaultValue(),"goodbye");
foo(local,9.2,defaultValue());
foo(local,defaultValue(),"goodbye");
foo(defaultValue(),9.2,"goodbye");
foo(local,9.2,"goodbye");
// calls with second argument "defaultValue" won't compile
// goo(defaultValue(),defaultValue(),defaultValue());
// goo(local,defaultValue(),defaultValue());
goo(defaultValue(),9.2,defaultValue());
// goo(defaultValue(),defaultValue(),"goodbye");
goo(local,9.2,defaultValue());
// goo(local,defaultValue(),"goodbye");
goo(defaultValue(),9.2,"goodbye");
goo(local,9.2,"goodbye");
return 0;
}
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Wed, 29 Jan 2003 06:49:29 +0000 (UTC) Raw View
anthony.williamsNOSPAM@anthonyw.cjb.net (Anthony Williams) wrote in message news:<d6mhxsal.fsf@anthonyw.cjb.net>...
> Thomas Becker discusses default function parameters in the February 2003 issue
Hi. I looked at the code, but I cannot believe that cost/benefit of
this, that approx. 100 LOC for doing (don't remember the parameters)
int foo(int i=1, double p=3.14, string s="hello")
{
cout ...;
}
int main()
{
foo(default, default, "goodbye");
...
return 0;
}
My questions are:
1- do you consider the 'readability' factor, that is, the person that
must continue a legacy code? How many lines of documentation do you
need for something so simple? (and lines of code!: you developed ~ 7
functions (ok, some of them reusable)
2- You use template functions, often inlined. What if you don't want
to inline them? (for example, in Windows, there are situations that
functions -as simple as you want- cannot be inlined due to memory
considerations [DLLs and memory spaces])
3- finally, what's wrong with this simple and intuitive proposal that
so many people wants to deny? Please let me know, because indeed I'm
missing the point.
Thanks anyway,
Daniel.
---
[ 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 ]
Author: anthony.williamsNOSPAM@anthonyw.cjb.net (Anthony Williams)
Date: Wed, 29 Jan 2003 14:07:44 +0000 (UTC) Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:
> anthony.williamsNOSPAM@anthonyw.cjb.net (Anthony Williams) wrote in message
> news:<d6mhxsal.fsf@anthonyw.cjb.net>...
>
> > Thomas Becker discusses default function parameters in the February 2003
> > issue
>
> Hi. I looked at the code, but I cannot believe that cost/benefit of
> this, that approx. 100 LOC for doing (don't remember the parameters)
>
> int foo(int i=1, double p=3.14, string s="hello")
> {
> cout ...;
> }
>
> int main()
> {
> foo(default, default, "goodbye");
> ...
> return 0;
> }
>
> My questions are:
>
> 1- do you consider the 'readability' factor, that is, the person that
> must continue a legacy code? How many lines of documentation do you
> need for something so simple? (and lines of code!: you developed ~ 7
> functions (ok, some of them reusable)
I would expect that the _technique_ would have to be documented, and then a
short description saying "this set of overloaded functions provides positional
defaults for function xyz". Once you have grasped the technique, the code is
quite readable, especially at the call site, IMO.
> 2- You use template functions, often inlined. What if you don't want
> to inline them? (for example, in Windows, there are situations that
> functions -as simple as you want- cannot be inlined due to memory
> considerations [DLLs and memory spaces])
If you don't inline them, you suffer the cost of a function call. I would
expect the optimizer to _completely eliminate_ the inline functions, so this
certainly shouldn't be an issue for memory considerations. The only issue I
see is that if the default values require construction, they will always be
constructed, irrespective of whether or not they are used.
> 3- finally, what's wrong with this simple and intuitive proposal that
> so many people wants to deny? Please let me know, because indeed I'm
> missing the point.
My point was merely that you can emulate your proposal in the current
language. If it is a sufficiently common requirement, it would be better being
standardized (as per your proposal, for example) to avoid the (maintenance)
overhead of my suggestion.
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.
---
[ 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 ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Wed, 29 Jan 2003 14:08:04 +0000 (UTC) Raw View
In article <23478c42.0301282057.1122a3f1@posting.google.com>,
"danielgutson@hotmail.com" <danielgutson@hotmail.com> writes
>anthony.williamsNOSPAM@anthonyw.cjb.net (Anthony Williams) wrote in message news:<d6mhxsal.fsf@anthonyw.cjb.net>...
>
>> Thomas Becker discusses default function parameters in the February 2003 issue
>
>Hi. I looked at the code, but I cannot believe that cost/benefit of
>this, that approx. 100 LOC for doing (don't remember the parameters)
>
> int foo(int i=1, double p=3.14, string s="hello")
> {
> cout ...;
> }
>
> int main()
> {
> foo(default, default, "goodbye");
> ...
> return 0;
> }
>
>My questions are:
>
>1- do you consider the 'readability' factor, that is, the person that
>must continue a legacy code? How many lines of documentation do you
>need for something so simple? (and lines of code!: you developed ~ 7
>functions (ok, some of them reusable)
>2- You use template functions, often inlined. What if you don't want
>to inline them? (for example, in Windows, there are situations that
>functions -as simple as you want- cannot be inlined due to memory
>considerations [DLLs and memory spaces])
>3- finally, what's wrong with this simple and intuitive proposal that
>so many people wants to deny? Please let me know, because indeed I'm
>missing the point.
I think we have two distinct problems. In the first we need to
understand how we got where we are.
I remember (well I am pretty sure it is not a fantasy, but at my age it
might be) a conversation I had with Bjarne Stroustrup on the subject of
using forwarding functions versus default parameters. I seem to remember
that he said that he had originally thought of default parameters as a
short-hand for forwarding functions. Against that background the current
rules make a good deal of sense.
However default parameters were not implemented as forwarding functions,
even worse to my mind, different TUs can (and too often do) have
different defaults declared. That rules out implementation of default
parameters as forwarding functions.
In the current circumstances I seriously prefer writing explicit
forwarding functions (they potentially have addresses, can be used as
arguments to both functions and templates, and they can participate in
containers of function pointers with similar signatures.)
However given the way that default parameters are implemented (and,
AFAIK always have been) allowing explicit defaulting on an argument by
argument basis makes perfectly good sense.
Can anyone provide a clear justification for not supporting explicit
defaulting of parameters?
Please note that I think those responsible for teaching C++ should have
a clearer idea of the advantages and disadvantages of default parameters
versus an overloaded set of forwarding functions. Note that almost
always the programmer must choose which mechanism to use.
--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU
---
[ 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 ]
Author: pkl@mailme.dk ("Peter Koch Larsen")
Date: Wed, 29 Jan 2003 17:54:14 +0000 (UTC) Raw View
<danielgutson@hotmail.com> skrev i en meddelelse
news:23478c42.0301282057.1122a3f1@posting.google.com...
> anthony.williamsNOSPAM@anthonyw.cjb.net (Anthony Williams) wrote in
message news:<d6mhxsal.fsf@anthonyw.cjb.net>...
>
> > Thomas Becker discusses default function parameters in the February 2003
issue
>
> Hi. I looked at the code, but I cannot believe that cost/benefit of
> this, that approx. 100 LOC for doing (don't remember the parameters)
>
> int foo(int i=1, double p=3.14, string s="hello")
> {
> cout ...;
> }
>
> int main()
> {
> foo(default, default, "goodbye");
> ...
> return 0;
> }
>
> My questions are:
>
> 1- do you consider the 'readability' factor, that is, the person that
> must continue a legacy code? How many lines of documentation do you
> need for something so simple? (and lines of code!: you developed ~ 7
> functions (ok, some of them reusable)
> 2- You use template functions, often inlined. What if you don't want
> to inline them? (for example, in Windows, there are situations that
> functions -as simple as you want- cannot be inlined due to memory
> considerations [DLLs and memory spaces])
> 3- finally, what's wrong with this simple and intuitive proposal that
> so many people wants to deny? Please let me know, because indeed I'm
> missing the point.
>
> Thanks anyway,
> Daniel.
Your example could be written as follows:
int foo(int i1, double p, string s)
{
cout ...;
}
inline int foo(string s) { return foo(1,3.14,s); }
// other inline overrides
int main()
{
foo("goodbye");
...
return 0;
}
I prefer this approach for the reasons stated by Francis: use with templates
and function-parameters. I also find it easier to read and far less
errorprone. Using your approach, it is to easy to forget the position of the
actual parameters (if they are type-compatible): did you really mean it when
you wrote foo(default,1,default) or should it be foo(1,default,default)?
An alternative solution would be to use named parameters directly - e.g.
write foo(s="goodbye"), but that approach can not be used as the
parameter-names are "white-space" in the declaration: The foo could be
prototyped as foo(int,double,string) or even have multiple definitions
(foo(int i=1, double p=3.14, string s="hello") in one place and (int j=1,
double k=3.14, string l="hello") in another). This fact was pointed out in
another thread with a similar proposal.
I am surprised of the fact that default parameters are so popular a theme.
In my own experience, I have usually been able to use function overloading
where default parameters are convenient. The few places where they are not
(mostly in GUI-code), I have used the named parameter idiom and found it
most useful. Apart from the clear indication of what parameters are
supplied, it is also very easy to put more "meat" in the call whenever the
situation should arise.
You obviously do not seem to have the same experience and I wonder if I am
the minority group here. Which problemdomains have this heavy need for
default parameters? I would like to know.
Kind regards
Peter Koch Larsen
---
[ 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 ]
Author: eldiener@earthlink.net ("Edward Diener")
Date: Wed, 29 Jan 2003 21:10:24 +0000 (UTC) Raw View
""Peter Koch Larsen"" <pkl@mailme.dk> wrote in message
news:3e37f2ce$0$230$edfadb0f@dread16.news.tele.dk...
> I am surprised of the fact that default parameters are so popular a theme.
> In my own experience, I have usually been able to use function overloading
> where default parameters are convenient. The few places where they are not
> (mostly in GUI-code), I have used the named parameter idiom and found it
> most useful. Apart from the clear indication of what parameters are
> supplied, it is also very easy to put more "meat" in the call whenever the
> situation should arise.
> You obviously do not seem to have the same experience and I wonder if I am
> the minority group here. Which problemdomains have this heavy need for
> default parameters? I would like to know.
Whether rightly or not, a number of API functions for Windows take a large
number of parameters, particularly those for GUI calls. Being able to
specify a number of these as defaults, whether in an application framework
built around the OS, such as MFC, .NET, VCL etc. or in C++ header files
implementing the raw API call, and allowing the end caller to just specify
the changes needed with "default" for the rest, eases the use of such a
framework and/or the basic API call.
Policy-based template classes may take quite a few clever policies, with
defaults, to provide maximum flexibility in building the eventual
instantiated version of the class one wants to use. Being able to just
specify "default" for the policies in which one has no interest, and a type
or value for the policies one is interested in changing, would be a
usability boon for such a template class.
The point is that one does not have to be a big fan of either designing
functions or template classes with default parameters to see that the
original poster presented an elegant solution to the problem of having to
unnecessarily remember and provide default parameters in order to specify
the change to the default one wants. The solution would minimally impact any
other code and should be very easy for a compiler to implement.
---
[ 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 ]
Author: pkl@mailme.dk ("Peter Koch Larsen")
Date: Wed, 29 Jan 2003 21:24:22 +0000 (UTC) Raw View
""Edward Diener"" <eldiener@earthlink.net> skrev i en meddelelse
news:ZAnZ9.7394$U27.685921@newsread2.prod.itd.earthlink.net...
> "Peter Koch Larsen" <pkl@mailme.dk> wrote in message
> news:61c84197.0301270025.4d129e8d@posting.google.com...
> > danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message
> news:<23478c42.0301242156.5b9e3e89@posting.google.com>...
> > > pkl@mailme.dk (Peter Koch Larsen) wrote in message
> > > What I state is: C++ already has a [simple] mechanism for default
> > > parameters; I just propose to extend it in order to exploit its
> > > simplicity and the ability of using it without the 'order'
> > > restriction, using an already existent word and with readable impact.
> >
> > I doubt that your approach will be better. If there is a significand
> > number of parameters (more than e.g. 3), my approach is the only
> > viable due to the problem of remembering the index of each individual
> > parameter. If there is less, often overloading will help you avoid
> > having these default parameters in the first place. Your approach
> > encourages a bad programming practice which makes the program more
> > difficult to read, and that is not the way to go.
>
> The original poster presented a simple solution to an already existing
issue
> in C++. You present a far more complicated solution and then claim that
only
> your own solution is viable, and that using default parameters is a bad
> programming practice. Rather than solve a problem, you just dismiss it
> because you don't like the feature itself.
Actually I _did_ solve the problem, did I not?
With regard to complexity, my solution is rather simple in understanding as
well as in implementation. The implementation of the helper-class might be a
little tedious, but everybody could do it without sweating.
I dismiss the proposal not just because I do not personally like the
feature. I dismiss it because my solution (which - as I believe I stated is
not my original idea but a commonly known idiom) already solves the problem
in a better way. If there are many parameters to a function, the position in
the function-definition is not easy to remember and the named parameter is a
better choice. Allowing a proposal that significanty reduces the readability
of the code is not the way to go.
My statements were simple:
*) default parameters should be avoided.
*) In practical life, there is not much use for the default parameters. If
there are few parameters, function overloading can often be used insted and
if there are many, the practical problem of remembering the index of a given
parameter will give cause to lots of trouble.
*) With a decently optimizing compiler, the named parameter idiom is as
efficient as the proposed solution.
*) the named parameter idiom clearly shows which parameters are non-default.
>
> I would rather see the simple solution implemented and if others, like
you,
> want to roll your own home-grown solution to the problem I have no problem
> with that. But to dismiss a simple and effective solution because you have
> decided that the issue should not exist because you don't program that way
> is, itself, "not the way to go".
A programming language should support readable code and discourage features
that may give trouble. I do not believe my advice in nature is much
different from "do not use C-casts". Thus I find your above remark unfair
and ungrounded.
Kind regards
Peter
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Thu, 30 Jan 2003 18:25:09 +0000 (UTC) Raw View
pkl@mailme.dk ("Peter Koch Larsen") wrote in message news:<3e37eae9$0$241$edfadb0f@dread16.news.tele.dk>...
> ""Edward Diener"" <eldiener@earthlink.net> skrev i en meddelelse
some few comments from me:
> feature. I dismiss it because my solution (which - as I believe I stated is
> not my original idea but a commonly known idiom) already solves the problem
> in a better way. If there are many parameters to a function, the position in
better: in which sense? You are stating a condition "If there are many
parameters...", do you mean IN THAT situation? what about the rest?
How many forwarding functions do you need in function of the number of
parameters?
> the function-definition is not easy to remember and the named parameter is a
> better choice. Allowing a proposal that significanty reduces the readability
> of the code is not the way to go.
Please, tell me why
f(default, 1)
is worse readably than your proposal.
>
> My statements were simple:
> *) default parameters should be avoided.
why?
> *) In practical life, there is not much use for the default parameters. If
please tell me your concept of practical life, which engineering
domain are you referring to. In the domains I worked the last 3 years,
that is, geographic information systems, interpreters, wireless
communications, and digital signal processing, I saw it many many
times.
> *) With a decently optimizing compiler, the named parameter idiom is as
> efficient as the proposed solution.
please tell me which compiler optimization technic are you referring
to, and why/how it would solve it.
Daniel.
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Sat, 25 Jan 2003 21:07:29 +0000 (UTC) Raw View
usenet_cpp@lehrerfamily.com (Joshua Lehrer) wrote in message news:<31c49f0d.0301240729.76213f0@posting.google.com>...
> actually, the <type> should be optional, as it is only required if
> there are overloads that need to be resolved:
100% agree.
>
> Requiring the type to be specified dangerous, as the function provider
> might change the types.
I'm not sure I understood your point: specifying the type is
'dangerous'?
If so, I don't agree here, because if the provider 'suddenly' changed
the type, it would be a good way of getting the impact and being
notified: it just helps strongness.
Probably without default parameters, you would too. But this would
also be an improvement in
original:
f(unsigned int x = 1, unsigned int y = 2);
changed to:
f(signed int x = 1, unsigned int y = 2);
then if the caller does
f( default<int>, 3 );
would get (a warning?) and this would be very useful.
Daniel
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Sat, 25 Jan 2003 21:08:05 +0000 (UTC) Raw View
pkl@mailme.dk (Peter Koch Larsen) wrote in message
> struct fparms
> {
> int myp1, myp2, myp3;
> fparms(): myp1(1), myp2(2), myp3(3) {}
> fparms& p1(int p) {myp1 = p; return *this; }
> fparms& p2(int p) {myp2 = p; return *this; }
> fparms& p3(int p) {myp3 = p; return *this; }
> }
>
> your example:
> > f( default<int>, default<int>, 5); //will call f(1,2,5)
> would then become f(fparms().p3(5)).
So would you create a class PER EACH function accepting those
parameters?
I admit that the idea has its elegance, but I don't like
- impractical (one struct per function)
- performance (against parameter-passing)
What I state is: C++ already has a [simple] mechanism for default
parameters; I just propose to extend it in order to exploit its
simplicity and the ability of using it without the 'order'
restriction, using an already existent word and with readable impact.
regards,
Daniel
---
[ 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 ]
Author: pkl@mailme.dk (Peter Koch Larsen)
Date: Mon, 27 Jan 2003 22:56:05 +0000 (UTC) Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301242156.5b9e3e89@posting.google.com>...
> pkl@mailme.dk (Peter Koch Larsen) wrote in message
> > struct fparms
> > {
> > int myp1, myp2, myp3;
> > fparms(): myp1(1), myp2(2), myp3(3) {}
> > fparms& p1(int p) {myp1 = p; return *this; }
> > fparms& p2(int p) {myp2 = p; return *this; }
> > fparms& p3(int p) {myp3 = p; return *this; }
> > }
> >
> > your example:
> > > f( default<int>, default<int>, 5); //will call f(1,2,5)
> > would then become f(fparms().p3(5)).
>
> So would you create a class PER EACH function accepting those
> parameters?
> I admit that the idea has its elegance, but I don't like
> - impractical (one struct per function)
Only structs for those functions where any parameter should have a
default. In my experience, these situations do not come up often.
> - performance (against parameter-passing)
I doubt there will be any performance difference if you use a decent
optimizing compiler. And again, i doubt that this issue pops up
frequently enough to care about performance in the first place. I have
only used the idiom in a handful of places.
>
> What I state is: C++ already has a [simple] mechanism for default
> parameters; I just propose to extend it in order to exploit its
> simplicity and the ability of using it without the 'order'
> restriction, using an already existent word and with readable impact.
I doubt that your approach will be better. If there is a significand
number of parameters (more than e.g. 3), my approach is the only
viable due to the problem of remembering the index of each individual
parameter. If there is less, often overloading will help you avoid
having these default parameters in the first place. Your approach
encourages a bad programming practice which makes the program more
difficult to read, and that is not the way to go.
>
> regards,
> Daniel
Regards
Peter
---
[ 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 ]
Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Fri, 24 Jan 2003 15:07:40 +0000 (UTC) Raw View
> Newgroup people:
> I would appreciate your feedback on the following proposal.
>
> DESCRIPTION:
> Given a function accepting more than one parameter with default
> values, the idea is to be able to leave the default parameters 'in the
> middle' and pass values at the end.
>
> EXAMPLE:
> void f( int p1 = 1, int p2 = 2, int p3 = 3);
>
> -> invoke f leaving the default values in p1 and p2, and specify the
> value in p3.
>
> HOW:
> I propose the use of the 'default' keyword:
> default<type>
> in the example:
> f( default<int>, default<int>, 5); //will call f(1,2,5)
>
> <type> is needed for avoiding ambiguities (if any) on overloaded
> functions.
>
So in that case, we would be able to write f(default, default, 5)
or maybe even f( , , 5) but that last solution may be less readable
particulary if the function has a lot of optional parameters and
we specify one in the middle.
>
> Daniel.
>
Maybe named arguments would be a better alternative. For the
syntax, we cannot uses parameter_name = value as it would be
ambiguous if a variable parameter_name already exists.
I see 2 solutions:
a) Uses { } for arguments inside current () like that:
f({p2 = 3, p3 = 5});
b) Uses a new operator :=
f(p3 := 5);
Both solutions would allows arbitrary order when calling and
would be more documentary... The only restriction would be
that when that syntax is used, parameters must be named in
at least one declaration and that there must be no conflict
between declarations (i.e. same same used at varying positions
for the same function). Note that overloadded function would
be independent so that "common" parameters need not to be at
the same position in each overload. In fact, we can even accept
some potential conflict provide that no ambiguities exists when
doing the actual call. We may also requires that all names come
from the same declaration. This would simplify diagnostic and
limit ambiguities if we try to mix name from different declarations.
I think that the new C standard (2000 ?) allows named value
for structure and array initialisation. We may be able to get
some inspiration from there.
---
[ 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 ]
Author: dross@iders.ca (Derek Ross)
Date: Fri, 24 Jan 2003 17:58:21 +0000 (UTC) Raw View
danielgutson@hotmail.com wrote:
> HOW:
> I propose the use of the 'default' keyword:
> default<type>
> in the example:
> f( default<int>, default<int>, 5); //will call f(1,2,5)
Here's an ugly, unoptimized, uninvestigated template class that will
behave something like what you're looking for. It will let you write
code such as:
func();
func(777);
func(use_default, 999);
func(777, 888, 999);
func(use_default, 888, 999);
func(777, use_default, 999);
func(777, 888, use_default);
func(use_default, use_default, use_default);
and insert the default values were needed. Attached is the template
class and code example. It compiles with gcc 2.96.
Derek Ross.
_______________________________________________________________________
#include <iostream>
using namespace std;
void const * const use_default = 0;
template <class T, T dflt_value>
class dflt
{
public:
T value;
dflt(const T& a_value)
:value(a_value)
{
//cout << __LINE__ << endl;
}
dflt(void const * const a_value)
:value(dflt_value)
{
//cout << __LINE__ << endl;
}
operator T()
{
return value;
}
};
void func(
dflt<int, 1> argA=use_default,
dflt<int, 2> argB=use_default ,
dflt<double, 3.141> argC=use_default
)
{
cout << "func:" << endl;
cout << argA << " " << argB << " " << argC << endl << endl;
}
int main()
{
func();
func(777);
func(use_default, 999);
func(777, 888, 999);
func(use_default, 888, 999);
func(777, use_default, 999);
func(777, 888, use_default);
func(use_default, use_default, use_default);
}
___________________________________________________________________
OUTPUT OF PROGRAM:
func:
1 2 3.141
func:
777 2 3.141
func:
1 999 3.141
func:
777 888 999
func:
1 888 999
func:
777 2 999
func:
777 888 3.141
func:
1 2 3.141
---
[ 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 ]
Author: pkl@mailme.dk (Peter Koch Larsen)
Date: Fri, 24 Jan 2003 20:20:32 +0000 (UTC) Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301231702.3f38b8da@posting.google.com>...
> Newgroup people:
> I would appreciate your feedback on the following proposal.
>
> DESCRIPTION:
> Given a function accepting more than one parameter with default
> values, the idea is to be able to leave the default parameters 'in the
> middle' and pass values at the end.
>
> EXAMPLE:
> void f( int p1 = 1, int p2 = 2, int p3 = 3);
>
> -> invoke f leaving the default values in p1 and p2, and specify the
> value in p3.
>
> HOW:
> I propose the use of the 'default' keyword:
> default<type>
> in the example:
> f( default<int>, default<int>, 5); //will call f(1,2,5)
>
> <type> is needed for avoiding ambiguities (if any) on overloaded
> functions.
>
> WHY: Readability and maintainability
> Right now, if you want to specify the value of a parameter, you must
> provide the values of all the preceeding params. If you want to keep
> their default values, you must explicit them and have to hand-update
> them each time they change (or use a constant or a #define). But
> keeping those values outside the function makes the [header] bigger
> and a crossed combination { function, concept } shall be kept, even if
> those values appear only once and in the context of that functions.
> And, in the usage side, by using this keyword, you are clearly saying
> "I WANT THE DEFAULT VALUE HERE".
>
> COMPATIBILITY:
> 'default' is already a keyword, but used in another context.
> Previous code works with this feature activated. 100% backward compat.
>
> Thanks!
>
> Daniel.
I do not like the idea of default parameters very much and rarely use
them except for constructors. Your problem is better solved with what
is commonly know as the (if i remember correctly) named parameter
idiom: Instead of having a bunch of parameters which often have
default parameters, you use a helper-struct (or class) with
accessor-functions. In your case:
struct fparms
{
int myp1, myp2, myp3;
fparms(): myp1(1), myp2(2), myp3(3) {}
fparms& p1(int p) {myp1 = p; return *this; }
fparms& p2(int p) {myp2 = p; return *this; }
fparms& p3(int p) {myp3 = p; return *this; }
}
your example:
> f( default<int>, default<int>, 5); //will call f(1,2,5)
would then become f(fparms().p3(5)).
Kind regards
Peter
---
[ 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 ]
Author: usenet_cpp@lehrerfamily.com (Joshua Lehrer)
Date: Fri, 24 Jan 2003 20:20:36 +0000 (UTC) Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301231702.3f38b8da@posting.google.com>...
> Newgroup people:
> I would appreciate your feedback on the following proposal.
>
> EXAMPLE:
> void f( int p1 = 1, int p2 = 2, int p3 = 3);
>
> -> invoke f leaving the default values in p1 and p2, and specify the
> value in p3.
>
> HOW:
> I propose the use of the 'default' keyword:
> default<type>
> in the example:
> f( default<int>, default<int>, 5); //will call f(1,2,5)
>
> <type> is needed for avoiding ambiguities (if any) on overloaded
> functions.
>
actually, the <type> should be optional, as it is only required if
there are overloads that need to be resolved:
void f(int p1=1, int p2=2, int p3=3);
void f(float f1=1.1, int p2=2, int p3=3);
f(default<float>,default,5);
Requiring the type to be specified dangerous, as the function provider
might change the types.
joshua lehrer
factset research systems
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Sat, 25 Jan 2003 00:28:09 +0000 (UTC) Raw View
dross@iders.ca (Derek Ross) wrote in message news:<37fY9.107896$sV3.4180309@news3.calgary.shaw.ca>...
> danielgutson@hotmail.com wrote:
> > HOW:
> > I propose the use of the 'default' keyword:
> > default<type>
> > in the example:
> > f( default<int>, default<int>, 5); //will call f(1,2,5)
>
> Here's an ugly, unoptimized, uninvestigated template class that will
> behave something like what you're looking for. It will let you write
> code such as:
Does it mean that it can be done without extensions?
Assuming so, I found the following problems in a lightly view:
(despite it is creative and is uninvestigated)
* doesn't solve overloading
* you provide a casting operator for dressing 'dflt' up as a <T> type;
you are not 'really' receiving such type, but a template wrapper
* readability: messes simple functions declarations
Daniel.
---
[ 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 ]
Author: allan_w@my-dejanews.com (Allan W)
Date: Sat, 25 Jan 2003 02:29:43 +0000 (UTC) Raw View
dross@iders.ca (Derek Ross) wrote
> Here's an ugly, unoptimized, uninvestigated template class that will
> behave something like what you're looking for. It will let you write
> code such as:
>
> func();
> func(777);
> func(use_default, 999);
> func(777, 888, 999);
> func(use_default, 888, 999);
> func(777, use_default, 999);
> func(777, 888, use_default);
> func(use_default, use_default, use_default);
I don't have a C++ compiler with me right now, but please try this
experiment for me.
func(777,0,999);
I'm suspiciious that the output will be,
777 2 999
---
[ 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 ]
Author: math@antiquark.com (Derek Ross)
Date: Sat, 25 Jan 2003 02:31:25 +0000 (UTC) Raw View
danielgutson@hotmail.com wrote:
> Does it mean that it can be done without extensions?
>
> Assuming so, I found the following problems in a lightly view:
> (despite it is creative and is uninvestigated)
It seems that it's a moot point now.
I tested it on a newer version (gcc 3.2) and it does not
work. In fact, it can not work. Template constants are not allowed
to be floating point, as the following google thread explains in more
detail:
http://groups.google.ca/groups?q=g:thl1061321500d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3b5f0445.982380%40news.libero.it
It mentions clause 14.1p7:
"A non-type template-parameter shall not be declared to have floating
point, class, or void type."
Oh well, I tried,
Derek.
---
[ 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 ]
Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Fri, 24 Jan 2003 02:17:47 +0000 (UTC) Raw View
Newgroup people:
I would appreciate your feedback on the following proposal.
DESCRIPTION:
Given a function accepting more than one parameter with default
values, the idea is to be able to leave the default parameters 'in the
middle' and pass values at the end.
EXAMPLE:
void f( int p1 = 1, int p2 = 2, int p3 = 3);
-> invoke f leaving the default values in p1 and p2, and specify the
value in p3.
HOW:
I propose the use of the 'default' keyword:
default<type>
in the example:
f( default<int>, default<int>, 5); //will call f(1,2,5)
<type> is needed for avoiding ambiguities (if any) on overloaded
functions.
WHY: Readability and maintainability
Right now, if you want to specify the value of a parameter, you must
provide the values of all the preceeding params. If you want to keep
their default values, you must explicit them and have to hand-update
them each time they change (or use a constant or a #define). But
keeping those values outside the function makes the [header] bigger
and a crossed combination { function, concept } shall be kept, even if
those values appear only once and in the context of that functions.
And, in the usage side, by using this keyword, you are clearly saying
"I WANT THE DEFAULT VALUE HERE".
COMPATIBILITY:
'default' is already a keyword, but used in another context.
Previous code works with this feature activated. 100% backward compat.
Thanks!
Daniel.
---
[ 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 ]