www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - An idea...

reply "Harvey" <hstroud ntlworld.com> writes:
Well two really.

First one, how's abouts being able to use the 'static' keyword for function
parameters, to denote that this parameter will not change on subsequent
calls to the function (from with itself only). This could be of use for
recursive functions where the (outside) caller needs to provide some info,
flag etc but once in the function it will retain the value upon further
internal calls (although just like other statics, this could get changed
internally).

recursiveFn(true);

int recursiveFn(static bit flag)
{
    recursiveFn();
}

This could produce more optimal code than functions which pass such args
back into themselves even though they might never change. Admittedly the
calling of a function with a different arg set internally than externally is
a bit strange but I guess the same could be said of funcs that are
overloaded or have defaulted params.

Would this work? Is a complete rubbish? Does anyone give two hoots?


Also, how's abouts the following syntax for functions arguments:

void fn(int a,b,c; float d,e,f,g,h; char *i,*j; AClassThatHasQuiteALongName
k,l)
{
}

The current syntax being somewhat long winded:

void fn(int a,int b,int c,float d,float e,float f,float g,float h,char
*i,char *j,AClassThatHasQuiteALongName k,AClassThatHasQuiteALongName l)
{
}

Ok passing in so many args isn't generally such a good idea but you get the
point.

Mind you, to be consistent you'd want to do the same elsewhere, so for loops
could pose a problem:

for (int i=0,n=123; float c=3.1415; i<10; ++i)
{
}

Ah well, back to the drawing board...
Nov 18 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cnjbhe$c51$1 digitaldaemon.com>, Harvey says...
Well two really.

First one, how's abouts being able to use the 'static' keyword for function
parameters, to denote that this parameter will not change on subsequent
calls to the function (from with itself only). This could be of use for
recursive functions where the (outside) caller needs to provide some info,
flag etc but once in the function it will retain the value upon further
internal calls (although just like other statics, this could get changed
internally).
Interesting idea, but I have two objections: the optimizer hints are provided in the function declaration, which I don't think is an appropriate place for that kind of thing, and it could create a maintenance headache, as it would be easy to write a function that does change its parameters but has them labeled as "static." I'd rather leave all this for the optimizer to figure out than add a new keyword for the purpose. Sean
Nov 18 2004
parent reply "Harvey" <hstroud ntlworld.com> writes:
The static keyword already exists but I guess overloading its meaning even 
further isn't ideal.

It's not just an optimisation hint, in the sense that 'register' or 'inline' 
is, it would actually operate differently. But I agree, it's better to keep 
optimisation implicit. I suppose maintenance could be a problem with this 
type of thing but then again it can be with class scope statics also - this 
could be resolved by using some prefix or such on the args to make it clear 
what we're dealing with (although not everyone likes this either).

Ah well, just thought I'd bat that one to the D community.

Harvey.


"Sean Kelly" <sean f4.ca> wrote in message 
news:cnjcsm$dtl$1 digitaldaemon.com...
 In article <cnjbhe$c51$1 digitaldaemon.com>, Harvey says...
Well two really.

First one, how's abouts being able to use the 'static' keyword for 
function
parameters, to denote that this parameter will not change on subsequent
calls to the function (from with itself only). This could be of use for
recursive functions where the (outside) caller needs to provide some info,
flag etc but once in the function it will retain the value upon further
internal calls (although just like other statics, this could get changed
internally).
Interesting idea, but I have two objections: the optimizer hints are provided in the function declaration, which I don't think is an appropriate place for that kind of thing, and it could create a maintenance headache, as it would be easy to write a function that does change its parameters but has them labeled as "static." I'd rather leave all this for the optimizer to figure out than add a new keyword for the purpose. Sean
Nov 18 2004
parent Matthias Becker <Matthias_member pathlink.com> writes:
It's not just an optimisation hint, in the sense that 'register' or 'inline' 
is
You aren't refering to C++'s inline, right? Because there it has a totaly different use. How to define (not declare) a function in a header without 'inline'? // foo.hpp inline int bar () // fine { return 42; } int baz () // bang! { return 42; } // x.cpp #include "foo.hpp" // y.cpp #include "foo.hpp" -- Matthias Becker
Nov 19 2004
prev sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Harvey" <hstroud ntlworld.com> skrev i en meddelelse 
news:cnjbhe$c51$1 digitaldaemon.com...
 First one, how's abouts being able to use the 'static' keyword for 
 function
 parameters, to denote that this parameter will not change on subsequent
 calls to the function (from with itself only).
That's not 'static' to me - that is 'const'. Regards, Martin
Nov 18 2004
next sibling parent "Harvey" <hstroud ntlworld.com> writes:
Not quite, I think I mentioned that the argument could be changed 
internally, much as normal arguments can be (unless you qualified it with 
const, but I think D's done away with this for function params anyhow?). Any 
change of the argument would be propagated to recursive invocations from 
within the same function.


"Martin M. Pedersen" <martin moeller-pedersen.dk> wrote in message 
news:cnjjtv$mpg$1 digitaldaemon.com...
 "Harvey" <hstroud ntlworld.com> skrev i en meddelelse 
 news:cnjbhe$c51$1 digitaldaemon.com...
 First one, how's abouts being able to use the 'static' keyword for 
 function
 parameters, to denote that this parameter will not change on subsequent
 calls to the function (from with itself only).
That's not 'static' to me - that is 'const'. Regards, Martin
Nov 19 2004
prev sibling parent reply Luke D <jikmo hotpop.com> writes:
Martin M. Pedersen wrote:
 "Harvey" <hstroud ntlworld.com> skrev i en meddelelse 
 news:cnjbhe$c51$1 digitaldaemon.com...
 
First one, how's abouts being able to use the 'static' keyword for 
function
parameters, to denote that this parameter will not change on subsequent
calls to the function (from with itself only).
That's not 'static' to me - that is 'const'. Regards, Martin
That definitely seems like static to me. He said that you can change the value of a static variable within the function, and the variable is not distroyed until the function completely exits (if it needs to be destroyed at all), so it's definately more like static than const. It sounds very interesting. You could write code like this: int doSomething(static int x) { ++x; doSomething(); } The same code in C++ would have to be written like this. class foo { static int x; int doSomething(int x); private: int doSomething(); } int foo::doSomething(int x) { this->x = ++x; doSomething(); } int foo::doSomething() { ++x; doSomething(); } Of course the code isn't really equivalent. The C++ version makes two different functions and stores the value of x differently. The D one just does an omptimization that keeps the variable in memory for subsuqent function calls. In the way Harvey suggests it, the D one forces the caller to use doSomething(int x) outside of the function doSomething. In the C++ version, within the class, you could accidentally call doSomething(), which may not be desirable. Also of course, in the C++ version, you'd need to place the function in a class or something. This use of the static keyword is consistent with the other uses. It's really the same as a static variable in a function except that it's with a parameter and it slightly changes the calling method. Of course, I just realized that the change in calling method might make it a deterent from being implemented. The code may end up having to be compiled as two seperate functions anyway.
Nov 19 2004
parent reply "Harvey" <hstroud ntlworld.com> writes:
You've hit the nail on the head. What this all boils down to is so called 
semantic sugar for statics with function scope. The C++ solution you gave is 
cumbersome (as you intended to show) with a class scope static variable 
having to be declared (then defined elsewhere for C++), and then two 
functions needing to be created in order to avoid the overhead of passing in 
the argument for subsequent (recursive) calls. Whether the compiler would do 
this behind the scenes isn't the problem, it's that this sort of 
implementation issue can't be more transparent to the programmer.

It would bother me that the calling convention for the function inside of 
itself differs from that externally (especially if arguments just 
disappeared and so wouldn't match up with the function's prototype, very 
confusing) but perhaps the solution would be to force the programmer to 
place all statics of this type at the end of the parameter list - in this 
way it would be consistent with default arguments whose values may be 
omitted which seems to cause no problems.

Btw, there's nothing to stop the function calling itself and specifying its 
static argument values, this would just be a convenient way to reassign a 
new value to the static before actually doing the recursive call - again, 
consistent with default argument behaviour.

Cheers,
Harvey.


"Luke D" <jikmo hotpop.com> wrote in message 
news:cnm440$1fn6$1 digitaldaemon.com...
 Martin M. Pedersen wrote:
 "Harvey" <hstroud ntlworld.com> skrev i en meddelelse 
 news:cnjbhe$c51$1 digitaldaemon.com...

First one, how's abouts being able to use the 'static' keyword for 
function
parameters, to denote that this parameter will not change on subsequent
calls to the function (from with itself only).
That's not 'static' to me - that is 'const'. Regards, Martin
That definitely seems like static to me. He said that you can change the value of a static variable within the function, and the variable is not distroyed until the function completely exits (if it needs to be destroyed at all), so it's definately more like static than const. It sounds very interesting. You could write code like this: int doSomething(static int x) { ++x; doSomething(); } The same code in C++ would have to be written like this. class foo { static int x; int doSomething(int x); private: int doSomething(); } int foo::doSomething(int x) { this->x = ++x; doSomething(); } int foo::doSomething() { ++x; doSomething(); } Of course the code isn't really equivalent. The C++ version makes two different functions and stores the value of x differently. The D one just does an omptimization that keeps the variable in memory for subsuqent function calls. In the way Harvey suggests it, the D one forces the caller to use doSomething(int x) outside of the function doSomething. In the C++ version, within the class, you could accidentally call doSomething(), which may not be desirable. Also of course, in the C++ version, you'd need to place the function in a class or something. This use of the static keyword is consistent with the other uses. It's really the same as a static variable in a function except that it's with a parameter and it slightly changes the calling method. Of course, I just realized that the change in calling method might make it a deterent from being implemented. The code may end up having to be compiled as two seperate functions anyway.
Nov 20 2004
parent "Harvey" <hstroud ntlworld.com> writes:
Duh, that should have read 'syntactic sugar', I'm not sure if the other kind 
exists.

"Harvey" <hstroud ntlworld.com> wrote in message 
news:cno181$17s7$1 digitaldaemon.com...
 You've hit the nail on the head. What this all boils down to is so called 
 semantic sugar for statics with function scope. The C++ solution you gave 
 is cumbersome (as you intended to show) with a class scope static variable 
 having to be declared (then defined elsewhere for C++), and then two 
 functions needing to be created in order to avoid the overhead of passing 
 in the argument for subsequent (recursive) calls. Whether the compiler 
 would do this behind the scenes isn't the problem, it's that this sort of 
 implementation issue can't be more transparent to the programmer.

 It would bother me that the calling convention for the function inside of 
 itself differs from that externally (especially if arguments just 
 disappeared and so wouldn't match up with the function's prototype, very 
 confusing) but perhaps the solution would be to force the programmer to 
 place all statics of this type at the end of the parameter list - in this 
 way it would be consistent with default arguments whose values may be 
 omitted which seems to cause no problems.

 Btw, there's nothing to stop the function calling itself and specifying 
 its static argument values, this would just be a convenient way to 
 reassign a new value to the static before actually doing the recursive 
 call - again, consistent with default argument behaviour.

 Cheers,
 Harvey.


 "Luke D" <jikmo hotpop.com> wrote in message 
 news:cnm440$1fn6$1 digitaldaemon.com...
 Martin M. Pedersen wrote:
 "Harvey" <hstroud ntlworld.com> skrev i en meddelelse 
 news:cnjbhe$c51$1 digitaldaemon.com...

First one, how's abouts being able to use the 'static' keyword for 
function
parameters, to denote that this parameter will not change on subsequent
calls to the function (from with itself only).
That's not 'static' to me - that is 'const'. Regards, Martin
That definitely seems like static to me. He said that you can change the value of a static variable within the function, and the variable is not distroyed until the function completely exits (if it needs to be destroyed at all), so it's definately more like static than const. It sounds very interesting. You could write code like this: int doSomething(static int x) { ++x; doSomething(); } The same code in C++ would have to be written like this. class foo { static int x; int doSomething(int x); private: int doSomething(); } int foo::doSomething(int x) { this->x = ++x; doSomething(); } int foo::doSomething() { ++x; doSomething(); } Of course the code isn't really equivalent. The C++ version makes two different functions and stores the value of x differently. The D one just does an omptimization that keeps the variable in memory for subsuqent function calls. In the way Harvey suggests it, the D one forces the caller to use doSomething(int x) outside of the function doSomething. In the C++ version, within the class, you could accidentally call doSomething(), which may not be desirable. Also of course, in the C++ version, you'd need to place the function in a class or something. This use of the static keyword is consistent with the other uses. It's really the same as a static variable in a function except that it's with a parameter and it slightly changes the calling method. Of course, I just realized that the change in calling method might make it a deterent from being implemented. The code may end up having to be compiled as two seperate functions anyway.
Nov 20 2004