Repository navigation
Conversation
| - ``renderer_curses`` (PRINT_MODE:TEXT) | ||
| - ``df.g_src.renderer_2d.xml`` | ||
| * - ``renderer_offscreen.cpp`` | ||
| - offscreen renderer for benchmarking |
There was a problem hiding this comment.
From what I recall, renderer_offscreen is used for things like map exports (or at least it was used for them in older versions)
| ``trandom_twist``. | ||
| - ``filest``/``stringvectst``/``textlinesst`` — path resolution across DF | ||
| dirs (``canon_location``/``both_locations``/ | ||
| ``with_flags(FILE_FLAG_*)``), manual ``char*`` string vector, raw-file |
There was a problem hiding this comment.
stringvectst is svector<std::string *> (actually svector<pstringst *>, where class pstringst { public: string dat; };), not char*.
| - **[stale]** ``endian.h`` byteswaps only under ``__ppc__``/ | ||
| ``__ppc64__`` — dead on all modern targets. | ||
| - **[bug-ish]** ``stringvectst`` (``files.h``/``basics.h``) manually owns | ||
| ``char*`` strings, erases from the front, and leaks if methods are used |
There was a problem hiding this comment.
As noted earlier, it actually owns std::string pointers (pointlessly wrapped inside a pstringst class) - all strings are added as copies of the input parameter (whether const char * or const string &) via std::string::operator=, so as long as you never touch the str vector itself (which is unfortunately marked public) and never try to do read_file on a non-empty list, I wouldn't expect it to leak.
There was a problem hiding this comment.
It'll leak if something reaches into the (public) vector and removes or modifies elements without properly deleting them. The problem is that this container should own its strings, but it doesn't actually own them, and instead requires its consumers to manage the lifetimes of the string objects it holds. It's, at best, fragile; it is certainly not a good example of RAII in action.
2 participants
some dev-facing notes on
g_srcas it relates to DFHack