Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with library solution. Implicit conversions are built into

Can't call nested template function unless it's anonymous?

/ test.d / // Call alias with a parameter. void callAlias(alias f)() { f(42); } alias Identity(alias X) = X; void main() { int local; // Declare an anonymous function template // which writes to a local. alias a =

Re: Align a variable on the stack.

On Wednesday, 4 November 2015 at 01:14:31 UTC, Nicholas Wilson wrote: Note that there are two different alignments: to control padding between instances on the stack (arrays) to control padding between members of a struct align(64) //arrays struct foo { align(16) short

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 21:22:04 UTC, ixid wrote: On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with

Re: Preventing implicit conversion

On Wednesday, November 04, 2015 21:22:02 ixid via Digitalmars-d-learn wrote: > On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: > > On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: > >> Is there an elegant way of avoiding implicit conversion to int > >> when you're using

looking for sdl2 based application skeleton

It seems to me I saw somewhere the project like this. I don't want to make another one if there is something like that.

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with library solution. Implicit conversions are built into language.

Re: good reasons not to use D?

On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. Sorry - I wrote this in a hurry, and I should have said on my experience of using D in finance (not the whole sector, which is absolutely enormous and very diverse),

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Also does this not seem inconsistent: ushort a = ushort.max, b = ushort.max; a += b; // Compiles fine a = a + b; // Error:

Preventing implicit conversion

Is there an elegant way of avoiding implicit conversion to int when you're using shorter types?

Re: foreach loop

On Tuesday, 3 November 2015 at 15:06:00 UTC, Namal wrote: Can you help me out please. Thx. reduce!((x, y) => x + !y)(0, arr).writeln; This would probably be the preferred way, that uses a lambda function (x, y) => x + !y which adds the inverse of the next array value (y) to the total so far

Re: good reasons not to use D?

On Tuesday, 3 November 2015 at 23:37:36 UTC, Chris wrote: On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: Interesting. Two points suggest that you should use D only for serious programming: "cases where you want to write quick one-off scripts that need to use a bunch of

Re: Help with Concurrency

On Tuesday, 3 November 2015 at 23:16:59 UTC, bertg wrote: while (true) { writeln("receiving..."); std.concurrency.receive( (string msg) { writeln("conn: received ws message: " ~ msg); } );

Re: good reasons not to use D?

On Wednesday, 4 November 2015 at 12:08:19 UTC, Laeeth Isharc wrote: this hardly matters for Java, C++, Python etc because mostly you won't need to use a bunch of different libraries. I meant mostly you won't need to go outside that ecosystem to use a bunch of different libraries whereas with

Re: good reasons not to use D?

On Wednesday, 4 November 2015 at 12:25:31 UTC, Laeeth Isharc wrote: On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: I'm writing a talk for codemesh on the use of D in finance. Sorry - I wrote this in a hurry, and I should have said on my experience of using D in finance (not

Re: Help with Concurrency

On Tuesday, 3 November 2015 at 23:16:59 UTC, bertg wrote: Running the following code I get 3 different tid's, multiple "sock in" messages printed, but no receives. I am supposed to get a "received!" for each "sock in", but I am getting hung up on "receiving...". [...] while (true)

Re: Preventing implicit conversion

V Wed, 04 Nov 2015 14:27:45 + ixid via Digitalmars-d-learn napsáno: > Is there an elegant way of avoiding implicit conversion to int > when you're using shorter types? http://dlang.org/phobos/std_typecons.html#.Typedef

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 17:26:04 UTC, Daniel Kozak wrote: V Wed, 04 Nov 2015 14:27:45 + ixid via Digitalmars-d-learn napsáno: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types?

Re: Help with Concurrency

On Wednesday, 4 November 2015 at 16:49:59 UTC, JR wrote: [...] And my indentation and brace-balancing there is wrong. Shows how dependent I've become on syntax highlighting. import core.time; import std.concurrency; bool received = receiveTimeout(1.seconds,

Re: How to detect overflow

On Wednesday, 4 November 2015 at 07:59:44 UTC, Ali Çehreli wrote: On 11/03/2015 11:52 PM, Namal wrote: http://dlang.org/phobos/core_checkedint.html It says: "The overflow is sticky, meaning a sequence of operations can be done and overflow need only be checked at the end." But how can I

Re: How to detect overflow

On 11/03/2015 11:52 PM, Namal wrote: http://dlang.org/phobos/core_checkedint.html It says: "The overflow is sticky, meaning a sequence of operations can be done and overflow need only be checked at the end." But how can I make multiple operations? I can only put 2 values in the function.

Re: How to detect overflow

On 11/04/2015 12:11 AM, Namal wrote: >> import core.checkedint; >> >> void main() { >> bool overflowed; >> auto result = adds(int.max, 1, overflowed); // this overflows >> adds(1, 2, overflowed); // this does not reset the flag >> >> assert(overflowed); >> } >> >> Ali > >

Re: How to detect overflow

On 11/03/2015 11:34 PM, BBasile wrote: On Wednesday, 4 November 2015 at 07:19:09 UTC, Ali Çehreli wrote: On 11/03/2015 10:34 PM, Namal wrote: http://dlang.org/phobos/core_checkedint.html Is it just an error in the documentation that the return value is stated as sum for the multiplication

Re: Is it possible to filter variadics?

On Wednesday, 4 November 2015 at 06:20:30 UTC, Jakob Ovrum wrote: On Tuesday, 3 November 2015 at 23:41:10 UTC, maik klein wrote: [...] import std.algorithm.iteration : sum; import std.meta : allSatisfy, Filter; import std.traits; import std.typecons : tuple; import std.range : only; // These

Re: How to detect overflow

On Wednesday, 4 November 2015 at 08:18:00 UTC, Ali Çehreli wrote: Thanks. I've noticed that the parameter of the subtraction functions should be named 'underflow', no? Integer math cannot underflow, unless you define division to be equivalent to division over reals. overflow => higher/lower

Re: How to detect overflow

On 11/04/2015 02:01 AM, Ola Fosheim Grøstad wrote: On Wednesday, 4 November 2015 at 08:18:00 UTC, Ali Çehreli wrote: Thanks. I've noticed that the parameter of the subtraction functions should be named 'underflow', no? Integer math cannot underflow, unless you define division to be equivalent

Re: Is it possible to filter variadics?

On Wednesday, 4 November 2015 at 09:48:40 UTC, maik klein wrote: Thanks, that is exactly what I wanted to achieve. What is the performance implication of 'only' in this context? Will it copy all arguments? Yes, it will, but just from the stack to a different location on stack.

Re: How to detect overflow

On Wednesday, 4 November 2015 at 10:06:47 UTC, Ali Çehreli wrote: Thanks. It looks like I've been making stuff up on this page: :( http://ddili.org/ders/d.en/arithmetic.html It's a common source for confusion, the word "underflow" is a bit misleading. Maybe better to use the term