On Tuesday, 9 April 2024 at 23:50:36 UTC, Richard (Rikki) Andrew Cattermole wrote:

Well then, perhaps this is a bug (though a useful bug in my case).

If you want to investigate, you can download this commit of Raylib-D. The DUB package in the rayguiexample directory has betterC as a build option, yet doesn't have this error. This is despite the inclusion of a CTFE function with string appending.

It's in source/raylib/package.d where mixin(EnumPrefixes!Key("KeyboardKey", "KEY_")); appears. The definition of EnumPrefixes is in source/templates.d.

On Tuesday, 9 April 2024 at 23:50:36 UTC, Richard (Rikki) Andrew Cattermole wrote:

Array appending calls a runtime function which accepts TypeInfo (In this case, TypeInfoGeneric!char). So this does indeed involve TypeInfo. But also, even if TypeInfo weren't involved, it also needs the GC which is unavailable with betterC. It's just that the TypeInfo error happens first.

The move to use templates instead of TypeInfo is slowly happening.

-Steve

On Tuesday, 9 April 2024 at 12:45:55 UTC, Richard (Rikki) Andrew Cattermole wrote:

Here's what I wanted to do.

In the library I'm working on, there are various declarations for functions defined in an external C library following the line extern (C) @nogc nothrow:. Here are some examples of such declarations which have a const(char)* parameter:

void InitWindow(int width, int height, const(char)* title);
void SetWindowTitle(const(char)* title);
Shader LoadShader(const(char)* vsFileName, const(char)* fsFileName);

I wanted to generate definitions of overloads of these functions using strings as parameters instead of const(char)*. For the InitWindow function shown above, the overload should be defined like this:

void InitWindow(int width, int height, ref string title) {
    InitWindow(width, height, cast(const(char)*)title);
}

or alternatively, like the following:

void InitWindow(int width, int height, string title) {
    InitWindow(width, height, title.toStringz);
}

I'm not sure which of these is better, thought the latter one would need to be modified to not accept string literals. I found that the former one has the advantage that making the title parameter ref string means that string literals use the existing version of the function. I know that the former can be @nogc, unlike the latter, though I don't know if there is any advantage offered by toStringz over cast(const(char)*).

But anyway, my goal was to generate function overloads like either of the above. I have already posted a version of a CTFE function that does this, though I put them under version (D_TypeInfo) so that they aren't available in betterC builds, since the function I wrote doesn't build with betterC.

On Friday, 12 April 2024 at 00:04:48 UTC, Liam McGillivray wrote:

void InitWindow(int width, int height, const(char)* title);
void SetWindowTitle(const(char)* title);
Shader LoadShader(const(char)* vsFileName, const(char)* fsFileName);

void InitWindow(int width, int height, ref string title) {
    InitWindow(width, height, cast(const(char)*)title);
}

This is invalid, a string may not be zero-terminated. You can't just cast.

void InitWindow(int width, int height, string title) {
    InitWindow(width, height, title.toStringz);
}

This will allocate from the GC.

So there are a few things to consider:

1. Is the string transiently used. That is, does the function just quickly use the string and never refers to it again? Given that this is raylib, the source is pretty readable, so you should be able to figure this out.
2. If 1 is false, will it be saved in memory that is scannable by the GC? This is one of the most pernicious issues with using C libraries from D. In this case, you will need to either allocate the memory with C malloc or pin the GC memory.

For transiently used strings, I would point you at the function tempCString, which allocates a temporary C string using malloc or a stack buffer, and then frees it when done with it.

The obvious problem in all this is to avoid accepting string literals (which are magic and automatically convert to const char *). This is currently impossible with function overloading, and so you need a separate function name, or put them in a different module.

-Steve

On Friday, 12 April 2024 at 15:24:38 UTC, Steven Schveighoffer wrote:

void InitWindow(int width, int height, ref string title) {
    InitWindow(width, height, cast(const(char)*)title);
}

Well, it did work when I tried it (using a string variable, not a literal of course). It displayed as it is supposed to. But from the information I can find on the web it looks like strings are sometimes but not always zero-terminated. Not a great look for the language. Are there any rules to determine when it is and when it isn't (for string variables)?

I suppose. But if it turns out that the string is used continuously (as I assume to be the case with InitWindow and SetWindowTitle) and it doesn't make a copy of it, I imagine it would be difficult to design the function overload, as it would need to store a copy of the string somewhere. In that case, the only clean solution would be to have a global array of strings to store everything that's been passed to such functions, but that doesn't feel like a very satisfying solution. I may take a look inside some Raylib functions if I get back to this task.

You mean that the GC can destroy objects that still have references from the C code?

Thank you. In a previous thread, someone told me that having to do many deallocations slows down the program, and the GC is more efficient because it deallocates many objects simultaneously. Is this something worth considering here, or is the overhead going to be tiny even when it's called a few times per frame?

Aren't there any compile-time conditions for this?

On Sunday, 14 April 2024 at 22:36:18 UTC, Liam McGillivray wrote:

void InitWindow(int width, int height, ref string title) {
    InitWindow(width, height, cast(const(char)*)title);
}

A cast "working" isn't enough. It could work in certain cases, with certain environmental conditions, etc., but fail horribly with memory corruption in other cases. It could even happen on different runs of the program. It could happen that it works 99.999% of the time. The risk is not worth it.

string literals are zero-terminated. All other strings are not. If you have a string generated at compile time, the chances are good it has zero termination. However, the implicit conversion to char * is the clue that it is zero terminated. If that doesn't happen automatically, it's not guaranteed to be zero terminated.

A string generated at runtime only has zero termination if you add a 0. You should not cast to a pointer assuming the zero is going to be there.

Casting is a blunt instrument, which does not validate what you are doing is sound. A cast says "compiler, I know what I'm doing here, let me do this even though it's outside the language rules".

You can pin memory in the GC to ensure it's not collected by using core.memory.GC.addRoot, which is effectively "storing in a global array".

Yes. If the GC is unaware of the memory that is being used by the C code, it can't scan that code for pointers. It may collect these strings early.

In an application, I would recommend not worrying about the allocation performance until it becomes an issue. I'm writing a simple game, and never have worried about GC performance. When you do need to worry, you can employ strategies like preallocating all things that need allocation (still with the GC).

In a general library, you do have to worry about the requirements of your users. If you can allocate locally (on the stack), this is the most efficient option. This is what tempCString does (with a fallback to malloc when the string gets to be large).

Unfortunately no. string does not implicitly convert to char * unless it is a string literal, and string literals bind to string before char *. So you can't rely on the overload working.

-Steve