"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: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
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 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?
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 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: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 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:
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 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 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 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 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: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 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 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 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
On Wednesday, 23 September 2015 at 08:27:43 UTC, ponce wrote:
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 just i
On Wednesday, 23 September 2015 at 08:27:43 UTC, ponce wrote:
I fail to see how the multi-part C++ object initialization is
any better than the one of D.
It just is very simple in D: first assign .init, then call the
destructor, virtual calls allowed (of course!).
The combination of being able
On Wednesday, 23 September 2015 at 06:06:42 UTC, Ola Fosheim
Grøstad wrote:
In Beta, the successor to Simula, all execution follows this
pattern:
this(){
begin_prepare_stuff();
subclass.this();
end_prepare_stuff();
}
Actually, this was how Simula did it too. If you didn't provide
th
On Wednesday, 23 September 2015 at 09:09:53 UTC, Ola Fosheim
Grøstad wrote:
The weird rules of virtual functions in ctor/dtor in C++ just
feel like one more special case. It doesn't even seem more
efficient, quite the contrary.
Devirtualized inlining is trivially more efficient than virtual
c
On Tuesday, 22 September 2015 at 21:28:27 UTC, Ola Fosheim
Grøstad wrote:
I tried to determine the actual author. It was not easy and I
still don't know. :)
Me neither. I'm getting the impression that I am looking at a
wall of guidelines-graffiti.
It was introduced in this commit:
https:/
On 9/23/15 2:06 AM, Ola Fosheim Grøstad wrote:
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 t
On Wednesday, 23 September 2015 at 13:14:54 UTC, Steven
Schveighoffer wrote:
You can do it in C++ via initializers too, just not as useful.
D still enforces sound construction.
The key quality for a good OO paradigm is that you can
independently modify super-classes and sub-classes in an
enca
On 9/23/15 9:48 AM, Ola Fosheim Grøstad wrote:
On Wednesday, 23 September 2015 at 13:14:54 UTC, Steven Schveighoffer
wrote:
You can do it in C++ via initializers too, just not as useful. D still
enforces sound construction.
The key quality for a good OO paradigm is that you can independently
m
On Wednesday, 23 September 2015 at 14:01:11 UTC, Steven
Schveighoffer wrote:
If the base ctor doesn't call any virtual functions, when it's
constructed doesn't really matter.
1. In D members are virtual by default, so the virtuality can be
a mistake.
2. In D/C++ you can do full override of v
On 09/23/2015 05:16 AM, Nemanja Boric wrote:
On Tuesday, 22 September 2015 at 21:28:27 UTC, Ola Fosheim Grøstad wrote:
I tried to determine the actual author. It was not easy and I still
don't know. :)
Me neither. I'm getting the impression that I am looking at a wall of
guidelines-graffiti.
On Wednesday, 23 September 2015 at 17:49:28 UTC, Ali Çehreli
wrote:
On 09/23/2015 05:16 AM, Nemanja Boric wrote:
On Tuesday, 22 September 2015 at 21:28:27 UTC, Ola Fosheim
Grøstad wrote:
I tried to determine the actual author. It was not easy and
I still
don't know. :)
Me neither. I'm gett
28 matches
Mail list logo
