[ If I'm not mistaken, judging by the list archives, this message never reached the list. New attempt. ]
> Le 13 févr. 2018 à 19:07, zyx <z...@gmx.us> a écrit : > > On Tue, 2018-02-13 at 16:50 +0100, Olivier Mascia wrote: >> I currently simply do a replace all on each subversion update. I'm >> fine with that. Time passing by, some others might become tired of >> it. > > Hi, > I guess there's not much interest in your issue, because C++17 is too > new. You can always use older C++ and it'll be fine. > The other reason is that its too late now, it's not a good idea to > change the sources in such way just before the release. > > Nonetheless, I attached one possible way to deal with it, but it also > changes one public header, one public function, which is bad. The API > might be changed to not expose this, because any library user would end > in the same mess. > > I'm not going to commit this to the sources, not now, neither later. > I'll keep the decision (and the API change) to others. Thanks a lot Zyx for the patch offered for discussion. I wasn't in such a hurry though. :) From your words I now understand that some 0.9.6 is so close to release... I just happen to have jumped on the PoDoFo wagon this month. This 'issue' can clearly wait for the next iteration. For future discussion about this, possibly in months from now, and more specifically about C++17: the issue is much less with C++17 than with C++11 (and then C++14). C++11 has been **long** to come out and compilers supported most of it for a **long** time before it even became tag as standard. Things have accelerated since in the C++ world. But back to these quite late years of C++11 slowly coming out to light, auto_ptr had already been marked deprecated and unique_ptr became, essentially, its new name. It just finally got dropped by C++17, years later. The argument of using an older compiler is moot. I'm not sure anyone can really impose on users of the library to use an older compiler for their own code, just because PoDoFo keeps using std::auto_ptr in any header to be included by the host program. That may not be easy or possible to achieve if the application code relies on modern features of the language. Time passing by it'll become a less and less defendable position anyway. If I'm not mistaken, the only appearance of std::auto-ptr in an include file is from PdfFilter.h: static std::unique_ptr<PdfFilter> PdfFilterFactory::Create( const EPdfFilter eFilter ); Maybe at some point in time, it might simply be more forward looking to simply list C++11 as the minimal requirement for PoDoFo, rename std::auto_ptr to std::unique_ptr and even possibly start indulging into relying on other more modern features of the language. But I'm looking to the future here, and have no idea if a large portion of the users of PoDoFo library depend on being able to compile its headers and link to it while using compilers from pre-C++11 era. > As PoDoFo has opened issue tracker in SourceForge now, maybe you'd open > a request there, thus this doesn't get forgotten. I'll probably do it. Thanks again, -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
