www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - static function and access frame

reply Alex <sascha.orlov gmail.com> writes:
Ok, I'm quite sure, I overlooked something.

First version, working

[code]
void main()
{
	auto s = S();
	auto t = T!s();
	t.fun;
}
struct S { void fun(){} }
struct T(alias s){ auto fun() { s.fun; } }
[/code]

Now, the fun method of struct T has to become static and the 
problems begin:
Error: static function app.main.T!(s).T.fun cannot access frame 
of function D main

Ok, found somewhere, that it could help to move the static 
function outside of the struct and tried this.

Second version, not working

[code]
void main()
{
	auto s = S();
	auto t = T!s();
	fun!(typeof(t));
}
struct S { void fun(){} }
struct T(alias s){  }
auto fun(T : T!s, alias s)() { s.fun; }
[/code]

 From my point of view, the second version is the most promising 
one, if there are problems with the first one. However, I didn't 
figured it out, how to match the alias template parameter to be 
able to call it from within the function fun (which is now at 
module level) directly.

Ok. Now, trying to find a solution I wrote the third version, 
working

[code]
void main()
{
	auto s = S();
	auto t = T!s();
	fun(t);
}
struct S { void fun(){} }
struct T(alias s){ auto ss(){return s; } }
auto fun(T)(T t) { t.ss.fun; }
[/code]

Is this meant to be the right way? I mean, ok, if so, then, the 
way from different frames is a little bit verbose, but working. 
However, the fun method is meant to not use a specific object 
from the time point, where it was marked static. Why should I 
pass an instance to it?
Jan 23
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 01/23/2018 01:51 PM, Alex wrote:
 Ok, I'm quite sure, I overlooked something.

 First version, working

 [code]
 void main()
 {
      auto s = S();
      auto t = T!s();
      t.fun;
 }
 struct S { void fun(){} }
 struct T(alias s){ auto fun() { s.fun; } }
 [/code]

 Now, the fun method of struct T has to become static and the problems
 begin:
 Error: static function app.main.T!(s).T.fun cannot access frame of
 function D main
Good news: Works at least with 2.078 as it should: void main() { auto s = S(); auto t = T!s(); t.fun; } struct S { static void fun(){} } struct T(alias s){ auto fun() { s.fun; } } Ali
Jan 23
next sibling parent Alex <sascha.orlov gmail.com> writes:
On Tuesday, 23 January 2018 at 22:33:31 UTC, Ali Çehreli wrote:
 On 01/23/2018 01:51 PM, Alex wrote:
 Ok, I'm quite sure, I overlooked something.

 First version, working

 [code]
 void main()
 {
      auto s = S();
      auto t = T!s();
      t.fun;
 }
 struct S { void fun(){} }
 struct T(alias s){ auto fun() { s.fun; } }
 [/code]

 Now, the fun method of struct T has to become static and the
problems
 begin:
 Error: static function app.main.T!(s).T.fun cannot access
frame of
 function D main
Good news: Works at least with 2.078 as it should: void main() { auto s = S(); auto t = T!s(); t.fun; } struct S { static void fun(){} } struct T(alias s){ auto fun() { s.fun; } } Ali
the other fun is meant to be static :) so, the fun inside T.
Jan 23
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/23/18 5:33 PM, Ali Çehreli wrote:
 On 01/23/2018 01:51 PM, Alex wrote:
  > Ok, I'm quite sure, I overlooked something.
  >
  > First version, working
  >
  > [code]
  > void main()
  > {
  >      auto s = S();
  >      auto t = T!s();
  >      t.fun;
  > }
  > struct S { void fun(){} }
  > struct T(alias s){ auto fun() { s.fun; } }
  > [/code]
  >
  > Now, the fun method of struct T has to become static and the problems
  > begin:
  > Error: static function app.main.T!(s).T.fun cannot access frame of
  > function D main
 
 Good news: Works at least with 2.078 as it should:
 
 void main()
 {
      auto s = S();
      auto t = T!s();
      t.fun;
 }
 struct S { static void fun(){} }
 struct T(alias s){ auto fun() { s.fun; } }
 
 Ali
 
No: void main() { auto s = S(); auto t = T!s(); t.fun; } struct S { void fun(){} } struct T(alias s){ static fun() { s.fun; } } Fails in 2.078. I don't know the reason. You would think that accessing s would be relative to T.fun's stack frame, and have nothing to do with an instance of T. I would file a bug, and see what the compiler devs say. -Steve
Jan 23
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/23/18 5:52 PM, Steven Schveighoffer wrote:
 I don't know the reason. You would think that accessing s would be 
 relative to T.fun's stack frame, and have nothing to do with an instance 
 of T.
 
using -vcg-ast gives a hint: https://run.dlang.io/is/MZHPTY Note that the T!(s) struct has a void *this member, that is probably the main stack frame pointer. -Steve
Jan 23
parent reply Alex <sascha.orlov gmail.com> writes:
On Tuesday, 23 January 2018 at 22:59:31 UTC, Steven Schveighoffer 
wrote:
 On 1/23/18 5:52 PM, Steven Schveighoffer wrote:
 I don't know the reason. You would think that accessing s 
 would be relative to T.fun's stack frame, and have nothing to 
 do with an instance of T.
 
using -vcg-ast gives a hint: https://run.dlang.io/is/MZHPTY Note that the T!(s) struct has a void *this member, that is probably the main stack frame pointer. -Steve
So, if change the fun to static, it cannot pickup the pointer and therefore can't call anything of the aliased object. If I get it right... cool option, by the way... didn't know anything about it. What does -ast do?
Jan 23
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/23/18 6:08 PM, Alex wrote:
 On Tuesday, 23 January 2018 at 22:59:31 UTC, Steven Schveighoffer wrote:
 On 1/23/18 5:52 PM, Steven Schveighoffer wrote:
 I don't know the reason. You would think that accessing s would be 
 relative to T.fun's stack frame, and have nothing to do with an 
 instance of T.
using -vcg-ast gives a hint: https://run.dlang.io/is/MZHPTY Note that the T!(s) struct has a void *this member, that is probably the main stack frame pointer.
So, if change the fun to static, it cannot pickup the pointer and therefore can't call anything of the aliased object. If I get it right...
I think so. But this is a guess, as the generated call clearly never uses that 'this' member. Interesting to me that it calls that member 'this', when 'this' is already defined!
 
 cool option, by the way... didn't know anything about it. What does -ast 
 do?
-vcg-ast means take the generated AST before optimization (I think), and output a d-source-like file (called file.d.cg) that shows the representation. Super useful when you are trying to figure out what the compiler does to your code. It only happens if compilation succeeds. -ast, I don't think does anything, but not sure if that's what your question was. The reason you don't know anything about it is because it's a debugging option and not documented :) At least, that's what I was told... If you click on the AST button on run.dlang.io, you get the same thing. -Steve
Jan 23
parent Alex <sascha.orlov gmail.com> writes:
On Tuesday, 23 January 2018 at 23:22:09 UTC, Steven Schveighoffer 
wrote:
 
 So, if change the fun to static, it cannot pickup the pointer 
 and therefore can't call anything of the aliased object. If I 
 get it right...
I think so. But this is a guess, as the generated call clearly never uses that 'this' member. Interesting to me that it calls that member 'this', when 'this' is already defined!
Hmm... yes, I see...
 
 cool option, by the way... didn't know anything about it. What 
 does -ast do?
-vcg-ast means take the generated AST before optimization (I think), and output a d-source-like file (called file.d.cg) that shows the representation. Super useful when you are trying to figure out what the compiler does to your code. It only happens if compilation succeeds. -ast, I don't think does anything, but not sure if that's what your question was. The reason you don't know anything about it is because it's a debugging option and not documented :) At least, that's what I was told...
:)
 If you click on the AST button on run.dlang.io, you get the 
 same thing.
bug filed https://issues.dlang.org/show_bug.cgi?id=18289 Thanks a lot.
Jan 23
prev sibling parent Alex <sascha.orlov gmail.com> writes:
On Tuesday, 23 January 2018 at 22:52:47 UTC, Steven Schveighoffer 
wrote:
 No:

 void main()
 {
     auto s = S();
     auto t = T!s();
     t.fun;
 }
 struct S { void fun(){} }
 struct T(alias s){ static fun() { s.fun; } }

 Fails in 2.078.

 I don't know the reason. You would think that accessing s would 
 be relative to T.fun's stack frame, and have nothing to do with 
 an instance of T.
Right. This was the intention.
 I would file a bug, and see what the compiler devs say.
ok, thanks.
Jan 23