Re: onDispatch demo not compiling
On Thu, 21 Aug 2014 06:34:10 + Shachar via Digitalmars-d-learn wrote: > Indeed. I ended up simply directly calling > "a.opDispatch!"do_something_cool"(5, 6)", which brought most of > those issues to light. ah, silly me. i forgot about such simple thing. signature.asc Description: PGP signature
Re: onDispatch demo not compiling
On Thursday, 21 August 2014 at 06:11:06 UTC, ketmar via Digitalmars-d-learn wrote: that will do the trick. Indeed. I ended up simply directly calling "a.opDispatch!"do_something_cool"(5, 6)", which brought most of those issues to light. Shachar
Re: onDispatch demo not compiling
On Thu, 21 Aug 2014 05:39:14 + Shachar via Digitalmars-d-learn wrote: that's it: failing to evaluate opDispatch() template is not a compilation error. compiler will silently try to find direct method if opDispatch() fails. so be very careful with it. you can add pragma(msg, "...") to your opDispatch to see if it really compiles without errors. i.e. auto onDispatch(string m, Args...)(Args args) { pragma(msg, "m="~m); enum t = underscoresToCamelCase(t); pragma(msg, "t="~t); return mixin("this."~t~"(args)"); } you should see output of this pragmas in compile-time. if you can't see "t", for example, it means that evaluation of underscoresToCamelCase() failed. signature.asc Description: PGP signature
Re: onDispatch demo not compiling
On Thu, 21 Aug 2014 05:39:14 + Shachar via Digitalmars-d-learn wrote: > auto onDispatch(string m, Args...)(Args args) first: opDispatch, not onDispatch. second: underscoresToCamelCase() can't be evaluated in compile-time anymore. the necessary changes: 1. add 'import std.string' -- we need toUpper() from this module. 2. change toupper(c) to toUpper(c) (first thing why ctfe fails) 3. remove 'result.reserve(sym.length);' line (second thing why ctfe fails). 4. uncomment 'return' in opDispatch. %-) that will do the trick. to check if underscoresToCamelCase() can be evaluated in compile time, you can add this line to the first unittest block: enum t = underscoresToCamelCase("hello_world"); then compiler will tell you why it can't evaluate the function. signature.asc Description: PGP signature
onDispatch demo not compiling
I'm trying to compile the onDispatch demo program from "The D Programming Language" (page 387). At first I had an import problem, but I fixed that. Now, however, when I try to call "a.do_something_cool", I get an error message saying: onDispatch.d(43): Error: no property 'do_something_cool' for type 'onDispatch.A' Full program follows (into onDispatch.d): import core.stdc.ctype; import std.stdio; string underscoresToCamelCase(string sym) { string result; result.reserve(sym.length); bool makeUpper; foreach (c; sym) { if (c == '_') { makeUpper = true; } else { if (makeUpper) { result ~= toupper(c); makeUpper = false; } else { result ~= c; } } } return result; } unittest { assert(underscoresToCamelCase("hello_world") == "helloWorld"); assert(underscoresToCamelCase("_a") == "A"); assert(underscoresToCamelCase("abc") == "abc"); assert(underscoresToCamelCase("a_bc_d_") == "aBcD"); } class A { auto onDispatch(string m, Args...)(Args args) { // return mixin("this."~underscoresToCamelCase(m)~"(args)"); } void doSomethingCool(int x, int y) { writeln("Do something cool"); } } unittest { auto a = new A; a.doSomethingCool(5, 6); a.do_something_cool(5, 6); }
D with no druntime
Hi All, I am playing with a small hack OS for fun and in 2066 there are these undefined refs (I have no druntime): _d_arraybounds (new to 2066) _d_assert (new to 2066) _d_unittest (new to 2066) _Dmodule_ref (also in 2065) _d_dso_registry (also in 2065) It is trivial to stub these out but it got me wondering... Is there any way to compile D that has no dependencies? Thanks, uri
Re: new error message in 2.066, type bool (const)
What changed? It ran okay with early beta versions, but not with the release. Paul It compiles in beta-5 but not beta-6. Is the list of changes in the beta testing wiki complete? None seem pertinent. monarch_dodra: Thanks for checking. I was trying to avoid tearing everything down. I was hoping someone would recognize the error. Looks like I'll have to chase it down. Paul
Re: No Output with shebang.
On Wed, 20 Aug 2014 23:03:48 +0200 Philippe Sigaud via Digitalmars-d-learn wrote: > Can compiler switches be used with the shebang notation? If yes, there > is certainly a GDC flag (-run?) that tells it to run the generated > executable. it's possible to use switches, but GDC is not fitted for such usage anyway. it will not automatically compile included modules, it will not automatically put the binary in predefined place and so on. ah, dmd is not suitable for such usage too, that's why we have rdmd. rdmd can be adapted to use GDC (if compiled with GDC, rdmd will use gdmd instead of dmd), but dmd is faster and the quality of generated code is not so important in scripts. signature.asc Description: PGP signature
Re: Variadic parameter of length 1
On Wed, 20 Aug 2014 17:47:36 + monarch_dodra via Digitalmars-d-learn wrote: > Yeah, what he said. It's a language artifact. by the way, it would be nice to have wiki page with such artifacts and their explanations. signature.asc Description: PGP signature
Re: Produce some COFF object with 2.066 ?
On Wednesday, 20 August 2014 at 23:56:23 UTC, Baz wrote: Hello, I've been very interested about the announce saying that DMD is able to produce COFF object files. Mostly because I'm thinking using some objects programmed in D in a software programmed in another lang, a bit like when statically linking a dll to a program but with an obj, to keep a nice monolithic executable. First thing: I've tried a simple thing: compile an exported function with the args "myfile.d -c -ms32mscoff" and dmd complains that "-ms32mscoff" is not a recognized switch. 32-bit COFF is only in git master currently. It'll be in 2.067 when that comes out. 64-bit COFF has been in dmd for quite some time now. You just have to have a copy of Visual Studio installed (the free Express edition should be fine) and compile with -m64. Second thing: If I understand well, it means that previously, to link D a object with a soft programmed in another lang was not possible because the OMF objs don't include everything (e.g the objs coming from other imported static libs) and that now it's faisable ? right ? They'd just have to both be OMF format if you wanted to statically link. If you had a DLL you could create an import library from the DLL and still link that just fine. Walter has a tool on Digital Mars to do it. Now you should be able to directly link to COFF libraries.
Produce some COFF object with 2.066 ?
Hello, I've been very interested about the announce saying that DMD is able to produce COFF object files. Mostly because I'm thinking using some objects programmed in D in a software programmed in another lang, a bit like when statically linking a dll to a program but with an obj, to keep a nice monolithic executable. First thing: I've tried a simple thing: compile an exported function with the args "myfile.d -c -ms32mscoff" and dmd complains that "-ms32mscoff" is not a recognized switch. Second thing: If I understand well, it means that previously, to link D a object with a soft programmed in another lang was not possible because the OMF objs don't include everything (e.g the objs coming from other imported static libs) and that now it's faisable ? right ?
Re: delegates & GC allocations
On Wednesday, 20 August 2014 at 21:30:41 UTC, Etienne wrote: So, my question inspired a new optimization? :-p A decent optimizing compiler would detect that the function is calling itself and save stack space by using register where possible...
Re: Can you explain this?
On Wednesday, 20 August 2014 at 21:06:49 UTC, monarch_dodra wrote: On Wednesday, 20 August 2014 at 20:39:42 UTC, Jonathan M Davis wrote: is(typeof(foo)) and __traits(compiles, foo) are not the same. The first tests for the existence of the symbol, whereas the second checks whether the code will actually compile. Is that even true? I mean, are you just repeating something you've heard, or have you checked? "is(typeof(foo))" has always failed for me merelly if "foo" fails to compile. "foo" being an existing (but private) symbol is enough. Test case: // module foo; struct S { private int i; } // import foo; void main(string[] args) { S s; writeln(is(typeof(s.i))); writeln(__traits(compiles, s.i)); } // This says false, false. I've yet to find a usecase where "is(typeof(...))" and "__traits(compiles, ...)" aren't interchangeable. I mean, I may have missed something, but it seems the whole "private" thing is just miss-information. Well, hereas an example of them not being the same: --- import std.stdio; struct S { static void foo() { writeln(is(typeof(this))); writeln(__traits(compiles, this)); } } void main() { S.foo(); } --- I originally found out about it from Don here: https://issues.dlang.org/show_bug.cgi?id=8339 I don't know why your example doesn't show them as different. But we should probably change it so that they _are_ the same - either that or document their differences explicitly and clearly, but I don't know why the is(typeof.. behavior here would be desirable. Maybe so that we could do type(this) to declare a local variable of the class type generically? I don't know. They're _almost_ the same but not quite, and I don't know what the exact differences are. Pretty much all I have to go on is Don's explanation in that bug report. - Jonathan M Davis
Re: delegates & GC allocations
On 2014-08-20 5:25 PM, Ola Fosheim Gr wrote: Well, I guess simple recursion could be solved easily too by having a wrapper function that puts the frame pointer in a free callee save register... So, my question inspired a new optimization? :-p
Re: delegates & GC allocations
On Wednesday, 20 August 2014 at 21:19:18 UTC, Ola Fosheim Gr wrote: On Wednesday, 20 August 2014 at 20:48:38 UTC, Chris Nicholson-Sauls wrote: On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: Only if it is recursive. Or if it refers to any state of the parent function. As long as the compiler knows where it will be called from it should be able use a stack pointer offset (unless alloca gets in the way) without the frame pointer of the parent. Well, I guess simple recursion could be solved easily too by having a wrapper function that puts the frame pointer in a free callee save register...
Re: new error message in 2.066, type bool (const)
On Wednesday, 20 August 2014 at 20:46:20 UTC, Paul D Anderson wrote: Re-compiling existing code with version 2.066 generates a lot of errors complaining about implicit conversion to const. Typical is this call (inside a struct with properties 1 & 2): z.sign = x.sign ^ y.sign; Error: None of the overloads of 'sign' are callable using argument types bool (const), candidates are: 1) @property @safe bool sign() const { return signed; } 2) @property @safe bool sign(in bool value) { signed = value; return signed; } What changed? It ran okay with early beta versions, but not with the release. Paul Could you provide a short, but complete program that reproduces the issue? With this: // struct S { bool signed; @property @safe bool sign() const { return signed; } @property @safe bool sign(in bool value) { signed = value; return signed; } } void main(string[] args) { S s; s.sign = s.sign ^ s.sign; } // It works for me with both 2.065.0 and 2.066.0. What is the type of "signed" ? Is it something other than bool, by any chance?
Re: delegates & GC allocations
On Wednesday, 20 August 2014 at 20:48:38 UTC, Chris Nicholson-Sauls wrote: On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive. Or if it refers to any state of the parent function. As long as the compiler knows where it will be called from it should be able use a stack pointer offset (unless alloca gets in the way) without the frame pointer of the parent.
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:39:42 UTC, Jonathan M Davis wrote: is(typeof(foo)) and __traits(compiles, foo) are not the same. The first tests for the existence of the symbol, whereas the second checks whether the code will actually compile. Is that even true? I mean, are you just repeating something you've heard, or have you checked? "is(typeof(foo))" has always failed for me merelly if "foo" fails to compile. "foo" being an existing (but private) symbol is enough. Test case: // module foo; struct S { private int i; } // import foo; void main(string[] args) { S s; writeln(is(typeof(s.i))); writeln(__traits(compiles, s.i)); } // This says false, false. I've yet to find a usecase where "is(typeof(...))" and "__traits(compiles, ...)" aren't interchangeable. I mean, I may have missed something, but it seems the whole "private" thing is just miss-information.
Re: No Output with shebang.
>> gdc just compiles the program to a.out. It doesn't run the >> resulting executable. You need to use something like rdmd instead >> of gdc. rdmd compiles to some temporary location and then runs >> the executable. > > > Wow, that was fast. Thanks a lot! Can compiler switches be used with the shebang notation? If yes, there is certainly a GDC flag (-run?) that tells it to run the generated executable.
new error message in 2.066, type bool (const)
Re-compiling existing code with version 2.066 generates a lot of errors complaining about implicit conversion to const. Typical is this call (inside a struct with properties 1 & 2): z.sign = x.sign ^ y.sign; Error: None of the overloads of 'sign' are callable using argument types bool (const), candidates are: 1) @property @safe bool sign() const { return signed; } 2) @property @safe bool sign(in bool value) { signed = value; return signed; } What changed? It ran okay with early beta versions, but not with the release. Paul
Re: delegates & GC allocations
On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive. Or if it refers to any state of the parent function.
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:12:58 UTC, Justin Whear wrote: On Wed, 20 Aug 2014 20:01:03 +, Colin wrote: It looks veryhacky. I see 3 distinct parts playing a role in my confusion: A) The 'is' keyword. What does it do when you have is(expression); B) typeof( expression ); whats this doing? Particularly when the expression its acting on is a closure that returns nothing? (at least as far as I can see) C) The closure expression: (inout int = 0) { // Check to see if I can do InputRangy stuff... } Why is there a need for that inout int = 0 clause at the start of it? Sorry for the long question! Thanks, Colin Before the introduction of __traits(compiles, ...), `is(typeof(...))` was used. is(typeof(foo)) and __traits(compiles, foo) are not the same. The first tests for the existence of the symbol, whereas the second checks whether the code will actually compile. In most cases, there's no real difference, but if you're trying to use a symbol in a context where it's not legal (e.g. using a private variable that you don't have access to), then the is expression will pass, whereas the _traits(compiles.. will fail. At least in Phobos, is(typeof... is used far more freqently than __traits(compiles... The trait is used almost exclusively in unit tests, not in template constraints or in user-defined traits such as isInputRange. - Jonathan M Davis
Re: No Output with shebang.
On Wednesday, 20 August 2014 at 20:21:13 UTC, anonymous wrote: On Wednesday, 20 August 2014 at 20:17:49 UTC, Newbie wrote: #!/usr/bin/gdc import std.stdio; void main() { writeln("Hello, world with automated script running!"); } When I compile the code above normal to an a.out binary it runs like expected. But running it with shebang it does nothing. No output, especially no error message. Nothing. What do I wrong? gdc just compiles the program to a.out. It doesn't run the resulting executable. You need to use something like rdmd instead of gdc. rdmd compiles to some temporary location and then runs the executable. Wow, that was fast. Thanks a lot!
Re: No Output with shebang.
On Wednesday, 20 August 2014 at 20:17:49 UTC, Newbie wrote: #!/usr/bin/gdc import std.stdio; void main() { writeln("Hello, world with automated script running!"); } When I compile the code above normal to an a.out binary it runs like expected. But running it with shebang it does nothing. No output, especially no error message. Nothing. What do I wrong? gdc just compiles the program to a.out. It doesn't run the resulting executable. You need to use something like rdmd instead of gdc. rdmd compiles to some temporary location and then runs the executable.
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:01:05 UTC, Colin wrote: I see 3 distinct parts playing a role in my confusion: A) The 'is' keyword. What does it do when you have is(expression); http://dlang.org/expression.html#IsExpression It is a tool for type checking. It has many options but plain `is(T)` checks if `T` is a valid type and returns `true` if it is. `void` is considered a valid type. B) typeof( expression ); whats this doing? Particularly when the expression its acting on is a closure that returns nothing? (at least as far as I can see) typeof(() {}) evaluates to void: static assert(is(typeof(() {}) == void)); However, if any compilation errors happen inside the delegate, it evaluates to special invalid type which yield `false` when supplied to `is` expression. Thus `is(typeof(expr))` is a way to express a concept "if `expr` compiles". Delegate is necessary to test statements because `typeof` only accepts expressions. C) The closure expression: (inout int = 0) { // Check to see if I can do InputRangy stuff... } Why is there a need for that inout int = 0 clause at the start of it? Now this is a really weird one. This is necessary for input ranges with `inout` functions to fit the trait because `inout` variables can be declared only inside `inout` functions. See this bug report for details : https://issues.dlang.org/show_bug.cgi?id=7824 It is one of surprising feature inter-operation cases you don't expect when designing features :)
No Output with shebang.
#!/usr/bin/gdc import std.stdio; void main() { writeln("Hello, world with automated script running!"); } When I compile the code above normal to an a.out binary it runs like expected. But running it with shebang it does nothing. No output, especially no error message. Nothing. What do I wrong?
Re: Can you explain this?
On Wed, 20 Aug 2014 20:01:03 +, Colin wrote: > It looks veryhacky. > > I see 3 distinct parts playing a role in my confusion: > A) The 'is' keyword. What does it do when you have is(expression); > B) typeof( expression ); whats this doing? Particularly when the > expression its acting on is a closure that returns nothing? (at least as > far as I can see) > C) The closure expression: > (inout int = 0) { > // Check to see if I can do InputRangy stuff... > } > Why is there a need for that inout int = 0 clause at the start of it? > > Sorry for the long question! > > Thanks, > Colin Before the introduction of __traits(compiles, ...), `is(typeof(...))` was used. It works because the is expression evaluates to false if the contents don't have a type or are semantically invalid. So this code creates a delegate to test the various properties--if it would compile, the delegate has a type and `is` returns true. The inout int parameter is very hacky, see this thread: http://forum.dlang.org/thread/opykgvxbqqeleuikt...@forum.dlang.org#post-mailman.102.1396007039.25518.digitalmars-d-learn:40puremagic.com
Can you explain this?
Hi, I'm implementing some template checks on some types I'm using in a project, and went to phobos for some indications on how to use them. In std.range, I see this construct quite a bit: template isInputRange(R) { enum bool isInputRange = is(typeof( (inout int = 0) { R r = R.init; // can define a range object if (r.empty) {} // can test for empty r.popFront(); // can invoke popFront() auto h = r.front; // can get the front of the range })); } Can anyone explain the: is(typeof( (inout int = 0) {} ); section to me? It looks veryhacky. I see 3 distinct parts playing a role in my confusion: A) The 'is' keyword. What does it do when you have is(expression); B) typeof( expression ); whats this doing? Particularly when the expression its acting on is a closure that returns nothing? (at least as far as I can see) C) The closure expression: (inout int = 0) { // Check to see if I can do InputRangy stuff... } Why is there a need for that inout int = 0 clause at the start of it? Sorry for the long question! Thanks, Colin
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 17:02:59 UTC, Dicebot wrote: On Wednesday, 20 August 2014 at 15:34:30 UTC, Dominikus Dittes Scherkl wrote: And why historical? Is that not necessary anymore? What better solution is there today? Historical in a sense that distinct "can be anything" template parameter is probably a better approach but it is too late to change such core language part. Yeah, what he said. It's a language artifact.
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:34:30 UTC, Dominikus Dittes Scherkl wrote: And why historical? Is that not necessary anymore? What better solution is there today? Historical in a sense that distinct "can be anything" template parameter is probably a better approach but it is too late to change such core language part.
Re: How to set workDir for std.process.execute ?
On Wednesday, 20 August 2014 at 16:16:03 UTC, ketmar via Digitalmars-d-learn wrote: On Wed, 20 Aug 2014 16:07:47 + KrzaQ via Digitalmars-d-learn wrote: It's as if the implementation didn't expect the last argument. try to upgrade to dmd 2.066. That did the trick. Thanks.
Re: How to set workDir for std.process.execute ?
On Wed, 20 Aug 2014 16:07:47 + KrzaQ via Digitalmars-d-learn wrote: > It's as if the implementation didn't expect the last argument. try to upgrade to dmd 2.066. signature.asc Description: PGP signature
How to set workDir for std.process.execute ?
Hello, I'm trying to follow the documentation: http://dlang.org/phobos/std_process.html#.execute Unfortunately, the following code gives me a compiler error: class Probator { char[] dir; this(const char[] dir){ this.dir = dir.dup; } int revision(){ import std.process; import std.conv; const char[] workDir = "~".dup; auto p = std.process.execute(["svnversion", dir], null, Config.none, size_t.max, workDir); if(p.status == 0){ return to!int(p.output); }else{ throw new Exception(p.output); } } } error: /d629/f876.d(15): Error: function std.process.execute (const(char[][]) args, const(immutable(char)[][string]) env = null, Config config = cast(Config)0, ulong maxOutput = 18446744073709551615LU) is not callable using argument types (const(char)[][], typeof(null), Config, ulong, const(char[])) It's as if the implementation didn't expect the last argument.
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:37:18 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: No better solution that I know of. alias template parameters (alias a) match symbols (names, user-defined types) whereas type parameter (T) match only pure types. So when we need to match anything, we use (T...) if (T.length == 1) Ok, now it's clear. Thank you very much. Sometimes D is really a little weird...
Re: Variadic parameter of length 1
On Wed, Aug 20, 2014 at 5:34 PM, Dominikus Dittes Scherkl via Digitalmars-d-learn wrote: > On Wednesday, 20 August 2014 at 15:26:14 UTC, monarch_dodra wrote: >> >> AFAIK, it's a historical workaround to accept T as either alias or not >> alias, as varargs have "auto alias". EG: >> >> foo!int //OK >> foo!"hello" //OK too > > > Ah, ok. > And why historical? Is that not necessary anymore? What better solution is > there today? No better solution that I know of. alias template parameters (alias a) match symbols (names, user-defined types) whereas type parameter (T) match only pure types. So when we need to match anything, we use (T...) if (T.length == 1)
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:11:53 UTC, Dominikus Dittes Scherkl wrote: I have several times seen a construct template foo(T...) if(T.length == 1) { ... } What is that good for? Why using variadic parameter if anyway exactly one parameter is required?!? That's because template alias parameters cannot take builtin types like int, and type parameters can only take types. But tuple elements can be anything. struct SomeType {} template a(X) {enum a = 0;} /* type parameter */ enum a1 = a!int; /* ok */ enum a2 = a!SomeType; /* ok */ version(none) enum a3 = a!42; /* Error: template instance a!42 does not match template declaration a(X) */ template b(alias x) {enum b = 0;} /* alias parameter */ version(none) enum b1 = b!int; /* Error: template instance b!int does not match template declaration b(alias x) */ enum b2 = b!SomeType; /* ok */ enum b3 = b!42; /* ok */ template c(x ...) if(x.length == 1) {enum c = 0;} /* tuple parameter */ enum c1 = c!int; /* ok */ enum c2 = c!SomeType; /* ok */ enum c3 = c!42; /* ok */
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:26:14 UTC, monarch_dodra wrote: AFAIK, it's a historical workaround to accept T as either alias or not alias, as varargs have "auto alias". EG: foo!int //OK foo!"hello" //OK too Ah, ok. And why historical? Is that not necessary anymore? What better solution is there today?
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:11:53 UTC, Dominikus Dittes Scherkl wrote: I have several times seen a construct template foo(T...) if(T.length == 1) { ... } What is that good for? Why using variadic parameter if anyway exactly one parameter is required?!? AFAIK, it's a historical workaround to accept T as either alias or not alias, as varargs have "auto alias". EG: foo!int //OK foo!"hello" //OK too
Re: delegates & GC allocations
On Wednesday, 20 August 2014 at 14:44:39 UTC, Etienne wrote: I've been hearing that delegates get a context pointer which will be allocated on the GC. Is this also true for delegates which stay in scope? e.g. void addThree() { int val; void addOne() { val++; } addOne(); addOne(); addOne(); return val; } Will the above function allocate on the GC? int getInt1() @nogc { int val; int func() @nogc { return val; } return func(); } int delegate() getInt2() //@nogc - thie one allocates! { int val; int func() @nogc { return val; } return &func; } int delegate() getInt3() @nogc { int val; int func() @nogc { return 0; } return &func; }
Re: delegates & GC allocations
non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive.
Variadic parameter of length 1
I have several times seen a construct template foo(T...) if(T.length == 1) { ... } What is that good for? Why using variadic parameter if anyway exactly one parameter is required?!?
Re: delegates & GC allocations
On Wednesday, 20 August 2014 at 14:54:31 UTC, ketmar via Digitalmars-d-learn wrote: On Wed, 20 Aug 2014 10:44:38 -0400 Etienne via Digitalmars-d-learn wrote: and this is not delegate, this is just nested function. non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. However, not every delegate is a closure - heap allocation of the context happens only if delegate leaves the scope it refers to (via return value or by being passed as an argument to external function)
Re: delegates & GC allocations
On Wed, 20 Aug 2014 10:44:38 -0400 Etienne via Digitalmars-d-learn wrote: and this is not delegate, this is just nested function. signature.asc Description: PGP signature
Re: delegates & GC allocations
On Wed, 20 Aug 2014 10:44:38 -0400 Etienne via Digitalmars-d-learn wrote: > Will the above function allocate on the GC? no. signature.asc Description: PGP signature
delegates & GC allocations
I've been hearing that delegates get a context pointer which will be allocated on the GC. Is this also true for delegates which stay in scope? e.g. void addThree() { int val; void addOne() { val++; } addOne(); addOne(); addOne(); return val; } Will the above function allocate on the GC?
Re: Auto attributes for functions
On Wednesday, 20 August 2014 at 09:13:15 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: On Wed, 20 Aug 2014 01:38:52 + uri via Digitalmars-d-learn wrote: Hi all, Bit new to D so this might be a very naive question... Can the compiler auto infer function attributes? I am often adding as many attributes as possible and use the compiler to show me where they're not applicable and take them away. It would be great if this could be achieved like so: auto function() @auto {} instead of manually writing: auto function() pure @safe nothrow @nogc const {} Currently, just templated functions get their attributes inferred. The biggest problem with inferring them for all functions is that you can declare a function without defining it in the same place (e.g. if you're using .di files), in which case the compiler has no function body to use for attribute inferrence. There have been discussions on ways to reasonably infer attributes under more circumstances, but nothing has come of them yet. However, I'd expect that there will be at least some improvements to the situation at some point given that there is a general consensus that while the attributes are quite useful, it's also rather annoying to have to keep typing them all. - Jonathan M Davis Thanks guys for the info. /uri
Re: Auto attributes for functions
On Wed, 20 Aug 2014 01:38:52 + uri via Digitalmars-d-learn wrote: > Hi all, > > Bit new to D so this might be a very naive question... > > Can the compiler auto infer function attributes? > > I am often adding as many attributes as possible and use the > compiler to show me where they're not applicable and take them > away. It would be great if this could be achieved like so: > > auto function() @auto > {} > > instead of manually writing: > > auto function() pure @safe nothrow @nogc const > {} Currently, just templated functions get their attributes inferred. The biggest problem with inferring them for all functions is that you can declare a function without defining it in the same place (e.g. if you're using .di files), in which case the compiler has no function body to use for attribute inferrence. There have been discussions on ways to reasonably infer attributes under more circumstances, but nothing has come of them yet. However, I'd expect that there will be at least some improvements to the situation at some point given that there is a general consensus that while the attributes are quite useful, it's also rather annoying to have to keep typing them all. - Jonathan M Davis
Re: How to realize isSortedRange?
Thank you!
Re: How to realize isSortedRange?
On Wednesday, 20 August 2014 at 07:18:12 UTC, Kagamin wrote: http://dlang.org/phobos/std_traits.html#TemplateOf Or isInstanceOf. static if (__traits(isSame, TemplateOf!R, SortedRange)) static if (isInstanceOf!(SortedRange, R))
Re: How to realize isSortedRange?
http://dlang.org/phobos/std_traits.html#TemplateOf