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 mapped, and that can be of any size.
>>
>> I
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 mapped, and that can be of any size.
I thought about that as well. But I would like the sizes of
On 8/17/22 18:31, Steven Schveighoffer wrote:
> 1. I highly recommend trying out the ring buffer solution to see if it
> helps. The disadvantage here is that you need to tie up at least a page
> of memory.
I started to think holding on to multiple pages of memory should not
matter anyway. If
On 8/17/22 2:40 PM, Ali Çehreli wrote:
On 8/16/22 19:33, Steven Schveighoffer wrote:
Using a 16-byte block sounds like a good strategy at first because
nobody knows whether an array will get more than one element.
However, if my guess is correct (i.e. the first element of size of
16-bytes
On 8/16/22 19:33, Steven Schveighoffer wrote:
> Everything in the memory allocator is in terms of pages. A pool is a
> section of pages. The large blocks are a *multiple* of pages, whereas
> the small blocks are pages that are *divided* into same-sized chunks.
Thank you. I am appreciating this
On 8/17/22 09:28, Diego wrote:
> I'm writing a little terminal tool, so i think `-betterC` is the best
> and simple solution in my case.
It depends on what you mean with terminal tool bun in general, no, full
features of D is the most useful option.
I've written a family of programs that
Thank you to everyone,
I'm writing a little terminal tool, so i think `-betterC` is the
best and simple solution in my case.
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 up with the following trick:
```D
enum itoa(int i) = i.stringof;
```
I have the same thing in my code:
```d
enum intStr(int x) =
On Wednesday, 17 August 2022 at 08:44:30 UTC, Ogi wrote:
Maybe I’m missing something?
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 ~ "." ~
It’s 2022 already and BetterC still imposes limits at compile
time and makes things awkward.
I have 3 integer enums that represents my library version. And I
want to generate a "1.2.3" enum from them. This is a trivial
thing to do in standard D but I can’t find a way to do it with
BetterC
10 matches
Mail list logo
