On 6 September 2016 at 21:28, Timon Gehr via Digitalmars-d
wrote:
> On 06.09.2016 08:07, Manu via Digitalmars-d wrote:
>>
>> I have weird thing:
>>
>> template E(F){
>> enum E {
>> K = F(1)
>> }
>> }
>>
>> struct S(F = float, alias e_ = E!double.K) {}
>> S!float x; // Error: E!doub
On 06.09.2016 08:07, Manu via Digitalmars-d wrote:
I have weird thing:
template E(F){
enum E {
K = F(1)
}
}
struct S(F = float, alias e_ = E!double.K) {}
S!float x; // Error: E!double.K is used as a type
alias T = E!double.K;
struct S2(F = float, alias e_ = T) {}
S2!float y; //
On 06/09/2016 6:42 PM, rikki cattermole wrote:
On 06/09/2016 6:23 PM, Manu via Digitalmars-d wrote:
On 6 September 2016 at 16:10, rikki cattermole via Digitalmars-d
wrote:
On 06/09/2016 6:07 PM, Manu via Digitalmars-d wrote:
I have weird thing:
template E(F){
enum E {
K = F(1)
On 06/09/2016 6:23 PM, Manu via Digitalmars-d wrote:
On 6 September 2016 at 16:10, rikki cattermole via Digitalmars-d
wrote:
On 06/09/2016 6:07 PM, Manu via Digitalmars-d wrote:
I have weird thing:
template E(F){
enum E {
K = F(1)
}
}
struct S(F = float, alias e_ = E!double.
On 6 September 2016 at 16:10, rikki cattermole via Digitalmars-d
wrote:
> On 06/09/2016 6:07 PM, Manu via Digitalmars-d wrote:
>>
>> I have weird thing:
>>
>> template E(F){
>> enum E {
>> K = F(1)
>> }
>> }
>>
>> struct S(F = float, alias e_ = E!double.K) {}
>
> typeof(E!double.K)
On 06/09/2016 6:07 PM, Manu via Digitalmars-d wrote:
I have weird thing:
template E(F){
enum E {
K = F(1)
}
}
struct S(F = float, alias e_ = E!double.K) {}
typeof(E!double.K)
S!float x; // Error: E!double.K is used as a type
alias T = E!double.K;
struct S2(F = float, alias e_
I have weird thing:
template E(F){
enum E {
K = F(1)
}
}
struct S(F = float, alias e_ = E!double.K) {}
S!float x; // Error: E!double.K is used as a type
alias T = E!double.K;
struct S2(F = float, alias e_ = T) {}
S2!float y; // alias makes it okay...
struct S3(F = float, alias e
On Wednesday, 16 March 2016 at 18:39:36 UTC, Mathias Lang wrote:
Sadly, to solve that without imposing much pain on the users,
you need a more decent VRP than we currently have,
I just read Walter's Dr. Dobbs article on VRP:
http://www.drdobbs.com/tools/value-range-propagation/229300211
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
Please consider the following program, which is a reduced
version of a problem I've spent the entire of today trying to
debug:
import std.stdio;
void main() {
enum ulong MAX_VAL = 256;
long value = -500;
if( valu
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
...
People who are marginally familiar with integer promotion will
not be surprised to know that the program prints "256". What is
surprising to me is that this produced neither error nor
warning.
The comparable program in
On Thursday, 17 March 2016 at 09:13:34 UTC, tsbockman wrote:
You could use the `DebugInt` wrapper. It aliases to `SafeInt`
in debug and unittest mode, to find problems (many, including
the specific one in this thread, are detected at compile time).
Then, in release mode, it aliases to the bui
On Thursday, 17 March 2016 at 12:35:27 UTC, Basile B wrote:
import std.traits;
bool safeIntegralCmp(string op, L, R)(auto ref L lhs, auto ref
R rhs)
if (isIntegral!R && isIntegral!L)
{
// safe
static if (is(Unqual!L == Unqual!R))
{
mixin("return lhs" ~ op ~ "rhs;");
}
On Thursday, 17 March 2016 at 09:13:34 UTC, tsbockman wrote:
On Thursday, 17 March 2016 at 06:55:34 UTC, Shachar Shemesh
wrote:
On 16/03/16 23:50, tsbockman wrote:
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
...
People who are marginally familiar with integer promotion
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
Please consider the following program, which is a reduced
version of a problem I've spent the entire of today trying to
debug:
import std.stdio;
void main() {
enum ulong MAX_VAL = 256;
long value = -500;
if( valu
On Thursday, 17 March 2016 at 09:59:41 UTC, Dominikus Dittes
Scherkl wrote:
Or you can use an improved opCmp implementation in the
compiler, that only add additional runtime cost, [...]
The compiler could statically fix two cases, ALWAYS without
runtime cost. I think that FPC does this: operan
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
People who are marginally familiar with integer promotion will
not be surprised to know that the program prints "256". What is
surprising to me is that this produced neither error nor
warning.
Here's a simpler example:
i
On Thursday, 17 March 2016 at 09:59:41 UTC, Dominikus Dittes
Scherkl wrote:
Or you can use an improved opCmp implementation in the
compiler, that only add additional runtime cost, if someone is
stupid enough to compare signed with unsigned values - but
yield the correct result:
I should also
Please consider the following program, which is a reduced version of a
problem I've spent the entire of today trying to debug:
import std.stdio;
void main() {
enum ulong MAX_VAL = 256;
long value = -500;
if( value>MAX_VAL )
value = MAX_VAL;
writeln(value);
}
People wh
https://issues.dlang.org/show_bug.cgi?id=259
On Thursday, 17 March 2016 at 06:55:34 UTC, Shachar Shemesh wrote:
On 16/03/16 23:50, tsbockman wrote:
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
...
People who are marginally familiar with integer promotion
will not be
surprised to know that the program prints "256".
On 16/03/16 23:50, tsbockman wrote:
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote:
...
People who are marginally familiar with integer promotion will not be
surprised to know that the program prints "256". What is surprising to
me is that this produced neither error nor war
On Thursday, 17 March 2016 at 09:59:41 UTC, Dominikus Dittes
Scherkl wrote:
Or you can use an improved opCmp implementation in the
compiler, that only add additional runtime cost, if someone is
stupid enough to compare signed with unsigned values - but
yield the correct result:
For the signed
On Wednesday, 16 March 2016 at 18:39:36 UTC, Mathias Lang wrote:
Sadly, to solve that without imposing much pain on the users,
you need a more decent VRP than we currently have...
Lionello Lunesu did a lot of work both on improving VRP, and on
bug 259:
https://github.com/D-Programming-Lan
23 matches
Mail list logo
