[x265] x265: Questions and comments from an outsider

[Steve Borho]

On Sun, Sep 15, 2013 at 6:21 PM, Jean-Baptiste Kempf <jb at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130916/1f03a4c5/attachment.html>