Re: Is old style compile-time foreach redundant?

On 01/06/2018 10:53 PM, Ali Çehreli wrote: On 01/06/2018 06:20 PM, Seb wrote: How about doing sth. similar like for DIP1003? https://dlang.org/spec/contracts.html#pre_post_contracts Already done! :) https://bitbucket.org/acehreli/ddili/commits/2f10c048c2940a49263319d0c23b0ad661449f3e

Re: Is old style compile-time foreach redundant?

On 01/06/2018 06:20 PM, Seb wrote: How about doing sth. similar like for DIP1003? https://dlang.org/spec/contracts.html#pre_post_contracts Already done! :) https://bitbucket.org/acehreli/ddili/commits/2f10c048c2940a49263319d0c23b0ad661449f3e Ali

Re: Is old style compile-time foreach redundant?

On Sunday, 7 January 2018 at 01:52:10 UTC, Ali Çehreli wrote: On 01/06/2018 04:55 PM, Stefan Koch wrote: > When you can use the old style do so. Since it puts less stress on the > compiler in the general case. My question is related to how to update my book. If the difference is mainly about

Re: Is old style compile-time foreach redundant?

On Sunday, 7 January 2018 at 01:08:44 UTC, H. S. Teoh wrote: On Sun, Jan 07, 2018 at 12:55:27AM +, Stefan Koch via Digitalmars-d-learn wrote: On Saturday, 6 January 2018 at 23:25:58 UTC, Ali Çehreli wrote: > Is 'static foreach' sufficient for all needs or is there any > value for regular

Re: Templates for DRY code

On Saturday, 6 January 2018 at 23:32:42 UTC, Paul Backus wrote: On Saturday, 6 January 2018 at 03:38:35 UTC, codephantom wrote: or even.. a.append( s.to!ConvertToElementType(a) ); That's not valid code of course, but the semantics are all contained in that single chunk. This works: import

Re: Is old style compile-time foreach redundant?

On 01/06/2018 04:55 PM, Stefan Koch wrote: > When you can use the old style do so. Since it puts less stress on the > compiler in the general case. My question is related to how to update my book. If the difference is mainly about performance, I think I will cover 'static foreach' but also

Re: Is old style compile-time foreach redundant?

On Sun, Jan 07, 2018 at 12:55:27AM +, Stefan Koch via Digitalmars-d-learn wrote: > On Saturday, 6 January 2018 at 23:25:58 UTC, Ali Çehreli wrote: > > Is 'static foreach' sufficient for all needs or is there any value > > for regular foreach over compile-time sequences? [...] > No it's not. >

Re: Is old style compile-time foreach redundant?

On Saturday, 6 January 2018 at 23:25:58 UTC, Ali Çehreli wrote: Is 'static foreach' sufficient for all needs or is there any value for regular foreach over compile-time sequences? Code unrelated to the question: import std.stdio; void main() { // Old style compile-time foreach. This

Re: Is old style compile-time foreach redundant?

On Saturday, 6 January 2018 at 23:25:58 UTC, Ali Çehreli wrote: Is 'static foreach' sufficient for all needs or is there any value for regular foreach over compile-time sequences? There is, as far as I've seen, there's nothing old foreach-over-tuple can do that new-style static foreach can't.

Re: Why is "array operation without destination memory not allowed"?

On Saturday, 6 January 2018 at 23:17:53 UTC, Ali Çehreli wrote: So, apparently a[] * 2 is not an expression in D. The reason must be for performance. If a[]*2 were an expression, the runtime would have to allocate memory and put the results there. Assigning that memory then to b[] would

Re: Templates for DRY code

On Saturday, 6 January 2018 at 03:38:35 UTC, codephantom wrote: or even.. a.append( s.to!ConvertToElementType(a) ); That's not valid code of course, but the semantics are all contained in that single chunk. This works: import std.range.primitives: ElementType; a ~=

Is old style compile-time foreach redundant?

Is 'static foreach' sufficient for all needs or is there any value for regular foreach over compile-time sequences? Code unrelated to the question: import std.stdio; void main() { // Old style compile-time foreach. This still works // when 'static' is uncommented below. import

Re: Why is "array operation without destination memory not allowed"?

On 01/06/2018 03:08 PM, Lily wrote: It seems a bit silly that I have to write int[] a = [1, 2, 300, -29]; int[] b; b.length = 4; b[] = a[] * 2; writeln(b); to do what I would expect int[] a = [1, 2, 300, -29]; writeln(a[] * 2); to do. What am I not understanding? So, apparently a[] * 2 is

Re: Why is "array operation without destination memory not allowed"?

On Saturday, 6 January 2018 at 23:08:14 UTC, Lily wrote: What am I not understanding? Where do you expect it to put the result?

Re: TemplateOf behavior

On Saturday, 6 January 2018 at 22:25:48 UTC, ag0aep6g wrote: On Saturday, 6 January 2018 at 19:58:10 UTC, Alex wrote: template T(alias S) { struct T { this(int dummy) { static assert(__traits(isSame, TemplateOf!(T!arr), T)); } } } Now

Why is "array operation without destination memory not allowed"?

It seems a bit silly that I have to write int[] a = [1, 2, 300, -29]; int[] b; b.length = 4; b[] = a[] * 2; writeln(b); to do what I would expect int[] a = [1, 2, 300, -29]; writeln(a[] * 2); to do. What am I not understanding?

Re: How to concatenate a tuple of strings at compile time?

Thanks for the input. Unfortunately I still can't convince the compiler. __traits allMembers includes functions. Trying to filter those with std.traits.isCallable, it complains about strings that can't be read or fields that can't be accessed at compile time. Affected are both solutions.

Re: TemplateOf behavior

On Saturday, 6 January 2018 at 19:58:10 UTC, Alex wrote: Given the code above, why the static assert inside the mixing template constructor yields false, while the others yield true? Let's resolve the mixin and write out the `T` template in the verbose form. It looks like this then:

Re: How to concatenate a tuple of strings at compile time?

On Saturday, 6 January 2018 at 21:41:56 UTC, user1205 wrote: On Saturday, 6 January 2018 at 21:38:41 UTC, user1205 wrote: On Saturday, 6 January 2018 at 21:35:19 UTC, user1205 wrote: On Saturday, 6 January 2018 at 19:35:33 UTC, paul wrote: Hi! How to concatenate a tuple of strings at

Re: How to concatenate a tuple of strings at compile time?

On Saturday, 6 January 2018 at 21:38:41 UTC, user1205 wrote: On Saturday, 6 January 2018 at 21:35:19 UTC, user1205 wrote: On Saturday, 6 January 2018 at 19:35:33 UTC, paul wrote: Hi! How to concatenate a tuple of strings at compile time? [...] Hello, this simple template does the job: ```

Re: How to concatenate a tuple of strings at compile time?

On Saturday, 6 January 2018 at 19:35:33 UTC, paul wrote: Hi! How to concatenate a tuple of strings at compile time? [...] Hello, this simple template does the job: ``` template staticCat(T...) if (T.length) { static if (T.length == 1) enum staticCat = T[0]; else static if

Re: How to concatenate a tuple of strings at compile time?

On Saturday, 6 January 2018 at 21:35:19 UTC, user1205 wrote: On Saturday, 6 January 2018 at 19:35:33 UTC, paul wrote: Hi! How to concatenate a tuple of strings at compile time? [...] Hello, this simple template does the job: ``` template staticCat(T...) if (T.length) { static if

Re: How to concatenate a tuple of strings at compile time?

On Saturday, 6 January 2018 at 19:35:33 UTC, paul wrote: Hi! How to concatenate a tuple of strings at compile time? Something like that maybe ? import std.stdio; import std.meta; enum connected = () { auto something = AliasSeq!("one", "two", "three"); string res = ""; static

TemplateOf behavior

//code starts import std.traits; void main() { static assert(__traits(isSame, TemplateOf!(T!arr), T)); } size_t[] arr; struct T(alias S) { mixin Contents!() contents; this(Args)(ref Args args) { contents.__ctor(42); } } static

How to concatenate a tuple of strings at compile time?

Hi! How to concatenate a tuple of strings at compile time? Appending to an enum or an immutable string in a static foreach doesn't work. (And shadowing the thing doesn't work either) a) Calling a function recursively doesn't work because I had to turn the tuple into an array which cannot be

Re: Help optimizing UnCompress for gzipped files

On 05.01.18 23:04, Steven Schveighoffer wrote: > On 1/5/18 3:09 PM, Christian Köstlin wrote: >> On 05.01.18 15:39, Steven Schveighoffer wrote: >>> Yeah, I guess most of the bottlenecks are inside libz, or the memory >>> allocator. There isn't much optimization to be done in the main program >>>

Re: Error: variable i cannot be read at compile time

On Saturday, 6 January 2018 at 06:47:33 UTC, Vino wrote: On Friday, 5 January 2018 at 18:00:34 UTC, thedeemon wrote: On Friday, 5 January 2018 at 17:59:32 UTC, thedeemon wrote: Tuple!( staticMap!(Arr, ColumnTypes) ) res; // array of tuples Sorry, I meant tuple of arrays, of course. Hi

Re: C++ Interop

On Saturday, 6 January 2018 at 13:51:54 UTC, qznc wrote: It would be great to have std::vector and std::string out of the box in D, but putting it into druntime? Druntime is supposed to be shared among all frontends, isn't it? GCC and Clang probably do not have equivalent vector/string classes

Passing Template to Function

Hi All, Request you help on the below program as it error out with the below error Error: UDictCompression.d(31): Error: template UDictCompression.compress cannot deduce function from argument types !()(string), candidates are: UDictCompression.d(19):

Re: Error: non-shared method Node.~this is not callable using a shared object

On Saturday, 6 January 2018 at 11:23:13 UTC, ChangLong wrote: This code is not working. --- shared struct Stack { Node n = void ; } struct Node { ~this() {} } --- Error: non-shared method test.Node.~this is not callable using a shared

Re: Does dub support generating source files?

On Saturday, 6 January 2018 at 13:40:54 UTC, rikki cattermole wrote: On 06/01/2018 1:23 PM, Bastiaan Veelo wrote: I could script a custom preBuildCommand that checks modification dates and supplies the Pegged include path explicitly but that seems hackish and non-portable and typically

Re: C++ Interop

On Saturday, 6 January 2018 at 11:20:01 UTC, Seb wrote: On Saturday, 6 January 2018 at 11:17:56 UTC, Seb wrote: On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote: I'm exploring [0] C++ interop after watching Walter's presentation [1]. [...] I know about this:

Re: Does dub support generating source files?

On Saturday, 6 January 2018 at 13:40:54 UTC, rikki cattermole wrote: On 06/01/2018 1:23 PM, Bastiaan Veelo wrote: Can dub do this or is this a thing for reggae? It must work on Windows though. Thanks! See: https://github.com/Abscissa/gen-package-version That seems to be a good tip,

Re: -L--demangle=dlang doesn't work

On Saturday, 6 January 2018 at 05:44:28 UTC, Venkat wrote: Why does gcc say "unknown demangling style `dlang'" ? Do I need GDC for demangling to work ? Check your version of binutils with `ld --version`. It looks like it was added in v2.25:

Re: Does dub support generating source files?

On 06/01/2018 1:23 PM, Bastiaan Veelo wrote: Hi, One of my source files (epparser.d) should be generated by calling rdmd on another soure file (make.d) and therefore should depend on changes in make.d and an additional module (epgrammar.d). An include path to Pegged is required for

Does dub support generating source files?

Hi, One of my source files (epparser.d) should be generated by calling rdmd on another soure file (make.d) and therefore should depend on changes in make.d and an additional module (epgrammar.d). An include path to Pegged is required for compilation. epparser.d should be part of the main

Re: C++ Interop

On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote: I'm exploring [0] C++ interop after watching Walter's presentation [1]. I hit a block with classes as template parameters. This means vector works, but vector does not. D seems to map vector!Foo to vector. Likewise shared_ptr is a

Error: non-shared method Node.~this is not callable using a shared object

This code is not working. --- shared struct Stack { Node n = void ; } struct Node { ~this() {} } --- Error: non-shared method test.Node.~this is not callable using a shared object Is this a bug ? Node.~this is not called from Stack.

Re: C++ Interop

On Saturday, 6 January 2018 at 11:17:56 UTC, Seb wrote: On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote: I'm exploring [0] C++ interop after watching Walter's presentation [1]. [...] I know about this: https://github.com/Remedy-Entertainment/binderoo

Re: C++ Interop

On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote: I'm exploring [0] C++ interop after watching Walter's presentation [1]. [...] I know about this: https://github.com/Remedy-Entertainment/binderoo https://github.com/dlang/druntime/pull/1802

Re: Templates for DRY code

On Saturday, 6 January 2018 at 03:08:19 UTC, Ali Çehreli wrote: I agree with your point as well. A better name can help there a little. void ConvertAndAppend(T, S)(ref T[] arr, S s) { arr ~= s.to!T; } problem solved ;-) btw. I never thought that I would be able (or actually..willing)

Re: Error: variable i cannot be read at compile time

On Saturday, 6 January 2018 at 06:47:33 UTC, Vino wrote: On Friday, 5 January 2018 at 18:00:34 UTC, thedeemon wrote: On Friday, 5 January 2018 at 17:59:32 UTC, thedeemon wrote: Tuple!( staticMap!(Arr, ColumnTypes) ) res; // array of tuples Sorry, I meant tuple of arrays, of course. Hi