On Fri, Apr 22, 2022 at 03:46:01PM +, IGotD- via Digitalmars-d-learn wrote:
> On Friday, 22 April 2022 at 12:58:24 UTC, H. S. Teoh wrote:
> >
> > Why would you not want to use OS APIs?
> >
>
> 1. Portability
Usually when portability matters, you already have specific OSes that
you're
On Friday, 22 April 2022 at 12:58:24 UTC, H. S. Teoh wrote:
Why would you not want to use OS APIs?
1. Portability
2. Language APIs are usually much better to use that the OS APIs,
like Berkeley sockets for example.
On Fri, Apr 22, 2022 at 09:26:13AM +, IGotD- via Digitalmars-d-learn wrote:
> On Thursday, 21 April 2022 at 07:20:30 UTC, dangbinghoo wrote:
> >
> > [... Berkley sockets network code ...]
> >
>
> It really makes me sad when I see this. D has some native networking
> API but unfortunately
On Thursday, 21 April 2022 at 07:20:30 UTC, dangbinghoo wrote:
[... Berkley sockets network code ...]
It really makes me sad when I see this. D has some native
networking API but unfortunately you have go to the OS API to
have this basic functionality. D should really expand its own API
On Friday, 22 April 2022 at 05:28:52 UTC, dangbinghoo wrote:
On Thursday, 21 April 2022 at 07:38:04 UTC, Alexander Zhirov
wrote:
[...]
```d
struct ifreq {
private union ifr_ifrn_ {
char[IFNAMSIZ] ifrn_name; /* if name, e.g. "en0" */
}
On Thursday, 21 April 2022 at 07:38:04 UTC, Alexander Zhirov
wrote:
On Thursday, 21 April 2022 at 07:20:30 UTC, dangbinghoo wrote:
On Thursday, 21 April 2022 at 07:04:18 UTC, Alexander Zhirov
wrote:
I want to get the IP address of the network interface. There
is both a wireless interface and a
On Thursday, 21 April 2022 at 07:20:30 UTC, dangbinghoo wrote:
On Thursday, 21 April 2022 at 07:04:18 UTC, Alexander Zhirov
wrote:
I want to get the IP address of the network interface. There
is both a wireless interface and a wired one. Is it possible,
knowing the name of the network
On Thursday, 21 April 2022 at 07:20:30 UTC, dangbinghoo wrote:
On Thursday, 21 April 2022 at 07:04:18 UTC, Alexander Zhirov
wrote:
I want to get the IP address of the network interface. There
is both a wireless interface and a wired one. Is it possible,
knowing the name of the network
On Thursday, 21 April 2022 at 07:04:18 UTC, Alexander Zhirov
wrote:
I want to get the IP address of the network interface. There is
both a wireless interface and a wired one. Is it possible,
knowing the name of the network interface, to get its IP
address?
```d
import
I want to get the IP address of the network interface. There is
both a wireless interface and a wired one. Is it possible,
knowing the name of the network interface, to get its IP address?
On 9/27/21 9:30 AM, kyle wrote:
That'd be great. Long live Beefconf.
I miss it way too often. Gotta have some beet ready for the next
BeetConf. :p
Ali
On Monday, 27 September 2021 at 16:23:49 UTC, Adam D Ruppe wrote:
On Monday, 27 September 2021 at 16:20:59 UTC, Steven
Schveighoffer wrote:
That's a regression. In 2.092.1, it reports:
aye known bug here
https://issues.dlang.org/show_bug.cgi?id=21321
maybe once dmd can compile C code we'll
On Monday, 27 September 2021 at 16:23:49 UTC, Adam D Ruppe wrote:
On Monday, 27 September 2021 at 16:20:59 UTC, Steven
Schveighoffer wrote:
That's a regression. In 2.092.1, it reports:
aye known bug here
https://issues.dlang.org/show_bug.cgi?id=21321
maybe once dmd can compile C code we'll
On Monday, 27 September 2021 at 16:20:59 UTC, Steven
Schveighoffer wrote:
That's a regression. In 2.092.1, it reports:
aye known bug here
https://issues.dlang.org/show_bug.cgi?id=21321
maybe once dmd can compile C code we'll fix it so it compiles D
code correctly again.
On Monday, 27 September 2021 at 16:11:31 UTC, kyle wrote:
DMD compiles this providing no notice...
What is the version of your DMD?
On 9/27/21 12:11 PM, kyle wrote:
I'm attempting Markdown for the first time so forgive me if that doesn't
go well. Consider the following:
```d
interface A
{
bool broken();
}
abstract class B : A
{
}
class C : B
{
}
void main()
{
import std.stdio;
C test = new C();
I'm attempting Markdown for the first time so forgive me if that
doesn't go well. Consider the following:
```d
interface A
{
bool broken();
}
abstract class B : A
{
}
class C : B
{
}
void main()
{
import std.stdio;
C test = new C();
writeln(test);
}
```
DMD compiles this
. (And, I
didn't know you could do it that way, so thanks for sharing!)
However, it still adds an unnecessary second level of indirection
for interfaces and classes. The simplest and most efficient
solution is actually this:
auto indirect = cast(void*) i; // i is of type I
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time. However, it appears to
produce garbage values on get().
Is this even possible, and if so, what is happening here? The
alternative
es.
Yeah, there are multiple reasonable ways of supporting interfaces
in a language, each with their own trade-offs. But, this is the
one used by D at the moment.
So much head-bashing, and it's over. Thanks, tsbockman,
Imperatorn.
You're very welcome!
using new makes more sense on second thought. Your example
templated implementation makes so much sense, though it doesn't
work in this case. Thanks for the idea though.
Aye, I'm using hashes. The idea is to support either D
interfaces or structs with arbitrary content.
You can use TypeInfo
(Indirect)() @trusted
if(is(Indirect : T*, T) // Support structs, static arrays,
etc.
|| is(Indirect == interface) || is(Indirect == class))
{
return map.remove(typeid(Indirect));
}
/** Returns a reference (for interfaces and classes) or
a pointer (for everything
(https://code.dlang.org/packages/arsd-official%3Ajsvar)? 樂
It doesn't appear to support interfaces, see opAssign at line
682.
It occurs to me that I.sizeof == 8 which is just enough for
the vtbl, but not enough for an implementation ptr. Maybe it's
a pointer to a {self, vtbl} pair
. The idea is to support either D interfaces
or structs with arbitrary content.
`I` is *not* the type of an interface instance, it is the type
of a reference to an instance of the interface.
So `I i` is a reference to the instance, which itself holds a
reference to the implementation, like
On Friday, 12 March 2021 at 18:50:26 UTC, tsbockman wrote:
/* This will return `null` if the value isn't really a
reference to an instance
of a subtype of `I`, or if the key isn't in the map yet. If
you don't care
about the latter case, it can be shortened to just `cast(I)
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time.
Assuming these interfaces are actual D `interface`s, declared
with the keyword and using the default `extern(D)` linkage,
you're
It doesn't appear to support interfaces, see opAssign at line
682.
It occurs to me that I.sizeof == 8 which is just enough for the
vtbl, but not enough for an implementation ptr. Maybe it's a
pointer to a {self, vtbl} pair? SomeClass.sizeof == 16, which
is enough storage for both...
Did you
On Friday, 12 March 2021 at 17:46:22 UTC, Imperatorn wrote:
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time. However, it appears to
produce garbage values on get().
Is this even
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time. However, it appears to
produce garbage values on get().
Is this even possible, and if so, what is happening here? The
alternative
I want to store interfaces as untyped void[], then cast them back
to the interface at a later time. However, it appears to produce
garbage values on get().
Is this even possible, and if so, what is happening here? The
alternative would be a struct { CheckedPtr self; api_fns }
e.g.
void
On Tuesday, 27 October 2020 at 11:30:53 UTC, frame wrote:
On Tuesday, 27 October 2020 at 10:41:06 UTC, Jacob Carlborg
wrote:
if (_arguments[i] == typeid(ubyte[])) {
auto foo = va_arg!(ubyte[])(_argptr);
}
The same is working with variadic template. I am missing
something?
Never mind, I
On Tuesday, 27 October 2020 at 10:41:06 UTC, Jacob Carlborg wrote:
On Tuesday, 27 October 2020 at 09:40:33 UTC, frame wrote:
Hmm, a question of design. Is there also a convenient way to
pass the arguments to a template or get a Variant[] from it?
Convenient, no not that I know of. You can
On Tuesday, 27 October 2020 at 09:40:33 UTC, frame wrote:
Hmm, a question of design. Is there also a convenient way to
pass the arguments to a template or get a Variant[] from it?
Convenient, no not that I know of. You can use a type safe
variadic function that takes Variant, if you want to
On Monday, 26 October 2020 at 13:02:33 UTC, Jacob Carlborg wrote:
On Monday, 26 October 2020 at 11:14:47 UTC, frame wrote:
Is there any way to get this working? I know, I could use a
known object to feed the arguments and use that instead - but
I want to keep things simple as possible.
As
On Monday, 26 October 2020 at 11:14:47 UTC, frame wrote:
Is there any way to get this working? I know, I could use a
known object to feed the arguments and use that instead - but I
want to keep things simple as possible.
As Simen mentioned, templates cannot be virtual. But you don't
need to
On Monday, 26 October 2020 at 11:48:48 UTC, Simen Kjærås wrote:
This makes sense if you consider that the user of the interface
has no knowledge of the types that implement it, and vice
versa: the implementing class has no idea which instantiations
to make, and the user has no idea which
On Monday, 26 October 2020 at 11:14:47 UTC, frame wrote:
Did not find this topic:
I have an interface and some wrapper classes that use it. The
wrapper's methods should accept variadic arguments. The runtime
should only work with the interface, trying casting to a
wrapper is not an option,
Did not find this topic:
I have an interface and some wrapper classes that use it. The
wrapper's methods should accept variadic arguments. The runtime
should only work with the interface, trying casting to a wrapper
is not an option, because it's a plugin design.
- defining a variadic
On 09/20/2019 12:02 PM, JN wrote:
> import std.stdio;
>
> interface IWriter
> {
> void write(U)(U x);
> }
>
> class Foo : IWriter
> {
> void write(U)(U x, int y)
> {
> writeln(x);
> }
> }
>
>
>
> void main()
> {
> }
>
> Does this code make sense?
No. Function
On Friday, 20 September 2019 at 19:02:11 UTC, JN wrote:
If so, why doesn't it throw an error about unimplemented write
(or incorrectly implemented) method?
because you never used it. templates don't get checked by the
compiler until they are used...
import std.stdio;
interface IWriter
{
void write(U)(U x);
}
class Foo : IWriter
{
void write(U)(U x, int y)
{
writeln(x);
}
}
void main()
{
}
Does this code make sense? If so, why doesn't it throw an error
about unimplemented write (or incorrectly implemented)
inherits from button which inherits from
abstract class widget and implements the signal/slot interfaces.
Another pattern is design by introspection.
An interface defines what something _is_,
by introspection defines what something _CanDo_.
That's to say: I don't care if foo is actually (or inherits
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
> > 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 k
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
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
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.
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
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.
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"
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
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{ }
.
Is there a solid reason to ever use an interface over an
abstract class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
The general question is tricky, as different languages differ
in details what is forced and what is allowed for abstract
classes and interfaces
? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
The general question is tricky, as different languages differ
in details what is forced and what is allowed for abstract
classes and interfaces.
But roughly speaking, my opinion is: if you can/want to provide
some
class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
Hi John.
One reason could be data. Abstract classes can hold data,
interfaces can't.
Antonio
That's a reason to use an abstract class, not a reason to use an
interface.
at anything related to OO.
The general question is tricky, as different languages differ in
details what is forced and what is allowed for abstract classes
and interfaces.
But roughly speaking, my opinion is: if you can/want to provide
some default behavior than you are about to write an abstract
at anything related to OO.
Hi John.
One reason could be data. Abstract classes can hold data,
interfaces can't.
Antonio
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
Thanks for the extra detail.
Is there a solid reason to ever use an interface over an abstract
class? (Other than multiple inheritance).
I'm such a noob at anything related to OO.
On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
We're getting into somewhat advanced topics now. This is
described in the Application Binary Interface page of the
documentation[0]. In short: classes and interfaces both use a
vtable[1] that holds pointers to each of their methods
entation[0]. In short: classes and interfaces both use a
vtable[1] that holds pointers to each of their methods. When we
cast a class instance to an interface, the pointer is adjusted,
such that the interface's vtable is the first member. Casting via
`void*` bypasses this adjustment.
Using `__trai
On Friday, 9 August 2019 at 13:19:14 UTC, kinke wrote:
On Friday, 9 August 2019 at 12:26:59 UTC, John Colvin wrote:
Why is there no "hi" between 0 and 1?
Because you are treating the unadjusted object pointer as
interface pointer and then call the only virtual function of
that interface, in
On Friday, 9 August 2019 at 12:26:59 UTC, John Colvin wrote:
Why is there no "hi" between 0 and 1?
Because you are treating the unadjusted object pointer as
interface pointer and then call the only virtual function of that
interface, in the 2nd vtbl slot (after the TypeInfo ptr). Casting
a
import std.stdio;
interface I
{
void foo();
}
class C : I
{
override void foo() { writeln("hi"); }
}
abstract class AC
{
void foo();
}
class D : AC
{
override void foo() { writeln("hi"); }
}
void main()
{
auto c = new C();
writeln(0);
(cast(I)cast(void*)c).foo();
On Sunday, 21 July 2019 at 07:04:00 UTC, rikki cattermole wrote:
COM is used heavily in WinAPI since about Vista. Pretty much
all new functionality has been exposed by it and NOT
extern(Windows) functions which was the standard during up to
about XP (for example notification icons would today
On 21/07/2019 5:44 PM, Kagamin wrote:
On Tuesday, 16 July 2019 at 01:38:49 UTC, evilrat wrote:
Also from what I see MS done this intentionally, means they either no
longer loves COM or there was some other good reason.
Primary consumer of COM interfaces is Visual Basic. It was really only
On Tuesday, 16 July 2019 at 01:38:49 UTC, evilrat wrote:
Also from what I see MS done this intentionally, means they
either no longer loves COM or there was some other good reason.
Primary consumer of COM interfaces is Visual Basic. It was really
only Bill Gates who loved Basic, he wrote
On Tuesday, 16 July 2019 at 01:38:49 UTC, evilrat wrote:
As you can see it is by design. IUnknown has different vtbl[]
comparing to regular D classes/interfaces. If it works with
declaring your own empty IUnknown use it, also you can try
extern(C++) which does similar thing to vtable, it might
On Monday, 15 July 2019 at 22:01:25 UTC, KytoDragon wrote:
I am currently trying to write a XAudio2 backend and have come
across the problem, that some of the interfaces for XAudio2's
COM objects seem to be missing the first entry in their vtable.
After reading the iterface article in the spec
On Monday, 15 July 2019 at 22:01:25 UTC, KytoDragon wrote:
I am currently trying to write a XAudio2 backend and have come
across the problem, that some of the interfaces for XAudio2's
COM objects seem to be missing the first entry in their vtable.
After reading the iterface article in the spec
I am currently trying to write a XAudio2 backend and have come
across the problem, that some of the interfaces for XAudio2's COM
objects seem to be missing the first entry in their vtable. After
reading the iterface article in the spec
(https://dlang.org/spec/interface.html#com-interfaces
On Friday, 21 June 2019 at 20:50:02 UTC, user1234 wrote:
On Friday, 21 June 2019 at 20:42:00 UTC, Tomas wrote:
Does it matter in which order a class inherits from interfaces?
class A : Interface1, Interface2{ ... }
vs
class A : Interface2, Interface1{ ... }
Conceptually it should
On Friday, 21 June 2019 at 20:42:00 UTC, Tomas wrote:
Does it matter in which order a class inherits from interfaces?
class A : Interface1, Interface2{ ... }
vs
class A : Interface2, Interface1{ ... }
Conceptually it should not matter, but I'm getting really weird
segfault errors
Does it matter in which order a class inherits from interfaces?
class A : Interface1, Interface2{ ... }
vs
class A : Interface2, Interface1{ ... }
Conceptually it should not matter, but I'm getting really weird
segfault errors with one version and no errors with the other
version
On 6/6/19 5:36 PM, Jonathan M Davis wrote:
On Thursday, June 6, 2019 2:52:42 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 6/6/19 4:49 PM, Steven Schveighoffer wrote:
Oh wait! It's not empty, it has an empty string as a single member!
That's definitely a bug.
OK, not a bug,
On Thursday, 6 June 2019 at 20:52:42 UTC, Steven Schveighoffer
wrote:
On 6/6/19 4:49 PM, Steven Schveighoffer wrote:
Oh wait! It's not empty, it has an empty string as a single
member! That's definitely a bug.
OK, not a bug, but not what I would have expected. From docs:
"If T isn't a
On Thursday, June 6, 2019 2:52:42 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 6/6/19 4:49 PM, Steven Schveighoffer wrote:
> > Oh wait! It's not empty, it has an empty string as a single member!
> > That's definitely a bug.
>
> OK, not a bug, but not what I would have expected.
On 6/6/19 4:49 PM, Steven Schveighoffer wrote:
Oh wait! It's not empty, it has an empty string as a single member!
That's definitely a bug.
OK, not a bug, but not what I would have expected. From docs:
"If T isn't a struct, class, or union, an expression tuple with an empty
string is
On 6/6/19 4:43 PM, Steven Schveighoffer wrote:
On 6/6/19 4:22 PM, Amex wrote:
FieldNameTuple!T
std.traits.Fields!T
are non-empty when T is an interface!
An interface cannot contain fields and yet these return non-zero and
screws up my code. While I can filter for interfaces it makes me
On 6/6/19 4:22 PM, Amex wrote:
FieldNameTuple!T
std.traits.Fields!T
are non-empty when T is an interface!
An interface cannot contain fields and yet these return non-zero and
screws up my code. While I can filter for interfaces it makes me wonder
what else may slip through?
Is it a bug
On Thursday, 6 June 2019 at 20:22:26 UTC, Amex wrote:
Is it a bug or what is going on?
my suspicion is it is actually the pointer to the vtable getting
caught up in it but idk, i didn't really look, just guessing.
FieldNameTuple!T
std.traits.Fields!T
are non-empty when T is an interface!
An interface cannot contain fields and yet these return non-zero
and screws up my code. While I can filter for interfaces it makes
me wonder what else may slip through?
Is it a bug or what is going on?
On Friday, 25 January 2019 at 19:34:02 UTC, Sebastien Alaiwan
wrote:
On Saturday, 19 January 2019 at 09:24:21 UTC, Kagamin wrote:
On Friday, 18 January 2019 at 18:48:46 UTC, Jonathan M Davis
wrote:
Yes, but some D features will use the GC
They would like to allocate, but they don't know nor
On Saturday, 19 January 2019 at 09:24:21 UTC, Kagamin wrote:
On Friday, 18 January 2019 at 18:48:46 UTC, Jonathan M Davis
wrote:
Yes, but some D features will use the GC
They would like to allocate, but they don't know nor care where
it's allocated from, if the developer uses custom memory
On Sunday, 20 January 2019 at 15:39:49 UTC, Antonio Corbi wrote:
Hi all,
Playing with interfaces and preconditions in methods I get
strange results with dmd-2.0.84.0 but also with dmd-nightly. My
code is like this:
-
import std.stdio;
interface Thing2D {
void width(int w
Hi all,
Playing with interfaces and preconditions in methods I get
strange results with dmd-2.0.84.0 but also with dmd-nightly. My
code is like this:
-
import std.stdio;
interface Thing2D {
void width(int w)
in {
writeln("Thing2D.width contract w = ",w);
On Friday, 18 January 2019 at 18:48:46 UTC, Jonathan M Davis
wrote:
Yes, but some D features will use the GC
They would like to allocate, but they don't know nor care where
it's allocated from, if the developer uses custom memory
management, he will know how it's allocated and will be able
On Friday, January 18, 2019 8:08:47 AM MST Kagamin via Digitalmars-d-learn
wrote:
> On Friday, 18 January 2019 at 00:08:00 UTC, 1001Days wrote:
> > It works, but I have two questions regarding its efficacy: is
> > it viable in the long run, and is it now possible to use
> > delegates without the
On Friday, 18 January 2019 at 00:08:00 UTC, 1001Days wrote:
It works, but I have two questions regarding its efficacy: is
it viable in the long run, and is it now possible to use
delegates without the GC?
GC is just a handy memory management approach, it even works for
C and C++, (example:
by making your code larger than it could have been.)
Yes, this is something I worried about too.
My personal tendency is to start with structs and compile-time
introspection as an initial stab, but depending on what might be
needed, I may use some classes / interfaces. The two can be
combined
se the
> abilities of Interfaces. So instead I used a combination of templates,
> constraints, the hasMember trait, and delegates to achieve a simple
> alternative.
Maybe you could help us answer your question better by explaining a bit
more what you're trying to achieve. Generally, if y
Hello,
Preface: I do apologize if this is too simplistic of a matter,
and if I need to RTFM. I'm quite slow.
I want to use Structs instead of Classes, but I don't want to
lose the abilities of Interfaces. So instead I used a combination
of templates, constraints, the hasMember trait
On Sunday, 30 December 2018 at 18:55:10 UTC, Ali Çehreli wrote:
On 12/30/2018 05:05 AM, 0xEAB wrote:
>> interface FooAdapter
>> {
>> FooBundle!(Handle) createSome(Handle)();
>> }
Function templates cannot be virtual functions. One reason is
the compiler cannot know how large the virtual
On 12/30/2018 05:05 AM, 0xEAB wrote:
>> interface FooAdapter
>> {
>> FooBundle!(Handle) createSome(Handle)();
>> }
Function templates cannot be virtual functions. One reason is the
compiler cannot know how large the virtual function table should be, and
the other one is it's just a
void main()
{
StaticThingy.register(new SomeAdapter());
StaticThingy.createSome!Dummy();
}
interface FooAdapter
{
FooBundle!(Handle) createSome(Handle)();
}
private class SomeAdapter : FooAdapter
{
Bundle createSome()
{
auto w = new Dummy();
auto c = new
instead of implementing an
interface... Any idea about why that?
Unlike interfaces, base class references don't need adjustment.
Yeah. You shouldn't need to know these details but if you are
interested, the details are here:
https://dlang.org/spec/abi.html#classes (it's meant for tech
reference
interfaces, base class references don't need adjustment.
You can see this in action by printing addresses:
https://run.dlang.io/is/m6icVr
import std.stdio;
interface I {}
class Base : I {}
class Derived : Base { }
void main()
{
auto derived = new Derived;
Base base = derived;
I i
On Monday, 24 December 2018 at 11:23:32 UTC, Johan Engelen wrote:
On Sunday, 23 December 2018 at 14:07:04 UTC, Johannes Loher
wrote:
[...]
The types of the 2nd and 3rd arguments of `cas` do not have to
be the same, and aren't in your case. I think what's happening
is that you are
On Sunday, 23 December 2018 at 14:07:04 UTC, Johannes Loher wrote:
I recently played around with atomic operations. While doing
so, I noticed a problem with the interaction of interfaces and
cas. Consider the following program:
```
import core.atomic;
import std.stdio;
interface
I recently played around with atomic operations. While doing so,
I noticed a problem with the interaction of interfaces and cas.
Consider the following program:
```
import core.atomic;
import std.stdio;
interface TestInterface
{
}
class TestClass : TestInterface
{
}
void main()
{
shared
On Monday, 1 October 2018 at 13:49:53 UTC, Emil wrote:
I am trying my hand at contracts and they work fine in plain
functions and in methods, but I can't make them work in
interfaces.
https://dlang.org/spec/interface.html#interface-contracts
$ dmd --version
DMD64 D Compiler v2.081.1
1 - 100 of 426 matches
Mail list logo
