.dup return strings?

This is GTK+'s documented behaviour. Not really safe, though. We could do better.

I don't think adding an additional parameter is the right way of doing this. Instead, I think we should create two methods for each get function that returns a character array: one with the default name, which returns a dup of the original string (i.e. Entry.getText()); and another one, which returns the original GTK+ string (i.e. Entry.getTextNoDup()).

I'll try to get to this in the following days.

In r353 strings are automatically dupped before returning them (wrapper only, will be mirrored in the next rewrap). Todo: set the wrapper to create sister methods that return the original string.

I've looked a bit more at the GTK docs, it looks like functions witch return a const gchar* return only a reference to the internaly used string. While the functions which return a normal gchar* return a string you are allowed to change. Since D1 doesn't have const we could return a dup for the functions with const gchar* as the return type, while returning the string from GTK for the functions with gchar* as the return type.

Replying to Pse:

Todo: set the wrapper to create sister methods that return the original string.

Does that mean there would be a duplicate of every function that return a sting, with the only difference would be dup or no dup and probably the method name. I don't like that option much i would rather go with a sensible default. or is there some case where you actually need access to the string directly ?

Replying to Mike Wey:

Replying to Pse:

Todo: set the wrapper to create sister methods that return the original string.

Does that mean there would be a duplicate of every function that return a sting, with the only difference would be dup or no dup and probably the method name. I don't like that option much i would rather go with a sensible default. or is there some case where you actually need access to the string directly ?

I guess the sole reason would be performance. I'd be pushed hard to think of an actual usage case where that kind of performance would be needed, though. Since dups are already implemented by default, I'm still waiting for any actual complaints. Given your recent discoveries, I guess we could set up dups the way you mentioned. If anyone really needs that kind of performance, we could always implement undupped sister methods at a later date.

Strings are .dupped by default. We haven't received any complaints on this issue. If anyone feels like we need to return to this ticket and review, let us know.