Re: getting member functions of a struct and Error: identifier expected following ., not this
On Tuesday, 23 January 2018 at 00:00:38 UTC, aliak wrote: Hi, I'm trying to get a list of only member functions of a struct. I've found that if you do not declare a struct as static inside a scope, then there's a hidden "this" member as part of the struct. Can someone explain the logic there? The struct defined inside a scope can mention variables defined in that scope (e.g. use them in its methods), so it needs a pointer to the place where those closed variables live. That's the main difference between such struct and a static one that cannot use those scope vars. I guess you're seeing that pointer as additional member. As for static foreach, when you write a simple foreach over some compile-time tuple (like in this case), it's unrolled at compile time similarly to "static foreach", the main difference is whether it creates a sub-scope for the loop body or not. "foreach" creates one, "static foreach" doesn't.
Re: static weirdness
On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
wrote:
On Wednesday, January 24, 2018 01:48:45 Alex via
Digitalmars-d-learn wrote:
the story of
https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org continues
How can this be?
void main()
{
auto s = S();
auto t = T!s();
assert(typeof(t).dummy == null);
assert(t.dummy == null);
t.foo;
}
struct S
{
auto fun()
{
return 42;
}
}
struct T(alias stats)
{
static typeof(stats)* dummy; // line 21
static auto foo()
{
assert(dummy == null); // line 24
assert(dummy.fun == 42); //line 25
}
}
I thought, if I don't initialize a pointer, like the one in
line
21 (I assert this by the check in line 24) I can't use it line
line 25.
However, I can...
That has nothing to do with static. That has to do with the
fact that S.fun
is non-virtual (so there's no need to dereference the pointer
to call it),
and fun doesn't access any members, so it doesn't need to
dereference the
this pointer internally either. And since the pointer is never
dereferenced,
it doesn't matter that it's null.
That's cool, by the way :)
You'd get the same behavior if you used
a non-static S.
On a side note, if you're checking for null, it's better to use
the is operator rather than ==. For strings, there's a semantic
difference, so it really matters. For classes, it avoids
calling the free function opEquals (which will give the same
result, but it's a pointless function call when you could just
use is and avoid the call). For pointers, it matters that much
less, but since it does matter in the other cases (especially
strings), it's a good habit to get into just using is null
instead of == null.
Thanks.
Re: static weirdness
On Wednesday, January 24, 2018 01:48:45 Alex via Digitalmars-d-learn wrote:
> the story of
> https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org
> continues
>
> How can this be?
>
> void main()
> {
> auto s = S();
> auto t = T!s();
> assert(typeof(t).dummy == null);
> assert(t.dummy == null);
> t.foo;
>
> }
>
> struct S
> {
> auto fun()
> {
> return 42;
> }
> }
>
> struct T(alias stats)
> {
> static typeof(stats)* dummy; // line 21
> static auto foo()
> {
> assert(dummy == null); // line 24
> assert(dummy.fun == 42); //line 25
> }
> }
>
> I thought, if I don't initialize a pointer, like the one in line
> 21 (I assert this by the check in line 24) I can't use it line
> line 25.
> However, I can...
That has nothing to do with static. That has to do with the fact that S.fun
is non-virtual (so there's no need to dereference the pointer to call it),
and fun doesn't access any members, so it doesn't need to dereference the
this pointer internally either. And since the pointer is never dereferenced,
it doesn't matter that it's null. You'd get the same behavior if you used
a non-static S.
On a side note, if you're checking for null, it's better to use the is
operator rather than ==. For strings, there's a semantic difference, so it
really matters. For classes, it avoids calling the free function opEquals
(which will give the same result, but it's a pointless function call when
you could just use is and avoid the call). For pointers, it matters that
much less, but since it does matter in the other cases (especially strings),
it's a good habit to get into just using is null instead of == null.
- Jonathan M Davis
Re: static weirdness
On Wednesday, 24 January 2018 at 01:48:45 UTC, Alex wrote: Ah... I figured it out. For using the function of S, an object does not have to exist... And in case I would return a member from S, there is a segmentation violation, as expected. So, everything is ok. Sorry for noise.
static weirdness
the story of
https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org
continues
How can this be?
void main()
{
auto s = S();
auto t = T!s();
assert(typeof(t).dummy == null);
assert(t.dummy == null);
t.foo;
}
struct S
{
auto fun()
{
return 42;
}
}
struct T(alias stats)
{
static typeof(stats)* dummy; // line 21
static auto foo()
{
assert(dummy == null); // line 24
assert(dummy.fun == 42); //line 25
}
}
I thought, if I don't initialize a pointer, like the one in line
21 (I assert this by the check in line 24) I can't use it line
line 25.
However, I can...
Re: static function and access frame
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.
Re: static function and access frame
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
Re: static function and access frame
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?
Re: static function and access frame
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
Re: static function and access frame
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.
Re: static function and access frame
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
Re: static function and access frame
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.
Re: static function and access frame
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
static function and access frame
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?
Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?
On Monday, 22 January 2018 at 19:38:45 UTC, John Gabriele wrote: On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe wrote: On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote: Maybe it's due to historical reasons. It's actually "future" reasons... the /phobos is the original one, and /library was supposed to replace it, but now many years later, /library is still kinda neglected and they both just exist. What's needed to remove the "/phobos" one? Is it a decision from on-high, or is there a lot of editing of hardcoded links required? This discussion and the referenced news group thread should give insights: https://github.com/dlang/dlang.org/pull/1526 BTW the fix for your issue is here: https://github.com/dlang/phobos/pull/6055
