- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1246308 ] MSVC support
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246308, was opened at 2005-07-27 13:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246308&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: config Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: MSVC support Initial Comment: rint function is not declared in any of MSVC's include files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246308&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

SF CVS having problems. ?? release delay ??
by Rene Rivera 27 Jul '05

27 Jul '05

As some of you may have noticed starting last night CVS access is not possible. This is currently preventing me from checking in changes to the explicit markup file. And of course also preventing me from getting any updates, and preventing it would seem the boost-consulting mirror from getting updated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2

[Signals] Proposal effort for TR2
by Doug Gregor 27 Jul '05

27 Jul '05

At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list: http://mail.gnome.org/mailman/listinfo/libsigc-list We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum. Doug

1 0

Boost.Serialization archive constructor performance
by Kim Barrett 27 Jul '05

27 Jul '05

I've been experimenting with the Boost.Serialization library, to decide whether to use it in a project I'm working on. If it weren't for some performance issues, the decision of whether to use this library would be a no-brainer. Because it seemed otherwise so promising, I've spent some time investigating these performance issues, and have a couple of suggestions for improvements that would address them. (Obviously these suggestions are for post-1.33 release.) The use case being considered is marshalling values for transport to some other process. This is among the use cases discussed in the overview section of the library's documentation. However, it turns out that with relatively fine-grained marshalling operations, constructor / destructor time for the archive can amount to a significant fraction of the time spent in performing such an operation. The thing that seems to be using up most of the time is the initialization of various standard containers (std:set, std::vector, std::list), most of which are used for pointer tracking. For reference, a snippet to show the sort of thing I'm doing. (Please ignore the fact that this code snippet is obviously not thread-safe and similar issues; I've simplified things to show just the parts relevant to this issue.) const int binary_archive_flags = boost::archive::no_header | boost::archive::no_codecvt; const std::size_t size 64; static char buffer[size]; // allocate stream once, and reset for reuse static boost::iostreams::stream<io::array_sink> out(buffer, size); out.seekp(0); #if REUSE_ARCHIVES // allocate archive once, and reset for reuse static boost::archive::binary_oarchive oa(out, binary_archive_flags); oa.reset(); #else boost::archive::binary_oarchive oa(out, binary_archive_flags); #endif save_ss(ss, oa); // write ss into archive oa // arrange for destination process to receive the contents of // buffer containing serialized ss A change which I think should be not too difficult to make, and which would make a large difference, would be to provide a mechanism for resetting and reusing an archive. As part of my experiments I added a public void reset() operation boost::archive::detail::basic_iarchive and basic_oarchive, which clear the various tracking related containers in the associated pimpl objects. I then modified my tests to allocate their archives once and reset before each use. The result was a significant speedup. Rather than spending roughly 1/3 of the time in archive construction / destruction, the archive reset time is now close to the noise level in my measurements. (As you can see in the above code snippet, I'd already started reusing the streams for similar reasons.) I'm not necessarily proposing exactly the interface I used here for experimentation. A better interface might be to reset the archive when the associated stream is changed (which involves adding an interface for changing the stream, of course). But I'm not sure that's right either, since there is some separation between the stream handling part and the pointer tracking part of things. Perhaps there is an intent to support something other than streams, by using something other than boost::archive::basic_binary_[i,o]primitive? I think that once the details of this interface are determined, the implementation is pretty straight-forward. A second change, which may or may not be worthwhile, would be to avoid allocating the various tracking-related containers at all when the archive is created with no_tracking specified. With archive reuse as described above, this probably wouldn't make any directly noticeable performance difference for my usage. It might make a difference in space usage though, as the design I'm investigating this library for might end up with a significant number of archives devoted to various specific things, with pointer-less data being common in this design. So avoiding the allocation of a bunch of always empty containers, might be worthwhile, depending on the space used by such. This seems like it might be significantly more difficult to implement than the reuse support though. And whether it is actually worth doing depends on the internal implementation of the standard containers being used.

5 8

Re: [boost] [wave]: possible use for makefile dependencies
by Martin Bonner 27 Jul '05

27 Jul '05

----Original Message---- From: Pavel Vozenilek [mailto:pavel_vozenilek@hotmail.com] Sent: 26 July 2005 17:09 To: boost(a)lists.boost.org Subject: [boost] [wave]: possible use for makefile dependencies > Hello Hartmut, > > Wave executable could have feature for use > in makefiles or makefile generators. [snip] > Most likely output consisting from only > space separated dependent headers > (no *.obj, no foo.c itself) is the best ouput > as the text is futher manipulated. That breaks horribly as soon as you have any headers whose names contain spaces! (P.S. Is this the correct list for this?) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

Re: [boost] Interest in a binary_int template for binary literals?
by Scott Schurr 26 Jul '05

26 Jul '05

Greetings, I'm back from vacation. I have a note and a question regarding the binary_int template. 1. I've compiled the binary_int template with Microsoft Visual Studio.NET version 7.0. It gets unhappy when the most significant bit is set in a 32-bit binary word. The compiler reports: warning C4307: '*' : integral constant overflow along with a bunch of other stuff about the template instantiation. It seems to be only a warning however, since the executable is still produced and runs properly. I tried a couple of things in the enum definition to try and convince the compiler to use an unsigned int for the computation, but to no avail. I couldn't figure out a way to get rid of the warning. 2. Pavel Vozenilek thinks that the names binary_nibble and binary_int could be improved on. Pavel suggests the names 'nibble' and 'bits', noting that the term 'binary' has too many connotations in C++. At any rate, what do folks think would be good names for these two templates? Thanks. Scott Schurr

2 1

zip iterator over containers of unequal sizes
by Leo Goodstadt 26 Jul '05

26 Jul '05

The zip iterator documentation says: "The zip iterator provides the ability to parallel-iterate over several controlled sequences simultaneously. ... Moving the zip iterator moves all the iterators in parallel." What is not specified is what happens when the several different sequences are of unequal size. At the moment, everything just blows up. python zip, if I remember correctly, just stops at the end of the shortest sequence in the tuple. (python map works differently). This seems a sensible thing to do. This requires just a modification to zip_iterator::equal. I guess distance_to might need to be changed as well. Leo Goodstadt The diff is attached at the end. Here is the example modified: #include <boost/iterator/zip_iterator.hpp> #include <boost/tuple/tuple.hpp> #include <iostream> #include <vector> int main() { typedef std::vector<int> IntSeq; // a = {1,2,3} IntSeq a; a.push_back(1); a.push_back(2); a.push_back(3); // b = {10,20,30,40} IntSeq b; b.push_back(10); b.push_back(20); b.push_back(30); b.push_back(40); // b = {100,200,300,400,500} IntSeq c; c.push_back(100); c.push_back(200); c.push_back(300); c.push_back(400); c.push_back(500); typedef boost::zip_iterator< boost::tuples::tuple< IntSeq::const_iterator, IntSeq::const_iterator, IntSeq::const_iterator> > ZIt; ZIt cur(boost::make_tuple(a.begin(), b.begin(), c.begin())); ZIt end(boost::make_tuple(a.end(), b.end(), c.end())); for ( ; cur != end; ++cur ) { std::cout << "{ " << boost::tuples::get<0>(*cur) << ", " << boost::tuples::get<1>(*cur) << ", " << boost::tuples::get<2>(*cur) << " }" << std::endl; } return 0; } diff old_boost/iterator/zip_iterator.hpp new_boost/iterator/zip_iterator.hpp 329a330,347 > > // Returns true if any tuples equal. NOTE: "==" for tuples currently (7/2003) > // has problems under some compilers, so I just do my own. > // No point in bringing in a bunch of #ifdefs here. This is > // going to go away with the next tuple implementation anyway. > // > bool tuple_any_equal(tuples::null_type, tuples::null_type) > { return false; } > > template<typename Tuple1, typename Tuple2> > bool tuple_any_equal( > Tuple1 const& t1, > Tuple2 const& t2 > ) > { > return t1.get_head() == t2.get_head() || > tuple_any_equal(t1.get_tail(), t2.get_tail()); > } 537c555 < return detail::tuple_impl_specific::tuple_equal( --- > return detail::tuple_impl_specific::tuple_any_equal(

4 4

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 26 Jul '05

26 Jul '05

Beman Dawes wrote: > "Jan Hermelink" <Jan.Hermelink(a)metalogic.de> wrote in message >> Another idea: >> - Get a WIN32 file handle with CreateFileW() >> - Get filename from handle: >> http://msdn.microsoft.com/library/en-us/fileio/fs/obtaining_a_file_name_ >> from_a_file_handle.asp - use thereby the "Ansi" function to get the >> "ansi" filename (GetMappedFileNameA()) >> >> However I have not tested this... > > I don't see how that could work unless the codepage is correct, but > like you I haven't actually tested. You are right - I have tried this with a file name with greek characters, and GetMappedFileNameA() failes to translate them correctly: all greek characters are replaced with '?' (with german system locale). Yet another idea: - open file with _wfopen() and get FILE pointer - construct basic_*fstream with this FILE pointer (Dinkumwares (and other) implementation has basic_fstream(FILE*) etc. as an extension) Jan

1 0

boost-jam-3.1.11 [was Re: Jam binaries for 1.33.0?]
by Rene Rivera 26 Jul '05

26 Jul '05

>>Doug Gregor wrote: >> >>>We'll need updated Jam binaries on Sourceforge for the 1.33.0 release. OK, that's done: <http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=72941…> Those are all the platforms I can directly generate bjam binaries for. If others would like to see specific platforms I would be glad to add them. To build a distribution package do: cd boost-root/tools/build/jam_src cvs -q -z3 update -r Boost_Jam_3_1_11 sh ./build.sh --- dist And upload the resulting "boost-jam-3.1.11-1-[platform].tgz" to ftp://uploads.sf.net/incoming -- And either add it directly to the SF file release system (all devs should be able to do this now). Or tell me the file is there and I'll do it. And of course you find anything wrong with the binaries please speak up. Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 1

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 26 Jul '05

26 Jul '05

Beman Dawes wrote: > At 04:42 AM 7/20/2005, Jan Hermelink wrote: > > >Replacing the current implementation thru a simple narrow conversion > >helps as workaround. > > My understanding (which could be faulty) is that there is no general > way to do such a wide to narrow conversion that always works. I don't know. It works with filenames with german characters but I can't say for filenames with e.g. CJK characters. Another idea: - Get a WIN32 file handle with CreateFileW() - Get filename from handle: http://msdn.microsoft.com/library/en-us/fileio/fs/obtaining_a_file_name_ from_a_file_handle.asp - use thereby the "Ansi" function to get the "ansi" filename (GetMappedFileNameA()) However I have not tested this... Jan

2 1