Function overloading and function with default parms

samsam598 · Post by **samsam598** » Mon Aug 13, 2012 9:33 pm

Greetings!

Just for fun,I would like to know why don't allow eC to support such two features,that is:

 
 
//1-->
int cal(int a,int b){}
string cal(string a,string b){}
 
 //2-->
int method(int a ,string b="hello"){}

And what's the disadvantage if we make the current String to class so that we could call class method such as

Code: Select all

 
String str{"Hello world!"};
int idx=str.find("ello");
String substr=str.substr(0,3);
...

Cheers,
Sam

Post by **jerome** » Mon Aug 13, 2012 10:18 pm

Hi Sam,

1 --> Function overloading -- I have something against it, for the sake of clarity.

When I'm in function CalString() (e.g. while debugging), I know exactly where I am.

If there are 2 functions named 'cal', to me, that is extremely confusing.

Sorry for those who like overloading =) I hate it.

2 --> Default parameters...

I don't have such a strong opinion against it as overloading, but sometimes it can be confusing as to whether a function has default parameters or not, or what the default parameters are... I agree it can be useful though, especially if parameters can be named on the arguments line, like eC instance member initializers (which I don't think C++ supports, but maybe Python does?)

Classes have default members/property values, which can sometimes achieve a similar goal... You can set values on an instance and then run a method with no (or less) arguments:

Code: Select all

class MyClass
{
   int a;
   string b;
   b = "hello";
 
   int method()
   {
   }
}
 
MyClass object { a = 20 }; or MyClass object { a = 20, b = "Bye" }; 
object.method();

If there's a feature you would like to see in the compiler, feel free to report an issue on mantis
( http://ecere.com/mantis ) with Severity set to Feature, Category set to Compiler, and we can review it when the time comes...

Right now however our resources are spread thin already with many things, so it's unlikely we'll be working on implementing such a feature soon... The current focus is ironing out bugs and support the Android platform!

About a String class, we still have a lot of work to do to make it easy to handle strings in eC.
At the moment it's pretty much just like in C + a few utility functions.
There is a tracked issue http://ecere.com/mantis/view.php?id=177 for which this is the focus.
It is planned in the future, currently assigned to 0.46 milestone ( https://launchpad.net/ecere/+milestone/0.46 ), but we'll see when we get to it...
Hopefully sooner than later!

In the meantime, you could use your own string class:

Code: Select all

class SamString : String
{
   SamString substr(int start, int n)
   {
      int len = this ? strlen(this) : 0;
      String s = null;
      if(start + n > len) n = Max(0, len - start);
      if(n > 0)
      {
         s = new char[n+1];
         memcpy(s, ((char *)this) + start, n);
         s[n] = 0;
      }
      else
         s = CopyString("");
      return s;
   }
 
   int find(String s)
   {
      String f = strstr(this, s);
      return f ? ((char *)f - (char *)this) : -1;
   }
}

Then you can do:

Code: Select all

         SamString str = "Hello world!";
         int idx=str.find("ello");
         String substr=str.substr(0,3);
         PrintLn("idx = ", idx, ", substr = ", substr);
         delete substr;

You won't be able to do String str{"Hello world!"} yet, with the curly bracket instantiation syntax, but that syntax is planned for our proper eC string solution

Take a look at the issue on Mantis for other ideas and discussion on what the string class should be...

Note that major issues which makes it tricky to decide how the String class will work is the memory management, and whether to represent it as a char * only or as an object which will contain members...

Hope this helps!

Thanks for the suggestions!!

All the best,

Jerome