On Sun, Sep 15, 2013 at 6:21 PM, Jean-Baptiste Kempf <j...@videolan.org>wrote:
> On 12 Sep, Steve Borho wrote : > > Reimplementations of STL and Related Identity Crises > > > ---------------------------------------------------- > > > > > > Why are you reimplementing STL classes like std::list? I could > understand > > > if it was in C, > > > so as to aid in the promised future port to C, but it's being done in > C++, > > > using new and > > > delete, etc. This makes no sense. There's no reason to do this other > than > > > some misguided > > > Not In House syndrome or obsession with the resulting binary size. So, > uh, > > > what? > > > > > > > STL implementations between different compilers (even between different > > compiler versions) cause serious headaches because it is half-header and > > half-lib. Since a lot of users will use x265 as a static library, it > > behooves us to avoid this pain. > > Sorry, but which one is actually broken? > I don't know that any of them are exactly broken, but I've heard from two different groups (one using two GCC versions and another using a combination of MSVC and Intel C) that when you link together libs that were compiled by different C++ compilers you get link errors or runtime heap corruption. I think GCC, MSVC, and Intel C all assume that if you compile against their STL headers you also link with their STL lib. It's not just me, I promise. See http://stackoverflow.com/questions/5736289/binary-compatibility-of-stl-containers > Moreover, if the basic is broken in the compiler, use a 3rd party > library to do the reimplementation (see projects like winpthread), why > bloat the codebase with stuff like that? For the most part, we want to replace the STL with more basic C style code; like how we replaced std::ostringstream with simple malloc and memcpy. list is the only std class, so far, that we've figured we need to have around a bit longer. -- Steve Borho
_______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
