Help with an algorithm!
There are two arrays of string [] mas1, mas2; Size of each about 5M lines. By the size they different, but lines in both match for 95%. It is necessary to find all lines in an array of mas2 which differ from mas1. The principal criterion - speed. There are the 8th core processor and it is good to involve a multithreading.
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 22:29:08 UTC, Balagopal Komarath
wrote:
On Wednesday, 14 June 2017 at 21:04:55 UTC, basile b. wrote:
The way to do that in D is with mixins:
That is an interesting solution.
However, my original goal was to figure out whether one can
make struct types behave polymorphically (Which is not
mentioned in my original question). I know that this is not
supported by design. I want to keep the original struct types
but also allow functions to accept those struct types and do
runtime dispatch. The following code should give a better idea
by what I mean by this.
https://dpaste.dzfl.pl/051f6a4da059
The user need only define Duck1, Duck2 ... with appropriate
functions and mixin toDuck. Then a function that accepts a Duck
can accept DuckLike (for dynamic dispatch) or templatize on the
type of Duck.
Duck typing doesn't work with the pattern you used initially.
The pattern you used initially is much more similar to the
solution i exposed.
The point is that "alias" cant do what you wished.
It's not in the language, end of story.
Finally duck types in D are more like this:
enum looksLikeaDuck(T) = __traits(hasMember, T, "quack");
class Test(T)
if (looksLikeaDuck!T)
{
T data;
alias data this;
}
struct Duck
{
void quack()
{
import std.stdio;
writeln("Quack");
}
}
void main()
{
Test!Duck d;
}
you use traits to verify that the template parameter looks like a
duck.
It's not like in Swift where an aggregate is used.
In D we use traits (even if traits can be used to verify that a
template parameter is compliant with the member of an aggregate).
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 21:04:55 UTC, basile b. wrote: The way to do that in D is with mixins: That is an interesting solution. However, my original goal was to figure out whether one can make struct types behave polymorphically (Which is not mentioned in my original question). I know that this is not supported by design. I want to keep the original struct types but also allow functions to accept those struct types and do runtime dispatch. The following code should give a better idea by what I mean by this. https://dpaste.dzfl.pl/051f6a4da059 The user need only define Duck1, Duck2 ... with appropriate functions and mixin toDuck. Then a function that accepts a Duck can accept DuckLike (for dynamic dispatch) or templatize on the type of Duck.
Re: Builtin array-scalar equality
On Wednesday, 14 June 2017 at 21:15:32 UTC, Nordlöw wrote: Why isn't bool c = a[] == 4; allowed when a[] = b[] + 4; is? given that int[] a, b; That's just how it is. There are a lot of array-wise operations that *could* be implemented in the language but aren't.
Builtin array-scalar equality
Why isn't bool c = a[] == 4; allowed when a[] = b[] + 4; is? given that int[] a, b;
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 09:34:27 UTC, Balagopal Komarath
wrote:
Why doesn't this work? The Test!Duck type has a void quack()
method but the compiler says it is not implemented.
import std.stdio;
interface IDuck
{
void quack();
}
class Test(T) : IDuck
{
T data;
alias data this;
}
struct Duck
{
void quack()
{
writeln("Quack");
}
}
void main()
{
Test!Duck d;
}
The way to do that in D is with mixins:
interface IDuck
{
void quack();
}
class Test(alias MyImpl) : IDuck
{
mixin MyImpl;
}
mixin template DuckImpl()
{
void quack()
{
import std.stdio;
writeln("Quack Quack");
}
}
void main()
{
(new Test!DuckImpl).quack;
}
Re: Implementing interfaces using alias this
Balagopal Komarath wrote: On Wednesday, 14 June 2017 at 11:40:02 UTC, ketmar wrote: interfaces *require* a full-featured class, with VMT, and some hidden pointers to support hidden interface machinery. I don't think that is the problem here. The type Test!Duck is a class and that type is the one implementing the interface. *sighs*
Re: D and memory mapped devices
On 2017-06-14 11:04, Rene Zwanenburg wrote: I've casted void buffers to structs containing bitfields to read pre-existing binary files, and that worked just fine. I don't see why it would be different for memory mapped devices. What do yo mean by 'do more'? This bitfield discussion came up in a DStep issue [1]. The bitfields mixin will generate a field to store the bits in, which I think was surprising for Russel. Although, currently there are no other way to specify which other field should be used for storage. Another issue that came up is that you can use the default generated constructor or the struct initializer syntax to bypass the generate methods and set the underlying storage field directly. [1] https://github.com/jacob-carlborg/dstep/issues/151 -- /Jacob Carlborg
Re: D and memory mapped devices
On Wednesday, 14 June 2017 at 08:10:57 UTC, Russel Winder wrote: This would appear a priori to not allow for actual memory mapped devices using it, or am I missing something? I believe the only case where it might matter is if the device was sensitive to the read/write size (1/2/4 bytes). Otherwise, the generated code should be functionally the same as C bitfields.
Re: Implementing interfaces using alias this
On 6/14/17 5:34 AM, Balagopal Komarath wrote:
Why doesn't this work? The Test!Duck type has a void quack() method but
the compiler says it is not implemented.
import std.stdio;
interface IDuck
{
void quack();
}
class Test(T) : IDuck
{
T data;
alias data this;
}
struct Duck
{
void quack()
{
writeln("Quack");
}
}
void main()
{
Test!Duck d;
}
An alias never causes implementation to be emitted. It should just be a
forward from one symbol name to another. You need an actual function
that can go into the vtable that takes a 'Test!Duck' as the context
pointer. This wrapper has to be written by you.
-Steve
Re: D and memory mapped devices
On 6/14/17 4:10 AM, Russel Winder via Digitalmars-d-learn wrote:
In C and C++ you often use bitfields to control devices with memory
mapped hardware control and data words. So for example:
typedef struct some_device {
unsigned int flob: 3;
unsigned int adob: 2;
unsigned int: 3;
unsigned int data: 8;
} some_device;
Clearly D has no bitfields. I know of std.bitfield, so somethign like:
struct some_device {
uint a;
mixin(bitfields!(
uint, "flob", 3,
uint, "adob", 2,
uint, "someMadeUpNameBecauseBlankIsNotAcceptable", 3,
uint, "data", 8));
}
but the bitfields mixin template appears to do more than add all the
bit twiddling functions to emulate the bitfields. This would appear a
priori to not allow for actual memory mapped devices using it, or am I
missing something?
Why not? It should work just the same as C's bitfields, but with more
configurability. It all depends on how the hardware register works, as
they often don't act like normal memory. One thing D does miss is the
volatile keyword.
Have you tried it? It might just work :)
-Steve
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 12:35:05 UTC, Mike B Johnson wrote:
void main()
{
Test!Duck d;
d.quack();
}
which, unfortunately causes a segmentation fault ;)
I think that is because you are not initializing d using new
Test!Duck();
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 11:40:02 UTC, ketmar wrote: interfaces *require* a full-featured class, with VMT, and some hidden pointers to support hidden interface machinery. I don't think that is the problem here. The type Test!Duck is a class and that type is the one implementing the interface.
Re: Implementing interfaces using alias this
Mike B Johnson wrote: I don't think it has to do with pasting code. d.Quack() is well defined through the alias. Inheritance requires that a Quack() exists, and it does, through the alias. The compiler could easily create an implementation wrapper that uses the alias this. this is called "code pasting".
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote:
Balagopal Komarath wrote:
Why doesn't this work? The Test!Duck type has a void quack()
method but the compiler says it is not implemented.
'cause `alias this` is *not* a tool that can be used to emulate
inheritance. no, `quack` is NOT impemented. `alias this` won't
automagically paste the code.
I don't think it has to do with pasting code.
d.Quack() is well defined through the alias. Inheritance requires
that a Quack() exists, and it does, through the alias.
The compiler could easily create an implementation wrapper that
uses the alias this.
I believe it is simply because the logic is not implement in the
compiler, not because there is some logic issue in it.
import std.stdio;
interface IDuck
{
void quack();
}
class Test(T) : IDuck
{
T data;
alias data this;
void quack() { data.quack(); }
}
struct Duck
{
void quack()
{
writeln("Quack");
}
}
void main()
{
Test!Duck d;
d.quack();
}
which, unfortunately causes a segmentation fault ;)(from dpaste)
(even if you remove IDuck) https://dpaste.dzfl.pl/69ddb3f2b1e9
The main issue is that the compiler would have to parse the alias
and see if it has members that are to be used, not hard... but
this is probably not standard behavior and might lead to other
problems down the road(specially with multiple alias this).
Basically, which quack to call? I think it's better to require it
to be explicit(as I have tried to do).
Re: Generic operator overloading for immutable types?
On Tuesday, 13 June 2017 at 19:29:26 UTC, Gary Willoughby wrote: Is it possible for the `result` variable in the following code to be returned as an immutable type if it's created by adding two immutable types? Why do you even want that? Such plain data structure is implicitly convertible to any const flavor: https://dpaste.dzfl.pl/c59c4c7131b2
Re: is it bug? (out contract in method causes dmd (2.072.2, 2.74.1) segfaults)
14.06.2017 14:25, ag0aep6g пишет: It's always a bug when dmd segfaults. filed https://issues.dlang.org/show_bug.cgi?id=17502
Re: Implementing interfaces using alias this
Balagopal Komarath wrote: On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote: Balagopal Komarath wrote: Why doesn't this work? The Test!Duck type has a void quack() method but the compiler says it is not implemented. 'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code. Thanks for the reply. Is there any reason for disallowing this? AFAIK, the alias this guarantees that the interface provided by Test!T is a superset of the interface provided by T. And, when T = Duck, T provides everything required by IDuck. Couldn't the compiler check while instantiating that Test!Duck provides all methods required by IDuck? besides improper using of `alias this`, there is a technical reason too: `struct` is not a `class`, it doesn't have VMT, and other class goodies. as i said, `alias this` is not a macro, it doesn't paste code, it just tells the compiler to make "symbol redirection" on typechecking. interfaces *require* a full-featured class, with VMT, and some hidden pointers to support hidden interface machinery.
Re: Implementing interfaces using alias this
On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote: Balagopal Komarath wrote: Why doesn't this work? The Test!Duck type has a void quack() method but the compiler says it is not implemented. 'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code. Thanks for the reply. Is there any reason for disallowing this? AFAIK, the alias this guarantees that the interface provided by Test!T is a superset of the interface provided by T. And, when T = Duck, T provides everything required by IDuck. Couldn't the compiler check while instantiating that Test!Duck provides all methods required by IDuck?
Re: is it bug? (out contract in method causes dmd (2.072.2, 2.74.1) segfaults)
On 06/14/2017 01:06 PM, drug wrote: https://dpaste.dzfl.pl/b66fffa3bc8d It's always a bug when dmd segfaults.
is it bug? (out contract in method causes dmd (2.072.2, 2.74.1) segfaults)
https://dpaste.dzfl.pl/b66fffa3bc8d
Re: Implementing interfaces using alias this
Balagopal Komarath wrote: Why doesn't this work? The Test!Duck type has a void quack() method but the compiler says it is not implemented. 'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code.
Implementing interfaces using alias this
Why doesn't this work? The Test!Duck type has a void quack()
method but the compiler says it is not implemented.
import std.stdio;
interface IDuck
{
void quack();
}
class Test(T) : IDuck
{
T data;
alias data this;
}
struct Duck
{
void quack()
{
writeln("Quack");
}
}
void main()
{
Test!Duck d;
}
Re: Generic operator overloading for immutable types?
On 06/14/2017 03:47 AM, Steven Schveighoffer wrote: The fundamental difference is that const and immutable share a characteristic that mutable doesn't -- you can't mutate the data. (... through the reference at hand.) const and mutable share this: The data may be mutated from elsewhere. Mutable shares as much with const as immutable does. But it's the other side of const, of course. The reason const(inout) works is because const(immutable) evaluates to just immutable. const() just evaluates to const. In this way, mutable is less "special" than immutable. Yeah. That makes it impossible to express the proposed type. But it's just because of the immutable > const > mutable progression in D, which makes for arbitrary asymmetries between mutable and immutable. If it were const > mutable = immutable (and if we had a `mutable` keyword), then `inout immutable` would work like today's `inout const`, `inout mutable` would be what I'm talking about, and `inout const` would just be the same as const. That's not going to happen, of course. It would break everything. And I'm sure there are many obvious issues that I'm just ignoring here because the thing won't happen anyway. But it would make `inout foo` more symmetric. [...] The soundness of the function above seems good, but I don't know how to reason about the return type of f. Because mutable has no type modifier, it's hard to imagine doing this without one. And any time I think about how to define it, it breaks down. I can't imagine const(blah(T)) evaluating to mutable, no matter what blah is called, or how it works. Literally the ONLY place this would be useful is for inout functions, and Andrei pretty much has declared that inout should be completely stricken from Phobos/druntime in favor of templates. I can't imagine any leeway for another type modifier. const(inout) literally was an afterthought observation that we could relax the rules for this one case and get a little more usability. Ok, I think we're in agreement. The described variant of inout would make sense, but isn't possible in D. It would be very awkward to implement the feature without changing how mutability qualifiers interact. And changing that would be way too disruptive. It's also not at all clear that it would go well with the rest of the language.
Re: D and memory mapped devices
On Wednesday, 14 June 2017 at 08:10:57 UTC, Russel Winder wrote: but the bitfields mixin template appears to do more than add all the bit twiddling functions to emulate the bitfields. This would appear a priori to not allow for actual memory mapped devices using it, or am I missing something? I've casted void buffers to structs containing bitfields to read pre-existing binary files, and that worked just fine. I don't see why it would be different for memory mapped devices. What do yo mean by 'do more'?
D and memory mapped devices
In C and C++ you often use bitfields to control devices with memory
mapped hardware control and data words. So for example:
typedef struct some_device {
unsigned int flob: 3;
unsigned int adob: 2;
unsigned int: 3;
unsigned int data: 8;
} some_device;
Clearly D has no bitfields. I know of std.bitfield, so somethign like:
struct some_device {
uint a;
mixin(bitfields!(
uint, "flob", 3,
uint, "adob", 2,
uint, "someMadeUpNameBecauseBlankIsNotAcceptable", 3,
uint, "data", 8));
}
but the bitfields mixin template appears to do more than add all the
bit twiddling functions to emulate the bitfields. This would appear a
priori to not allow for actual memory mapped devices using it, or am I
missing something?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
