On Tuesday, 22 September 2015 at 23:21:20 UTC, Steven
Schveighoffer wrote:
Yeah, but you can't do this in C++ though:
class D : B {
this()
{
writeln("derived is only now complete");
super();
}
}
I find the ability to control the construction order far more
important than v
On Tuesday, 22 September 2015 at 22:14:56 UTC, deadalnix wrote:
It is part of the .init, so the compiler would set it BEFORE
calling the constructor. constructor can then call each other
and rely on the fact that the vtable is initialized.
We were discussing the cost if doing it like c++, whe
On 9/22/15 3:38 PM, Ali Çehreli wrote:
On 09/22/2015 11:58 AM, Tourist wrote:
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual calls, but I didn't und
On Tuesday, 22 September 2015 at 22:09:59 UTC, Ola Fosheim
Grostad wrote:
On Tuesday, 22 September 2015 at 21:25:06 UTC, deadalnix wrote:
You can call super, so you need the virtual dispatch.
I understand Ali's argument about setting local vtable before
calling external functions in C++, but
On Tuesday, 22 September 2015 at 21:25:06 UTC, deadalnix wrote:
You can call super, so you need the virtual dispatch.
I understand Ali's argument about setting local vtable before
calling external functions in C++, but other than that it should
be sufficient to set vtable in the new() or equi
On Tuesday, 22 September 2015 at 20:42:44 UTC, Ali Çehreli wrote:
However, it is not possible in general e.g. if the object is
passed to a function by reference, that function can call any
virtual method on it so the vtbl pointer must have been set
upon entry to the constructor, at every level
On Tuesday, 22 September 2015 at 19:52:48 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 22 September 2015 at 19:38:35 UTC, Ali Çehreli
wrote:
C++'s approach is better from the point of view of corretness.
However, it is slower because the object's vtbl pointer must
be stamped several times during
On 9/22/15 12:38 PM, Ali Çehreli via Digitalmars-d wrote:
On 09/22/2015 11:58 AM, Tourist wrote:
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual call
On Tuesday, 22 September 2015 at 19:52:48 UTC, Ola Fosheim
Grøstad wrote:
But neither approach is good for correctness.
The approach that would be "Good for Correctness" is "Hey! You're
doing to much work in a constructor, that's a code smell anyway.
And invoking virtual methods in a constru
On 09/22/2015 12:52 PM, Ola Fosheim Grøstad wrote:
On Tuesday, 22 September 2015 at 19:38:35 UTC, Ali Çehreli wrote:
C++'s approach is better from the point of view of corretness.
However, it is slower because the object's vtbl pointer must be
stamped several times during construction. (I am not
On Tuesday, 22 September 2015 at 19:45:33 UTC, Iakh wrote:
Your solution is platform dependent, isn't it?
Platform-dependent in what way? Yes, the intrinsic for PMOVMSKB
is obviously x86-only.
core.simd XMM enum has commented this opcode
//PMOVMSKB = 0x660FD7
__simd is similarly DMD-only.
On Tuesday, 22 September 2015 at 19:38:35 UTC, Ali Çehreli wrote:
C++'s approach is better from the point of view of corretness.
However, it is slower because the object's vtbl pointer must be
stamped several times during construction. (I am not aware of
available compiler optimizations there.)
On Tuesday, 22 September 2015 at 17:46:32 UTC, David Nadlinger
wrote:
On Tuesday, 22 September 2015 at 16:36:42 UTC, Iakh wrote:
__mm_movemask_epi a cornerstone of the topic currently not
implemented/not supported in D :(
AFAIK it has irregular result format
From ldc.gccbuiltins_x86:
int __b
On 09/22/2015 11:58 AM, Tourist wrote:
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual calls, but I didn't understand what he
means. What does he mean?
Perhaps he meant how in Java, methods are virtual by default, unlike C++
where they are final by default.
--
Ziad
On Tue, Sep 22, 2015 at 12:15 PM, Freddy via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 22 September 2015 at 18:58:31 UTC, Tourist wrote:
>
>> "D disappointed
On Tuesday, 22 September 2015 at 18:58:31 UTC, Tourist wrote:
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual calls, but I didn't understand
what he me
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual calls, but I didn't understand what
he means. What does he mean?
On Tuesday, 22 September 2015 at 18:17:42 UTC, Maxim Fomin wrote:
Two examples. I am aware of only one case when Walter and
Andrei agreed with community.
Well, but the community doesn't agree with itself either ;^) But
Walter did add @nogc and changed his view on GC being a total
non-issue, s
On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote:
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
Sure, but in many cases D allows you to work around decisions
you don't like. Plus, you can actively contribute, make
suggestions and prove your case. The length of so
On Tuesday, 22 September 2015 at 16:36:42 UTC, Iakh wrote:
__mm_movemask_epi a cornerstone of the topic currently not
implemented/not supported in D :(
AFAIK it has irregular result format
From ldc.gccbuiltins_x86:
int __builtin_ia32_pmovmskb128(byte16);
int __builtin_ia32_pmovmskb256(byte32)
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin
wrote:
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
to be confined by committee decisions etc.,
D has committee (Walter & Andrei). Some of their decisions
fr
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
The thing is that a lot of people who use D don't mind the lack
of IDE support. One reason is that D doesn't need it as badly
as e.g. Java or C++.
These are bad excuses.
On Tuesday, 22 September 2015 at 13:06:39 UTC, Andrei
Alexandrescu wrote:
A paper I found interesting:
http://openproceedings.org/EDBT/2014/paper_107.pdf -- Andrei
__mm_movemask_epi a cornerstone of the topic currently not
implemented/not supported in D :(
AFAIK it has irregular result format
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
it's only from D that users expect perfection, other languages
are accepted as they are, warts and all.
it's true
On Tuesday, 22 September 2015 at 15:34:19 UTC, Chris wrote:
Then we need a transition strategy. I wouldn't mind refactoring
my code in order to adapt it to changes that are for the better
in the long run. However, I wouldn't want it to happen in a
sudden way that would render all my code useles
On Tuesday, 22 September 2015 at 14:46:30 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
too long. But as I said before, it's only from D that users
expect perfection, other languages are accepted as they are,
warts and all.
I don't think that is t
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
too long. But as I said before, it's only from D that users
expect perfection, other languages are accepted as they are,
warts and all.
I don't think that is true. It has been common among C++ users to
build custom libraries with ver
On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote:
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
to be confined by committee decisions etc.,
D has committee (Walter & Andrei). Some of their decisions
frustrate D users too.
Sure, but in many cases D allows you t
A paper I found interesting:
http://openproceedings.org/EDBT/2014/paper_107.pdf -- Andrei
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
to be confined by committee decisions etc.,
D has committee (Walter & Andrei). Some of their decisions
frustrate D users too.
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:
It's almost exclusively due to the error messages and IDE. I
know many here will write off such complaints, So be it.
The thing is that a lot of people who use D don't mind the lack
of IDE support. One reason is that D doesn't need i
On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc
wrote:
On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:
OK, the frustration is understandable. D is good enough to
impress in short-run but has problems damaging itself in the
long run. This leads to impression -> fru
On Mon, 21 Sep 2015 19:07:32 +, Adam D. Ruppe wrote:
>> https://issues.dlang.org/show_bug.cgi?id=10679
>
> I don't think this one is valid though maybe I'm wrong. But the
> instruction pointer would be on the next instruction.
You are correct and I realized this later on and 'fixed' it in
dr
33 matches
Mail list logo
