Re: compilation issues in a shared library project

2015-06-14 Thread Nicholas Wilson via Digitalmars-d-learn
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 =

Re: Process a TypeTuple

2015-06-14 Thread Baz via Digitalmars-d-learn
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.typ

Process a TypeTuple

2015-06-14 Thread Yuxuan Shui via Digitalmars-d-learn
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

2015-06-14 Thread Jonathan Villa via Digitalmars-d-learn
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 _

Re: CPU cores & threads & fibers

2015-06-14 Thread via Digitalmars-d-learn
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

Re: @property on free function for UFCS?

2015-06-14 Thread Gary Willoughby via Digitalmars-d-learn
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-u

Re: @property on free function for UFCS?

2015-06-14 Thread ketmar via Digitalmars-d-learn
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 m

Re: @property on free function for UFCS?

2015-06-14 Thread Timon Gehr via Digitalmars-d-learn
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

Re: CPU cores & threads & fibers

2015-06-14 Thread Etienne Cimon via Digitalmars-d-learn
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 m

Re: @property on free function for UFCS?

2015-06-14 Thread ketmar via Digitalmars-d-learn
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;

Re: CPU cores & threads & fibers

2015-06-14 Thread John Colvin via Digitalmars-d-learn
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?

2015-06-14 Thread Adam D. Ruppe via Digitalmars-d-learn
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 semantical

Re: @property on free function for UFCS?

2015-06-14 Thread rcorre via Digitalmars-d-learn
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 sti

Re: @property on free function for UFCS?

2015-06-14 Thread Adam D. Ruppe via Digitalmars-d-learn
You can use @property there, but you don't have to because you can call it with optional parenthesis anyway.

CPU cores & threads & fibers

2015-06-14 Thread Robert M. Münch via Digitalmars-d-learn
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?

2015-06-14 Thread rcorre via Digitalmars-d-learn
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?

2015-06-14 Thread John Colvin via Digitalmars-d-learn
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 u

Re: __traits getMember is context sensetive?

2015-06-14 Thread ketmar via Digitalmars-d-learn
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

Re: More type-flexible arrays?

2015-06-14 Thread via Digitalmars-d-learn
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 (als

Re: __traits getMember is context sensetive?

2015-06-14 Thread anonymous via Digitalmars-d-learn
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?

2015-06-14 Thread JDemler via Digitalmars-d-learn
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 r

Re: Qualified destructors / immutable objects

2015-06-14 Thread via Digitalmars-d-learn
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)

Re: __traits getMember is context sensetive?

2015-06-14 Thread anonymous via Digitalmars-d-learn
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

Re: __traits getMember is context sensetive?

2015-06-14 Thread JDemler via Digitalmars-d-learn
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

Re: __traits getMember is context sensetive?

2015-06-14 Thread ketmar via Digitalmars-d-learn
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:

Re: __traits getMember is context sensetive?

2015-06-14 Thread John Colvin via Digitalmars-d-learn
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: __tr

Re: __traits getMember is context sensetive?

2015-06-14 Thread JDemler via Digitalmars-d-learn
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 befo

Re: More type-flexible arrays?

2015-06-14 Thread John Colvin via Digitalmars-d-learn
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

Re: Qualified destructors / immutable objects

2015-06-14 Thread anonymous via Digitalmars-d-learn
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() { im