Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, I remember now I've seen a lot of

    return ~"something" 
lines. Can you please point me to some complete-enough example of the new "lighter" string return? Thanks.

Edit: I guess the key is in 'if you must return the string on the heap.' Why should be common that anybody must return the string on the heap? Why shouldn't be possible to program so that only the receiver must place something on the heap due to his own needs? Why shouldn't the one doing return be able to always return "something"? Couldn't it be made possible in the language? The one doing return shouldn't need to put something he knows it's static on the heap, especially as most probably the receiver will just discard it as soon as it reads the content.



Just use `return "something"`. That returns a `&'static str`. If you must return a heap allocated string, the you can use `return StrBuf::new("something")`.


Why is there a "must" for returning the string on the heap? Can't it be solved in the language to use the static string up to the point the reallocation is needed?


Rust has builtin types &'static str for strings that live for the entire runtime of the program and ~str for strings that live in dynamically managed heap memory (from the more general ~T for T that live there with T=str). If the function always returns a static string it can return the former type and won't need a ~ or any allocations for that.

If you need something more dynamic... you could have a user-defined type that can hold either and remembers whether it's responsible for freeing the memory, but that doesn't fall out of the builtin types naturally.


It would require runtime overhead over C/C++ to check whether every pointer is really is in static or heap memory every time you want to free it.


As far as I understand, the effective overhead of "free" can be practically zero if the compile-time construction of the static strings would contain some "nothing to deallocate here" info versus any info which anyway has to be run-time maintained to anything that is really allocated. Any non-trivial allocator has a bunch of checks to do (e.g. different-sized small objects are typically allocated in separate blocks, differently to the big allocations etc).

As soon as your language doesn't use C-like zero-terminated characters but anything with more information, it's trivial to avoid these unnecessary copy-to-heap-just-to-use-and-deallocate steps.


As other have said: it can be solved in the library by defining a string type with the appropriate semantics (e.g. the MaybeOwned[1] type they refer to).

[1]: http://static.rust-lang.org/doc/master/std/str/enum.MaybeOwn...


There is MaybeOwned for that. It's either a &'static str or a ~str IIRC.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: