On Monday, 28 June 2021 at 07:44:25 UTC, Mathias LANG wrote:
(the case you are thinking of), but also provides us from
making non backward-compatible downstream changes (meaning we
can't change it as we see fit if we realize there is potential
for optimization).
Has this ever happened?
On Monday, 28 June 2021 at 06:13:06 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 27 June 2021 at 23:20:38 UTC, Mathias LANG wrote:
- It locks us in a position where we depend on an external
committee / implementation to define our ABI.
Well, that could be an issue, but it is not likely to
On Monday, 28 June 2021 at 06:25:39 UTC, Mike Parker wrote:
Slack isn't like our IRC or Discord channels. It's more async
like the forums.
Thanks for the info, I might look into Slack if it doesn't
require me to install anything. If it is an official channel you
might consider adding it to
On Monday, 28 June 2021 at 06:13:06 UTC, Ola Fosheim Grøstad
wrote:
I don't have much time for chat, I prefer async communication.
Slack isn't like our IRC or Discord channels. It's more async
like the forums.
On Sunday, 27 June 2021 at 23:20:38 UTC, Mathias LANG wrote:
- It locks us in a position where we depend on an external
committee / implementation to define our ABI.
Well, that could be an issue, but it is not likely to change fast
or frequently so I don't think it is a high risk approach.
On Sunday, 27 June 2021 at 08:41:27 UTC, kinke wrote:
On Sunday, 27 June 2021 at 07:54:38 UTC, Ola Fosheim Grøstad
wrote: [AFAIK, most C++ implementations put the - of course
totally incompatible - *C++* TypeInfo into vtable slot -1.]
Actually my understanding is that it's part of the ABI:
On Sunday, 27 June 2021 at 10:11:44 UTC, kinke wrote:
On Sunday, 27 June 2021 at 09:46:45 UTC, Ola Fosheim Grøstad
We need organized action,Instead of doing it blindly.
I always say organize.
On Sunday, 27 June 2021 at 12:00:41 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 27 June 2021 at 10:11:44 UTC, kinke wrote:
Right, but what does all supported C++ runtimes mean? I thought
LDC was tied to clang, which I guess means two runtimes? If C++
doesn't use arbitrary negative offsets, then
On Sunday, 27 June 2021 at 10:11:44 UTC, kinke wrote:
It's not about classes using monitors themselves, it's about
people potentially using `synchronized (obj)` for some
arbitrary class reference `obj`.
I wasn't aware this was a thing. If people want this they can
just embed a mutex in the
On Sunday, 27 June 2021 at 09:46:45 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 27 June 2021 at 08:41:27 UTC, kinke wrote:
Getting rid of the monitor field was discussed multiple times.
You don't have to get rid of it, just implicitly declare it for
classes that use monitors? I don't think it
On Sunday, 27 June 2021 at 09:35:10 UTC, IGotD- wrote:
Probably about all managed languages.
I am sceptical of this assumption. There are no reasons for a GC
language to require the usage of fat pointers?
When you use a struct as a member variable in another struct
the data will be
On Sunday, 27 June 2021 at 08:41:27 UTC, kinke wrote:
Getting rid of the monitor field was discussed multiple times.
You don't have to get rid of it, just implicitly declare it for
classes that use monitors? I don't think it has to be at a
specific offset?
The other major and not so
On Sunday, 27 June 2021 at 07:48:22 UTC, Ola Fosheim Grøstad
wrote:
Which languages use fat pointers? C++ may use it (but is not
required to).
Probably about all managed languages. One common method is a that
it is actually an identifier it is used in a hash table. Then you
can find all
On Sunday, 27 June 2021 at 07:54:38 UTC, Ola Fosheim Grøstad
wrote:
That is all good, but it will lead to `extern(C++) class`
replacing D classes. So why not unify right away? Why wait for
the inevitable?
The assumption that all D code and all classes therein are or
need to be designed for
On Saturday, 26 June 2021 at 20:03:01 UTC, kinke wrote:
On Saturday, 26 June 2021 at 13:49:25 UTC, Ola Fosheim Grøstad
wrote:
Is it possible to inherit from a C++ class and get a D
subclass, and is it possible to inherit from a D class and get
a C++ class?
Sure thing, with `extern(C++)
On Friday, 25 June 2021 at 21:05:36 UTC, IGotD- wrote:
Yes, that's a tradeoff but one I'm willing to take. I'm
thinking even bigger managed pointers of perhaps 32 bytes which
has more metadata like the allocated size. Managed languages in
general have fat pointers which we see everywhere and
On Saturday, 26 June 2021 at 20:03:01 UTC, kinke wrote:
With C++, you can today, an `extern(C++) class C` is equivalent
to and mangled as C++ `C*`. You can't pass it directly to some
`unique_ptr` or `shared_ptr` of course; an according D
wrapper reflecting the C++ implementation
On Saturday, 26 June 2021 at 13:49:25 UTC, Ola Fosheim Grøstad
wrote:
Is it possible to inherit from a C++ class and get a D
subclass, and is it possible to inherit from a D class and get
a C++ class?
Sure thing, with `extern(C++) class` of course.
But the best solution is to get to a place
On Saturday, 26 June 2021 at 07:39:44 UTC, kinke wrote:
I'm pretty sure I haven't seen a weak pointer in C++ yet. I
don't look at C++ much anymore, but I suspect they are even a
lot rarer than shared_ptr.
Weak pointers are usually not needed, but sometimes you do need
them and then not
On Saturday, 26 June 2021 at 07:00:37 UTC, Ola Fosheim Grøstad
wrote:
Weak pointers aren't in the language, so I don't see why they
would matter here. I thought you were after replacing
GC-allocated class instances by a simple RC scheme.
One goal could be to make a class compatible with C++
On Friday, 25 June 2021 at 23:55:40 UTC, kinke wrote:
I cannot imagine how weak pointers would work without an ugly
extra indirection layer. If we're on the same page, we're
talking about embedding the reference counter *directly* in the
class instance, and the class ref still pointing
On Friday, 25 June 2021 at 17:05:41 UTC, Ola Fosheim Grøstad
wrote:
Yes, if you don't want to support weak pointers. I think you
need two counters if you want to enable the usage of weak
pointers.
I cannot imagine how weak pointers would work without an ugly
extra indirection layer. If we're
On Friday, 25 June 2021 at 20:22:24 UTC, Ola Fosheim Grøstad
wrote:
Hm. Not sure if I follow, I think we are talking about stuffing
bits into the counter and not the address?
Then I misunderstood. If it's a counter it should be fine.
But fat pointers are 16 bytes, so quite expensive.
On Friday, 25 June 2021 at 17:37:13 UTC, IGotD- wrote:
You cannot use the most significant bit as it will not work
with some 32-bit systems. Linux with a 3G kernel position for
example. Better to use the least significant bit as all
allocated memory is guaranteed to be aligned. Regardless this
On Friday, 25 June 2021 at 17:37:13 UTC, IGotD- wrote:
You cannot use the most significant bit as it will not work
with some 32-bit systems. Linux with a 3G kernel position for
example. Better to use the least significant bit as all
allocated memory is guaranteed to be aligned. Regardless
On Friday, 25 June 2021 at 07:17:20 UTC, kinke wrote:
Wrt. manual non-heap allocations (stack/data segment/emplace
etc.), you could e.g. reserve the most significant bit of the
counter to denote such instances and prevent them from being
free'd (and possibly finalization/destruction too; this
On Friday, 25 June 2021 at 07:17:20 UTC, kinke wrote:
Wrt. manual non-heap allocations (stack/data segment/emplace
etc.), you could e.g. reserve the most significant bit of the
counter to denote such instances and prevent them from being
free'd (and possibly finalization/destruction too; this
On Friday, 25 June 2021 at 07:01:31 UTC, kinke wrote:
Well AFAIK it's mandated by the language, so an RC scheme
replacing such allocations by heap ones seems like a definite
step backwards - it's a useful pattern, and as Stefan pointed
out, definitely in use. You could still stack-allocate but
Wrt. manual non-heap allocations (stack/data segment/emplace
etc.), you could e.g. reserve the most significant bit of the
counter to denote such instances and prevent them from being
free'd (and possibly finalization/destruction too; this would
need some more thought I suppose).
On Friday, 25 June 2021 at 06:09:17 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
Yes, class *refs* are always pointers. *scope* classes are
deprecated (I don't think I've ever seen one); with `scope c =
new Object`, you can have the compiler allocate
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
Yes, class *refs* are always pointers. *scope* classes are
deprecated (I don't think I've ever seen one); with `scope c =
new Object`, you can have the compiler allocate a class
*instance* on the stack for you, but `c` is still a *ref*.
On Thursday, 24 June 2021 at 12:31:08 UTC, Stefan Koch wrote:
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
On Thursday, 24 June 2021 at 06:50:44 UTC, Ola Fosheim Grøstad
wrote:
[...]
(I don't think I've ever seen one); with `scope c = new
Object`, you can have the compiler
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
On Thursday, 24 June 2021 at 06:50:44 UTC, Ola Fosheim Grøstad
wrote:
[...]
(I don't think I've ever seen one); with `scope c = new
Object`, you can have the compiler allocate a class *instance*
on the stack for you, but `c` is still a
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
*scope* classes are deprecated (I don't think I've ever seen
one);
I used it for my database thing where it is supposed to be
destroyed reliably but also uses runtime polymorphism.
I now suggest people just stick `scope(exit)
On Thursday, 24 June 2021 at 06:50:44 UTC, Ola Fosheim Grøstad
wrote:
[...]
Yes, class *refs* are always pointers. *scope* classes are
deprecated (I don't think I've ever seen one); with `scope c =
new Object`, you can have the compiler allocate a class
*instance* on the stack for you, but
35 matches
Mail list logo
