Re: Class qualifier vs struct qualifier
On Thursday, 14 June 2018 at 17:07:09 UTC, Jonathan M Davis wrote:
Sure, it would save you a little bit of typing when you do
something like
auto foo = new Foo;
if makes it immutable for you, but it's at the cost of code
clarity.
Why should it even?
Isn't
immutable class C
{
int a;
}
the same as
class C
{
immutable
{
int a;
}
}
?
Does the following code clarify why an instance if immutable
struct HAS to be immutable while an instance of class does not
have to be immutable??
immutable struct S {}
immutable class C {}
void main()
{
S sa = S();
pragma(msg, typeof(sa)); // immutable(S)
S sb = S();
// sa = sb; // Error: cannot modify immutable expression sa
C ca = new C();
pragma(msg, typeof(ca)); // C
C cb = new C();
ca = cb; // works
}
Then the question would rather be why
S s = S(); // immutable(S)
does what it seems to be doing..?
Re: foreach DFS/BFS for tree data-structure?
On Thursday, 14 June 2018 at 11:31:50 UTC, Robert M. Münch wrote:
I have a simple tree C data-structure that looks like this:
node {
node parent:
vector[node] children;
}
I would like to create two foreach algorthims, one follwing the
breadth first search pattern and one the depth first search
pattern.
Is this possible? I read about Inputranges, took a look at the
RBTree code etc. but don't relly know/understand where to start.
What I found really interesting when reading Ali Çehreli's book
'Programming in D' was using fibers for tree iteration.
Check out http://ddili.org/ders/d.en/fibers.html and skip to the
section "Fibers in range implementations"
Re: Class qualifier vs struct qualifier
On Saturday, June 16, 2018 07:13:28 Timoses via Digitalmars-d-learn wrote:
> On Thursday, 14 June 2018 at 17:07:09 UTC, Jonathan M Davis wrote:
> > Sure, it would save you a little bit of typing when you do
> > something like
> >
> > auto foo = new Foo;
> >
> > if makes it immutable for you, but it's at the cost of code
> > clarity.
>
> Why should it even?
>
> Isn't
>
> immutable class C
> {
> int a;
> }
>
> the same as
>
> class C
> {
> immutable
> {
> int a;
> }
> }
>
> ?
>
> Does the following code clarify why an instance if immutable
> struct HAS to be immutable while an instance of class does not
> have to be immutable??
>
> immutable struct S {}
> immutable class C {}
>
> void main()
> {
> S sa = S();
> pragma(msg, typeof(sa)); // immutable(S)
> S sb = S();
> // sa = sb; // Error: cannot modify immutable expression sa
>
> C ca = new C();
> pragma(msg, typeof(ca)); // C
> C cb = new C();
> ca = cb; // works
> }
>
> Then the question would rather be why
>
> S s = S(); // immutable(S)
>
> does what it seems to be doing..?
It's perfectly legal to do
struct S
{
int i;
immutable int j;
}
and, declaring a variable of that type
S s;
does not result in the type of s being treated as immutable - just the
members. Similarly,
struct S
{
immutable int i;
}
S s;
does not result in s being immutable(S). It's just when the struct itself is
marked as immutable that every variable of that type is suddenly treated as
immutable as well. And of course, with classes, marking the class as
immutable is identical to marking all of its members as immutable. Why
that's not the case for structs, I have no idea.
Regardless, I think that it's a terrible idea to implicitly make a type
immutable everywhere. If I see
S s;
I expect S to be mutable. Sure, it could have const or immutable members
(much as that's generally a terrible idea for structs, because it makes them
non-assignable and potentially non-copyable), but I would never expect the
type to be immutable(S) when the variable is clearly typed as S - just like
I wouldn't expect new S to result in an immutable(S). I was _very_ surprised
to see that the compile treats
immutable struct S
{
}
differently from
struct S
{
immutable:
}
and I really think that it should be fixed so that it doesn't. The fact that
S s;
could ever result in the variable being anything other than S most
definitely breaks the principle of least surprise, and it doesn't match how
the rest of the language works. It's particularly bizarre when you consider
that it doesn't happen when all of the members are immutable if the struct
wasn't directly marked with immutable.
IMHO, even if a type were unusable as anything other than immutable,
variables of that type should still have to be marked with immutable,
otherwise the variable declaration doesn't match the actual type of the
variable, which seems like a terrible idea.
- Jonathan M Davis
Re: Get static fields!
On Saturday, 16 June 2018 at 05:05:19 UTC, DigitalDesigns wrote: tupleof does not return static fields as does not Fields. Currently the only method seems to be use allMembers, but that returns members requiring filtering, which there is no good filtering checks. I'd simply like to get all the fields of a type, static and non-static. What about derivedMembers?
Re: Get static fields!
On Saturday, 16 June 2018 at 07:56:22 UTC, Bauss wrote: On Saturday, 16 June 2018 at 05:05:19 UTC, DigitalDesigns wrote: tupleof does not return static fields as does not Fields. Currently the only method seems to be use allMembers, but that returns members requiring filtering, which there is no good filtering checks. I'd simply like to get all the fields of a type, static and non-static. What about derivedMembers? But I don't want derived members!
typeof on protected field
mixin(`foo!(typeof(T.`~m~`)); gives me an error about m being protected. Error: class `X` member `name` is not accessible. this also happens when using __traits(getMember, T, m); X is in another module. Works fine when X is in the same module. I need to get the protected and private members for serialization.
Re: How do you test whether a variable is static or not?
On Saturday, 30 July 2016 at 13:04:56 UTC, Ali Çehreli wrote:
On 07/30/2016 05:47 AM, Jonathan M Davis via
Digitalmars-d-learn wrote:
> I'm writing some serialization code where I need to skip
static variables.
> So, I have a symbol from a struct, and I'd like to test
whether it's static
> or not.
static variables don't have the .offsetof property:
struct S {
int a;
static int b;
}
// Bonus question: should field be alias or string?
template isStaticVar(T, alias field)
{
enum isStaticVar = !__traits(compiles, mixin("T." ~ field ~
".offsetof"));
}
void main() {
static assert (!isStaticVar!(S, "a"));
static assert (isStaticVar!(S, "b"));
}
Ali
This doesn't work, treats fields in base classes as static.
One way to test if a member is static is if it it doesn't exist
in tupleof... but this only returns the immediate members and so
will fail. I guess one will have to check all base types too and
if it doesn't exist in any of then it should be static.
Why is it so hard to be able to get basic information like if a
type is static or not?
Re: Can't start application on heroku
On Saturday, 16 June 2018 at 01:24:04 UTC, crimaniak wrote: Hi all! The first try to host application on Heroku provider. The application is started and starts to listen in 3 seconds on the port, provided by heroku-buildpack-d. But the server doesn't detect listening and stops the application. On the local machine, the application works as expected. What can be the problem here? [...] Probably you could try to change your listening address from 127.0.0.1 to 0.0.0.0
Re: Can't start application on heroku
On Saturday, 16 June 2018 at 09:00:21 UTC, Jacob Shtokolov wrote: On Saturday, 16 June 2018 at 01:24:04 UTC, crimaniak wrote: Hi all! The first try to host application on Heroku provider. The application is started and starts to listen in 3 seconds on the port, provided by heroku-buildpack-d. But the server doesn't detect listening and stops the application. On the local machine, the application works as expected. What can be the problem here? [...] Probably you could try to change your listening address from 127.0.0.1 to 0.0.0.0 Thanks! It is. Initially, I did not pay attention to the default interface address, because I expected the 'bind-address' parameter according to the documentation.
Re: How do you test whether a variable is static or not?
On Saturday, 16 June 2018 at 08:52:20 UTC, DigitalDesigns wrote:
On Saturday, 30 July 2016 at 13:04:56 UTC, Ali Çehreli wrote:
On 07/30/2016 05:47 AM, Jonathan M Davis via
Digitalmars-d-learn wrote:
> I'm writing some serialization code where I need to skip
static variables.
> So, I have a symbol from a struct, and I'd like to test
whether it's static
> or not.
static variables don't have the .offsetof property:
struct S {
int a;
static int b;
}
// Bonus question: should field be alias or string?
template isStaticVar(T, alias field)
{
enum isStaticVar = !__traits(compiles, mixin("T." ~ field
~ ".offsetof"));
}
void main() {
static assert (!isStaticVar!(S, "a"));
static assert (isStaticVar!(S, "b"));
}
Ali
This doesn't work, treats fields in base classes as static.
One way to test if a member is static is if it it doesn't exist
in tupleof... but this only returns the immediate members and
so will fail. I guess one will have to check all base types
too and if it doesn't exist in any of then it should be static.
Why is it so hard to be able to get basic information like if a
type is static or not?
Probably because the symbols don't carry the information. I'd
reckon a compiler addition to __traits() would probably solve
this. Something like getStaticMembers
Re: typeof on protected field
On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote: mixin(`foo!(typeof(T.`~m~`)); gives me an error about m being protected. Error: class `X` member `name` is not accessible. this also happens when using __traits(getMember, T, m); X is in another module. Works fine when X is in the same module. I need to get the protected and private members for serialization. You can't get that information when they're in another module, unfortunately. The only solution would be to expose them as public or have a public member expose them.
Re: typeof on protected field
On Saturday, June 16, 2018 13:12:13 bauss via Digitalmars-d-learn wrote: > On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote: > > mixin(`foo!(typeof(T.`~m~`)); > > > > gives me an error about m being protected. > > > > Error: class `X` member `name` is not accessible. > > > > this also happens when using __traits(getMember, T, m); X is in > > another module. Works fine when X is in the same module. > > > > I need to get the protected and private members for > > serialization. > > You can't get that information when they're in another module, > unfortunately. > > The only solution would be to expose them as public or have a > public member expose them. There has been discussion of making private, protected, etc. accessible to type introspection, and I expect that it will work at some point, but yeah, at the moment, it doesn't work. - Jonathan M Davis
multiqualifier
I'm going to post this in learn in order not to disturb "the
guys".
Multiqualifiers
---
Warning: Stop reading if you don't have time. Tail-const rant in
disguise.
(1) Going from immutable to mutable, one layer deep.
---
In the D programming language const(int ***) means the same as
const int ***
const int *** source; //head-const body-tail-const or just
const
const (int **)* destination;//head-mutable body-tail-const
destination = source; //works with ldc2 (1.2.0)
Assigning the source to the destination is possible and the head
which was
initially const becomes mutable. This is possible because a copy
is made
of that head pointer.
const int *** source; //const
const (int *)** destination;//head-body-mutable tail-const
//error
destination = source; //error
Assigning the source to the destination is not possible because
you would
have to alter the initial head. To clarify with invalid D code
(no-code).
//warning: Fake D code
const (int ***) source;
const (int *)dup(*)dupchange(*) destination;
const (int ) source;
const (int *)dup(*)dupchange(**) destination;
So we don't do this altering of the values and go only one layer
deep. The D
programming language is even able to figure this one layer deep
out with
regard to structs.
struct HeadMutableTailConst
{
const (int*) * pMutableHeadPointer; //head-mutable
body-tail-const
}
const(HeadMutableTailConst) source;
HeadMutableTailConst destination;
//const-head to mutable-head with destination body-tail-const
destination = source; //works with ldc2 (1.2.0)
The important part is that the head is either mutable or const
and the
rest must always be body-tail-const.
1.a) Naming
---
Starting to realize I need a different wording. The first pointer
on the right
is the head and the second pointer is the body.
const(int ***)*** tailConst; //tail-const
const(int **) headTailConst; //head-const body-tail-const
const(int *)* bodyTailConst; //head-mutable body-tail-const
Which means that body-tail-const can be either
const(int **) headTailConst; //head-const body-tail-const
const(int *)* bodyTailConst; //head-mutable body-tail-const
body-tail-const completally ignores the head.
(2) Going the other way.
mutable can be assigned to const, and so does immutable.
int *** source;
const(int **)* destination;
destination = source; //works
The destination needs to be body-tail-const not just tail-const.
int source;
const(int*)*** destination;
destination = source; //error
struct Container1
{
int * data;
}
struct Container2
{
const(int) * data;
}
Container1 source;
Container2 destination;
destination = source; //error
Both cases "mutable to const tail" and "const head to mutable
head" with
full BODY-TAIL-CONST (or recently head-mutability)
(3) Multiple tails
--
3.a
---
A user defined type can have multiple tails so it should have
multiple
qualifiers, one for each tail. I've numbered them here with $1
and $2 in fake
D code or no-code.
//warning: Fake D code
struct MultiTail
{
qual$1 (int) * a; //Mandatory BODY-TAIL-QUAL$1 or head-body-tail
qual$2 (int) * b; //Mandatory BODY-TAIL-QUAL$2
this()(const, immutable)
{
//qual$1 is const
//qual$2 is immutable
}
}
(const, immutable) MultiTail a; //impossible D code.
I'm going to be verbose so. The first "$1" becomes "const" and
the second
"$2" becomes immutable. Field "a" defined as const(int) * a; and
the second
field "b" is immutable(int) * b;
I will use (const) for the multiqualifier between those ().
(const) vs const
3.b
---
warning: fake D code
struct MultiTail
{
qual$1 (int) * a; //mandatory applied to body-tail or
head-body-tail
qual$1 (int) * b;
qual$1 (int) * c;
qual$2 (int) * z;
}
(const, immutable) MultiTail a; //impossible D code.
A qualifier in a multitail qualifier applying to more tails then
the number of
qualifiers in a multiqualifier.
3.c
---
Can you determine that a type is passable to a routine by just
looking at the
multiqualifier?
(immutable, immutable) MultiTail parameter;
void routine( (const, immutable) MultiTail a)
{
}
3.d classes
Since classes are reference types.
class MultiQualifiedType
{
qual$1(int) field; //mandatory on head-body-tail and not just
body-tail for classes
qual$2(int *) other;
}
(immutable, const) MultiQualifiedType a;
Similarly for structs
//--
struct HeadQualified
{
qual$1(int) field;
}
(const) HeadQualified * a; //a is body-tail-const
//--
struct HeadMutableBodyTailQualified
{
qual$1(int) * field;
}
(const) HeadMutableTailQualified * a; //a is not body-tail-const
error
/--
4. Faking
Re: What is the point of nothrow?
On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote: On Thursday, June 14, 2018 18:11:20 wjoe via Digitalmars-d-learn wrote: On Wednesday, 13 June 2018 at 20:08:06 UTC, Jonathan M Davis wrote: > On Wednesday, June 13, 2018 10:56:41 wjoe via > The idea is that because your program is in an invalid state, > attempting a graceful shutdown is unsafe. But regardless of > whether you agree with that, the fact that nothrow doesn't do > clean-up pretty much ensures that it isn't safe in the > general > case, and nothrow can't do clean-up without negating one of > the > main reasons that it exists in the first place - which is to that fact also means that a program which threw an Error cannot be debugged anymore; because of invalid state you can neither know, nor assume, that what you see in your debugger or core dump is actually the state which led to the throw. As I said, personally, I think that the program shut just print and terminate rather than throwing an Error. Walter seems to have designed things from the premise that you could rerun the program to reproduce the problem (which in is usually true with the programs he works on). And in that case, simply getting the error message and stacktrace would be plenty. The problem is when you can't simply rerun the program to reproduce the problem and is why I'm of the opinion that printing and terminating would be better than throwing an Error. > improve performance by not emitting exception-handling code. if performance matters so much I would use betterC. 'Improving' performance without profiling and such a trade-off is a bad idea. If it were opt in - yes, I know I will get undebuggable code on error thrown but I want or need the performance gain, fair enough. But instead you are a victim of that implementation whether you like it or not and you might not even be aware about it. betterC really has nothing to do with performance. It just has to do with avoiding druntime so that you can have C code just link in and use the D code as if it were C (though using it would avoid the issue of Errors, since the runtime wouldn't be there to handle them). And again, Errors are intended for fatal cases, so most of the concerns about doing clean-up are irrelevant. Attempting to recover from an Error is considered to be like attempting to recover from a segfault, which is a terrible, terrible idea. And there are plenty of folks who want to be able to have their code be more performant when it's not using exceptions. So, as long as folks aren't trying to catch Errors, the fact that nothrow doesn't emit the exception handling code really isn't a problem. What you said earlier: On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote: [...] 2. If the compiler knows that a function can't throw an Exception, then it doesn't have to insert any of the Exception handling mechanism stuff [...] So, the fact that a function is nothrow gives you a performance benefit, [...] - Jonathan M Davis made me believe that performance is one of the major reasons to use it. No? From the betterC page https://dlang.org/spec/betterc.html section 40.2: --- Not Available D features not available with BetterC: Garbage Collection TypeInfo and ModuleInfo Classes Built-in threading (e.g. core.thread) Dynamic arrays (though slices of static arrays work) and associative arrays Exceptions switch with strings final switch synchronized and core.sync Static module constructors or destructors Struct destructors unittest (testing can be done without the -betterC flag) --- Apart from a few convenience features lost this list reads like a shopping list for performance gain over full fledged D, in the spirit of nothrow omitting exception handling mechanism, to me. You gain from no garbage collection overhead, no vtable overhead, no RTTI overhead, no exception overhead, etc, etc, ... Back in the late 90ies I used to write the lion's share of code in Pascal and implement mission critical algorithms in asm. Worked back then why wouldn't it work today, except that I wouldn't use asm anymore but something like C or betterC. Thus, people who need this kind of performance boost can benefit 2 fold from using betterC. 1. They get to keep most of D's awesomeness, including compile time features, scope statements, RAII, lack of a pre processor, memory safety protections and complete meta programming, are just _some_ of the highlights. And on the other hand 2. they gain by getting rid of a lot the 'performance hogs' like GC, exceptions and more, right? And, with no exceptions altogether they do not need to worry about it at all. I'm sold! And out of curiosity again, where would I find this place where the printing and terminating occurs ? I'd have to go digging in druntime. I don't know. I've probably seen it before, but it's not code that I've dealt with often enough to
Re: How do you test whether a variable is static or not?
On 7/30/16 8:47 AM, Jonathan M Davis via Digitalmars-d-learn wrote: I'm writing some serialization code where I need to skip static variables. So, I have a symbol from a struct, and I'd like to test whether it's static or not. Ideally, I'd be able to do something like is(field == static) std.traits.hasStaticMember ? https://dlang.org/phobos/std_traits.html#hasStaticMember -Steve
Re: Create an Algebraic type at compile time and more
On Friday, 15 June 2018 at 12:03:28 UTC, Simen Kjærås wrote: On Friday, 15 June 2018 at 10:53:35 UTC, uknys wrote: On Friday, 15 June 2018 at 07:27:22 UTC, Simen Kjærås wrote: [snip] Yeah I saw that Algebraic doesn't work at compile time, then I thought of using an Interface with one function (execute()) and making Hello and Toto as classes implementing even if that's somewhat slower. Then I could use pragma(msg, getSymbolsByUDA!(mixin(__MODULE__), X)); and make an array sorted by opcode of this interface. Am I right about this ? That would be the idea, yes. -- Simen I found about the sumtype package that does the same thing as Algebraic but also works at compile time, so here is my idea implemented : https://gist.github.com/uknys/dc47a092ff900f8c99f221eda8c9ab42
Re: What is the point of nothrow?
On Saturday, June 16, 2018 18:45:53 wjoe via Digitalmars-d-learn wrote: > What you said earlier: > > On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote: > > [...] > > > > 2. If the compiler knows that a function can't throw an > > Exception, then it doesn't have to insert any of the Exception > > handling mechanism stuff [...] So, the fact that a function is > > nothrow gives you a performance benefit, [...] > > > > - Jonathan M Davis > > made me believe that performance is one of the major reasons to > use it. No? > > From the betterC page https://dlang.org/spec/betterc.html section > 40.2: > --- > Not Available > > D features not available with BetterC: > > Garbage Collection > TypeInfo and ModuleInfo > Classes > Built-in threading (e.g. core.thread) > Dynamic arrays (though slices of static arrays work) and > associative arrays > Exceptions > switch with strings > final switch > synchronized and core.sync > Static module constructors or destructors > Struct destructors > unittest (testing can be done without the -betterC flag) > --- > Apart from a few convenience features lost this list reads like a > shopping list for performance gain over full fledged D, in the > spirit of nothrow omitting exception handling mechanism, to me. > You gain from no garbage collection overhead, no vtable overhead, > no RTTI overhead, no exception overhead, etc, etc, ... > > Back in the late 90ies I used to write the lion's share of code > in Pascal and implement mission critical algorithms in asm. > Worked back then why wouldn't it work today, except that I > wouldn't use asm anymore but something like C or betterC. > > Thus, people who need this kind of performance boost can benefit > 2 fold from using betterC. > 1. They get to keep most of D's awesomeness, including compile > time features, scope statements, RAII, lack of a pre processor, > memory safety protections and complete meta programming, are just > _some_ of the highlights. And on the other hand > 2. they gain by getting rid of a lot the 'performance hogs' like > GC, exceptions and more, right? > And, with no exceptions altogether they do not need to worry > about it at all. > > I'm sold! The _entire_ point of betterC is to be able to call D code from C code without having to deal with druntime (you can call D code from C code even without betterC, but then you have to worry about initializing and shutting down druntime). Basically every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural consequence of the goal of being callable from C code without needing to worry about druntime. All of those features that betterC can't use can be avoided in normal D code if you don't want them for whatever reason. nothrow is actually one of the few cases where you have to explicitly do something in order to avoid that list of features that you have there. In the other cases, you just don't use the feature, and the only cost you're paying is the startup and shutdown time for druntime and the few resources that it uses. So, while you might choose to use betterC over concerns about the performance of D features that betterC doesn't allow, that was never the point of betterC. - Jonathan M Davis
Re: How do you test whether a variable is static or not?
On Saturday, June 16, 2018 14:55:51 Steven Schveighoffer via Digitalmars-d- learn wrote: > On 7/30/16 8:47 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > > I'm writing some serialization code where I need to skip static > > variables. So, I have a symbol from a struct, and I'd like to test > > whether it's static or not. Ideally, I'd be able to do something like > > > > is(field == static) > > std.traits.hasStaticMember ? > > https://dlang.org/phobos/std_traits.html#hasStaticMember Yeah. I wrote that, and it got added to Phobos. If you'll note, my post in this thread was from almost two years ago. - Jonathan M Davis
Re: How do you test whether a variable is static or not?
On Saturday, 16 June 2018 at 21:41:37 UTC, Jonathan M Davis wrote: On Saturday, June 16, 2018 14:55:51 Steven Schveighoffer via Digitalmars-d- learn wrote: On 7/30/16 8:47 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > I'm writing some serialization code where I need to skip > static variables. So, I have a symbol from a struct, and I'd > like to test whether it's static or not. Ideally, I'd be > able to do something like > > is(field == static) std.traits.hasStaticMember ? https://dlang.org/phobos/std_traits.html#hasStaticMember Yeah. I wrote that, and it got added to Phobos. If you'll note, my post in this thread was from almost two years ago. Haha! I usually don’t get caught with these old threads! -Steve
Re: How do you test whether a variable is static or not?
On Saturday, June 16, 2018 22:11:09 Steven Schveighoffer via Digitalmars-d- learn wrote: > On Saturday, 16 June 2018 at 21:41:37 UTC, Jonathan M Davis wrote: > > On Saturday, June 16, 2018 14:55:51 Steven Schveighoffer via > > > > Digitalmars-d- learn wrote: > >> On 7/30/16 8:47 AM, Jonathan M Davis via Digitalmars-d-learn > >> > >> wrote: > >> > I'm writing some serialization code where I need to skip > >> > static variables. So, I have a symbol from a struct, and I'd > >> > like to test whether it's static or not. Ideally, I'd be > >> > able to do something like > >> > > >> > is(field == static) > >> > >> std.traits.hasStaticMember ? > >> > >> https://dlang.org/phobos/std_traits.html#hasStaticMember > > > > Yeah. I wrote that, and it got added to Phobos. If you'll note, > > my post in this thread was from almost two years ago. > > Haha! I usually don’t get caught with these old threads! It's _really_ obvious in my e-mail reader, since I have threading turned on, and it the threads are sorted by the date of the first post in the thread, so the thread is way up in the list such that I'm only likely to even notice that such a post has been made if I tell my client to filter out read e-mails so that I can find the e-mails that I haven't read yet which aren't at the bottom where all of the recent stuff is. Someone could have replied in an old thread and really want me to respond, and I could easily not notice the message for weeks if I'm not trying to get the unread count down to zero and notice that once I've caught up with all of the recent messages, the number is still greater than zero. I kind of wish that the forum software discouraged against necro-ing threads like this, since they're easy for many of us to miss, and once someone replies to them and brings them to the front of the list in the forum software, folks tends to reply as if the thread were recent without noticing how old it is. - Jonathan M Davis
Re: How do you test whether a variable is static or not?
On Saturday, 16 June 2018 at 21:41:37 UTC, Jonathan M Davis wrote: On Saturday, June 16, 2018 14:55:51 Steven Schveighoffer via Digitalmars-d- learn wrote: On 7/30/16 8:47 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > I'm writing some serialization code where I need to skip > static variables. So, I have a symbol from a struct, and I'd > like to test whether it's static or not. Ideally, I'd be > able to do something like > > is(field == static) std.traits.hasStaticMember ? https://dlang.org/phobos/std_traits.html#hasStaticMember Yeah. I wrote that, and it got added to Phobos. If you'll note, my post in this thread was from almost two years ago. - Jonathan M Davis doesn't work: ..\..\src\phobos\std\traits.d(3823): Error: class `app.A` member `z` is not accessible. What is the point of introspection if one can't get information about a type due to it's protection level? For example, how is one suppose to serialize a class that has protected and private members, which are common, when using properties?
Re: How do you test whether a variable is static or not?
On Saturday, June 16, 2018 22:56:38 DigitalDesigns via Digitalmars-d-learn wrote: > On Saturday, 16 June 2018 at 21:41:37 UTC, Jonathan M Davis wrote: > > On Saturday, June 16, 2018 14:55:51 Steven Schveighoffer via > > > > Digitalmars-d- learn wrote: > >> On 7/30/16 8:47 AM, Jonathan M Davis via Digitalmars-d-learn > >> > >> wrote: > >> > I'm writing some serialization code where I need to skip > >> > static variables. So, I have a symbol from a struct, and I'd > >> > like to test whether it's static or not. Ideally, I'd be > >> > able to do something like > >> > > >> > is(field == static) > >> > >> std.traits.hasStaticMember ? > >> > >> https://dlang.org/phobos/std_traits.html#hasStaticMember > > > > Yeah. I wrote that, and it got added to Phobos. If you'll note, > > my post in this thread was from almost two years ago. > > > > - Jonathan M Davis > > doesn't work: > > ..\..\src\phobos\std\traits.d(3823): Error: class `app.A` member > `z` is not accessible. > > What is the point of introspection if one can't get information > about a type due to it's protection level? > > For example, how is one suppose to serialize a class that has > protected and private members, which are common, when using > properties? The fact that you can't introspect on private variables with stuff like __traits is a well-known bug, and I expect that it will be fixed at some point. But if it's serialization that you want, then as I understand it, tupleof should work to get at the direct fields of a struct or class even if they're private. And you can always look at what a serialization library like Orange did. - Jonathan M Davis
Quick Refresher book?
Hello, I was wondering if there's any quick refresher resource to brush up on my D after a long time? Is there a short and quick language reference book like "A Tour of C++"?
Re: Quick Refresher book?
On Saturday, 16 June 2018 at 23:33:18 UTC, Aedt wrote: Hello, I was wondering if there's any quick refresher resource to brush up on my D after a long time? Is there a short and quick language reference book like "A Tour of C++"? if you havent seen it yet, there is the dlang tour https://tour.dlang.org
Re: typeof on protected field
On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote: I need to get the protected and private members for serialization. This breaks encapsulation. A better design would be to have a class know how to serialize itself via a serializable interface.
How to list all the manifest constants in a class or struct
Here is a struct named S:
struct S
{
enum X = 10;
enum Y
{
i = 10
}
enum Z = "str";
struct S {}
class C {}
static int sx = 0;
__gshared int gx = 0;
shared void g();
}
I want list all then the manifest constants in it.
I searched the std.traits and this forums, but get nothing.
Maybe, my real question is how to get the storage class for a
member in a class or struct.
Thanks.
Re: How to list all the manifest constants in a class or struct
On Sunday, June 17, 2018 02:44:38 Heromyth via Digitalmars-d-learn wrote:
> Here is a struct named S:
>
> struct S
> {
> enum X = 10;
> enum Y
> {
> i = 10
> }
> enum Z = "str";
> struct S {}
> class C {}
>
> static int sx = 0;
> __gshared int gx = 0;
>
> shared void g();
> }
>
> I want list all then the manifest constants in it.
>
> I searched the std.traits and this forums, but get nothing.
> Maybe, my real question is how to get the storage class for a
> member in a class or struct.
As the storage class isn't part of the type, type introspection tends to
ignore it. You'll basically have to get the full list of members of the type
and then filter out stuff that isn't a manifest constant, which is not
exactly pleasant and can get a bit tricky but should be possible. You'll
probably have to do something like filter out all of the members where you
can take their address and filter out all of the ones that are types, and
and at that point, you'd be close, but I'd have to experiment to figure out
whether that was enough or not or whether something crept through.
Andrei has been working on coming up with a better wrapper around the
current introspection stuff so that you'll actually get data types which
contain the information about a symbol rather than having to figure out
which combination of __traits and traits from std.traits are required to get
what you want. So, I expect that stuff like this will get a lot easier once
that's ready, but in the interim, if you're trying to do something less
common, it can involve having to do a lot clever filtering to get exactly
the stuff you want and only the stuff you want - and I don't think that
getting the list of manifest constants in a type is a very typical thing for
folks to do, so std.traits certainly doesn't have anything like
isManifestConstant.
- Jonathan M Davis
