[x265] [PATCH] List: Basic List Operations To Replace std::list

[Steve Borho]

On Thu, Sep 12, 2013 at 5:56 AM, Derek Buitenhuis <
derek.buitenhuis at gmail.com> wrote:

> On 9/12/2013 11:46 AM, Steve Borho wrote:
> > The short term issue is that STL makes integration into applications
> that were compiled by a different compiler pretty fragile, and just having
> the same class not in namespace std makes those problems go away.
>
> From what I understand, std::list is very well supported in all major C++
> compilers.
>

Yes, and they each have their own implementations (with identical bindings)
with enough differences that they break each other at run time.  Our first
workaround for this was to add CMake support for compiling with STLport,
which is just a replacement for the STL classes in a private namespace.  It
avoids these conflicts, but is just a stop-gap.


> > The medium term issue is that the encoder still has logic that inserts
> NALs between other NALs in the access unit, and so we can't simply
> concatenate NALs as we generate them, we still need a list structure.  And
> since we also need a list structure for the picture lists, this is the one
> place in the encoder (outside of vector primitives) where templating would
> be somewhat sane.
>
> I'm not a C++ guy, but couldn't you use something like std::vector's
> insert() method?
> Perhaps that would be slow? Don't know. std::vector is very well supported.
>

Using a std:vector<> as a list doesn't really resolve the short or medium
term problems though

> Long term.. I haven't looked at how this is handled in x264.  Advice
> welcome.
>
> You should ask Jason, Anton, or Kieran.
>

That's good advice :)  I think I'll do that after a bit of sleep.

Thanks.

--
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130912/c434c8a8/attachment.html>