This is a conspiracy theory, but what if there are bugs in it that they can't find and so they're open sourcing it in the hope that someone else will fix it.
i think you're just paranoid
Folly - The Faceboook open source library
21–30 of 44 posts
Re: Folly - The Faceboook open source library
#22This is all pretty great stuff. Make sure you read through the docs; I'm unlikely to use Fb's C++ code, but I'm sure as hell going to look at making my C vector code do some of what FBVector does: https://github.com/facebook/folly/blob/master/folly/docs/FBV...
Hmm, I recently created a private memory allocator so the discussion on the page is somewhat interesting... Only a tiny minority of objects are genuinely non-relocatable: Hmm, I'm not exactly what is meant here. Moving a block of memory from here to there in the most general case will leave your pointers dangling and crash you in no short order. Things that pointed to the data you moved just don't any more. If you ar…
If your object is in a vector, it's already possible for the vector to move the object without updating any pointers to it. The only question is whether it is safe for the vector to move the object with memmove instead of invoking a copy/move constructor, essentially skipping the step of telling the object that it is being moved. This will only fail if the object contains pointers to its own sub-objects (or the move constructor updates external pointers). This is fairly rare, especially for objects that you would store directly in a vector.
std::string is a key exception to this, but fbstring is not.
Re: Folly - The Faceboook open source library
#23This is all pretty great stuff. Make sure you read through the docs; I'm unlikely to use Fb's C++ code, but I'm sure as hell going to look at making my C vector code do some of what FBVector does: https://github.com/facebook/folly/blob/master/folly/docs/FBV...
That's all good and well, but I'm not sure I understand what it brings compared to std::vector with a good allocator. In addition, it does not support concurrent growth.
- It adjusts its growth strategy to work well with the properties of the allocator.
- It requires that its members be relocatable and uses memmove to speed up move operations.
Re: Folly - The Faceboook open source library
#24Earlier quoted context omitted.
C++.
I realise this is a dangerous subject, but I am genuinly curious: given the business you run and the work you do for the Freebsd team, why would you object to using c++, but not c? I could understand why you would object to both, but why only the lower level language.
I don't work for the FreeBSD team.
Re: Folly - The Faceboook open source library
#25Earlier quoted context omitted.
Aren't most of these already within boost or recent C++ standard ? I just took a look at the format and dynamic cases.
Some of them. For example Boost.Spirit.Karma is an order of magnitude faster than sprintf (I don't know compared to fbformat), with the drawback of a very long compile time (see here: http://tinodidriksen.com/2010/02/07/cpp-convert-int-to-strin... ). Arena, SmallLocks and AtomicHashMap will have to challenge Intel TBB. I submit TBB will be better, but I haven't done the benchmarks. As for the rest, some of the stuff…
From the OP: "Our primary aim with this 'foolishness' is to create a solution that allows us to continue open sourcing parts of our stack without resorting to reinventing some of our internal wheels."
And: "we think C++ developers might find parts of this library interesting in their own right."
I think the key thing is that these are some basic pieces that a lot of FB's internal C++ code depends on. These pieces are being made available as a stepping stone to open sourcing more significant work.
Re: Folly - The Faceboook open source library
#26Is the 3 "o" intentional?
Re: Folly - The Faceboook open source library
#27I'm going to be taking a serious look at this for my own projects. I like Format: https://github.com/facebook/folly/blob/master/folly/docs/For... Histogram is going to come in handy. :) fbstring seems to be exactly what the doctor ordered. I like the emphasis on cooperating with the memory allocator in fbstring and fbvector. If the entire library does that, that's going to a big win for long-running programs: memory…
Modern heaps typically have some low-fragmentation technique built-in, for example, Windows ships with Low Fragmentation Heap, which is turned on by default since Vista.
What is "low-fragmentation heap"? Why would anyone want "high-fragmentation heap"? (since you imply that it's an option)
Re: Folly - The Faceboook open source library
#28Earlier quoted context omitted.
C++.
I realise this is a dangerous subject, but I am genuinly curious: given the business you run and the work you do for the Freebsd team, why would you object to using c++, but not c? I could understand why you would object to both, but why only the lower level language.
given the business you run and the work you do for the Freebsd team
Are you getting confused between tptacek and me?
Re: Folly - The Faceboook open source library
#29Earlier quoted context omitted.
Modern heaps typically have some low-fragmentation technique built-in, for example, Windows ships with Low Fragmentation Heap, which is turned on by default since Vista.
What is "low-fragmentation heap"? Why would anyone want "high-fragmentation heap"? (since you imply that it's an option)
Why would anyone want "high-fragmentation heap"?
For short-lived processes, it's faster and uses less memory. The code is also simpler (important if you're writing a malloc in the mid-1980s).
Re: Folly - The Faceboook open source library
#30Earlier quoted context omitted.
I realise this is a dangerous subject, but I am genuinly curious: given the business you run and the work you do for the Freebsd team, why would you object to using c++, but not c? I could understand why you would object to both, but why only the lower level language.
given the business you run and the work you do for the Freebsd team Are you getting confused between tptacek and me?
Hey, why don't you use C++? :)