in real scenarios.
Ah =/
You have this in your code example:
```d
static assert(Derived.someInt.offsetof == 16); // that's
important otherwise D ctor will mess up everything
```
Would this fix it, or is it just not super viable to hack
around C++ multiple inheritance in D?
Maybe generating
On Tuesday, 25 May 2021 at 17:52:14 UTC, Gavin Ray wrote:
void takesADerived(Derived derived);
extern class Derived : Base1, Base2
Like I said in chat, these are NOT the same thing. The C++
Derived is a *sibling* class, not a parent, child, nor binding to
the D Derived.
All your
On Tuesday, 25 May 2021 at 18:12:27 UTC, Gavin Ray wrote:
Would this fix it, or is it just not super viable to hack
around C++ multiple inheritance in D?
You can do anything you want with structs, raw memory, and
casting, so it is viable, if you have a strong interest for this.
But if you
example:
```d
static assert(Derived.someInt.offsetof == 16); // that's
important otherwise D ctor will mess up everything
```
Would this fix it, or is it just not super viable to hack around
C++ multiple inheritance in D?
Maybe generating some wrapper C++ code to be linked could help
too?
I'm
crafted using
structs and templates.
With this code it is possible to pass back C++ class received
from C++ code and call it.
So it seems support for multiple inheritance shouldn't be that
hard to implement (for Windows), no idea how it works on Linux
though.
Maybe I'll be able to create
On Tuesday, 25 May 2021 at 17:52:14 UTC, Gavin Ray wrote:
```d
void main()
{
Derived dlangDerived = new Derived(123);
printf("[D] Derived.Base1::getSomething() = %d \n",
dlangDerived.getSomething());
printf("[D] Derived.Base2::getOtherThing() = %d \n",
dlangDerived.getOtherThing());
On Tuesday, 25 May 2021 at 06:02:55 UTC, evilrat wrote:
Anyway all this stuff requires thorough research & testing as
such ABI tinkering is very easy to mess up and very hard to
debug, for example if you mess up the order(functions layout)
it can land on another final method call that
and templates.
With this code it is possible to pass back C++ class received
from C++ code and call it.
So it seems support for multiple inheritance shouldn't be that
hard to implement (for Windows), no idea how it works on Linux
though.
```d
// replacement for second base
template iBase2
On Tuesday, 25 May 2021 at 02:47:19 UTC, Gavin Ray wrote:
The below seems to work at least, which is encouraging:
Awesome!
At least, it becomes problematic with fields in base classes, it
would be nice if we could map them to @property annotated
functions in D interfaces.
On Tuesday, 25 May 2021 at 02:47:19 UTC, Gavin Ray wrote:
Unfortunately, it does not work if I try to add `final int
getSomething()` or the other one to the D interfaces, it throws
a symbol error because the mangled names are slightly different:
```sh
unresolved external symbol "public:
think classes annotated with extern is your only high level
guaranteed == type safe option to be compatible to other c++
classes.
But you seek for the general multiple inheritance case which
seems not to be supported with `extern`, sadly.
So you stick with manual solutions like template
On Monday, 24 May 2021 at 17:39:38 UTC, Gavin Ray wrote:
I'd be grateful for solid information on this
Here is a more informal report how it works in C++:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.4735=rep1=pdf
But in the end, I think a byte code analysis is needed to be
guaranteed == type safe option to be compatible to other c++
classes.
But you seek for the general multiple inheritance case which
seems not to be supported with `extern`, sadly.
So you stick with manual solutions like template metaprogramming
or/and raw pointer fiddling.
Anyway, both
On Monday, 24 May 2021 at 18:52:22 UTC, Ola Fosheim Grostad wrote:
If an informal description is needed then the best option is to
search the Clang mailing list.
Btw clang docs say they strive to match msvsc, so apparently it
is platform dependent. The only sensible option is to check with
On Monday, 24 May 2021 at 18:46:00 UTC, Guillaume Piolat wrote:
Multiple inheritance is a rare topic here, I doubt too many
people know how it works internally.
It is described in the link I gave, or? If I tried to give an
informal description I would probably be inaccurate and that
would
of
"inheritance" after it's been compiled?
Yes, in the structure of the vtable, which is why the spec is
so hard to read.
If possible stick to single inheritance in C++...
Yeah agreed, multiple inheritance is asking for trouble.
But unfortunately when you're binding to existing lib
led?
Yes, in the structure of the vtable, which is why the spec is
so hard to read.
If possible stick to single inheritance in C++...
Yeah agreed, multiple inheritance is asking for trouble.
But unfortunately when you're binding to existing libraries you
don't have control over the API
Hence why I was
Multiple inheritance is hard.
If you know how it works, just add it to the dmd,ldc compilers.
If no, try to walk around it :)
With interfaces you can mimic a bit, but don't get Bjarne
Stroustrup level.
On Sunday, 23 May 2021 at 21:02:31 UTC, Gavin Ray wrote:
I don't really know anything at all about compilers or
low-level code -- but is there any high-level notion of
"inheritance" after it's been compiled?
Yes, in the structure of the vtable, which is why the spec is so
hard to read.
If
On Sunday, 23 May 2021 at 20:16:17 UTC, Ola Fosheim Grostad wrote:
On Sunday, 23 May 2021 at 19:44:01 UTC, Gavin Ray wrote:
So one of the problems with generating D code for bindings to
C++ is that there's no true/direct multiple inheritance.
If anyone happens to understand well how vtables
On Sunday, 23 May 2021 at 19:44:01 UTC, Gavin Ray wrote:
So one of the problems with generating D code for bindings to
C++ is that there's no true/direct multiple inheritance.
If anyone happens to understand well how vtables work and the
way the compiler treats these things, is there a way
So one of the problems with generating D code for bindings to C++
is that there's no true/direct multiple inheritance.
If anyone happens to understand well how vtables work and the way
the compiler treats these things, is there a way to hackily make
semantically-equivalent objects
On Saturday, 18 February 2017 at 19:45:45 UTC, biozic wrote:
On Saturday, 18 February 2017 at 19:05:14 UTC, Jean Cesar wrote:
This is exactly what I want this code I did to understand how
would apply multiple inheritance in D, C # also process using
interfaces but the difference from C # to D
On Saturday, 18 February 2017 at 19:05:14 UTC, Jean Cesar wrote:
This is exactly what I want this code I did to understand how
would apply multiple inheritance in D, C # also process using
interfaces but the difference from C # to D is that C # already
in the base class you have to define
t return is required
}
This is exactly what I want this code I did to understand how
would apply multiple inheritance in D, C # also process using
interfaces but the difference from C # to D is that C # already
in the base class you have to define it as interface. ..
On Saturday, 18 February 2017 at 12:56:51 UTC, wiki wrote:
On Saturday, 18 February 2017 at 09:33:25 UTC, biozic wrote:
A mixin can be used to provide an base implementation for the
methods of an interface, along with data members, so that you
don't have to define it in every class that
but how would I do so
I could use the constructor in the same way as such a C ++
code?
Interfaces + mixin templates give you something very similar
to multiple inheritance. You can have named functions in the
mixin templates that do the work of the constructor, then
call them from the real
way as such a C ++
code?
Interfaces + mixin templates give you something very similar
to multiple inheritance. You can have named functions in the
mixin templates that do the work of the constructor, then call
them from the real constructor.
Yes I saw here that it uses interface to make
On Friday, 17 February 2017 at 23:24:57 UTC, Nicholas Wilson
wrote:
Something like this would be a goods use for struct multiple
alias this, except that we haven't implemented that yet
unfortunately.
What's the deal with that? It seems someone made progress on this
issue 2 years ago and then
something very similar to
multiple inheritance. You can have named functions in the mixin
templates that do the work of the constructor, then call them
from the real constructor.
Yes I saw here that it uses interface to make multiple
inheritance just like C#, but I did not understand what
On Friday, 17 February 2017 at 23:11:25 UTC, Jean Cesar wrote:
so I changed the code to use interface but how would I do so I
could use the constructor in the same way as such a C ++ code?
Interfaces + mixin templates give you something very similar to
multiple inheritance. You can have named
On Friday, 17 February 2017 at 23:11:25 UTC, Jean Cesar wrote:
import std.stdio;
import std.string;
I've been reading a bit about multi-inheritance in D, but I
have to use interface like C # to use multiple inheritance, but
I have the code in C ++ that I've been testing to understand
how
import std.stdio;
import std.string;
I've been reading a bit about multi-inheritance in D, but I have
to use interface like C # to use multiple inheritance, but I have
the code in C ++ that I've been testing to understand how it
would be possible to implement multi-inheritance constructor
The solution is simple:
mixin template _Transform() {
public:
alias this Transformable;
// ...
}
How can i implement C++ behaviour like this:
class Shape : Drawable, Transformable {
class Sprite : Drawable {
class Image : Transformable {
?
One way is to declare Transformable or Drawable as interface.
But what if i have more then one class which implements
Transformable/Drawable and i
On 07/08/2012 07:31 PM, Namespace wrote:
How can i implement C++ behaviour like this:
class Shape : Drawable, Transformable {
class Sprite : Drawable {
class Image : Transformable {
?
One way is to declare Transformable or Drawable as interface.
But what if i have more then one class which
Namespace rswhi...@googlemail.com writes:
How can i implement C++ behaviour like this:
class Shape : Drawable, Transformable {
class Sprite : Drawable {
class Image : Transformable {
?
One way is to declare Transformable or Drawable as interface.
But what if i have more then one class
Smart idea.
Why the inner class and not direct Transformable _t; ?
I made a compromise:
[code]
import std.stdio;
interface Transformable {
public:
void transform();
}
mixin template Transform() {
public:
this() {
writeln(Transform Ctor);
}
void transform() {
writeln(transformiere);
}
}
And finally:
[code]
import std.stdio;
interface Transformable {
public:
void transform();
}
mixin template _Transform() {
public:
this() {
writeln(Transform Ctor);
}
void transform() {
writeln(transformiere);
}
}
On 07/08/2012 07:47 PM, Namespace wrote:
Smart idea.
Why the inner class and not direct Transformable _t; ?
If it should be true multiple inheritance, the class must be able to
override the virtual methods of each superclass and each overridden
method must be given access to the fields
On 2012-03-31 19:05, Andrej Mitrovic wrote:
This is related to wrapping wxWidgets.
One issue with the new wxWidgets 2.9.x series is that there seem to be
more multiply-inherited classes than before. In particular some of the
main classes have become MI classes (e.g. wxApp derives from
On 03/31/2012 10:05 AM, Andrej Mitrovic wrote:
This is related to wrapping wxWidgets.
One issue with the new wxWidgets 2.9.x series is that there seem to be
more multiply-inherited classes than before
As Jacob already said mixin templates and Interfaces are the way to go.
I think you have to
On 03/31/2012 10:05 AM, Andrej Mitrovic wrote:
One issue with the new wxWidgets 2.9.x series is that there seem to be
more multiply-inherited classes than before
A bit more complete snippet.
interface Foo
{
void doFoo();
}
// Foo implementation
mixin template FooMixin()
{
alias
This is related to wrapping wxWidgets.
One issue with the new wxWidgets 2.9.x series is that there seem to be
more multiply-inherited classes than before. In particular some of the
main classes have become MI classes (e.g. wxApp derives from
wxAppConsole which is now an MI class). Some wrappers
What's the difference between the (forbidden) multiple inheritance, and
multiple subtyping?
BTW, IMO the syntax of multiple subtyping is strange and ugly.
46 matches
Mail list logo
