Re: Compile time int to string conversion in BetterC
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(versionString == "3.2.1"); ``` Nice! Thank you, I’ll use this.
Re: Compile time int to string conversion in BetterC
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 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) = x.stringof; ``` I merged a version of this into Phobos (for internal use): https://github.com/dlang/phobos/blob/v2.100.1/std/conv.d#L5986-L5987 It also comes with a unit test, so we don't get surprise breakage if the behavior of `.stringof` ever changes. 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 essentially can't rely on it anywhere. It's something that has baffled me a lot. Like are there something I'm missing that means it cannot be specified?
Re: Programs in D are huge
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 terminal programs. What you commonly do is tokenize text, remove white space, convert text to numbers etc. The D library is good for these tasks. Rewrite all this for betterC would be a tedious tak
Re: Programs in D are huge
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 for such task but betterC would be limited unless you want to write your own array and string functionality. 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. A general toupper/tolower for Unicode is doomed to fail. As already mentioned Turkish has its specificity, but other languages also have traps. In Greek toupper/tolower are not reversible i.e. `x.toupper.tolower == x` is not guaranteed . Some languages have 1 codepoint input and 2 codepoints as result (German ß becomes SS in most cases, capital ẞ is not the right choice in most cases). etc. etc. That's why you should implementat formatting providers for languages that handle such things. Like in C# you have the CultureInfo class that you can give to methods such as ToString, ToLower etc. which will correctly handle specific "cultures" 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.
Re: Programs in D are huge
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 for Phobos v2.
Re: In-place extension of arrays only for certain alignment?
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 mapped, and that can be of any size. >> >> I thought about that as well. But I would like the sizes of blocks >> (Appenders?) be equal in size so that opIndex still can provide O(1) >> guarantee. (Compute the block + an offset.) > > It's still O(1). You only have 2 slices to worry about. Sometimes 2... I wanted to leave the sliding window width dynamic. So, there will be M buffers, not 2. If their lengths are not equal, opIndex must be O(M). M is expected to be small but still... Once you need more size, you can reallocate (it should stabilize). A ring buffer of N values where N doesn't change should only require one buffer, 2 slices of that buffer. -Steve
"Error: no property `offsetof` for type `char*`"
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 this at https://run.dlang.io/, build with ```LDC```,
with argument: ```-mtriple=x86_64-windows-msvc```.
Re: This code completely breaks the compiler:
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 tests. It doesn't exist. How could
the compiler catch any problems if it has no idea what `Mtypes`
is?
This is true for any template parameter. Consider this:
```d
import std.stdio;
T derp(T)(T val) {
val += 10;
return val;
}
void main()
{
writeln("Hello D");
}
```
`derp` obviously isn't going to work with every type. But this
code compiles because `derp` is never instantiated. The
compiler can't check if the code in `derp` is valid because it
has no idea what `T` might be. If it's `int`, then no problem.
If it's `string` then no way:
```d
void main()
{
writeln(derp!string("No way"));
}
```
Now you'll get this:
```
onlineapp.d(4): Error: slice `val` is not mutable
onlineapp.d(10): Error: template instance
`onlineapp.derp!string` error instantiating
```
This makes sense. Still, in my code, where the function has the
same return type regardless of instantiation, the compiler should
at least check that expressions independent of the template
parameter are valid.
Re: "Error: no property `offsetof` for type `char*`"
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.
Re: Compile time int to string conversion in BetterC
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 essentially can't rely on it anywhere. It's something that has baffled me a lot. Like are there something I'm missing that means it cannot be specified? Basically, `.stringof` is what the compiler uses when it needs to display something in an error message. If it were locked down in the spec, then making improvements to error messages would in some cases require a deprecation cycle. That said, it might still be worth specifying the behavior in a few specific cases—e.g., guaranteeing that `.stringof` on an integer value will always produce a valid integer literal.
Re: "Error: no property `offsetof` for type `char*`"
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.
Re: "Error: no property `offsetof` for type `char*`"
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. The error message could be better though. -Steve
Re: "Error: no property `offsetof` for type `char*`"
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 "member" is a macro in C. D doesn't have macros, so it uses properties. Nope, it's really a dynamically sized struct with a last `CHAR[1]` member: https://docs.microsoft.com/en-us/windows/win32/api/setupapi/ns-setupapi-sp_device_interface_detail_data_a Just like with C, these abominations need very special care, and regularly allocating on the stack or using as an aggregate field isn't possible.
Re: "Error: no property `offsetof` for type `char*`"
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 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.
Re: Recommendation for parallelism with nested for loops?
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 passes on the outer loop is large enough relative to the number of cores, applying parallel to the outer loop is the best you can do - uneven amounts of work on the inner loop will get spread out across cores. There are always counterexamples, but the ratio of passes to cores needs to be pretty low for further optimizations to have any chance to help.
Re: Fixed-size OutBuffer that doesn't call .resize() automatically? (for database page buffers)
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/ringbuffer
Thanks for this suggestion, I hadn't considered it
I discovered 3 ways of doing it:
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?)
2. Copy the `OutBuffer` class into a new `FixedSizeOutBuffer(T)`
and alter its behavior
3. Use `ubyte[PAGE_SIZE]` and manually write like below:
```d
ubyte[] toBytes(uint value)
{
static ubyte[4] bytes = new ubyte[4];
bytes[0] = cast(ubyte)(value >> 24);
bytes[1] = cast(ubyte)(value >> 16);
bytes[2] = cast(ubyte)(value >> 8);
bytes[3] = cast(ubyte)(value);
return bytes;
}
void serialize(out ubyte[PAGE_SIZE] outbuf)
{
ubyte[] buf;
reserve(buf, PAGE_SIZE);
buf ~= toBytes(header.pageId);
buf ~= toBytes(header.logStorageNumber);
buf ~= toBytes(header.prevPageId);
buf ~= toBytes(header.nextPageId);
buf ~= toBytes(header.freeSpacePointer);
buf ~= toBytes(header.tupleCount);
foreach (idx, ref slot; header.slots)
{
buf ~= toBytes(slot.offset);
buf ~= toBytes(slot.size);
}
// Skip over free space
ubyte[] padding = new ubyte[header.freeSpacePointer];
padding[] = 0;
buf ~= padding;
foreach (idx, ref tuple; tuples)
{
buf ~= toBytes(tuple.size);
buf ~= tuple.data;
}
move(buf.ptr, outbuf.ptr);
}
```
Re: "Error: no property `offsetof` for type `char*`"
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 that path is closed to me, I think.
Re: "Error: no property `offsetof` for type `char*`"
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 manually. I am using ```-BetterC```, so that path is closed to me, I think. dynamic arrays are really slices, and they are allowed in betterC. -Steve
Re: Fixed-size OutBuffer that doesn't call .resize() automatically? (for database page buffers)
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 allocate when it needs to. It grows but never shrinks again. 2. Copy the `OutBuffer` class into a new `FixedSizeOutBuffer(T)` and alter its behavior 3. Use `ubyte[PAGE_SIZE]` and manually write like below: ```d static ubyte[4] bytes = new ubyte[4]; ``` Looks still unnecessary - you are allocating thread local memory. Just use a static array. ```d foreach (idx, ref slot; header.slots) ``` No need to reference `slot` here. You may prevent compiler optimizations. ```d // Skip over free space ubyte[] padding = new ubyte[header.freeSpacePointer]; padding[] = 0; buf ~= padding; ``` Unnecessary, the initial value of `ubyte` is 0 and allocation is done automatically. Just set the slice length: ```d buf.length += header.freeSpacePointer; ``` ```d foreach (idx, ref tuple; tuples) ``` Again, no need to reference ```d move(buf.ptr, outbuf.ptr); ``` Not sure what that is. A simple ```d outbuf[0 .. buf.length] = buf; // or whatever position to write in outbuf ``` should do it too.
Re: Compile time int to string conversion in BetterC
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"? I find it really odd that it's implementation defined and you essentially can't rely on it anywhere. It's something that has baffled me a lot. Like are there something I'm missing that means it cannot be specified? Basically, `.stringof` is what the compiler uses when it needs to display something in an error message. If it were locked down in the spec, then making improvements to error messages would in some cases require a deprecation cycle. That said, it might still be worth specifying the behavior in a few specific cases—e.g., guaranteeing that `.stringof` on an integer value will always produce a valid integer literal. Yeah I mean not all of its behavior has to be implementation defined.
Re: "Error: no property `offsetof` for type `char*`"
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 computing the pointer manually. I am using ```-BetterC```, so that path is closed to me, I think. I believe you aren't allowed to _append_ to dynamic arrays/slices; otherwise you can use them
