On Thu, 2019-01-03 at 11:23 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
> On Thursday, 3 January 2019 at 08:35:17 UTC, Russel Winder wrote:
> > Sorry about that, fairly obvious that the backtrace is needed
> > in hindsight. :- )
> >
> > #0 __GI___libc_free (mem=0xa) at malloc.c:3093
>
On Friday, January 4, 2019 4:50:30 AM MST Jacob Shtokolov via Digitalmars-d-
learn wrote:
> On Friday, 4 January 2019 at 11:41:59 UTC, Simen Kjærås wrote:
> > The thing is, compile-time tests like static if and static
> > assert can only test values that are known at compile-time, and
> > are for
On Friday, 4 January 2019 at 20:21:56 UTC, Steven Schveighoffer
wrote:
missing in the source. But why is d a null reference in the
first place?
Because when you dynamically cast one object or interface to
another object or interface, and that result is not possible
(if you remove ",D" from
On 01/04/2019 01:08 PM, Ali Çehreli wrote:
> There is only one vtbl per class object
Correcting myself after reading Neia Neutuladh's post: I should have
said "There is only one vtbl per class type". Every class object has a
vtbl pointer that points at its type's vtbl.
So, it's normally two
On Friday, 4 January 2019 at 21:47:59 UTC, Neia Neutuladh wrote:
On Fri, 04 Jan 2019 08:46:24 +, Alex wrote:
Let's assume this is right. How to force a B object to behave
like an A object? I thought casting is a possible approach...
It requires a bit of surgery:
:)
import
On Friday, 4 January 2019 at 21:08:24 UTC, Ali Çehreli wrote:
[...]
In this case, casting is using the B object through it's A
interface. The overridden behavior does not change.
Yeah... This was my mistake.
(Actually, that is possible in languages that support multiple
inheritance through
On Fri, 04 Jan 2019 08:46:24 +, Alex wrote:
> Let's assume this is right. How to force a B object to behave like an A
> object? I thought casting is a possible approach...
It requires a bit of surgery:
import std.stdio;
class A
{
void foo() { writeln("hello from A!"); }
On 01/04/2019 12:46 AM, Alex wrote:
> On Friday, 4 January 2019 at 07:37:43 UTC, bauss wrote:
>> No, because you OVERRIDE A's foo().
>>
>> A does not exist. A is B and when you cast B to A you just tell the
>> compiler that the reference should only have A's signature available.
>>
>> You're not
On 1/4/19 2:55 PM, kdevel wrote:
On Friday, 4 January 2019 at 11:27:59 UTC, Alex wrote:
On Friday, 4 January 2019 at 09:58:59 UTC, bauss wrote:
[...]
As for the OP, I think here the usefulness of ", D" should be visible:
[...]
class B : A, D
{
override int foo() { return 2; }
}
On Friday, 4 January 2019 at 11:27:59 UTC, Alex wrote:
On Friday, 4 January 2019 at 09:58:59 UTC, bauss wrote:
[...]
As for the OP, I think here the usefulness of ", D" should be
visible:
[...]
class B : A, D
{
override int foo() { return 2; }
}
[...]
D d = cast(D) b;
On Friday, 4 January 2019 at 11:53:41 UTC, Jacob Shtokolov wrote:
On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov
wrote:
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
Sorry, invalid link.
Here is a new one: https://run.dlang.io/is/QZ5hLV
On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov wrote:
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
Sorry, invalid link.
Here is a new one: https://run.dlang.io/is/QZ5hLV
On Friday, 4 January 2019 at 11:41:59 UTC, Simen Kjærås wrote:
The thing is, compile-time tests like static if and static
assert can only test values that are known at compile-time, and
are for the most part useful only in templates.
Thanks for this answer! That's sad to hear.
But, is there
On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov wrote:
On Friday, 4 January 2019 at 10:34:07 UTC, Basile.B wrote:
Show us some code.
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
The thing I'm trying to do is to make an experimental port
On Friday, 4 January 2019 at 10:34:07 UTC, Basile.B wrote:
Show us some code.
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
The thing I'm trying to do is to make an experimental port (for
education purposes) of https://github.com/fthomas/refined
On Friday, 4 January 2019 at 09:54:25 UTC, Jacob Shtokolov wrote:
Hi,
I'd like to implement some compile time constraints for a
struct (though not sure if that's possible).
I already tried to place "static assert" or any kind of static
condition into a body of @property and opAssign(), but
On Friday, 4 January 2019 at 09:58:59 UTC, bauss wrote:
On Friday, 4 January 2019 at 09:53:18 UTC, Alex wrote:
I assume the move method of an Animal is not abstract, and
therefore I supposed, casting to this type explicitly should
restore this very non-abstract behavior. But this is not the
On Friday, 4 January 2019 at 09:54:25 UTC, Jacob Shtokolov wrote:
Hi,
I'd like to implement some compile time constraints for a
struct (though not sure if that's possible).
I already tried to place "static assert" or any kind of static
condition into a body of @property and opAssign(), but
On Friday, 4 January 2019 at 09:48:55 UTC, greatsam4sure wrote:
On Thursday, 3 January 2019 at 04:57:57 UTC, Me wrote:
On Thursday, 3 January 2019 at 00:23:50 UTC, greatsam4sure
wrote:
On Wednesday, 2 January 2019 at 21:46:57 UTC, bauss wrote:
Error: linker exit with status 1
Dmd failed
On Friday, 4 January 2019 at 09:53:18 UTC, Alex wrote:
I assume the move method of an Animal is not abstract, and
therefore I supposed, casting to this type explicitly should
restore this very non-abstract behavior. But this is not the
case.
And the final/virtual thing above explains this to
On Friday, 4 January 2019 at 09:30:32 UTC, bauss wrote:
Your C++ example is not the same as in D because in C++
functions aren't virtual by default, they are in D.
Mark your functions as virtual in your C++ example and see what
happens.
All functions in D are virtual by default!
Yep. Got
Hi,
I'd like to implement some compile time constraints for a struct
(though not sure if that's possible).
I already tried to place "static assert" or any kind of static
condition into a body of @property and opAssign(), but every time
it shows the error "variable cannot be read at compile
On Friday, 4 January 2019 at 09:19:48 UTC, Simen Kjærås wrote:
On Friday, 4 January 2019 at 08:40:04 UTC, Alex wrote:
class A
{
public:
int foo(){return 1;}
};
class B : public A
{
public:
int foo(){return 2;}
};
In C++, methods are non-virtual by default. In D, they are
virtual by
On Thursday, 3 January 2019 at 04:57:57 UTC, Me wrote:
On Thursday, 3 January 2019 at 00:23:50 UTC, greatsam4sure
wrote:
On Wednesday, 2 January 2019 at 21:46:57 UTC, bauss wrote:
Error: linker exit with status 1
Dmd failed with exit code 1
This is all the compiler emit
Windows 10 ---
On Friday, 4 January 2019 at 08:40:04 UTC, Alex wrote:
On Friday, 4 January 2019 at 02:13:27 UTC, Neia Neutuladh wrote:
I can't think of a single class system that works like that.
C++, Java, C#, Dart, and TypeScript all work like D here.
GObject in C works like D.
In the example below, the
On Friday, 4 January 2019 at 08:40:04 UTC, Alex wrote:
class A
{
public:
int foo(){return 1;}
};
class B : public A
{
public:
int foo(){return 2;}
};
In C++, methods are non-virtual by default. In D, they are
virtual by default. Because of this, the two examples are
different. In
On Friday, 4 January 2019 at 07:37:43 UTC, bauss wrote:
No, because you OVERRIDE A's foo().
A does not exist. A is B and when you cast B to A you just tell
the compiler that the reference should only have A's signature
available.
You're not assigning B to A.
Let's assume this is right.
On Friday, 4 January 2019 at 02:13:27 UTC, Neia Neutuladh wrote:
I can't think of a single class system that works like that.
C++, Java, C#, Dart, and TypeScript all work like D here.
GObject in C works like D.
In the example below, the "2" of B.foo is printed only once.
Independently of the
28 matches
Mail list logo
