digitalmars.D - Why does toStringz return an immutable(char)*?
- Jonathan M Davis (6/6) Jun 18 2011 The main purpose of toStringz is to turn a string into a char* which can...
- Mafi (4/10) Jun 18 2011 If anyone ever writes a function which needs immutable chars, toStringz
- Jonathan M Davis (7/19) Jun 18 2011 Good point. I should have thought of that. I wouldn't expect many functi...
- Adam D. Ruppe (4/4) Jun 18 2011 I don't know if it does this, but immutable could avoid copying:
- Jonathan M Davis (6/13) Jun 18 2011 Well, the return type doesn't really matter for that as far as const vs
-
Stewart Gordon
(6/8)
Jun 19 2011
- Jonathan M Davis (16/27) Jun 19 2011 That doesn't require immutable at all. And returning const(char)* would ...
The main purpose of toStringz is to turn a string into a char* which can be passed to a C function. C doesn't have immutable, and I don't see any gain in having toStringz return an immutable(char)* rather than a const(char)*. Does anyone know why it returns an immutable rather than a const? What possible benefit does that have? - Jonathan M Davis
Jun 18 2011
Am 18.06.2011 10:36, schrieb Jonathan M Davis:The main purpose of toStringz is to turn a string into a char* which can be passed to a C function. C doesn't have immutable, and I don't see any gain in having toStringz return an immutable(char)* rather than a const(char)*. Does anyone know why it returns an immutable rather than a const? What possible benefit does that have? - Jonathan M DavisIf anyone ever writes a function which needs immutable chars, toStringz just wroks for it. And functions which take const(char)* can get immutable(char)* without problems. (If not, that is bug, I hope)
Jun 18 2011
On 2011-06-18 03:52, Mafi wrote:Am 18.06.2011 10:36, schrieb Jonathan M Davis:Good point. I should have thought of that. I wouldn't expect many functions to be taking immutable(char)* though, since the main reason to use char* is to interface with C. But it doesn't hurt to make it immutable, I guess. It's more flexible even if that flexibility is almost always useless. But since that flexibility doesn't cost anything, we might as well have it. - Jonathan M DavisThe main purpose of toStringz is to turn a string into a char* which can be passed to a C function. C doesn't have immutable, and I don't see any gain in having toStringz return an immutable(char)* rather than a const(char)*. Does anyone know why it returns an immutable rather than a const? What possible benefit does that have? - Jonathan M DavisIf anyone ever writes a function which needs immutable chars, toStringz just wroks for it. And functions which take const(char)* can get immutable(char)* without problems. (If not, that is bug, I hope)
Jun 18 2011
I don't know if it does this, but immutable could avoid copying: string a = "hello\0"; auto c_str = toStringz(a); assert(c_str is a.ptr); // it already fit the bill so no change needed
Jun 18 2011
On 2011-06-18 20:59, Adam D. Ruppe wrote:I don't know if it does this, but immutable could avoid copying: string a = "hello\0"; auto c_str = toStringz(a); assert(c_str is a.ptr); // it already fit the bill so no change neededWell, the return type doesn't really matter for that as far as const vs immutable goes. However, it does look like the current implementation is able to avoid copying when given a string explicitly (as opposed to any other type of character array), though it ends up copying anything else. - Jonathan M Davis
Jun 18 2011
On 18/06/2011 11:52, Mafi wrote:Am 18.06.2011 10:36, schrieb Jonathan M Davis:<snip>If anyone ever writes a function which needs immutable chars, toStringz just wroks for it.<snip> You mean a C function that keeps the pointer for later use, and relies on you not to change it? Stewart.
Jun 19 2011
On 2011-06-19 13:28, Stewart Gordon wrote:On 18/06/2011 11:52, Mafi wrote:That doesn't require immutable at all. And returning const(char)* would work just as well. You can't alter it in either case. The only way that it would be alterable would be if the original string which was passed to toStringz wasn't immutable (e.g. char[]), and the overload of toStringz which took it didn't make a new array. But the overload of toStringz which takes a char[] _does_ return a new array. So, there is _no_ difference between returning const(char)* and immutable(char)* unless you have a D function which takes immutable(char)* that you're trying to pass it to. Of course, in the case that you're describing, there's always the fun bug that the GC doesn't know that it needs to hang onto the immutable(char)* which was returned unless you hold a reference to it somewhere, in which case it could be collected and screw over the C function which held onto it. Now that I think about it, it might actually be worth adding a note to the documentation about that. - Jonathan M DavisAm 18.06.2011 10:36, schrieb Jonathan M Davis:<snip>If anyone ever writes a function which needs immutable chars, toStringz just wroks for it.<snip> You mean a C function that keeps the pointer for later use, and relies on you not to change it?
Jun 19 2011