[LLVMdev] Forward: Discussion about custom memory allocators for STL

Gordon Henriksen gordonhenriksen at mac.com
Sun May 18 07:02:49 PDT 2008


On 2008-05-18, at 04:36, Roman Levenstein wrote:

> Chris Lattner wrote:
>
>> We have already imported pieces of boost.
>
> BTW, which ones?
>
>> The general rule is that it  is ok to use specific pieces,
>
> Totally agree with you.
>
>> but they have to be converted to the  LLVM style and way of doing  
>> things. Also, things with huge chains of  dependencies sometimes  
>> have to be simplified.
>
> One comment here:
> While I agree with this approach for most libraries, I think that  
> boost is (almost) becoming a second-important libray for C++, almost  
> as important as the STL. Therefore, modifying/re-formating/ 
> converting it it is not such a great idea, eventually, since  
> everyone using it assumes that its implementation and semantics is  
> exactly the same on each platform.


I just imported some boost code at work. It was a relatively minor  
library, but using it pulled in 340 headers—out of boost's 5400! This  
was after computing the minimum closure of includes; importing each  
top-level boost/* folder yielded a 1600 headers.

I find this more than slightly excessive. It was a complete non- 
starter to bring in the 1600 or 5400 headers.

As for the 340, for an highly replaceable library comprising 1% of our  
LOC to bloat the source file count in our tree by 20%—after using a  
script to extract a perfect transitive dependency closure—well, I was  
on the verge of tossing it overboard. I can't blame Chris for his  
reticence to add such nonsense to LLVM, as it only serves to slow  
builds and source control operations for all.

That said, there are some parts of boost which are well-structured  
with few or minimal dependencies—like shared_pointer. I feel there's  
not a lot of need to rewrite these headers. Then again, there's not a  
lot of need to pull them in either, being as how such templates are  
trivial.

— Gordon





More information about the llvm-dev mailing list