Re: How to get only the field name from an alias?
On Tuesday, 21 February 2023 at 03:13:38 UTC, ryuukk_ wrote:
I'm not sure what the solution is for your specific question,
but there is some alternative way you could do: (no longer need
function on your struct)
[...]
This is super neat, but the order of the fields will have to be
frozen, and I won't be able to do something like this:
sz.processField!hasData();
if (this.hasData)
{
sz.processField!data();
}
Unless I can mark versions and dependencies with attributes and
analyse them somehow.
The Deserializer shares the same interface by the way.
Re: How to get only the field name from an alias?
I'm not sure what the solution is for your specific question, but
there is some alternative way you could do: (no longer need
function on your struct)
I tried to comment the lines, even thought i'm not sure i
remember everything correctly, but it compiles :p
More info: https://dlang.org/spec/traits.html
```D
import std.stdio;
class Serializer
{
void process(string k, ref int v)
{
writeln("serializing int ", k, ": ", v);
}
void process(string k, ref long v)
{
writeln("serializing long ", k, ": ", v);
}
void process(U)(ref U v) if (is(U == struct))
{
// get all members from U
static foreach (member; __traits(allMembers, U))
{
// get attributes from U.member
static foreach (attr; __traits(getAttributes,
__traits(getMember, U, member)))
{
// is the attribute OldName
static if (is(typeof(attr) == OldName))
{
// the name you put in OldName attribute
string oldName = attr.name;
auto value = __traits(getMember, v, member);
writeln("field: ", member);
writeln("oldname: ", oldName);
writeln("value: ", value);
}
}
}
}
}
struct OldName
{
string name;
}
struct Serializable
{
@OldName("ifield")
int intField;
}
void main()
{
import std.stdio;
import std.traits;
import core.internal.traits;
Serializable v;
auto sz = new Serializer();
sz.process(v);
}
```
How to get only the field name from an alias?
I'm experimenting on a serializer design. The idea includes a
shorthand for processing a field and its attributes with an
alias. But I'm not sure whether I can gather enough information
from it, such as the name of the field. apparently F.stringof
stands for "this.\" in this context. So how can I get
only the field's name? And is it possible to check if F is a
field? -- In a well defined manner.
import std.stdio;
void processField(alias F)(Serializer sz) // is field?
{
writeln("attrs ", __traits(getAttributes, F)); // OK
writeln(F.stringof); // "this.intField"
sz.process(F.stringof, F); // "serializing int this.intField: 0"
}
class Serializer
{
void process(string k, ref int v)
{
writeln("serializing int ", k, ": ", v);
}
void process(string k, ref long v)
{
writeln("serializing long ", k, ": ", v);
}
void process(U)(ref U v) if (is(U == struct))
{
v.serialize(this);
}
}
struct OldName
{
string name;
}
struct Serializable
{
@OldName("ifield")
int intField;
void serialize(Serializer sz)
{
sz.processField!intField();
}
}
void main()
{
import std.stdio;
import std.traits;
import core.internal.traits;
Serializable v;
auto sz = new Serializer();
sz.process(v);
}
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 20 February 2023 at 07:11:49 UTC, Mike Parker wrote: On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature wrote: There have now been three pages produced by three people all agreeing with each other. At what point does it start being spam? Yes, it's all just noise now. Let's end it here. Further posts in this thread will be deleted. oy vey, shut it down fucking idiot
Re: Lazy and GC Allocations
On Monday, 20 February 2023 at 19:58:32 UTC, Steven Schveighoffer wrote: On 2/20/23 1:50 PM, Etienne wrote: On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote: See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't? The opposite, the delegate doesn't force a closure, and so when the variable goes out of scope, memory corruption ensues. I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently It shouldn't. Now, lazy can't be `@nogc` (because that's just what the compiler dictates), but it won't actually *use* the GC if you don't allocate in the function call. I just tested and you can use lazy parameters with betterC. -Steve The @nogc issue might be what might be why it didn't work for me. I use it because it's easier to work with betterC but perhaps I should avoid writing @nogc code altogether Thanks for the info! Etienne
Re: Dub is not finding the dynamic link library MSVCR120.dll...
On Monday, 20 February 2023 at 01:04:25 UTC, Mike Parker wrote: Any error about a missing DLL is a run-time error that's unrelated to dub or the compiler. Normally, for end users, a missing MSVC runtime DLL means you have to install the MSVC Redistributable package. This version of the DLL you're missing is from MSVC 2013, so that's the version of the package you'd need. However, I wonder what's causing the problem in the first place. Do you have Visual Studio installed, or are you using the out-of-the-box libraries and linker that ship with DMD? Thanks for setting me straight. I'm trying to make D application that you can just download and start up. Hopefully with having to install D first or the DLL. I see that msvc120.dll is in the same directory as dmd.exe.and dub.exe.
Re: Lazy and GC Allocations
On 2/20/23 1:50 PM, Etienne wrote: On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote: See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't? The opposite, the delegate doesn't force a closure, and so when the variable goes out of scope, memory corruption ensues. I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently It shouldn't. Now, lazy can't be `@nogc` (because that's just what the compiler dictates), but it won't actually *use* the GC if you don't allocate in the function call. I just tested and you can use lazy parameters with betterC. -Steve
Re: Lazy and GC Allocations
On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote: See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627 -Steve So, according to this bug report, the implementation is allocating a closure on the GC even though the spec says it shouldn't? I've been writing some betterC and the lazy parameter was prohibited because it allocates on the GC, so I'm wondering what the situation is currently Etienne
