[LLVMdev] std::string

[Chris Lattner]

On Jan 20, 2013, at 7:46 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
>> It is one of the motivations.
> 
> The reason I ask is that STL comes all ready, with containers and algorithms.  They may not be optimal for every task, but they do their job and they are part of the standard.  There may be some price to pay in terms of performance/memory usage/etc. for a specific application, but overall it may be worth it.  Evidently, in case of LLVM, someone (you?) decided that having local set of containers is a better idea.  I simply want to understand the reasons behind this decision.

I'm confused here.  You're acting as though we don't use the STL.  In fact, we do use std::string, std::vector, std::map etc when they are the right solution for the job.  We are not avoiding the STL, we're just not using it when it isn't the best tool for a job.

LLVM's purpose isn't to use inappropriate C++ containers just because they are "standard".  Our goal is to build the best compiler possible, and if that means we have to implement custom containers, so be it.  I would really like for the C++ standard library to provide containers better than what LLVM does, but until it does, we are stuck with ours.

> I quickly looked over the library section on containers in the C++03 standard and I didn't see any paragraphs regarding the allocation strategy for classes like "set" or "map".  The LLVM page seems to contain information that was based on some specific implementation (or several implementations), but was not mandated by the standard itself.

We live in a pragmatic world, not a theoretical one.

-Chris