On Sunday, 28 May 2017 at 14:30:00 UTC, Ola Fosheim Grøstad wrote:
Struct and class is one type in C++. The difference is in the
syntax where the grammar does not allow access protection for
the struct keyword. So not semantical, but syntactical.
I.e. you can just search-and-replace "struct"
On Sunday, 28 May 2017 at 12:31:35 UTC, Iain Buclaw wrote:
I said it all in one breath, so you could leave it up to
interpretation whether they applauded the fact that there is a
separation in semantics, or whether there is no multiple
inheritance in D (except via interfaces).
When asking
On 28 May 2017 at 13:30, Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
>>
>> However, for extern(D) classes, there's actually nothing stopping a D
>> compiler implementer from making class types more memory
On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
However, for extern(D) classes, there's actually nothing
stopping a D compiler implementer from making class types more
memory efficient, an optimizing compiler could decide to
re-arrange class fields as:
class Something
{
On 27 May 2017 at 20:13, Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Saturday, 27 May 2017 at 18:06:11 UTC, Stanislav Blinov wrote:
>>
>> Perhaps it wouldn't be if we were talking about new language.
>> With D, such a change falls out of "some language changes,
On Sunday, 28 May 2017 at 08:24:50 UTC, Iain Buclaw wrote:
Strictly speaking, this already is the case.
Something sth = new Something (...);
all that is really doing is just:
struct Something* sth = new Something (...);
You just aren't exposed this in the language.
Right, but since
On 27 May 2017 at 20:34, Jonathan M Davis via Digitalmars-d
wrote:
> On Saturday, May 27, 2017 16:37:04 Ola Fosheim Grøstad via Digitalmars-d
> wrote:
>> > Monitor (i.e. for "synchronized") and
>>
>> Wasn't this going to be removed?
>
> There was definitely talk of
On 27 May 2017 at 16:12, Ola Fosheim Grøstad via Digitalmars-d
wrote:
> I wonder, what would break if all the features of class was merged into
> struct?
>
> Imagine that:
>
> class Something ... { ... }
>
> is lowered into:
>
> struct _class_Something ... {
On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote:
Sure, and the definition requires it.
[1] https://dlang.org/spec/abi.html#delegates
Please note that an ABI is an implementation specific linkage
detail, it cannot be portable so it does not define language
semantics.
On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote:
On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner
wrote:
Here, `bar`, takes a (pointer to a) class instance as
parameter `foo`. `foo` is a single
On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
Here, `bar`, takes a (pointer to a) class instance as
parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a
64bit OS, with *no* special semantics.
On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
Here, `bar`, takes a (pointer to a) class instance as parameter
`foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS,
with *no* special semantics.
Does the language spec say anything about the size of class
references?
On Saturday, 27 May 2017 at 18:56:47 UTC, Stanislav Blinov wrote:
I've seen this argument from you before, and it's incorrect.
Structs may adopt reference semantics if they aggregate
pointers, that's true. But they are not themselves reference
types. Their representation is laid out inline.
On Saturday, 27 May 2017 at 18:42:02 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 18:26:07 UTC, Moritz Maxeiner wrote:
mechanism, but you *cannot* use a smart pointer as a
replacement for a class instance, because the latter is normal
pointer, and the former adds features on
On Saturday, 27 May 2017 at 18:44:42 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov
wrote:
On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad
wrote:
Or did we leave behind your original question?
No. I am talking about language
On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad
wrote:
Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics
for class and struct conflicting or can they be merged?
That is the question.
I am talking about the language,
On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov wrote:
On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad
wrote:
Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics
for class and struct conflicting or can they be
On Saturday, 27 May 2017 at 18:26:07 UTC, Moritz Maxeiner wrote:
mechanism, but you *cannot* use a smart pointer as a
replacement for a class instance, because the latter is normal
pointer, and the former adds features on top of a pointer; they
cannot be the same as a matter of definition,
On Saturday, 27 May 2017 at 18:33:36 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 18:21:41 UTC, Moritz Maxeiner wrote:
Then please don't call them "smart", because that term is
specifically reserved for something that adds at least some
additional features over a regular pointer
On Saturday, May 27, 2017 16:37:04 Ola Fosheim Grøstad via Digitalmars-d
wrote:
> > Monitor (i.e. for "synchronized") and
>
> Wasn't this going to be removed?
There was definitely talk of doing it, but it's never actually happened. I
don't think that it was actually decided that we would though,
On Saturday, 27 May 2017 at 18:21:41 UTC, Moritz Maxeiner wrote:
Then please don't call them "smart", because that term is
specifically reserved for something that adds at least some
additional features over a regular pointer (bounds checking,
memory / lifetime management, etc.).
"smart
On Saturday, 27 May 2017 at 17:28:47 UTC, Stanislav Blinov wrote:
On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
The class reference type should be fixable with a rewrite
into templated smart pointers,
On Saturday, 27 May 2017 at 17:24:14 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
The class reference type should be fixable with a rewrite
into templated smart
On Saturday, 27 May 2017 at 18:06:11 UTC, Stanislav Blinov wrote:
Perhaps it wouldn't be if we were talking about new language.
With D, such a change falls out of "some language changes, a
bit of automated source updating and a little bit of breakage",
and becomes "whole language change, a
On Saturday, 27 May 2017 at 17:30:49 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov
wrote:
But they are incompatible precisely because structs "don't
have it". Inheritance for one. Reference semantics for
another. A class reference is a pointer in
On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov wrote:
But they are incompatible precisely because structs "don't have
it". Inheritance for one. Reference semantics for another. A
class reference is a pointer in disguise, struct is full layout
on the stack. The only way to retain
On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
The class reference type should be fixable with a rewrite into
templated smart pointers, so no need for big changes there, I
think.
Smart pointers impose
On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
The class reference type should be fixable with a rewrite into
templated smart pointers, so no need for big changes there, I
think.
Smart pointers impose
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 16:52:17 UTC, Stanislav Blinov
wrote:
But structs in D have none of that.
Neither does C++ if you don't add a virtual function to it, so
it would be the same.
My question isn't whether structs
On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad
wrote:
The class reference type should be fixable with a rewrite into
templated smart pointers, so no need for big changes there, I
think.
Smart pointers impose a specific object lifetime, whereas (D)
classes do not. You
On Saturday, 27 May 2017 at 16:52:17 UTC, Stanislav Blinov wrote:
But structs in D have none of that.
Neither does C++ if you don't add a virtual function to it, so it
would be the same.
My question isn't whether structs have it now, but if the concept
struct and class could be merged.
On Saturday, 27 May 2017 at 16:37:04 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 16:31:32 UTC, Stanislav Blinov
wrote:
There's a lot more difference in D. Classes in D are fat
memory chunks storing pointers to ClassInfo (inc. vtable),
So are classes with virtual functions in
On Saturday, 27 May 2017 at 16:31:32 UTC, Stanislav Blinov wrote:
There's a lot more difference in D. Classes in D are fat memory
chunks storing pointers to ClassInfo (inc. vtable),
So are classes with virtual functions in C++, to get RTTI you
need to have a virtual member function. I don't
On Saturday, 27 May 2017 at 16:23:33 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 27 May 2017 at 16:04:42 UTC, Stanislav Blinov
wrote:
It's not "a little bit", it's ABI down the drain, along with a
good part of runtime. And we'd lose interfaces and extern(C++).
Why would you loose interfaces
On Saturday, 27 May 2017 at 16:04:42 UTC, Stanislav Blinov wrote:
It's not "a little bit", it's ABI down the drain, along with a
good part of runtime. And we'd lose interfaces and extern(C++).
Why would you loose interfaces and extern(C++)?
"struct" and "class" are interchangeable keywords in
On Saturday, 27 May 2017 at 14:12:09 UTC, Ola Fosheim Grøstad
wrote:
I wonder, what would break if all the features of class was
merged into struct?
Imagine that:
class Something ... { ... }
is lowered into:
struct _class_Something ... { ... }
alias Something =
I wonder, what would break if all the features of class was
merged into struct?
Imagine that:
class Something ... { ... }
is lowered into:
struct _class_Something ... { ... }
alias Something = MagicClassRef!_class_Something;
Is it conceivable with some language changes, a bit of
37 matches
Mail list logo