#process a string before returning it
1 messages · Page 1 of 1 (latest)
where wrapStr adds \n every few words
fn wrapStr(comptime string: []const u8) [:0]const u8 {
comptime {
var wrap = 20;
var out: [string.len:0]u8 = undefined;
for (0..out.len) |i| {
if (string[i] == ' ' and i > wrap) {
out[i] = '\n';
wrap += 20;
}
else {
out[i] = string[i];
}
}
return &out;
}
}```
very bad code, im in a rush
var out: [string.len:0]u8 = undefined;
seems bit suspicious since it's suspposed to represent null terminated array yet undefined is assigned to it. Maybe remove the null sentinel and use 0..string.len in the for loop
i need the null sentinel for a library
you can write the null byte at the end of the out and return slice with null terminator
its a wrapper around a clibrary that requires [:0]const u8 specifcally
also out has to be longer than string.len, since you'll be adding new characters to it.
In comptimes it's usually easier to have dynamic arrays using concatenate operator
you can cast to appropriate type on return, is what i meant
iirc [:0] increases the array by 1 invisibily for the null character
im replacing spaces
yep
i dont know how to cast from []const u8 to [:0] const u8 at comptime
the above code gives global variable contains reference to comptime var
hmm maybe can just do it in place, something like:
fn wrapStr(comptime string: []const u8) [:0]const u8 {
var wrap = 20;
var out: [string.len:0]u8 = string.*;
for (0..out.len) |i| {
if (out[i] == ' ' and i > wrap) {
out[i] = '\n';
wrap += 20;
}
}
return &out;
}
which makes sense, its returning a slice/pointer, but im not sure how else
can return array
is comptime not needed?
should be implied given that it operates on comptime variable
yeah, couldn't remember, have to use string.ptr.* then
same error message wierdly
not sure how this would work, even tho its comptime its being equalled to a ptr
ah right, original doesn't have sentinel. Then will have to add it manually
wait no it does, specify in the type since in zig literals by default have the 0 sentinel to be compatible with C when needed
comptime string: [:0]const u8, will work in your case of const mystr: [:0]u8 = wrapStr("Some long text 123 abc efg hij klm nop")
maybe thisi s impossible in zig ;/
not at comptime
fn wrapStr(comptime string: [:0]const u8) [:0]const u8 {
var wrap = 20;
var out: [string.len:0]u8 = string[0..string.len].*;
for (0..out.len) |i| {
if (out[i] == ' ' and i > wrap) {
out[i] = '\n';
wrap += 20;
}
}
return &out;
}```
this just gives the same error message as mine
can i not return some "comptime literal" instead of a slice
i find this wierd, is there no way to return a N sized array? its all pointers.
right, not sure what global variable it's talking about there
can i not do fn wrapStr(...) [N:0]const u8 {...}
you can return array in zig
i'm not sure if this works, but hopefuly it does:
fn wrapStr(comptime string: [:0]const u8) [string.len:0]u8 {
(removed const, this isn't pointer)
wow
works flawlessly
syntax for pointers/slices/fixed is so similar i think its bad
i barely know the idfferences between [*]u8 and *[]u8 and []u8
yeah, zig comptime needs to get used to, but it blurs the line between runtime logic and comptime. Like in other languages you'd need to use some generic N, while here you can use string.len in comptime context
this is even wierder at comptime because you always know the size of the var so everything can be a slice so it makes 0 sense
the syntax for pointers and slices is fine to be similar, since both are pointer types. As for array type, it follows C style of [N], but that is pretty similar to [*] and []
thank you for helping, im so lost with comptime
also i think this is a lifetime issue
think of slices as pointers with length. So if array is the byte sequence, slice is a pointer to this byte sequence with amount of elements coupled with it
yes but at comptime, even a non slice pointer you still know the length of
so a pointer and a slice is the same at comptime or should be the same
yeah which sort of makes it simpler since you can use both, but have to keep in mind that in one case you're passing around value and in other case passing around pointer to the value