On Sunday, 2 January 2022 at 15:13:06 UTC, Paul Backus wrote:

p1.d(9): Error: cannot cast expression `until(b[], '\x0a', Flag.yes)` of type `Until!("a == b", ubyte[], char)` to `char[]`

import std.stdio;
import std.string;
import std.algorithm : until, map;
import std.conv : to;

void main() {
    ubyte[8] b = [0x68, 0x65, 0x6C, 0x6C, 0x6F, 0x0A, 0x00, 0x00];
    /* "hello\n\0\0" */
    writefln("'%-(%s%), world'", b[].until('\n').map!(to!char));
}

Well, just a Gross!
But I am not a fun of functional programming style :)
(sorry for replying late)

On 1/7/22 2:54 PM, eugene wrote:

No, until will iterate the string one character at a time until it sees that character (excluding it). It doesn't make a copy of the data.

In effect, it's doing the "trim" and the iteration to print in one step. In your chosen solution earlier, you were doing it 3 times -- once to find the end of the null-terminated string (via fromStringz), once to strip the newline (well, this isn't too bad, since it goes from both ends), and once to actually print it.

There are a million ways to get what you want. I like to go for ones that:

1. don't allocate needlessly (I hate allocating a string just to print it, and then throw it away, regardless of whether it's GC or not)
2. read concisely and clearly.
3. Are as efficient as possible.

The one wart here is the cast, but that's impossible to avoid unless you want to allocate. Adhering to 2 and 3 above sometimes are in conflict. But rule 1 is essential for performance.

In C you have one choice (printf), but that choice may not fit your needs.

-Steve

On Friday, 7 January 2022 at 20:40:02 UTC, Adam D Ruppe wrote:

Aha, unless you'll build GC into OS core :)

if (ptr) {
    free(ptr);
    ptr = NULL;
}

...

    if (NULL == someptr)
        BUG()/PANIC()/WHATEVER()

first time I've heard this )))
tell that to py/js super-coders :)

other way around

• when the lifetime is trivial (whithin a function, including thread function) - trust GC
• when the lifetime is not trivial (ptr goes through or a self-pipe or similar) - GC has no info about that

On Friday, 7 January 2022 at 21:17:33 UTC, Steven Schveighoffer wrote:

There are 2 buffers (RX one and TX one, both of 'reasonable' size)
(it's the effing echo-server, nothing more)

• print content of RX-buffer, ommiting terminating '\n' ('\n' is the 'end of request') to (log/journal file)/stdout/

• ouptut received 'message' back to client, with terminating '\n'

On Thursday, 30 December 2021 at 09:34:27 UTC, eugene wrote:

char[] s = cast(char[])ioCtx.buf[0 .. strlen(cast(char*)ioCtx.buf.ptr) - 1];
// -1 is to eliminate terminating '\n'
writefln("got '%s' from '%s:%d'", s, client.addr, client.port);

Try auto s = fromStringz(cast(char*)ioCtx.buf.ptr).

On Friday, 7 January 2022 at 22:04:28 UTC, eugene wrote:

However, you should not rely on a terminating '\n' even you are the source. You determine the length of string trough '\n' but maybe your buffer doesn't contain it (yet) if the connection wasn't blocking or the message is longer as the buffer size or you received just error data.

Then, accessing the ubyte[] data directly via .ptr/ casting it to char* without knowing the possible content seems not a good idea - if you are using any function that returns bytes till it finds a needle or terminating '\0'.

I know it's a little bit off topic but if the question is about the best concise way, the solution you choose should respect that too.