Re: [Podofo-users] std::auto_ptr --> std::unique_ptr
On Thu, 2018-12-06 at 09:09 +0100, Olivier Mascia wrote: > > I'd remove the std::auto_ptr usage from the public > > API completely, and use, if needed, either of them based on the > > compiler being used (and what it offers) only in internal code. > > That > > would support both old and new C++ standards. > > It wouldn't work. There is no point in having an option to compile > internal code with (auto|unique)_ptr when interfaces would use > unique_ptr. Because unique_ptr support would then be required for > internal code anyway, so why would it need to insist on using > auto_ptr in some places? :) Hi, I said: a) remove from public API, b) use in private API, only if needed. It's not the same as what you object to. It doesn't matter what is used internally, when it doesn't touch public API. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] std::auto_ptr --> std::unique_ptr
> Le 6 déc. 2018 à 08:25, zyx a écrit :
>
> I'd remove the std::auto_ptr usage from the public
> API completely, and use, if needed, either of them based on the
> compiler being used (and what it offers) only in internal code. That
> would support both old and new C++ standards.
It wouldn't work. There is no point in having an option to compile internal
code with (auto|unique)_ptr when interfaces would use unique_ptr. Because
unique_ptr support would then be required for internal code anyway, so why
would it need to insist on using auto_ptr in some places? :)
The readme.html is probably wildly outdated:
> Installation with CMake
>
> PoDoFo has support for builds using CMake on all supported platforms. The
> CMake build has been tested on:
>
> • Visual C++ 9 Express Edition [Win32] ("Visual Studio 9 2008" target)
> • Visual C++ 8 Express Edition [Win32] ("Visual Studio 8 2005" target)
> (needs additional setup)
> • Visual C++ 8 Express +NMake [Win32] ("NMake Makefiles" target) (needs
> additional setup)
> • MinGW with GCC 3.4.2 [Win32] ("MinGW Makefiles" target)
> • gcc 3.3.5 [Linux: Debian 3.1] ("Unix Makefiles" target)
> • gcc 4.0, 4.1, 4.2 [Linux: Debian 4.0] ("Unix Makefiles" target)
> • gcc 4.0 [Mac OS X 10.4.10] ("Unix Makefiles" target)
For Windows for instance, I don't even know, except maybe on an old dusty CD
out from the attic, where anybody might find a Visual C++ 9 (or 8!) and an OS
in good order to run it, build PoDoFo, and develop, build, test, deploy any
valuable application using it, with these outdated tools. On the computer-era
timeline, I'm a rather old man, born in the early 60', but believe me or not, I
have no nostalgia of the compiler tools we used by the end of the 20th century.
Not even those used more than a decade ago.
I'm NOT advocating to use cutting-edge C++ new goodies. Just to think about
deciding, setting in stone, that for now and some yet undefined future, PoDoFo
is based on C+11, a stable reasonable, old-enough, standard basis. So that any
line of code inside PoDoFo (and that includes its 'public' interfaces) could
make use of any language feature supported by C++11, when really appropriate to.
Switching from auto_ptr to unique_ptr would be more than enough as a valuable
first step in that direction.
:)
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] std::auto_ptr --> std::unique_ptr
On Wed, 2018-12-05 at 22:43 +0100, Olivier Mascia wrote: > Have the main contributors to the project finally made a decision > about replacing std::auto_ptr by std::unique_ptr within PoDoFo source > code and its public interfaces? Hi, being it up to me, I'd remove the std::auto_ptr usage from the public API completely, and use, if needed, either of them based on the compiler being used (and what it offers) only in internal code. That would support both old and new C++ standards. > std::unique_ptr has been introduced in the standard by C++11, and > std::auto_ptr has been deprecated since. > Then came C++14 and last year C++17 removed the deprecated > std::auto_ptr. Projects using C++17 code need to patch PoDoFo source > code and interfaces (by a replacing occurrences of std::auto_ptr by > std::unique_ptr). That is not a terrible inconvenience, I agree. No no, either it's inconvenient for the users or for the developers of the library, where both are bad. Patching the library code means bundling it with the project, instead of using some precompiled version, which is even worse in general. I mean, an option of "either use old enough compiler, or patch and bundle the library on your own" isn't good option. For those looking for nitpicks, where I say "compiler" I mean either compiler or compiler options, and/or C++ standard being enabled/targeted by the compiler options. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] std::auto_ptr --> std::unique_ptr
You can use -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR with gcc and maybe other compilers have something similar. But the best would be to replace auto_ptr with unique_ptr in podofo (and move to git, ...). On Wed, Dec 5, 2018 at 10:44 PM Olivier Mascia wrote: > Dear all, > > Just an outsider view... > > Have the main contributors to the project finally made a decision about > replacing std::auto_ptr by std::unique_ptr within PoDoFo source code and > its public interfaces? > > std::unique_ptr has been introduced in the standard by C++11, and > std::auto_ptr has been deprecated since. > Then came C++14 and last year C++17 removed the deprecated std::auto_ptr. > Projects using C++17 code need to patch PoDoFo source code and interfaces > (by a replacing occurrences of std::auto_ptr by std::unique_ptr). That is > not a terrible inconvenience, I agree. > > Anyway, it probably would be fairly conservative to decide and declare > that PoDoFo code relies on C++11 and requires a C++11 compliant compiler. > Then it wouldn't be an issue to migrate the code to std::unique_ptr. And > to take care not to rely on anything else clearly deprecated by C++11, 14 > and 17. Just a matter of looking forward instead of behind, I think. > > Are there really, in the eve of year 2019, users expecting to compile > PoDoFo or use PoDoFo from C++ environments not meeting C++11 compliance, or > at least the introduction of std::unique_ptr which had started to be > supported by some compilers even before C++11 had turned standard? > > -- > Best Regards, Meilleures salutations, Met vriendelijke groeten, > Olivier Mascia > > > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
[Podofo-users] std::auto_ptr --> std::unique_ptr
Dear all, Just an outsider view... Have the main contributors to the project finally made a decision about replacing std::auto_ptr by std::unique_ptr within PoDoFo source code and its public interfaces? std::unique_ptr has been introduced in the standard by C++11, and std::auto_ptr has been deprecated since. Then came C++14 and last year C++17 removed the deprecated std::auto_ptr. Projects using C++17 code need to patch PoDoFo source code and interfaces (by a replacing occurrences of std::auto_ptr by std::unique_ptr). That is not a terrible inconvenience, I agree. Anyway, it probably would be fairly conservative to decide and declare that PoDoFo code relies on C++11 and requires a C++11 compliant compiler. Then it wouldn't be an issue to migrate the code to std::unique_ptr. And to take care not to rely on anything else clearly deprecated by C++11, 14 and 17. Just a matter of looking forward instead of behind, I think. Are there really, in the eve of year 2019, users expecting to compile PoDoFo or use PoDoFo from C++ environments not meeting C++11 compliance, or at least the introduction of std::unique_ptr which had started to be supported by some compilers even before C++11 had turned standard? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] std::auto_ptr
[ 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 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 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
Re: [Podofo-users] std::auto_ptr
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.
As PoDoFo has opened issue tracker in SourceForge now, maybe you'd open
a request there, thus this doesn't get forgotten.
Bye,
zyxIndex: CMakeLists.txt
===
--- CMakeLists.txt (revision 1887)
+++ CMakeLists.txt (working copy)
@@ -20,6 +20,7 @@ SET(PODOFO_LIBVERSION "${PODOFO_SOVERSIO
#
# Main includes
#
+INCLUDE(CheckCXXSourceCompiles)
INCLUDE(CheckIncludeFile)
INCLUDE(CheckLibraryExists)
INCLUDE(TestBigEndian)
@@ -92,6 +93,14 @@ ENDIF(WANT_LIB64)
ENDIF(DEFINED LIB_SUFFIX)
MESSAGE("Will install libraries to ${CMAKE_INSTALL_PREFIX}/${LIBDIRNAME}")
+CHECK_CXX_SOURCE_COMPILES("#include
+ class Cls {
+ public:
+ Cls() {}
+ ~Cls() {}
+ };
+ int main(void) { std::unique_ptr cls; return 0; }" PODOFO_HAVE_UNIQUE_PTR)
+
# Some headers that tend to vary a bit
CHECK_INCLUDE_FILE("strings.h" PODOFO_HAVE_STRINGS_H)
CHECK_INCLUDE_FILE("arpa/inet.h" PODOFO_HAVE_ARPA_INET_H)
Index: podofo_config.h.in
===
--- podofo_config.h.in (revision 1887)
+++ podofo_config.h.in (working copy)
@@ -16,6 +16,7 @@
#cmakedefine PODOFO_MULTI_THREAD
/* somewhat platform-specific headers */
+#cmakedefine PODOFO_HAVE_UNIQUE_PTR 1
#cmakedefine PODOFO_HAVE_STRINGS_H 1
#cmakedefine PODOFO_HAVE_ARPA_INET_H 1
#cmakedefine PODOFO_HAVE_WINSOCK2_H 1
Index: src/base/PdfCompilerCompat.h
===
--- src/base/PdfCompilerCompat.h (revision 1887)
+++ src/base/PdfCompilerCompat.h (working copy)
@@ -113,6 +113,13 @@
#define NOMINMAX
#endif
+// prefer std::unique_ptr over std::auto_ptr
+#ifdef PODOFO_HAVE_UNIQUE_PTR
+#define PODOFO_UNIQUEU_PTR std::unique_ptr
+#else
+#define PODOFO_UNIQUEU_PTR std::auto_ptr
+#endif
+
// Integer types - fixed size types guaranteed to work anywhere
// because we detect the right underlying type name to use with
// CMake. Use typedefs rather than macros for saner error messages
Index: src/base/PdfFilter.cpp
===
--- src/base/PdfFilter.cpp (revision 1887)
+++ src/base/PdfFilter.cpp (working copy)
@@ -131,7 +131,7 @@ class PdfFilteredEncodeStream : public P
private:
PdfOutputStream* m_pOutputStream;
-std::auto_ptr m_filter;
+PODOFO_UNIQUEU_PTR m_filter;
};
/** Create a filter that is a PdfOutputStream.
@@ -206,7 +206,7 @@ class PdfFilteredDecodeStream : public P
private:
PdfOutputStream* m_pOutputStream;
-std::auto_ptr m_filter;
+PODOFO_UNIQUEU_PTR m_filter;
bool m_bFilterFailed;
};
@@ -264,7 +264,7 @@ PdfFilterFactory::PdfFilterFactory()
{
}
-std::auto_ptr PdfFilterFactory::Create( const EPdfFilter eFilter )
+PODOFO_UNIQUEU_PTR PdfFilterFactory::Create( const EPdfFilter eFilter )
{
PdfFilter* pFilter = NULL;
switch( eFilter )
@@ -316,7 +316,7 @@ std::auto_ptr PdfFilterFactor
break;
}
-return std::auto_ptr(pFilter);
+return PODOFO_UNIQUEU_PTR(pFilter);
}
PdfOutputStream* PdfFilterFactory::CreateEncodeStream( const TVecFilters & filters, PdfOutputStream* pStream )
Index: src/base/PdfFilter.h
===
--- src/base/PdfFilter.h (revision 1887)
+++ src/base/PdfFilter.h (working copy)
@@ -454,7 +454,7 @@ class PODOFO_API PdfFilterFactory {
public:
/** Create a filter from an enum.
*
- * Ownership is transferred to the caller, who should let the auto_ptr
+ * Ownership is transferred to the caller, who should let the auto_ptr/unique_ptr
* the filter is returned in take care of freeing it when they're done
* with it.
*
@@ -463,7 +463,7 @@ class PODOFO_API PdfFilterFactory {
* \returns a new PdfFilter allocated using new, or NULL if no
* filter is available for this type.
*/
-static std::auto_ptr Create( const EPdfFilter eFilter );
+static PODOFO_UNIQUEU_PTR Create( const EPdfFilter eFilter );
/** Create a PdfOutputStream that applies a list of filters
* on al
Re: [Podofo-users] std::auto_ptr
> Le 8 févr. 2018 à 12:06, Olivier Mascia a écrit : > > Dear, > > That may have been changed since 0.9.5 code base released, but it might be > good to replace all uses of std::auto_ptr with std::unique_ptr (which has > been here since C++11 and possibly earlier in some compilers), while auto_ptr > has been deprecated since C++11 and more annoyingly *removed* since C++17. > > http://en.cppreference.com/w/cpp/memory/auto_ptr > http://en.cppreference.com/w/cpp/memory/unique_ptr Understanding PoDoFo wants to stay compatible with historic compilers not even being C++11 compliant, what should be done regarding CMake and PoDoFo source code to conditionally use "std::unique_ptr" instead of "std::auto_ptr" based on the compiler being >= C++11 (which deprecated auto_ptr and replaced it by unique_ptr, or maybe based on C++17 which dropped std::auto_ptr (requiring to patch the source - easy replace, no semantic changes between these two, to be able to compile)? 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. I'm virgin regarding CMake to the point that I couldn't get it to succeed configuring the project for me (on Windows x64, MSVC 2017) and found it much simpler to rebuild a Solution/Project by myself. It was easy understanding what files were needed for what through the CMakefiles.txt. This to say I'm not best suited for helping in reconfiguring CMake files for this C++11/17 detection. -- 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
[Podofo-users] std::auto_ptr
Dear, That may have been changed since 0.9.5 code base released, but it might be good to replace all uses of std::auto_ptr with std::unique_ptr (which has been here since C++11 and possibly earlier in some compilers), while auto_ptr has been deprecated since C++11 and more annoyingly *removed* since C++17. http://en.cppreference.com/w/cpp/memory/auto_ptr http://en.cppreference.com/w/cpp/memory/unique_ptr I had to build with a C++17 setup and these were the only errors encountered. The remaining unclear bits are only warnings which I still need to investigate. What this experience means is that PoDoFo C++ coding is very good. :) -- 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
