[poppler] [PATCH 0/5] Various fixes relating to bug #24575
Albert Astals Cid
aacid at kde.org
Sun Jan 24 06:00:26 PST 2010
A Diumenge, 24 de gener de 2010, David A Benjamin va escriure:
> On Sat, 23 Jan 2010, Albert Astals Cid wrote:
> > A Dissabte, 23 de gener de 2010, David A Benjamin va escriure:
> >> So, what is the story with GooVector? Is it just unknown copyright?
> > Yes, it mentions three people in the copyright that never answered my
> > mails asking to clarify which license their file was under.
> >> Vectors are hardly complicated structures to implement. Making a new one
> >> with a much fuller interface would be trivial.
> > Yeah, but still somewhat time consuming. Are you volunteering to create
> > one? GPL2 or later?
> Done. Rebased history including new GooVector at
> File in question is here:
> It implements considerably more of std::vector's interface than the old
> GooVector. I was having some fun. :-)
Could you please send the patches? My git-foo is pretty low and i don't really
know how to extract them correctly from your github branch
> >> (Or we could use the
> >> STL's... I'm not sure what libpoppler's policies are w.r.t STL usage. I
> >> would think it's safe to consider "portable" these days.)
> > Yes, i agree STL is safe to use everywhere but the poppelr core isn't
> > using it and just for a small vector i'd prefer to keep not doing it.
> Alright. I should mention that a correct vector implementation (the old
> one was not one) must use placement-new to handle ctors and dtors
> correctly. This would be found in the header <new>, so you'd at least
> require that header anyway. Requiring the build environment to provide
> some working <vector> header seems a mild additional restriction.
> Given that, I think avoiding the STL here is somewhat silly. It imposes no
> runtime requirements, is much further tested and optimized (for instance,
> they maintain type traits to know when you can use memmove and friends and
> when you must be careful with constructors), and involves maintaining less
> code. Also, for instance, my GooVector does not take alignment
> restrictions of various types into account as that was more than I wanted
> to deal with.
Yeah well, i also think avoiding the STL is somewhat silly, but what i don't
want is people start to send patches replacing GooList with std::list just for
the fun of it, so unless we *really* need it, let's just not use it for now.
> David Benjamin
> poppler mailing list
> poppler at lists.freedesktop.org
More information about the poppler