Re: IOStreams formal review start
The latest package can be found at the following
locations:
The package avalaible on this page doesn't build with gcc-3.3 on linux and darwin. There are some compilation-time warnings and errors: boost/libs/io/src/file_descriptor.cpp: In member function `void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode, std::_Ios_Openmode)': boost/libs/io/src/file_descriptor.cpp:91: error: no matching function for call to `boost::io::file_descriptor_resource::open( const char*, int&, mode_t&)' boost/libs/io/src/file_descriptor.cpp:47: error: candidates are: void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16), std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16)) boost/libs/io/src/file_descriptor.cpp:68: warning: enumeration value `_M_ios_openmode_end' not handled in switch boost/libs/io/src/file_descriptor.cpp:68: warning: case value `8' not in enumerated type `_Ios_Openmode' /boost/libs/io/src/file_descriptor.cpp:68: warning: case value `16' not in enumerated type `_Ios_Openmode' boost/libs/io/src/file_descriptor.cpp:68: warning: case value `24' not in enumerated type `_Ios_Openmode' ... you may apply the patch file_descriptor-cpp.patch to solve the problem. The link of the shared libraries fails too, because the gzip and bzip2 libraries names are wrong in the file compression.jam (the common names are libz.so and libbz2.so on unix/darwin/solaris...): darwin-Link-DyLib-action bin/boost/libs/io/build/libboost_io.dylib/darwin/debug/shared-linkable-true/libboost_io-d-1_32.dylib ld: can't locate file for: -lzlib ld: can't locate file for: -llibbz2 The patch compression-jam.patch solves the problem, but it may break your build system on other platforms (I'm not a jam file expert yet ;) MD. Vous manquez despace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com
"Michel Decima" <michel_decima@yahoo.fr> wrote:
The latest package can be found at the following
locations:
The package avalaible on this page doesn't build with gcc-3.3 on linux and darwin. There are some compilation-time warnings and errors:
Thanks!
you may apply the patch file_descriptor-cpp.patch to solve the problem.
I've applied you're changes, even though the library is meant to be frozen for review, since they're so important.
The link of the shared libraries fails too, because the gzip and bzip2 libraries names are wrong in the file compression.jam (the common names are libz.so and libbz2.so on unix/darwin/solaris...):
Eventually I'll have to have someone familiar with boost.build critique my Jamfiles. For now, try defining the variables ZLIB_BINARY and LIBBZ2_BINARY, as described in Installation ("Building with Bjam"), and let me know if it works. Best Regards, Jonathan
Hello, I made another changes to the library source to make it works on my test platform (Linux.x86, gcc-3.3.4 and gcc-3.4.1) : The library compiles well with gcc-3.3.4, but gcc-3.4.1 needs some help to find the 'read' and 'write' functions: In file included from /Boost/src/boost/boost/io/zlib.hpp:19, from /Boost/src/boost/libs/io/build/../src/zlib.cpp:11: /Boost/src/boost/boost/io/symmetric_filter_adapter.hpp: In member function `streamsize boost::io::detail::symmetric_filter_adapter_impl< SymmetricFilter, Alloc >::read(Source &, typename boost::io::char_type<T>::type *, streamsize )': /Boost/src/boost/boost/io/symmetric_filter_adapter.hpp:93: error: `read' is not a member of `boost::io' Same error for `write' on lines 110 and 160. The missing fuctions are defined in the header operations.hpp, which is not included. (see operations-hpp.patch) The inclusions of the headers gives another problem: In file included from /Boost/src/boost/boost/io/symmetric_filter_adapter.hpp:44, from /Boost/src/boost/boost/io/zlib.hpp:19, from /Boost/src/boost/libs/io/build/../src/zlib.cpp:11: /Boost/src/boost/boost/io/operations.hpp: In static member function `static void boost::io::detail::read_impl< boost::io::input >::putback(T &, typename boost::io::char_type<T>::type)': /Boost/src/boost/boost/io/operations.hpp:102: error: invalid application of `sizeof' to incomplete type `boost::STATIC_ASSERTION_FAILURE< false>' I don't understand why this assertion fails (but I didn't tried to ;) so I changed it to true... The lib is now ready to be linked against, let's see some example programs: To compile the bzip2 example (doc section 5.9.3.3) with gcc-3.4.1, you need to define the macro BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT (gcc-3.3.4 does not need it). Without this macro you get the following errors: In file included from /Boost/stow/boost- 1.32.0/include/boost-1_32/boost/io/detail/push.hpp:12, from /Boost/stow/boost-1.32.0/include/boost- 1_32/boost/io/detail/chain.hpp:23, from /Boost/stow/boost-1.32.0/include/boost- 1_32/boost/io/filtering_streambuf.hpp:17, from simple_bzcat.cpp:4: /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/detail/resolve.hpp:34: error: non-template `result_type' used as template /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/detail/resolve.hpp:34: note: use `U::template result_type' to indicate that it is a template /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/detail/resolve.hpp:34: error: expected `{' before ';' token The two builds of the program run as expected. The gzip example (doc section 5.9.3.2) fails (using gcc-3.3.4 or gcc-3.4.1) with the errors : In file included from simple_gzcat.cpp:6: /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/gzip.hpp:88: error: expected unqualified-id before numeric constant /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/gzip.hpp:88: error: expected `, ' or `;' before numeric constant /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/gzip.hpp:145: error: declaration of `int boost::io::gzip_error::zlib_error() const' /Boost/stow/boost-1.32.0/include/boost-1_32/boost/io/zlib.hpp:116: error: changes meaning of `zlib_error' from `boost::io::zlib_error' The first error (line 88) : the declaration of the constant 'unix' clashes with the platform-dependant macro 'unix' already defined by the compiler (see boost/config/select_platform_config.hp). The attached patch (gzip-hpp.patch) renames the constant to unix_os (not the best name, but it is not the question). The second error is big collision around the name zlib_error : a class in the namespace boost::io (zlib.hpp), a constant in the namespace gzip (gzip.hpp) and a member function of the class gzip_error (gzip.hpp) The patch renames the member function to lib_error, it's not the best solution again, but it works. After a library rebuild, the second example compiles with both compilers, and runs without any problems. MD --- ../iostream/boost/io/gzip.hpp Tue Aug 31 23:12:01 2004 +++ boost/io/gzip.hpp Wed Sep 1 09:11:44 2004 @@ -85,7 +85,7 @@ namespace os { const int fat = 0; const int amiga = 1; const int vms = 2; -const int unix = 3; +const int unix_os = 3; const int vm_cms = 4; const int atari = 5; const int hpfs = 6; @@ -135,16 +135,16 @@ class gzip_error : public std::ios::fail public: gzip_error(int error) : std::ios::failure("gzip error"), - error_ (error), zlib_error_(zlib::okay) { } + error_ (error), lib_error_(zlib::okay) { } gzip_error(const zlib_error& e) : std::ios::failure("gzip error"), - error_(gzip::zlib_error), zlib_error_(e.error()) + error_(gzip::zlib_error), lib_error_(e.error()) { } int error() const { return error_; } - int zlib_error() const { return zlib_error_; } + int lib_error() const { return lib_error_; } private: int error_; - int zlib_error_; + int lib_error_; }; // --- ../iostream/boost/io/operations.hpp Tue Aug 31 23:12:01 2004 +++ boost/io/operations.hpp Tue Aug 31 23:23:59 2004 @@ -99,7 +99,7 @@ struct read_impl<input> { template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) - { BOOST_STATIC_ASSERT(false); } + { BOOST_STATIC_ASSERT(true); } }; template<> --- ../iostream/boost/io/symmetric_filter_adapter.hpp Tue Aug 31 23:12:01 2004 +++ boost/io/symmetric_filter_adapter.hpp Tue Aug 31 23:23:03 2004 @@ -41,6 +41,7 @@ #include <boost/io/detail/config.hpp> // scope_guard. #include <boost/io/detail/scope_guard.hpp> #include <boost/io/io_traits.hpp> +#include <boost/io/operations.hpp> // read, write #include <boost/shared_ptr.hpp> namespace boost { namespace io {
--- ../iostream/boost/io/operations.hpp Tue Aug 31 23:12:01 2004 +++ boost/io/operations.hpp Tue Aug 31 23:23:59 2004 @@ -99,7 +99,7 @@ struct read_impl<input> {
template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) - { BOOST_STATIC_ASSERT(false); } + { BOOST_STATIC_ASSERT(true); }
This is caused by the fact that since 3.4.1, template bodies that do not depend on a template parameter need to be compilable. Thus, the body *is* checked for compilation problems, even when putback is never instantiated. Obviously, the change from false -> true is not the solution here. If 'T' would always define a type 'false', then this might work (as example), causing 'T' to be part of the body: template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) { BOOST_STATIC_ASSERT(typename T::false); } Hmm, what about: template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) { BOOST_STATIC_ASSERT(sizeof(T) == 0); } Does that work? -- Carlo Wood <carlo@alinoe.com>
"Carlo Wood" <carlo@alinoe.com> wrote in message news:20040831234344.GB18151@alinoe.com...
--- ../iostream/boost/io/operations.hpp Tue Aug 31 23:12:01 2004 +++ boost/io/operations.hpp Tue Aug 31 23:23:59 2004 @@ -99,7 +99,7 @@ struct read_impl<input> {
template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) - { BOOST_STATIC_ASSERT(false); } + { BOOST_STATIC_ASSERT(true); }
This is caused by the fact that since 3.4.1, template bodies that do not depend on a template parameter need to be compilable. Thus, the body *is* checked for compilation problems, even when putback is never instantiated.
Thanks for the tip. Do you know whether this is considered standard conforming? Jonathan
On Tue, Aug 31, 2004 at 07:59:49PM -0600, Jonathan Turkanis wrote:
"Carlo Wood" <carlo@alinoe.com> wrote in message news:20040831234344.GB18151@alinoe.com...
+++ boost/io/operations.hpp Tue Aug 31 23:23:59 2004 @@ -99,7 +99,7 @@ struct read_impl<input> {
template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) - { BOOST_STATIC_ASSERT(false); } + { BOOST_STATIC_ASSERT(true); }
This is caused by the fact that since 3.4.1, template bodies that do not depend on a template parameter need to be compilable. Thus, the body *is* checked for compilation problems, even when putback is never instantiated.
Thanks for the tip. Do you know whether this is considered standard conforming?
Yes, it is. The problem can be avoided, though, by an indirection as suggested by Peter Dimov: http://lists.boost.org/MailArchives/boost/msg06980.php Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
"Christoph Ludwig" <cludwig@cdc.informatik.tu-darmstadt.de> wrote in message news:20040901092828.GD11098@cdc-ws9.cdc.informatik.tu-darmstadt.de...
Yes, it is. The problem can be avoided, though, by an indirection as suggested by Peter Dimov:
Thanks. I think Peters idea is better than my intended patch, which was domain specific. Jonathan
"Michel Decima" <michel_decima@yahoo.fr> wrote in message news:4134FDF4.1080803@yahoo.fr...
Hello,
I made another changes to the library source to make it works on my test platform (Linux.x86, gcc-3.3.4 and gcc-3.4.1) :
The library compiles well with gcc-3.3.4, but gcc-3.4.1 needs some help to find the 'read' and 'write' functions:
<snip>
Same error for `write' on lines 110 and 160. The missing fuctions are defined in the header operations.hpp, which is not included. (see operations-hpp.patch)
Thanks. Funny no other compiler picked this up. I'll apply this patch as soon as the other things are resolved (see below).
The inclusions of the headers gives another problem:
<snip>
/Boost/src/boost/boost/io/operations.hpp:102: error: invalid application of `sizeof' to incomplete type `boost::STATIC_ASSERTION_FAILURE< false>'
I don't understand why this assertion fails (but I didn't tried to ;) so I changed it to true...
Carlo explained this one. Here's the way it should be patched: ----------------------------------- --- operations.hpp 1 Sep 2004 01:48:40 -0000 1.37 +++ operations.hpp 1 Sep 2004 01:48:49 -0000 @@ -19,6 +19,7 @@ #if !defined(BOOST_NO_STD_LOCALE) # include <locale> // neeed for boost::io::imbue. #endif +#include <boost/io/detail/assert_convertible.hpp> #include <boost/io/detail/dispatch.hpp> #include <boost/io/detail/iterator_traits.hpp> #include <boost/io/detail/ios_traits.hpp> @@ -103,7 +104,7 @@ template<typename T> static void putback(T&, BOOST_IO_CHAR_TYPE(T)) - { BOOST_STATIC_ASSERT(false); } + { BOOST_IO_ASSERT_CONVERTIBLE(BOOST_IO_CATEGORY(T), peekable_tag); } }; ----------------------------------
The lib is now ready to be linked against, let's see some example programs:
To compile the bzip2 example (doc section 5.9.3.3) with gcc-3.4.1, you need to define the macro BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT
error: expected `{' before ';' token
Could you try applying the following patch, and tell me if it works without defining BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT? ---------------------------------- --- resolve.hpp 31 Aug 2004 18:02:51 -0000 1.4 +++ resolve.hpp 1 Sep 2004 01:13:32 -0000 @@ -35,7 +35,7 @@ BOOST_STATIC_ASSERT(!is_const<T>::value); #ifndef BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT template<typename U> - struct get_result_type : U::result_type<Mode, Ch> { }; + struct get_result_type : U::template result_type<Mode, Ch> { }; #else template<typename U> struct get_result_type { ----------------------------------
The two builds of the program run as expected.
The gzip example (doc section 5.9.3.2) fails (using gcc-3.3.4 or gcc-3.4.1) with the errors :
<snip>
The first error (line 88) : the declaration of the constant 'unix' clashes with the platform-dependant macro 'unix' already defined by the compiler (see boost/config/select_platform_config.hp).
Ouch! I ran in to this with newline filter but forgot about it here. My inclination is to get rid of the 'os' namespace and prefix each constant with 'os_'.
The attached patch (gzip-hpp.patch) renames the constant to unix_os (not the best name, but it is not the question).
The second error is big collision around the name zlib_error : a class in the namespace boost::io (zlib.hpp), a constant in the namespace gzip (gzip.hpp) and a member function of the class gzip_error (gzip.hpp) The patch renames the member function to lib_error, it's not the best solution again, but it works.
Before I patch this, I'd like to understand the error a little better. It's hard to see how 'zlib_error_' could clash with anything. At any rate, I don't really care what the member variable is called, but I think I prefer 'zlib_error_code_'.
After a library rebuild, the second example compiles with both compilers, and runs without any problems.
Thank you for all your help!!
MD
Jonathan
Jonathan Turkanis wrote:
"Michel Decima" <michel_decima@yahoo.fr> wrote in message news:4134FDF4.1080803@yahoo.fr...
To compile the bzip2 example (doc section 5.9.3.3) with gcc-3.4.1, you need to define the macro BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT
Could you try applying the following patch, and tell me if it works without defining BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT?
Yes, it works.
"Michel Decima" <michel_decima@yahoo.fr> wrote in message news:4137936A.7010502@yahoo.fr...
Jonathan Turkanis wrote:
"Michel Decima" <michel_decima@yahoo.fr> wrote in message news:4134FDF4.1080803@yahoo.fr...
To compile the bzip2 example (doc section 5.9.3.3) with gcc-3.4.1, you need to define the macro BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT
Could you try applying the following patch, and tell me if it works without defining BOOST_IO_NO_FULL_SMART_ADAPTER_SUPPORT?
Yes, it works.
Great. Otherwise I wouldn't know what to do. Jonathan
Jonathan Turkanis wrote:
Eventually I'll have to have someone familiar with boost.build critique my Jamfiles. For now, try defining the variables ZLIB_BINARY and LIBBZ2_BINARY, as described in Installation ("Building with Bjam"), and let me know if it works.
mmmh. mea maxima culpa. Of course it works (this time on darwin) : bjam -sTOOLS=darwin -sZLIB_BINARY=z -sLIBBZ2_BINARY=bz2 --with-io stage ... FileClone stage/lib/libboost_io-1_32.dylib ...updated 4 targets... next time, I'll read the doc first (just kidding ;)
participants (4)
-
Carlo Wood -
Christoph Ludwig -
Jonathan Turkanis -
Michel Decima