Re: compilation issues in a shared library project
On Sunday, 7 June 2015 at 00:38:17 UTC, Jonathan Villa wrote:
module dt2.DataBlock;
class DataBlock
{
public DataBlock * NextBlock;
public DataBlock * PrevBlock;
public string value;
this()
{
NextBlock = null;
PrevBlock = null;
value = null;
}
this(string newvalue)
{
this();
value = newvalue;
}
~this()
{
value = "";
}
}
Just an FYI classes are reference types in D so you probably meant
public DataBlock NextBlock; // is a class reference
public DataBlock * PrevBlock; //classes are reference types
already no need for *
// is a pointer to a
class reference
Re: Process a TypeTuple
On Monday, 15 June 2015 at 03:53:35 UTC, Yuxuan Shui wrote:
Is it possible to apply some operation on every member of a
TypeTuple, then get the result back?
Say I have a TypeTuple of array types, and I want a TypeTuple
of their element types, how could I do that?
You can do that with std.typetuple.staticMap, example:
---
import std.stdio;
import std.typetuple;
template ElemType(T)
{
alias ElemType = typeof(T.init[0]);
}
void main(string[] args)
{
alias T1 = TypeTuple!(int[],ubyte[]);
alias T2 = staticMap!(ElemType, T1);
writeln(typeof(T1.init).stringof);
writeln(typeof(T2.init).stringof);
}
---
outputs:
---
(int[], ubyte[])
(int, ubyte)
---
It's like the higher-order function map() but for type list:
http://dlang.org/phobos/std_typetuple.html#.staticMap
Process a TypeTuple
Is it possible to apply some operation on every member of a TypeTuple, then get the result back? Say I have a TypeTuple of array types, and I want a TypeTuple of their element types, how could I do that?
Re: compilation issues in a shared library project
On Tuesday, 9 June 2015 at 14:30:24 UTC, Benjamin Thaut wrote: Shared libraries (DLLs) don't work on windows. They only work for the simplest of all cases (e.g. global functions) and even then there are pitfalls. Just don't do it. The only viable option currently is to link statically or put _all_ your D code into one single Dll and use that Dll from C. Any other use case is bound to fail. I'm currently working on propper dll support for D but it is a lot of work. Kind Regards Benjamin Thaut ah ok, thank you very much for the advise :)
Re: CPU cores & threads & fibers
On Sunday, 14 June 2015 at 12:35:44 UTC, Robert M. Münch wrote: Hi, just to x-check if I have the correct understanding: fibers = look parallel, are sequential => use 1 CPU core threads = look parallel, are parallel => use several CPU cores Is that right? Fibers/co-routines run on a thread and is conceptually the same as a functor/object-with-method that can suspend itself and hold onto the state until it is restarted. Like yield in Python generators. Fibers have their own stack, but that is an implementation detail. It is possible to do the same thing with object-method-calls if you have stackless code-generation (D does not support stackless runtimes, but you'll find this in other languages).
Re: @property on free function for UFCS?
On Sunday, 14 June 2015 at 12:53:43 UTC, rcorre wrote: Is there a good reference for the current state of @property? I know it was hotly debated for awhile (and maybe still is?). I'm just never sure when I should be using it (if at all). Oh yes: http://wiki.dlang.org/Property_Discussion_Wrap-up
Re: @property on free function for UFCS?
On Sun, 14 Jun 2015 18:21:39 +0200, Timon Gehr wrote:
>> only if you plan to use it like `foo = 5;`.
>
> You can use it like that anyway.
sure, but i'm talking about style, not about compiler demands.
>> i.e. exactly like field variable.
>
> struct S{
> void delegate() dg;
> }
>
> int main(){
> S s;
> s.dg=(){ writeln("!"); };
> s.dg();
> }
>
> Now show me the UFCS way.
i'm afraid i didn't understood you here.
>> compiler will not complain, but putting `@property` here is
>> stylistically wrong.
>>
> It's neither wrong nor right.
yet i never saw this:
struct S { int n; }
S s; s.n(42);
the whole concept of properties (not bolted into the compiler yet) is to
emulate *fields*. so it's stylistically right to declare something as a
property if one wants to use it like `foo = 42;`. that means `mymodule.foo
= 42;` actually. yet `42.foo` means `42.module.foo`, which even looks
wrong.
signature.asc
Description: PGP signature
Re: @property on free function for UFCS?
On 06/14/2015 05:50 PM, ketmar wrote:
On Sun, 14 Jun 2015 12:26:52 +, rcorre wrote:
Suppose I have a function defined like so:
void foo(int i) { }
intended to be called like:
5.foo
Should it be labeled with @property?
Or is @property only for true member functions?
only if you plan to use it like `foo = 5;`.
You can use it like that anyway.
i.e. exactly like field variable.
struct S{
void delegate() dg;
}
int main(){
S s;
s.dg=(){ writeln("!"); };
s.dg();
}
Now show me the UFCS way.
compiler will not complain, but putting `@property` here is
stylistically wrong.
It's neither wrong nor right.
Re: CPU cores & threads & fibers
On 2015-06-14 08:35, Robert M. Münch wrote: Hi, just to x-check if I have the correct understanding: fibers = look parallel, are sequential => use 1 CPU core threads = look parallel, are parallel => use several CPU cores Is that right? Yes, however nothing really guarantees multi-threading = multi-core. The kernel reserves the right and will most likely do everything possible to keep your process core-local to use caching efficiently. There's a few ways around that though https://msdn.microsoft.com/en-us/library/windows/desktop/ms686247%28v=vs.85%29.aspx http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html
Re: @property on free function for UFCS?
On Sun, 14 Jun 2015 12:26:52 +, rcorre wrote:
> Suppose I have a function defined like so:
>
> void foo(int i) { }
>
> intended to be called like:
>
> 5.foo
>
> Should it be labeled with @property?
> Or is @property only for true member functions?
only if you plan to use it like `foo = 5;`. i.e. exactly like field/
variable. compiler will not complain, but putting `@property` here is
stylistically wrong.
signature.asc
Description: PGP signature
Re: CPU cores & threads & fibers
On Sunday, 14 June 2015 at 12:35:44 UTC, Robert M. Münch wrote: Hi, just to x-check if I have the correct understanding: fibers = look parallel, are sequential => use 1 CPU core threads = look parallel, are parallel => use several CPU cores Is that right? Pretty much.
Re: @property on free function for UFCS?
On Sunday, 14 June 2015 at 12:53:43 UTC, rcorre wrote: Is there a good reference for the current state of @property? Easy: it does absolutely nothing right now. I'm just never sure when I should be using it (if at all). You should really only use it when you know the function is semantically the same as a field, aka if you want the @property function to be entirely invisible. Don't ask if you want it callable without parens, likely ALL functions will remain that way, instead ask if you want it to be entirely substitutable for the return value. I'd say in practice, only use it when you're returning a callable and want a.foo() to call the return value (so the fact that foo is actually a function is entirely hidden) or if you're returning a ref and want &a.foo to give the address of the referenced variable instead of a delegate to the function (again, the fact that it is a function is entirely hidden, it acts identically to the variable). Though note that even now, since @property doesn't do anything yet, you'd still have to call it explicitly, which will mean compile errors when it is finally implemented... So perhaps best is to just not use it at all.
Re: @property on free function for UFCS?
On Sunday, 14 June 2015 at 12:36:43 UTC, Adam D. Ruppe wrote: You can use @property there, but you don't have to because you can call it with optional parenthesis anyway. Thanks. Is there a good reference for the current state of @property? I know it was hotly debated for awhile (and maybe still is?). I'm just never sure when I should be using it (if at all).
Re: @property on free function for UFCS?
You can use @property there, but you don't have to because you can call it with optional parenthesis anyway.
CPU cores & threads & fibers
Hi, just to x-check if I have the correct understanding: fibers = look parallel, are sequential => use 1 CPU core threads = look parallel, are parallel => use several CPU cores Is that right? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
@property on free function for UFCS?
Suppose I have a function defined like so:
void foo(int i) { }
intended to be called like:
5.foo
Should it be labeled with @property?
Or is @property only for true member functions?
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 10:16:24 UTC, JDemler wrote: On Sunday, 14 June 2015 at 10:04:35 UTC, John Colvin wrote: [...] If that is the case then i really do not get why my first example compiles and my second does not. The compiler sees the pragma(msg, test(e)) and runs test(e). If test uses __traits it does not work if it does not it works. If __traits is just another ctfe function i dont see the difference. An easy to remember rule: If it won't work at runtime, it won't work in ctfe.
Re: __traits getMember is context sensetive?
On Sun, 14 Jun 2015 10:29:08 +, anonymous wrote: > One important thing I didn't see stated clearly by anyone in here: > > CTFE may run at compile time but it follows the same rules as run time > evaluation (plus some restrictions). > > This means, you can't use dynamic values (e.g. function parameters) in > static contexts (e.g. __traits). yes, i managed to write a wall of text escaping to talk about the main issue of the thread. ;-) signature.asc Description: PGP signature
Re: More type-flexible arrays?
On Sunday, 14 June 2015 at 06:12:30 UTC, Ozan wrote: Hallo! Is it possible to create arrays which has more then one type, f. ex. array[0] = 1; array[1] = "z"; array[2] = new clazz(), I tried "Variant", but it slow down heavily my app. Greetings, Ozan You can try Algebraic instead (also in std.variant). It's possible that it's faster, but OTOH, you need to specify the list of types it can accept.
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 10:41:24 UTC, JDemler wrote: So if i want to use parameters in a static context at compile time i have to pass them as template parameters? Yes, template parameters are fine.
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 10:29:09 UTC, anonymous wrote:
On Sunday, 14 June 2015 at 10:10:51 UTC, ketmar wrote:
i.e. when it need a value in compile time. the interpreter is
invoked, it evaluates (interprets) the given code (function or
template instantiation), and then it returns result (or raises
an error).
One important thing I didn't see stated clearly by anyone in
here:
CTFE may run at compile time but it follows the same rules as
run time evaluation (plus some restrictions).
This means, you can't use dynamic values (e.g. function
parameters) in static contexts (e.g. __traits).
Example:
int f(int x)
{
if (__ctfe)
{
enum e = x; /* nope, not even during CTFE */
alias t = some_template!x; /* nope */
pragma(msg, x); /* nope */
}
return x;
}
enum result = f(1); /* CTFE-ing f */
So if i want to use parameters in a static context at compile
time i have to pass them as template parameters?
That would explain my problems. Thanks
Re: Qualified destructors / immutable objects
On Sunday, 14 June 2015 at 07:28:39 UTC, anonymous wrote:
To come back to destructors and immutable objects:
Even without the default initialized variables issue it is
possible to modify immutable data:
struct S {
int[] bar;
~this() {
bar[0] = 123;
}
}
void foo(immutable(int[]) i) {
immutable(S) s = immutable S(i);
}
void main() {
immutable array = [42, 42];
foo(array);
// fails
assert(array == [42, 42]);
}
I'm not sure whether ~this() should be forbidden to modify
immutable data. Consider e.g. some fields need to be free'd. If
someone else is using references to such a field after ~this()
-> segfault, but it could be seen as analogon to the list of
undefined operations on pointer to GC memory.
Additionally the same happens already for stack allocated
fields like int[4] inside a (mutable/const/immutable) struct.
Found this bug report [1], in which Andrei says: "Mutable
destructors shouldn't apply to objects that were immutable,
otherwise they can mutate immutable objects."
[1] https://issues.dlang.org/show_bug.cgi?id=4338#c6
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 10:10:51 UTC, ketmar wrote:
i.e. when it need a value in compile time. the interpreter is
invoked, it evaluates (interprets) the given code (function or
template instantiation), and then it returns result (or raises
an error).
One important thing I didn't see stated clearly by anyone in here:
CTFE may run at compile time but it follows the same rules as run
time evaluation (plus some restrictions).
This means, you can't use dynamic values (e.g. function
parameters) in static contexts (e.g. __traits).
Example:
int f(int x)
{
if (__ctfe)
{
enum e = x; /* nope, not even during CTFE */
alias t = some_template!x; /* nope */
pragma(msg, x); /* nope */
}
return x;
}
enum result = f(1); /* CTFE-ing f */
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 10:04:35 UTC, John Colvin wrote: On Sunday, 14 June 2015 at 09:46:56 UTC, JDemler wrote: On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote: oh, seems that i managed to make everything even less understandable... Your code works perfectly and makes at least some sense to me. Thank you. If i understand it correctly: __traits-time = templateinstatiation-time = pragma-time before ctfe-time? Not really. These things are just (conceptually) done as/when they are required. If a template instantiation needs to do ctfe to calculate it's result, it does it. If some code running in ctfe needs the result of a template, it instantiates it. The only distinction you have to think about is compile-time vs run-time, with the caveat that ctfe code is run as if it were run-time, but the result can be used at compile-time. If you imagine ctfe as being "compiling the function, running it, getting the answer and copying it in to your code" then even that distinction goes away and you just have ct vs rt. If that is the case then i really do not get why my first example compiles and my second does not. The compiler sees the pragma(msg, test(e)) and runs test(e). If test uses __traits it does not work if it does not it works. If __traits is just another ctfe function i dont see the difference.
Re: __traits getMember is context sensetive?
On Sun, 14 Jun 2015 09:46:54 +, JDemler wrote: > On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote: >> oh, seems that i managed to make everything even less understandable... > > Your code works perfectly and makes at least some sense to me. > Thank you. > > If i understand it correctly: __traits-time = templateinstatiation-time > = pragma-time before ctfe-time? not quite right. there is no dedicated "CTFE time". compiler triggers CTFE when it needs to, i.e. when it sees something like this: enum myval = myfunction(); // or mytemplate!(...) i.e. when it need a value in compile time. the interpreter is invoked, it evaluates (interprets) the given code (function or template instantiation), and then it returns result (or raises an error). so CTFE can occur at any stage of semantic analysis. to be clear: compiler goes (roughly) thru this stages: 1. parsing and building AST. 2. semantic analysis. 3. generating code. at the stage (1) only syntax is checked, and source is converted to internal representation (AST). at the state (2) compiler tries to actually make sense of your code. it deducing types, checking type correctness and such. if it need to instantiate some template, it does that here. it does semantic for each function (note: not for templates or eponymous templates!), one by one. and here compiler may step on something that needs CTFE. it invokes interpreter on this stage. so there is no dedicated "CTFE time", compiler does it while it busy with semantic analysis, on demand. this way it avoids evaluating CTFE values that never used, which is good for compile speed. ;-) pragmas and traits are executed by the very same CTFE engine, on demand too. i.e. when compiler hits pragma or traits during semantic analysis, compiler executes that. overal semantic stage is more complex, of course, but i hope you get the idea. signature.asc Description: PGP signature
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 09:46:56 UTC, JDemler wrote: On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote: oh, seems that i managed to make everything even less understandable... Your code works perfectly and makes at least some sense to me. Thank you. If i understand it correctly: __traits-time = templateinstatiation-time = pragma-time before ctfe-time? Not really. These things are just (conceptually) done as/when they are required. If a template instantiation needs to do ctfe to calculate it's result, it does it. If some code running in ctfe needs the result of a template, it instantiates it. The only distinction you have to think about is compile-time vs run-time, with the caveat that ctfe code is run as if it were run-time, but the result can be used at compile-time. If you imagine ctfe as being "compiling the function, running it, getting the answer and copying it in to your code" then even that distinction goes away and you just have ct vs rt.
Re: __traits getMember is context sensetive?
On Sunday, 14 June 2015 at 05:52:00 UTC, ketmar wrote: oh, seems that i managed to make everything even less understandable... Your code works perfectly and makes at least some sense to me. Thank you. If i understand it correctly: __traits-time = templateinstatiation-time = pragma-time before ctfe-time?
Re: More type-flexible arrays?
On Sunday, 14 June 2015 at 06:12:30 UTC, Ozan wrote: Hallo! Is it possible to create arrays which has more then one type, f. ex. array[0] = 1; array[1] = "z"; array[2] = new clazz(), I tried "Variant", but it slow down heavily my app. Greetings, Ozan It's always going to be slower. To do this, every access to the array has to come with some amount of branching and/or and indirection (including an indirect function call if you do it the OOP way), which all have a cost, not to mention obstructing optimisation by the compiler. It's possible that std.variant.Variant isn't as fast as it could be, but it's never going to be even close to zero-performance-cost.
Re: Qualified destructors / immutable objects
To come back to destructors and immutable objects:
Even without the default initialized variables issue it is
possible to modify immutable data:
struct S {
int[] bar;
~this() {
bar[0] = 123;
}
}
void foo(immutable(int[]) i) {
immutable(S) s = immutable S(i);
}
void main() {
immutable array = [42, 42];
foo(array);
// fails
assert(array == [42, 42]);
}
I'm not sure whether ~this() should be forbidden to modify
immutable data. Consider e.g. some fields need to be free'd. If
someone else is using references to such a field after ~this() ->
segfault, but it could be seen as analogon to the list of
undefined operations on pointer to GC memory.
Additionally the same happens already for stack allocated fields
like int[4] inside a (mutable/const/immutable) struct.
