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

Albert Astals Cid aacid at kde.org
Sun Jan 24 06:01:27 PST 2010


A Diumenge, 24 de gener de 2010, Albert Astals Cid va escriure:
> 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/f62d5e579ec96f6b73adee0ffcad4367d
> >b 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

Wait, the patches are probably the same just that i need to use your GooVector 
isntead of ours, is that right?

Albert

> 
> > >> (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
> 
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
> 


More information about the poppler mailing list