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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler > _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
