> Problem is, there are REALLY bad std::string implementations out there in > widely used c++ runtimes.No doubt - though widely used to build llvm/clang? Perhaps, I suppose, I'm not sure just how portable llvm code is.> StringRef/Twine is efficient everywhere.Yep - I'm just pedantic about having a tidy codebase, and duplicate code to workaround bad implementations when clang/llvm itself is a good one & can selfhost seems a bit of a pity. (which raises another side question on a comment I saw Chris make a few weeks ago: that llvm/clang (or perhaps the comment was limited to llvm only?) wouldn't be migrating to C++0x in the near/foreseeable future. Given the ability to selfhost, I was wondering why that would be? (My best guess is that clang/llvm can't bootstrap itself yet, so it still needs to remain compilable with something that can be bootstrapped))
> Perhaps, I suppose, I'm not sure just how portable llvm code is.Very portable AFAICT. I'm even going to port it to my hobbyist OS once C++ rtti is totally gone in the llvm code base.
>> Perhaps, I suppose, I'm not sure just how portable llvm code is. > > Very portable AFAICT. I'm even going to port it to my hobbyist OS once C++ > rtti is totally gone in the llvm code base.Sorry, I meant source portable to different compilers (ie: which compilers does llvm compile on & how many have really poor std::string implementations). - David
On Jul 19, 2011, at 10:44 AM, David Blaikie wrote:>> Problem is, there are REALLY bad std::string implementations out there in >> widely used c++ runtimes. > > No doubt - though widely used to build llvm/clang? Perhaps, I suppose, > I'm not sure just how portable llvm code is.GCC's libstdc++ std::string implementation (as of GCC 4.2, but I doubt they've fixed it recently due to ABI concerns) is COW (and thus does atomic accesses) with no short-string optimization. It's brutally slow. -Chris
On Jul 19, 2011, at 10:44 AM, David Blaikie wrote:> (which raises another side question on a comment I saw Chris make a > few weeks ago: that llvm/clang (or perhaps the comment was limited to > llvm only?) wouldn't be migrating to C++0x in the near/foreseeable > future. Given the ability to selfhost, I was wondering why that would > be? (My best guess is that clang/llvm can't bootstrap itself yet, so > it still needs to remain compilable with something that can be > bootstrapped))Clang certainly self hosts on unix based platforms. I have no idea if it self hosts on windows though, and relying on a cross build to windows seems like a bad idea to me :) That said, I'd really like to see (e.g.) the clang static analyzer get split out into a clang plugin, and then *it* could use c++'0x features. -Chris