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 20:12:09 UTC, jfondren wrote:
On Sunday, 27 June 2021 at 19:50:09 UTC, Matilda wrote:
[...]
This works with either readf line for me on v2.097.0.
Try stracing your program.
Okay, thank you. I'll try it out.
On Sunday, 27 June 2021 at 19:50:09 UTC, Matilda wrote:
I'm trying to read from stdin and then print an integer value.
This is how my code looks like:
```d
import std.stdio;
import std.conv;
import std.string;
void main()
{
writeln("Input your variant (1 - 10):");
int key;
I'm trying to read from stdin and then print an integer value.
This is how my code looks like:
```d
import std.stdio;
import std.conv;
import std.string;
void main()
{
writeln("Input your variant (1 - 10):");
int key;
//readf(" %d", );
//readf!" %d"(key);
key =
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
14 matches
Mail list logo
