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