[poppler] [PATCH 0/5] Various fixes relating to bug #24575

[Albert Astals Cid]

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
> 
>    http://github.com/davidben/poppler/
> 
> File in question is here:
> 
>   
>  http://github.com/davidben/poppler/blob/f62d5e579ec96f6b73adee0ffcad4367db
> 18e975/goo/GooVector.h
> 
> 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.

Albert

> 
> 
> David Benjamin
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>