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

[Steve Borho]

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

> On 9/12/2013 8:54 AM, Gopu Govindaswamy wrote:
> > # HG changeset patch
> > # User Gopu Govindaswamy <gopu at multicorewareinc.com>
> > # Date 1378972464 -19800
> > # Node ID 7be0ceae34e059849737050c52a326becd8bbf1a
> > # Parent  0482a5c72c21dc14d6be5f4b9c4ffe2ae574ebc3
> > List: Basic List Operations To Replace std::list
>
> I still do not understand the benefit of rewriting a subset of std::list
> in C++. What's the end goal? It is not clear.
>

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.

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.

Long term.. I haven't looked at how this is handled in x264.  Advice
welcome.


> > +#ifndef __LIST__
> > +#define __LIST__
>
> Header guards should always be prefixed/namespaced. __LIST__
> is far too generic and could very easily conflict with
> system headers.
>

agreed, __LIST__ is to generic


>
> > +#endif // ifndef __COMMON__
>
> Wrong comment. Copypasta code is Bad™.
>
> - Derek
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>



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