[iostreams(jonathan)] - using with 1.32

Jonathan, Do you have a version that works with the 1.32 release? If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp. I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient? I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp . Is this sufficient? I've got some other compile errors but I'm not sure if they are just downstream errors caused by these issues. Thanks, Jeff

"Jeff Flinn" <TriumphSprint2000@hotmail.com> wrote in message news:cntdut$d6i$1@sea.gmane.org...
Jonathan,
Do you have a version that works with the 1.32 release?
If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp.
I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient?
I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp .
Is this sufficient? I've got some other compile errors but I'm not sure if
Hi. Thanks for using the library! they are just downstream errors caused by these issues. I haven't worked on iostreams for a while. Now that 1.32 is out, I'm going to make getting the library in shape for 1.33 a high priority. There is a chance that later today I will try to modify the compression filters to use the named param library currently under review, since this is the last day of the review and I'd like users to be able to write stuff like filtering_ostream out; out.push(zlib_compressor(compression_level = 7, strategy = filtered)); If I get around to this, I'll have to confront the 1.32 compatibility issue today. Otherwise, it will be a few days from now. By the way, what compiler/standard library are you using?
Thanks, Jeff
Jonathan

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cntimk$rhr$1@sea.gmane.org...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> wrote in message news:cntdut$d6i$1@sea.gmane.org...
Jonathan,
Hi. Thanks for using the library!
Thanks for writing it!
Do you have a version that works with the 1.32 release?
If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp.
I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient?
I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp .
Is this sufficient? I've got some other compile errors but I'm not sure if they are just downstream errors caused by these issues.
I haven't worked on iostreams for a while. Now that 1.32 is out, I'm going to make getting the library in shape for 1.33 a high priority. There is a chance that later today I will try to modify the compression filters to use the named param library currently under review, since this is the last day of the review and I'd like users to be able to write stuff like
filtering_ostream out; out.push(zlib_compressor(compression_level = 7, strategy = filtered));
If I get around to this, I'll have to confront the 1.32 compatibility issue today. Otherwise, it will be a few days from now.
Either is appreciated.
By the way, what compiler/standard library are you using?
VC7.1 with it's standard standard library. Thanks again, Jeff

Jonathan, Just to let you know the apply_if -> eval_if changes that I previously mentioned were sufficient in my case to utilize your library with boost 1.32.0. The library is used to 'wrap' MFC non-standard facilities for cut/copy/paste and drag/drop for use with Robert's serialization library. In this case I am not using many of the more advanced features of your library (yet). Please let me know when you have any updates available. Thanks again, Jeff

"Jeff Flinn" <TriumphSprint2000@hotmail.com> wrote in message news:co2be4$dug$1@sea.gmane.org...
Jonathan,
Just to let you know the apply_if -> eval_if changes that I previously mentioned were sufficient in my case to utilize your library with boost 1.32.0.
Great!
The library is used to 'wrap' MFC non-standard facilities for cut/copy/paste and drag/drop for use with Robert's serialization library. In this case I am not using many of the more advanced features of your library (yet).
Please let me know when you have any updates available.
Will do.
Thanks again, Jeff
Jonathan

Jeff Flinn wrote:
Jonathan,
Just to let you know the apply_if -> eval_if changes that I previously mentioned were sufficient in my case to utilize your library with boost 1.32.0.
I can confirm this, as I am using it myself. However, msvc-8.0 requires inclusion of <ios> in the file boost/io/detail/streambufs/linked_streambuf.hpp to fix an error at line 54.
The library is used to 'wrap' MFC non-standard facilities for cut/copy/paste and drag/drop for use with Robert's serialization library. In this case I am not using many of the more advanced features of your library (yet).
I am playing around with the library. Here are a few thoughts: [1] And is it possible to access Sink members from stream_facade, for example: stream_facade< speech_reader > speech; speech.set_pitch( 50 ); speech.set_voice( "LH Michelle" ); speech << "This is the Lernout & Hauspie Michelle voice.\n" [2] I would like to collapse: std::ofstream out( "encoded.txt" ); boost::io::filtering_ostream os; os.push( ascii85_encoder()); os.push( out ); os << ...; to: class ascii85_ofstream: public boost::io::filtering_ostream { std::ofstream out; public: ascii85_ofstream( const char * fn ): out( fn ) { push( ascii85_encoder()); push( out ); } }; ascii85_ofstream os( "encoded.txt" ); os << ...; but this results in a crash at the destructor (tested with msvc-8.0). Maybe if filtering_ostream takes a bool denoting if it closes on the destructor (default to true), so I could do: ascii85_ofstream::ascii85_ofstream( const char * fn ): filtering_ostream( false ), out( fn ) { push( ascii85_encoder()); push( out ); } ascii85_ofstream::~ascii85_ofstream() { close(); } Regards, Reece

"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:co2o7c$ms8$1@sea.gmane.org...
Jeff Flinn wrote:
Jonathan,
Just to let you know the apply_if -> eval_if changes that I previously mentioned were sufficient in my case to utilize your library with boost 1.32.0.
I can confirm this, as I am using it myself. However, msvc-8.0 requires inclusion of <ios> in the file boost/io/detail/streambufs/linked_streambuf.hpp to fix an error at line 54.
Thanks -- I'll make a note of this. I have 8.0 beta now, and it seems to be much better behaved in some respects. I'm getting a lot fewer ICEs and out of resource type errors.
The library is used to 'wrap' MFC non-standard facilities for cut/copy/paste and drag/drop for use with Robert's serialization library. In this case I am not using many of the more advanced features of your library (yet).
I am playing around with the library. Here are a few thoughts:
[1] And is it possible to access Sink members from stream_facade, for example:
stream_facade< speech_reader > speech; speech.set_pitch( 50 ); speech.set_voice( "LH Michelle" ); speech << "This is the Lernout & Hauspie Michelle voice.\n"
This would require stream_facade to derive from the policy class, which I didn't do for several reasons. The way to access the policy is with operators * or ->: stream_facade< speech_reader > speech; speech->set_pitch( 50 ); // Or: (*speech).set_pitch( 50 );
[2] I would like to collapse:
std::ofstream out( "encoded.txt" ); boost::io::filtering_ostream os; os.push( ascii85_encoder()); os.push( out ); os << ...;
to:
class ascii85_ofstream: public boost::io::filtering_ostream { std::ofstream out; public: ascii85_ofstream( const char * fn ): out( fn ) { push( ascii85_encoder()); push( out ); } };
ascii85_ofstream os( "encoded.txt" ); os << ...;
Yes, this is certainly one of the intended uses of the library.
but this results in a crash at the destructor (tested with msvc-8.0).
Maybe if filtering_ostream takes a bool denoting if it closes on the destructor (default to true), so I could do:
ascii85_ofstream::ascii85_ofstream( const char * fn ): filtering_ostream( false ), out( fn ) { push( ascii85_encoder()); push( out ); }
ascii85_ofstream::~ascii85_ofstream() { close(); }
I believe the problem is that the filtering_ostream (a base class) is accessing the ofstream (a member of a derived class) after the ofstream has been destroyed. This would be unacceptable even if filtering_ostream had a no-close-on-exit option. I believe the solution is to pop the ofstream in the ascii85_ofstream destructor. ascii85_ofstream::~ascii85_ofstream() { pop(); // Or: reset(); } Please let me know if this works.
Regards, Reece
Jonathan

Jonathan Turkanis wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote in message
I am playing around with the library. Here are a few thoughts:
[1] And is it possible to access Sink members from stream_facade, for example:
This would require stream_facade to derive from the policy class, which I didn't do for several reasons. The way to access the policy is with operators * or ->:
stream_facade< speech_reader > speech; speech->set_pitch( 50 ); // Or: (*speech).set_pitch( 50 );
That is still just as good :).
[2] I would like to collapse:
std::ofstream out( "encoded.txt" ); boost::io::filtering_ostream os; os.push( ascii85_encoder()); os.push( out ); os << ...;
to:
class ascii85_ofstream: public boost::io::filtering_ostream { std::ofstream out; public: ascii85_ofstream( const char * fn ): out( fn ) { push( ascii85_encoder()); push( out ); } };
ascii85_ofstream os( "encoded.txt" ); os << ...;
Yes, this is certainly one of the intended uses of the library.
but this results in a crash at the destructor (tested with msvc-8.0).
I believe the problem is that the filtering_ostream (a base class) is accessing the ofstream (a member of a derived class) after the ofstream has been destroyed.
This was my thoughts as well.
This would be unacceptable even if filtering_ostream had a no-close-on-exit option. I believe the solution is to pop the ofstream in the ascii85_ofstream destructor.
ascii85_ofstream::~ascii85_ofstream() { pop(); // Or: reset(); }
Please let me know if this works.
pop() does indeed fix the problem :). Regards, Reece
participants (3)
-
Jeff Flinn
-
Jonathan Turkanis
-
Reece Dunn