Re: Template constructor in a non-template struct.
On Monday, 9 February 2015 at 09:52:13 UTC, Marc Schütz wrote: You could also hide the ugly __ctor() call behind a nicely named factory method. Yes, that's pretty much what I ended up doing. Added a couple static member functions like: static Boring CreateWithOption1(args); static Boring CreateWithOption2(args); Then made the struct constructor private. Not too bad for now. Thanks for your help.
Re: Explicit Interface Implementation
On 02/14/2015 12:13 PM, Adam D. Ruppe wrote:
On Saturday, 14 February 2015 at 20:08:09 UTC, Ali Çehreli wrote:
int foo()
{
return 42;
}
the difference is C# also allows you to implement A.foo separately from
B.foo. I don't think D allows that.
Yeah, I obviously read too little of the C# document. Basically, I
implemented their presentation of the problem. :)
Ali
Re: The best way to compare floating point values.
On Saturday, 14 February 2015 at 10:23:48 UTC, Gary Willoughby wrote: I wrote a similar function here: https://github.com/nomad-software/dunit/blob/master/source/dunit/toolkit.d#L42 or using an epsilon value: https://github.com/nomad-software/dunit/blob/master/source/dunit/toolkit.d#L134 I don't know if they are useful to you? Very interesting. Thanks.
Re: std.conv.to purity
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
'cause float-string conversion is damned hard task. to perform this
conversion `to!` falls back to `formatValue` from std.format, which in
turn using `snprintf()` from libc.
signature.asc
Description: PGP signature
Re: The best way to compare floating point values.
On Saturday, 14 February 2015 at 09:37:05 UTC, Jack Applegame
wrote:
I wrote this function for comparing two floating point values:
import std.math;
import std.traits;
bool isEqual(T)(T v1, T v2) if(isFloatingPoint!T) {
return T.mant_dig - feqrel(v1, v2) 2;
}
What do you think about it?
I wrote a similar function here:
https://github.com/nomad-software/dunit/blob/master/source/dunit/toolkit.d#L42
or using an epsilon value:
https://github.com/nomad-software/dunit/blob/master/source/dunit/toolkit.d#L134
I don't know if they are useful to you?
std.conv.to purity
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
Re: The best way to compare floating point values.
There is an approxEqual in std.math, in addition in feqrel: http://dlang.org/phobos/std_math.html#.approxEqual It takes maximum absolute and relative difference as arguments.
The best way to compare floating point values.
I wrote this function for comparing two floating point values:
import std.math;
import std.traits;
bool isEqual(T)(T v1, T v2) if(isFloatingPoint!T) {
return T.mant_dig - feqrel(v1, v2) 2;
}
What do you think about it?
Re: What is the Correct way to Malloc in @nogc section?
On Sat, 14 Feb 2015 07:59:51 +, weaselcat wrote: how smart pointers can help here? they don't magically hiding all the low-level mechanics. The file he was referring to was a smart pointer implementation. *one* of the files. signature.asc Description: PGP signature
Re: dmd-2.067.0-b1
It is your profile? http://www.cyberforum.ru/members/491746.html
Re: How to make a Currency class from std.BigInt?
The next version https://bpaste.net/show/dc3c5f10f2ca I use https://github.com/dsimcha/Rational/blob/master/rational.d I want to do it: auto c = new Currencies!Rational.rational.Rational!(BigInt); where Rational.rational.Rational it is std.rational.Rational I get the error: Error: template instance Currencies!(Rational) does not match template declaration Currencies(T)
Explicit Interface Implementation
Does D provide a way for explicit interface implementation? [C#] https://msdn.microsoft.com/en-us/library/ms173157.aspx
Re: Explicit Interface Implementation
ref2401 wrote:
Does D provide a way for explicit interface implementation?
[C#] https://msdn.microsoft.com/en-us/library/ms173157.aspx
Not exactly, but you may try something like this:
interface A
{
void foo();
}
interface B
{
void foo();
}
class C : A
{
class Nested : B
{
void foo()
{
this.outer.fooB();
}
}
Nested nested;
alias nested this;
this()
{
nested = this.new Nested;
}
void foo()
{
import std.stdio : writeln;
writeln(A's foo);
}
void fooB()
{
import std.stdio : writeln;
writeln(B's foo);
}
}
void main()
{
C c = new C;
A a = c;
B b = c;
a.foo();
b.foo();
}
Prints:
A's foo
B's foo
Re: std.conv.to purity
On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
'cause float-string conversion is damned hard task. to perform
this
conversion `to!` falls back to `formatValue` from std.format,
which in
turn using `snprintf()` from libc.
Forgive me being a bit dense but that doesn't necessarily mean
it's impure though, right?
Re: Explicit Interface Implementation
On 02/14/2015 09:19 AM, ref2401 wrote:
Does D provide a way for explicit interface implementation?
[C#] https://msdn.microsoft.com/en-us/library/ms173157.aspx
Apparently, yes:
interface A
{
int foo();
}
interface B
{
int foo();
}
class C : A, B
{
int foo()
{
return 42;
}
}
void main()
{
auto c = new C();
A a = c;
B b = c;
assert(a.foo() == 42);
assert(b.foo() == 42);
}
Ali
Re: Explicit Interface Implementation
On Saturday, 14 February 2015 at 20:08:09 UTC, Ali Çehreli wrote:
int foo()
{
return 42;
}
the difference is C# also allows you to implement A.foo
separately from B.foo. I don't think D allows that.
You can call a specific interface at the usage site, but
implementing the function differently is something I don't think
we can do.
Re: std.conv.to purity
On Sat, 14 Feb 2015 19:59:58 +, Gary Willoughby wrote:
On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
'cause float-string conversion is damned hard task. to perform this
conversion `to!` falls back to `formatValue` from std.format,
which in turn using `snprintf()` from libc.
Forgive me being a bit dense but that doesn't necessarily mean it's
impure though, right?
yes, you are right, it *may* be pure. yet `snprintf()` can't be marked as
`pure`, so it contaminates everything. and there are no guarantees that
`snprintf()` is pure even for known arguments (compiler can't prove that,
and libc is free to do any funny things in it), so it will be wrong to
just force-reimport it as `pure`.
tl;dr: we need native D float-string converter to allow purity in this
case. you are free to force-hack purity flag on function if you want, but
this can be wrong and may lead to various heisenbugs.
native pure D converter will also allow CTFE, btw, which is impossible
now.
signature.asc
Description: PGP signature
Re: std.conv.to purity
While snprintf might be one thing that provides to be an interesting
obstacle, the better answer to why std.conv.to isnt pure is that no one
has invested the time to work through issues like that to make it so.
It _should_ be pure.
On 2/14/2015 12:32 PM, ketmar via Digitalmars-d-learn wrote:
On Sat, 14 Feb 2015 19:59:58 +, Gary Willoughby wrote:
On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
'cause float-string conversion is damned hard task. to perform this
conversion `to!` falls back to `formatValue` from std.format,
which in turn using `snprintf()` from libc.
Forgive me being a bit dense but that doesn't necessarily mean it's
impure though, right?
yes, you are right, it *may* be pure. yet `snprintf()` can't be marked as
`pure`, so it contaminates everything. and there are no guarantees that
`snprintf()` is pure even for known arguments (compiler can't prove that,
and libc is free to do any funny things in it), so it will be wrong to
just force-reimport it as `pure`.
tl;dr: we need native D float-string converter to allow purity in this
case. you are free to force-hack purity flag on function if you want, but
this can be wrong and may lead to various heisenbugs.
native pure D converter will also allow CTFE, btw, which is impossible
now.
foreach filter by cast
Is there a brief way to iterate an array of objects, and process
only objects of certain type (in either two ways, with/without
inheritance)?
foreach(p; obj.children){ // KObj[] children
DPFile dfile = cast(DPFile)p;
if(!dfile)continue;
...
}
I saw the std.algorithm.filter template helper could be used, but
it's a bit complex:
foreach(unit; file.children.filter!(a = cast(KUnit)a)){
...
}
Thanks
Re: foreach filter by cast
I found a solution I like a lot, with templated opApply:
class Cont{
Thing[] kids;
int opApply(T)(int delegate(ref T) dg){
int result = 0;
for (int i = 0; i kids.length; i++){
T t = cast(T)kids[i];
if(t){ result = dg(t);
if (result) break;
}
}
return result;
}
}
class Thing{
string name;
this(){ name = thing;}
}
class TBan : Thing{
this(){ name = tban;}
}
class TOne : Thing{
this(){ name = tone;}
}
void main(){
Cont c = new Cont;
c.kids ~= new TBan;
c.kids ~= new TOne;
c.kids ~= new TOne;
c.kids ~= new Thing;
foreach(TOne k; c){ // the TOne k declares the filtering-type
writeln(k);
}
}
Re: What is the Correct way to Malloc in @nogc section?
On Saturday, 14 February 2015 at 06:38:19 UTC, ketmar wrote: On Sat, 14 Feb 2015 00:57:33 +, weaselcat wrote: On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote: On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote: This is something I've done recently. Would be glad if my code will help you: https://github.com/Dgame/m3 Especially the m3.d module could be useful for you. /* Class and Struct */ emplace: You can't assume zero-initialization for structs. destruct: Is not memory-safe, and must not be marked @trusted. /* Array */ make: You can't assume zero-initialization. T.sizeof is not the size of an element. reserve: Not safe (you're freeing the old memory), must not be @trusted. append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`. destruct: Not safe, must not be @trusted. Low level memory management isn't easy. Bugs like these wouldn't exist if D had decent smart pointer implementations in its standard library. You seem knowledgeable enough, care to lend a hand? ; ) how smart pointers can help here? they don't magically hiding all the low-level mechanics. The file he was referring to was a smart pointer implementation.
Re: Number of Bits Needed to Represent a Zero-Offset Integer
On Friday, 13 February 2015 at 22:39:10 UTC, bearophile wrote: H. S. Teoh: So it could be called ilog2? Perhaps floorIlog2? Isn't ilog2 a different function? Bye, bearophile I think the naming depends on use context, so it is reasonable to land on different names in different domains. Maybe the standard notation should be ffs(x): http://en.wikipedia.org/wiki/Find_first_set I like to think of it as position of most significant bit, msbpos(x), but the trouble with non log2 names is that you have to decide wether to count from 0 or 1... The advantage with counting from 1 is that ffs(0) could be 0, whereas with counting from 0 you need to return -1 or fail... Maybe one should have both, log2 that fails and a msb-counting one that does not fail.
Re: Number of Bits Needed to Represent a Zero-Offset Integer
On Saturday, 14 February 2015 at 08:01:27 UTC, Ola Fosheim Grøstad wrote: I think the naming depends on use context, so it is reasonable to land on different names in different domains. Maybe the standard notation should be ffs(x): Oops, I meant fls(x)... I just woke up :-P. It is a bad name anyway... first and last, left or right...? msb position or integer log2 in some form is better... Just floor log2 with overloading might be good enough.
