On Sunday, 10 January 2021 at 18:58:13 UTC, aberba wrote:
I'm looking to explore running a D application on Android based
on Adams previous foundation work. However, I'm not familiar
with the Android + D integration so I need some help.
Has any of you successfully done that? Could use a sample
On Saturday, 13 March 2021 at 00:36:37 UTC, David Zhang wrote:
On Friday, 12 March 2021 at 22:18:59 UTC, tsbockman wrote:
You can use TypeInfo references as the keys for the struct
types, too. It's better than hashes because the TypeInfo is
already being generated anyway, and is guaranteed to
On Friday, 12 March 2021 at 22:18:59 UTC, tsbockman wrote:
Why do you think you need a `void[]` slice? I think `void*`
pointers are sufficient. This handles all normal data types, as
long as they are allocated on the GC heap:
I wanted to have the registry own the structs' memory, though
using
On Friday, 12 March 2021 at 19:24:17 UTC, David Zhang wrote:
On Friday, 12 March 2021 at 18:50:26 UTC, tsbockman wrote:
The idea is to implement a service locator s.t. code like this
is possible:
...
I don't really need to copy or move the class instances here,
just be able to read, assig
On Friday, 12 March 2021 at 18:14:12 UTC, Imperatorn wrote:
On Friday, 12 March 2021 at 17:57:06 UTC, David Zhang wrote:
On Friday, 12 March 2021 at 17:46:22 UTC, Imperatorn wrote:
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
[...]
Have you tried using Variant or jsvar
(ht
On Friday, 12 March 2021 at 18:50:26 UTC, tsbockman wrote:
The idea is to implement a service locator s.t. code like this is
possible:
// struct (I didn't mention this in the top post, my mistake)
auto log = Logger()
api_registry.register!Logger(log);
// class/interface
On Friday, 12 March 2021 at 18:50:26 UTC, tsbockman wrote:
/* This will return `null` if the value isn't really a
reference to an instance
of a subtype of `I`, or if the key isn't in the map yet. If
you don't care
about the latter case, it can be shortened to just `cast(I)
map[I.str
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time.
Assuming these interfaces are actual D `interface`s, declared
with the keyword and using the default `extern(D)` linkage,
you're wa
On Friday, 12 March 2021 at 17:57:06 UTC, David Zhang wrote:
On Friday, 12 March 2021 at 17:46:22 UTC, Imperatorn wrote:
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
[...]
Have you tried using Variant or jsvar
(https://code.dlang.org/packages/arsd-official%3Ajsvar)? 🤔
It
On Friday, 12 March 2021 at 17:46:22 UTC, Imperatorn wrote:
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time. However, it appears to
produce garbage values on get().
Is this even po
On Friday, 12 March 2021 at 17:37:43 UTC, David Zhang wrote:
I want to store interfaces as untyped void[], then cast them
back to the interface at a later time. However, it appears to
produce garbage values on get().
Is this even possible, and if so, what is happening here? The
alternative w
I want to store interfaces as untyped void[], then cast them back
to the interface at a later time. However, it appears to produce
garbage values on get().
Is this even possible, and if so, what is happening here? The
alternative would be a struct { CheckedPtr self; api_fns }
e.g.
void
On Friday, 12 March 2021 at 10:26:55 UTC, Dennis wrote:
```
version(BigEndian) {
private enum bigEndian = true;
} else {
private enum bigEndian = false;
}
int parse(in ubyte[] data) {
if (__ctfe || bigEndian) {
// Portable code
} else {
// Little-endian optimized
On Friday, 12 March 2021 at 05:53:40 UTC, Preetpal wrote:
This is not an important issue to me but I was just curious to
see if anyone actually tests for portability issues related to
endianness by compiling their D Lang code for a big endian
architecture and actually running it on that system.
14 matches
Mail list logo
