> later the developer of Answer realize that 42 isn't the answer !
> maybe it's 43 ?
> so he rewrite
> class A
> {
>     void myfunc(int i=43) {}
> }
>
> and you upgrade your work to use this dll. you don't need to compile
again,
> it's a dll !


Well, here the interface of a library has changed!
So you *do* need to recompile. (Or otherwise get
the change propagated to the client stuff; obviously,
if a system silently swallows an interface conflict,
that stuff is simply broken.)

Sab

"Sab" <sab@neuropolis.org> wrote in message news:arok6l$147i$1@digitaldaemon.com...
> > later the developer of Answer realize that 42 isn't the answer !
> > maybe it's 43 ?
> > so he rewrite
> > class A
> > {
> >     void myfunc(int i=43) {}
> > }
> >
> > and you upgrade your work to use this dll. you don't need to compile
> again,
> > it's a dll !
>
>
> Well, here the interface of a library has changed!
> So you *do* need to recompile. (Or otherwise get
> the change propagated to the client stuff; obviously,
> if a system silently swallows an interface conflict,
> that stuff is simply broken.)
>
> Sab


I agree. Default parameter is part of the interface of the function. And if there is no checking for interface conficts, you can easily cause other errors:

class A
{
  void myfunc(int i);
}

later changed to

class A
{
  void myfunc(double i);
}

Now do you need to recompile the client side??

Please note that C++ already takes care of this. Since default parameters are in the header files, changing them causes the client side to recompile.

Do you know any other reasons to label default parameters evil?

Yours,
Sandor

[snip]
> 
> Do you know any other reasons to label default parameters evil?
> 
> Yours,
> Sandor
> 
> 

Here's another example why default parameters are evil, that I saw on a C++ web site.


#include <stdio.h>
struct SomeBaseClass
{
   virtual void func(char* msg="Default parameters are EVIL.")
   {
      printf("%s\n", msg);
   }
};

struct SomeClass : public SomeBaseClass
{
   virtual void func(char* msg="Default parameters would be great for D.")
   {
      SomeBaseClass::func(msg);
   }
};

int main(char*, char*[])
{
   SomeBaseClass* p=new SomeClass();
   p->func();  // print "Default parameters would be great for D."
   return 0;
}

The output of this program is "Default parameters are EVIL." !!
It is not "Default parameters would be great for D." as one expects at the
first glance.

If this code is translated to D (with default parameters added), the same BUG will exist.



Farmer

I must remember that example,
lack of default params in Java annoyed me for the first few weeks of Java
programming, then you get used to putting in a few more methods;

it could be argued that the compile could create the methods for you rather
than "defaulting" the params
so the D (with "predefined" params) would be
 class SomeBaseClass
 {
    void func(char[] msg="Default parameters are EVIL.")
    {
       printf("%.*s\n", msg);
    }
 };

class SomeClass : public SomeBaseClass
{
    void func(char[] msg="Default parameters in D would could be better that
C++." )
    {
        SomeBaseClass::func(msg);
    }
};

which would create (in effect)

 class SomeBaseClass
 {
    void func()
    {
       func("Default parameters are EVIL.")
    }
    void func(char[] msg)
    {
       printf("%.*s\n", msg);
    }
 };

class SomeClass : public SomeBaseClass
{
    void func()
    {
        func("Default parameters would be great for D.");
    }
    void func(char[] msg="Default parameters in D would could be better that
C++.")
    {
        SomeBaseClass::func(msg);
    }
};

so

int main( char[][] )
{
    SomeBaseClass p = new SomeClass();
    p.func();  // will now print print "Default parameters in D would could
be better that C++."
    return 0;
}

obviously it's the same as C++ that only the end params can be "predefined"
class c {
int func( int a, int b =1, int c) {.. } // this is not allowed. 'c' must be
"predefined" too if you want to predefine 'b'
}

so
class c {
int func( int a, int b =1, int c = 2 ) {.. }
}
would expand to

class c {
int func( int a, int b, int c ) {.. }
int func( int a, int b, ) { return func(a, b, 2); }
int func( int a, ) { return func(a, 1, 2); }
}

that's not to say I agree with default/predefined params, but offer a slighty less error prone solution if you must have them.

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns9300BD258659itsFarmer@63.105.9.61...
> [snip]
> >
> > Do you know any other reasons to label default parameters evil?
> >
> > Yours,
> > Sandor
> >
> >
>
> Here's another example why default parameters are evil, that I saw on a
C++
> web site.
>
>
> #include <stdio.h>
> struct SomeBaseClass
> {
>    virtual void func(char* msg="Default parameters are EVIL.")
>    {
>       printf("%s\n", msg);
>    }
> };
>
> struct SomeClass : public SomeBaseClass
> {
>    virtual void func(char* msg="Default parameters would be great for D.")
>    {
>       SomeBaseClass::func(msg);
>    }
> };
>
> int main(char*, char*[])
> {
>    SomeBaseClass* p=new SomeClass();
>    p->func();  // print "Default parameters would be great for D."
>    return 0;
> }
>
> The output of this program is "Default parameters are EVIL." !!
> It is not "Default parameters would be great for D." as one expects at the
> first glance.
>
> If this code is translated to D (with default parameters added), the same
> BUG will exist.
>
>
>
> Farmer