On Friday, 19 August 2022 at 16:36:24 UTC, MyNameHere wrote:
On Friday, 19 August 2022 at 14:30:50 UTC, kinke wrote:
Oh and `DevicePath()` is a convenience member returning a
pointer to the 'dynamic array' (as the array decays to a
pointer in C too), so no need to fiddle with `.offsetof` and
c
On Friday, 19 August 2022 at 13:47:41 UTC, Paul Backus wrote:
On Friday, 19 August 2022 at 10:22:25 UTC, bauss wrote:
Is there a reason why .stringof is implementation defined and
not clearly defined in the spec how types and declarations
should be treated when being "converted to a string"?
On Friday, 19 August 2022 at 16:19:04 UTC, Gavin Ray wrote:
1. Calling `.toBytes()` on an `OutBuffer` will discard the
extra bytes allocated past what was reserved and used. But this
will still allocate the memory in the first place I guess (will
the compiler optimize this away?)
It does allo
On 8/19/22 12:36 PM, MyNameHere wrote:
On Friday, 19 August 2022 at 14:30:50 UTC, kinke wrote:
Oh and `DevicePath()` is a convenience member returning a pointer to
the 'dynamic array' (as the array decays to a pointer in C too), so no
need to fiddle with `.offsetof` and computing the pointer ma
On Friday, 19 August 2022 at 14:30:50 UTC, kinke wrote:
Oh and `DevicePath()` is a convenience member returning a
pointer to the 'dynamic array' (as the array decays to a
pointer in C too), so no need to fiddle with `.offsetof` and
computing the pointer manually.
I am using ```-BetterC```, so
On Monday, 15 August 2022 at 22:47:21 UTC, frame wrote:
On Monday, 15 August 2022 at 20:51:07 UTC, Gavin Ray wrote:
Is there an alternative to `OutBuffer` or a method you can
call to set a byte limit on the resizing?
Are you looking for a circular buffer?
https://code.dlang.org/packages/ring
On Friday, 19 August 2022 at 02:02:57 UTC, Adam D Ruppe wrote:
Even if they aren't equal, you'll get decent benefit from
parallel on the outer one alone, but not as good since the work
won't be balanced.
Unless there's some kind of blocking going on in D's
implementation, if the number of pa
On Friday, 19 August 2022 at 13:49:08 UTC, MyNameHere wrote:
Thank you, that seems to have resolved the issue, though I wish
these sorts of problems would stop cropping up, they are
souring the experience with the language.
Oh and `DevicePath()` is a convenience member returning a pointer
to
On Friday, 19 August 2022 at 14:22:04 UTC, Steven Schveighoffer
wrote:
On 8/19/22 9:49 AM, MyNameHere wrote:
Thank you, that seems to have resolved the issue, though I
wish these sorts of problems would stop cropping up, they are
souring the experience with the language.
Most likely that "mem
On 8/19/22 9:49 AM, MyNameHere wrote:
Thank you, that seems to have resolved the issue, though I wish these
sorts of problems would stop cropping up, they are souring the
experience with the language.
Most likely that "member" is a macro in C. D doesn't have macros, so it
uses properties.
T
Thank you, that seems to have resolved the issue, though I wish
these sorts of problems would stop cropping up, they are souring
the experience with the language.
On Friday, 19 August 2022 at 10:22:25 UTC, bauss wrote:
Is there a reason why .stringof is implementation defined and
not clearly defined in the spec how types and declarations
should be treated when being "converted to a string"?
I find it really odd that it's implementation defined and you
It's a method returning a `CHAR*` - `_DevicePath` is the actual
member. I guess it's a dynamically sized struct, which cannot be
mapped directly to D, hence this representation.
On Friday, 19 August 2022 at 05:50:17 UTC, Mike Parker wrote:
On Friday, 19 August 2022 at 04:25:25 UTC, Ruby The Roobster
wrote:
[...]
If the template is never instantiated, it never makes it into
the executable. It doesn't matter if it's in production or not,
and has nothing to do with t
I am receiving this error:
```
Error: no property `offsetof` for type `char*`
```
from this snippet:
```d
import core.sys.windows.setupapi;
void main() {
SP_DEVICE_INTERFACE_DETAIL_DATA_A DeviceInterfaceDetail;
uint Offset = DeviceInterfaceDetail.DevicePath.offsetof;
}
```
You may try
On 8/18/22 1:16 AM, Ali Çehreli wrote:
On 8/17/22 19:27, Steven Schveighoffer wrote:
> On 8/17/22 10:09 PM, Ali Çehreli wrote:
>> > IIRC, your data does not need to be sequential in *physical memory*,
>> > which means you can use a ring buffer that is segmented instead of
>> > virtually ma
On Friday, 19 August 2022 at 11:18:48 UTC, bauss wrote:
It's one thing D really misses, but is really hard to implement
when it wasn't thought of to begin with. It should have been
implemented alongside functions that may change between
languages and cultures.
I guess we have another task f
On Friday, 19 August 2022 at 06:34:19 UTC, Patrick Schluter wrote:
On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole
wrote:
On 19/08/2022 4:56 AM, IGotD- wrote:
BetterC means no arrays or strings library and usually in
terminal tools you need to process text. Full D is wonderful
f
On Thursday, 18 August 2022 at 17:15:12 UTC, rikki cattermole
wrote:
Unicode support in Full D isn't complete.
There is nothing in phobos to even change case correctly!
Both are limited if you care about certain stuff like non-latin
based languages like Turkic.
I think full D is fine for te
On Thursday, 18 August 2022 at 22:00:06 UTC, Paul Backus wrote:
On Wednesday, 17 August 2022 at 11:38:31 UTC, Steven
Schveighoffer wrote:
On 8/17/22 6:38 AM, Dennis wrote:
On Wednesday, 17 August 2022 at 08:44:30 UTC, Ogi wrote:
Maybe I’m missing something?
I had the same problem, and came u
On Wednesday, 17 August 2022 at 10:38:33 UTC, Dennis wrote:
I had the same problem, and came up with the following trick:
```D
enum itoa(int i) = i.stringof;
enum major = 3;
enum minor = 2;
enum patch = 1;
enum versionString = itoa!major ~ "." ~ itoa!minor ~ "." ~
itoa!patch;
static assert(
21 matches
Mail list logo
