Re: filtering a row of a jagged array
On 08/11/2019 09:43 AM, DanielG wrote: such a simple error You're not alone. We want this bug fixed: https://issues.dlang.org/show_bug.cgi?id=17263 Ali
Re: Abstract classes vs interfaces, casting from void*
On Sunday, 11 August 2019 at 20:32:14 UTC, John Colvin wrote: As I see this, everything you wrote is correct. :) But you compared abstractness with interface usage, initially. So... I would say, interfaces are more like the abstract method case without any function body. But then, you will have to use "override" all across the inherited classes. Ok. So that means the difference is pretty subtle, give or take a few extra keywords. Which leaves multiple inheritance as the only significant difference? From my perspective it looks like there are two massively overlapping features with some quite arbitrary feeling restrictions and differences. E.g. why can I not inherit from multiple 100% abstract empty classes? Wouldn't that be the same as inheriting from multiple interfaces? The overlap is there, but it is not so massive, I would say. If you inherit from abstract classes, then you do not plan to keep them empty. So, the overlap you are speaking about is exactly as large as the amount of "100% abstract empty classes". And for these, the approach to keep the interface as a separate interface seems more convenient, as Adam said. In the end, by forcing an explicit override, some semantic is also implied.
Re: Abstract classes vs interfaces, casting from void*
On Sunday, August 11, 2019 2:32:14 PM MDT John Colvin via Digitalmars-d- learn wrote: > On Sunday, 11 August 2019 at 20:15:34 UTC, Alex wrote: > > As I see this, everything you wrote is correct. :) > > > > But you compared abstractness with interface usage, initially. > > So... I would say, interfaces are more like the abstract method > > case without any function body. But then, you will have to use > > "override" all across the inherited classes. > > Ok. So that means the difference is pretty subtle, give or take a > few extra keywords. > > Which leaves multiple inheritance as the only significant > difference? > > From my perspective it looks like there are two massively > overlapping features with some quite arbitrary feeling > restrictions and differences. E.g. why can I not inherit from > multiple 100% abstract empty classes? Wouldn't that be the same > as inheriting from multiple interfaces? Well, as things stand, _no_ class is 100% abstract, because they all derive from Object, and Object has virtual functions on it with implementations, whereas an interface _is_ 100% abstract. Maybe once we have ProtoObject, it could be argued for allowing 100% abstract classes to be treated as interfaces, but right now, that wouldn't be possible, and even with ProtoObject, it arguably wouldn't be worth the extra complication, since if you really intend to have a 100% abstract class, that's what interfaces are for. There's also the weird complications that come with D's COM support, since that uses interfaces but gets treated differently from how classes are normally treated, and I don't know how that affects the implementation of interfaces. If we'd had ProtoObject from the get-go, I wonder if it would have just been better to implement COM interfaces as being derived from a specific class that's derived from ProtoObject instead of mucking up interfaces the way that we currently hove, but I don't know. I haven't ever actually used D's COM support, so I don't fully understand it. For the most, D's interfaces and abstract classes follow what you get in Java and C# (though the weirdness with COM is unique to D as is the ability to have final functions with an implementation). Basically, it seems like what we got with interfaces and abstract classes was copied from Java and then tweaked. I suspect that the separation between interfaces and abstract classes in Java comes from the fact that Object has functions on it, and that same logic carried over to D. In practice, what I would expect to typically happen is that if you're defining a set of functions that a class needs to have but not providing any implementations, then you'd use an interface, whereas if you intend to provide an implementation for any part of it but not all of it, you'd use an abstract class. I wouldn't expect abstract classes with no functions (outside of those from Object) or variables being declared on them to be used much. Maybe someone would have a use case where it would make sense to have a common base class with no implementations, but I can't think of any reason why that would be useful other than preventing classes from being derived from any class from a different class hierarchy, which isn't usually something that's worth preventing. Regardless, the whole weirdness that you're running into with void* is not something that much code would care about, because very little code is going to do something like cast a reference to void*, and the code that does do that is @system and expected to deal with it correctly. In general, casting to void* and then casting to anything other than the original type is probably asking for trouble. If I understand correctly, with void*, you're basically doing a reinterpet cast, and that's not usually the type of cast you want when dealing with class references. If I had code where whether casting to an interface or abstract class mattered, I'd want to redesign it so that that didn't matter. - Jonathan M Davis
Re: Abstract classes vs interfaces, casting from void*
On Sunday, 11 August 2019 at 20:32:14 UTC, John Colvin wrote: E.g. why can I not inherit from multiple 100% abstract empty classes? Wouldn't that be the same as inheriting from multiple interfaces? There's kinda no such thing as 100% empty abstract classes, since they all have the implicit parent of Object with its associated pieces. D's interfaces have no implicit parent. But if that were to change, then yeah, it should work - that's basically what C++ does in lieu of interfaces. (I personally prefer separate interfaces anyway, as it makes the intention clear and thus can help with better error messages and documentation, but it would work.)
Re: Abstract classes vs interfaces, casting from void*
On Sunday, 11 August 2019 at 20:15:34 UTC, Alex wrote:
On Sunday, 11 August 2019 at 16:05:20 UTC, John Colvin wrote:
I'm trying to narrow down exactly what patterns work with each
and how they overlap.
What I was trying to get at with the abstract method thing is
that
abstract class C
{
void foo();
}
is an abstract class with a non-abstract method, whose
implementation is going to come from somewhere else (not a
common pattern in D).
class C
{
abstract void foo();
}
is an abstract class with an abstract method foo, which means
you have to override it in a inheriting class to get a
non-abstract class.
As I see this, everything you wrote is correct. :)
But you compared abstractness with interface usage, initially.
So... I would say, interfaces are more like the abstract method
case without any function body. But then, you will have to use
"override" all across the inherited classes.
Ok. So that means the difference is pretty subtle, give or take a
few extra keywords.
Which leaves multiple inheritance as the only significant
difference?
From my perspective it looks like there are two massively
overlapping features with some quite arbitrary feeling
restrictions and differences. E.g. why can I not inherit from
multiple 100% abstract empty classes? Wouldn't that be the same
as inheriting from multiple interfaces?
Re: Abstract classes vs interfaces, casting from void*
On Sunday, 11 August 2019 at 16:05:20 UTC, John Colvin wrote:
I'm trying to narrow down exactly what patterns work with each
and how they overlap.
What I was trying to get at with the abstract method thing is
that
abstract class C
{
void foo();
}
is an abstract class with a non-abstract method, whose
implementation is going to come from somewhere else (not a
common pattern in D).
class C
{
abstract void foo();
}
is an abstract class with an abstract method foo, which means
you have to override it in a inheriting class to get a
non-abstract class.
As I see this, everything you wrote is correct. :)
But you compared abstractness with interface usage, initially.
So... I would say, interfaces are more like the abstract method
case without any function body. But then, you will have to use
"override" all across the inherited classes.
Re: CT filtering of class members
On Sunday, 11 August 2019 at 16:32:20 UTC, Simen Kjærås wrote: [...] Something like this: import std.meta : Filter; import std.traits : isFunction; import std.algorithm.searching : canFind; enum isNonspecialMemberFunction(string name) = !ctorAndDtor.canFind(name) && isFunction!(__traits(getMember, T, name)); enum memberFunctions = Filter!(isNonspecialMemberFunction, __traits(derivedMembers, T)); Filter operates on AliasSeqs, not arrays. That's why I restated the __traits(derivedMembers, T) part, but this could just as easily be done by changing this line: enum members = [__traits(derivedMembers, T)]; to: alias members = __traits(derivedMembers, T); -- Simen Works beautiful, thank you very much!
Re: filtering a row of a jagged array
Thank you both! Ugh, I have to roll my eyes at missing such a simple error. (This literally occurred in the context of a bunch of other code using 'map' and 'reduce' with the exclamation point, so I don't know why my brain turned off for 'filter') Thanks again!
Re: filtering a row of a jagged array
On Sunday, 11 August 2019 at 16:11:15 UTC, DanielG wrote: int[][] whatever = [ [0], [0, 1, 2], [5, 6, 7, 8, 9, 10] ]; writeln(whatever[2]);// [5, 6, 7, 8, 9, 10] writeln(typeid(whatever[2]));// int[] auto x = whatever[2].filter(x => x > 7); // error Error: template std.algorithm.iteration.filter cannot deduce function from argument types !()(int[], void), candidates are: ... Online example: https://run.dlang.io/is/LUXFuF ... I'm guessing I need to give the compiler some help understanding that this is an array of ints, but 1) how, and 2) why? [if typeid() seems to understand just fine?] You're missing an exclamation mark after filter - it takes the predicate as a template argument. This compiles just fine: auto x = whatever[2].filter!(x => x > 7); -- Simen
Re: filtering a row of a jagged array
On 11.08.19 18:11, DanielG wrote: auto x = whatever[2].filter(x => x > 7); // error You just forgot an exclamation mark here. auto x = whatever[2].filter!(x => x > 7); // works
Re: CT filtering of class members
On Sunday, 11 August 2019 at 15:27:54 UTC, Sjoerd Nijboer wrote: The following snippet doesn't compile I am trying to reflect on a class and only do an operation with all member functions of a class. But I can't seem to use a filter to only get the member functions out of a type T. I understand that there are two errors in my snippet. 1) It cannot mixin a `name` because it is a variable from the lambda that `filter()` is using. 2) members.filter!(name => !ctorAndDtor.canFind(name)) does not filter on symbols defined in ctorAndDtor How can I fix these problems and return all member functions whitout ctor and dtor of a type T? This is classic D mix of compile-time and compile-time (no typo). I suggest reading H.S. Teoh's text on the topic: https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time Now, as for what can actually be done: you should probably use std.meta.Filter (https://dlang.org/library/std/meta/filter.html) to filter the members list. This will require you to define a template to operate on each element. Something like this: import std.meta : Filter; import std.traits : isFunction; import std.algorithm.searching : canFind; enum isNonspecialMemberFunction(string name) = !ctorAndDtor.canFind(name) && isFunction!(__traits(getMember, T, name)); enum memberFunctions = Filter!(isNonspecialMemberFunction, __traits(derivedMembers, T)); Filter operates on AliasSeqs, not arrays. That's why I restated the __traits(derivedMembers, T) part, but this could just as easily be done by changing this line: enum members = [__traits(derivedMembers, T)]; to: alias members = __traits(derivedMembers, T); -- Simen
filtering a row of a jagged array
int[][] whatever = [ [0], [0, 1, 2], [5, 6, 7, 8, 9, 10] ]; writeln(whatever[2]);// [5, 6, 7, 8, 9, 10] writeln(typeid(whatever[2]));// int[] auto x = whatever[2].filter(x => x > 7); // error Error: template std.algorithm.iteration.filter cannot deduce function from argument types !()(int[], void), candidates are: ... Online example: https://run.dlang.io/is/LUXFuF ... I'm guessing I need to give the compiler some help understanding that this is an array of ints, but 1) how, and 2) why? [if typeid() seems to understand just fine?]
Re: Abstract classes vs interfaces, casting from void*
On Sunday, 11 August 2019 at 15:16:03 UTC, Alex wrote:
On Sunday, 11 August 2019 at 13:09:43 UTC, John Colvin wrote:
Ok. What would go wrong (in D) if I just replaced every
interface with an abstract class?
I think there's some confusion here, because B.foo is not
abstract. abstract on a class is not inherited by its methods.
https://dlang.org/spec/attribute.html#abstract
Now, I'm confused, as you asked about abstract classes. So,
yes, you can define the abstractness of classes differently.
And what is your point?
I'm trying to narrow down exactly what patterns work with each
and how they overlap.
What I was trying to get at with the abstract method thing is that
abstract class C
{
void foo();
}
is an abstract class with a non-abstract method, whose
implementation is going to come from somewhere else (not a common
pattern in D).
class C
{
abstract void foo();
}
is an abstract class with an abstract method foo, which means you
have to override it in a inheriting class to get a non-abstract
class.
CT filtering of class members
The following snippet doesn't compile
I am trying to reflect on a class and only do an operation with
all member functions of a class.
But I can't seem to use a filter to only get the member functions
out of a type T.
I understand that there are two errors in my snippet.
1) It cannot mixin a `name` because it is a variable from the
lambda that `filter()` is using.
2) members.filter!(name => !ctorAndDtor.canFind(name)) does not
filter on symbols defined in ctorAndDtor
How can I fix these problems and return all member functions
whitout ctor and dtor of a type T?
Code snippet:
void main()
{
GetFunctionMembers!Foo();
}
void GetFunctionMembers(T)()
{
enum members = [__traits(derivedMembers, T)];
pragma(msg, "Functions: " ~ members.stringof);
enum ctorAndDtor = ["this", "__ctor", "__dtor"];
enum memberFunctions = members.filter!(name =>
!ctorAndDtor.canFind(name)
&& mixin("isFunction!(T." ~ name ~ ")"))();
pragma(msg, memberFunctions);
}
class Foo
{
bool myBool;
int k;
this()
{
}
~this()
{
}
void bar(int k)
{
this.k = k;
}
void qux()
{
}
}
Re: Abstract classes vs interfaces, casting from void*
On Sunday, 11 August 2019 at 13:09:43 UTC, John Colvin wrote: Ok. What would go wrong (in D) if I just replaced every interface with an abstract class? I think there's some confusion here, because B.foo is not abstract. abstract on a class is not inherited by its methods. https://dlang.org/spec/attribute.html#abstract Now, I'm confused, as you asked about abstract classes. So, yes, you can define the abstractness of classes differently. And what is your point?
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 17:28:32 UTC, Alex wrote:
´´´
void main(){}
interface A { void fun(); }
abstract class B{ void fun(); }
class C : A{ void fun(){} }
class D : B{ /*override*/ void fun(){} }
´´´
case 1:
interface A and class C implementing interface A:
You don't need to "override" anything. You are forced to
provide an implementation of the function inside the class.
case 2:
abstract class B and class D inheriting from it:
You can but not have to provide an implementation of a function
inside the abstract class.
If I don't and do not provide any implementation inside D I get
a linker error. Don't how this case behaves on your system.
If you provide an implementation inside the abstract class, you
don't have to provide any in the derived one.
In any case, if you want to provide an implementation inside
the derived class you have to literally "override", as in D
implicit overrides are not allowed.
I think there's some confusion here, because B.foo is not
abstract. abstract on a class is not inherited by its methods.
https://dlang.org/spec/attribute.html#abstract
Re: Abstract classes vs interfaces, casting from void*
On Saturday, 10 August 2019 at 17:46:37 UTC, Timon Gehr wrote:
On 10.08.19 16:29, John Colvin wrote:
Ok. What would go wrong (in D) if I just replaced every
interface with an abstract class?
interface A{}
interface B{}
class C: A,B{ }
Yes, I know, I guess it wasn't clear unless you read my previous
question, I said "apart from multiple inheritance".
Re: How to run the dub bundle with dmd
On Saturday, 10 August 2019 at 16:44:48 UTC, greatsam4sure wrote: On Saturday, 10 August 2019 at 15:42:39 UTC, rikki cattermole wrote: This is a crazy question but is your Windows install 64bit? yes. See the spec below https://ibb.co/M1TwY7W I am currently assuming it is not a general problem. Do you have a virus scanner on your system? You might also try instead of DMD try LDC https://github.com/ldc-developers/ldc/releases/download/v1.16.0/ldc2-1.16.0-windows-x64.7z Does the issue occur here too? Kind regards Andre
