>>>>> "Martin" == Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
Martin> FWIW, I have prototyped Martin> a simple string class over the weekend (based on auto_vec) that I'm Martin> willing to contribute if std::string turns out to be out of favor. I wonder whether GDB and GCC can or should collaborate in this area. GDB has been using C++ for a while now, and we've encountered many of these same transitional problems. My sense is that, unlike GCC, GDB has been a bit more aggressive about adopting C++11 style though. For this particular area, GDB uses std::string pretty freely -- but not universally, both due to its history as a C code base, but also because std::string can be too heavy for some uses. Not all code needs to carry around the length, etc. Pedro adapted the C++17 string_view from libstdc++, and this is used in some spots in GDB. See gdbsupport/gdb_string_view.h. GDB also uses a unique_ptr specialization that wraps xmalloc/xfree. See gdbsupport/gdb_unique_ptr.h. So in GDB, instead of writing a new string-ish class, I suppose we'd simply hook string_view up to unique_xmalloc_ptr<char> or something along those lines. Martin> There is std::unique_ptr that we could use rather than rolling our Martin> own. That said, I don't think using std::unique_ptr over a string Martin> class would be appropriate for things like local (string) variables Martin> or return types of functions returning strings. In GDB we do this kind of thing all the time. The main idea is to indicate ownership transfer via the type system. This helps eliminate comments like "the caller must free the result" -- the return of a unique_ptr explains this directly. >> But then there's the issue of introducing lifetime bugs because >> you definitely need to have the pointer escape at points like >> the printf ... This is a valid concern in C++, but hasn't been a big practical issue in GDB. Tom
