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:

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

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: __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: 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[])

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

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.

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

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 (also

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: 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: __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

@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: @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

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 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

Re: More type-flexible arrays?

2015-06-14 Thread ketmar via Digitalmars-d-learn
p.s. faster weak typing solution is definitely possible if you'll narrow possible type set. but as i said, i'd not recommend to go this way. there can be dragon in the end. signature.asc Description: PGP signature

Re: More type-flexible arrays?

2015-06-14 Thread Ali Çehreli via Digitalmars-d-learn
On 06/13/2015 11:12 PM, Ozan wrote: Hallo! Is it possible to create arrays which has more then one type, Not possible. f. ex. array[0] = 1; array[1] = z; array[2] = new clazz(), I tried Variant, but it slow down heavily my app. Another option is OOP. Depending on the way they are

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() {

Re: More type-flexible arrays?

2015-06-14 Thread ketmar via Digitalmars-d-learn
On Sun, 14 Jun 2015 06:12:29 +, 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. it is possible. with Variant. ;-) chances are that

More type-flexible arrays?

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

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 do

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:

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

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;`. i.e.

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 main(){

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

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: 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: 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

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?