January 2006 - Boost - lists.preview.boost.org

Re: [boost] [Release 1.34] Supported Compilers
by brangdon＠cix.compulink.co.uk 15 Mar '06

15 Mar '06

In-Reply-To: <drn6le$4d0$1(a)sea.gmane.org> rh_gmane(a)mac.com (Russell Hind) wrote (abridged): > Can't people still working with this just use 1.33.x version of boost? I completely agree. People who won't upgrade VC++ 6 shouldn't expect to upgrade boost. I see no need for "depreciated" here. (I'm speaking as a user who had to stick with VC++ 6 for a long time.) -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] [asio] some stuff about ipv4::address
by Martin Bonner 25 Feb '06

25 Feb '06

----Original Message---- From: Chris Cleeland > On Fri, 13 Jan 2006, Christopher Kohlhoff wrote: > >> Some thoughts, both for and against: >> >> - Does unsigned char always imply 0..255? No. >> Might there be a >> standards-conforming C++ implementation where char is not 8 >> bits? Yes. Plausible other values are 9 (for 36-bit word addressed machines), and 32 (for DSPs where it is just too much heartache to slice a 32-bit word). >> (Admittedly porting a sockets library, which inherently >> deals in sequences of octets, to this architecture could be >> rather difficult.) Not as bad as you think. Each octet must be able to fit into an unsigned char. It's just that an unsigned char can hold a value which doesn't fit in an octet. > > Good question; I know that sizeof(char) == sizeof(unsigned char) == > 1, but I don't know that it's guarantee anywhere that something > that has a sizeof==1 is exactly 8 bits. It isn't. It is defined that unsigned char has AT LEAST 8 bits (because it can hold 0..255). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

6 5

[Boost Test] - MSVC 6.0 issue in recent HEAD
by Robert Ramey 19 Feb '06

19 Feb '06

In preparing to upload some changes to the serialization library I updated my local tree and re-ran my tests. I'm getting a new kind of error with MSVC 6.0 - here it is. It looks to me that something has been improved in the test library beyond the point of functionality - at leaset as msvc 6.0 is concerned. Robert Ramey logged_expectations.cpp C:\BoostHead\boost/test/utils/named_params.hpp(269) : error C2989: 'typed_keyword<bool,T,0>' : template class has already been defined as a non-template class C:\BoostHead\boost/test/utils/named_params.hpp(269) : error C2988: unrecognizable template declaration/definition C:\BoostHead\boost/test/utils/foreach.hpp(353) : fatal error C1506: unrecoverable block scoping error

6 8

bcbboost - The unofficial BCB Boost patches
by Nicola Musatti 15 Feb '06

15 Feb '06

Hallo, everybody. As you probably know Borland released their new C++ product, BCB 2006, right after Boost 1.33.1 came out. As a result users of this product are faced with a longish period of time without a version of Boost that supports it. Moreover, given that standard compliance doesn't seem to have increased all that much with the new compiler it remains to be seen how many of the libraries that currently are compatible with Borland compilers will continue to be as they evolve. As a stopgap measure I created the bcbboost project in SourceForge to collect patches against Boost 1.33.1 that make it possible to use Boost with BCB 2006. Right now there's only the minimum necessary to build the libraries to the same level as BCB6. I kind of hope that some of those interested will rather join forces than repeat the same steps over and over each on their own. I also hope to submit to Boost any newly discovered fix that is applicable to the main development line. For those interested: http://sourceforge.net/projects/bcbboost Comments, suggestions and bug reports are obviously welcome. Help is even more welcome :-) Cheers, Nicola Musatti

4 4

Late asio review
by Chris Cleeland 15 Feb '06

15 Feb '06

Hi, I'd like to offer the following comments on asio based on 15+ years of network programming in various languages and various situations, but as somebody who is pretty much a boost novice. I wish I could become a boost expert instantly; my commentary from many previous experiences (some successful, and some not) trying to wrap the network programming monster up with higher level abstractions. There are definitely areas that felt "wierd" to me. Unfortunately, I don't know if that is b/c I'm not in tune with "the boost way", or if it's something in either the design or the implementation. In general, I tried to ignore those sorts of things. Regardless, these are the things that really stick out to me: 1. too abstract in places Specifically, I'm talking about the whole buffer thing and the hiding of the demuxer's implementation. I'll address each of these separately: (a) buffers: from a certain perspective, this sounds nice, but it seems that there are already so many abstractions over a (void* + length)--do we REALLY need another? Could this be simplified to something like std::pair<void*, std::size_t> ? (b) hiding of demux impl: first, I don't like the fact that it chooses for me at compile time. Abstraction is nice, but sometimes I, as the programmer, really DO know better or have good reason to choose one thing over another. Anytime libraries completely force my hand, I rebel. In general, I feel that this library throws in enough abstraction to be in the way, but not enough to completely abstract away the features that it's really using. I don't see how one can get hold of the raw socket descriptor to twiddle options that the library hasn't abstracted. I also know that after 15+ years of network programming, KNOWING the details all the way down to the wire is important for how one writes code. Purists may say that one should never make such assumptions, but the reality is that when your "wire" is gigabit ethernet you get to write code with a certain set of assumption that is completely different from assumptions in place when the "wire" are high-bandwidth/high-latency satellites in geosynch orbit. The abstractions that are in place in this library seem to insulate me too much. I would prefer to see a "you don't have to know if you don't want to" philosophy rather than a "you don't need to know because I don't think you need to know" philosophy. 2. unnecessary features Is hostname resolution really so much of an overhead that we need asynch hostname resolution? If the feature were basically "free", I would say okay, but the fact that it requires firing up an extra thread behind the scenes (another one of my pet peeves) makes it seem like a wholly unnecessary feature. 3. header-only implementation Besides the fact that this style is "wierd" to me (that's a personal thing), this implementation choice forces users' hands down the line. First, it forces all the code in the "library" to be replicated in every executable. This is not efficient and increases footprint. 4. How would I implement a timed write with the current async API? By "timed write", I mean that I want to write some hunk of data, but I need to know if the write hasn't completed within a certain window of time. This is a common need in performance-sensitive systems, and writing it synchronously can be done, but how do I write it asynch? 5. TSS and threads Shouldn't these rely on boost.thread? I'm especially thinkng of TSS in this case, bceause in ACE/TAO we've found that TSS is, at the very least, inconsistent across platforms. See changelog entry in ACE_wrappers/Changelogs/ChangeLog-05a for one of t he more aggregious examples. Wed Feb 16 16:18:45 2005 Dale Wilson <wilson_d(a)ociweb.com> I look forward to seeing Jeff's consolidation of all the review material and what Chris comes up with afterwards! -- Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris Principal Software Engineer, Object Computing, Inc., +1 314 579 0066 Support Me Supporting Cancer Survivors in Ride for the Roses 2005 >>>>>>>>> Donate at http://www.milodesigns.com/donate <<<<<<<<<

6 10

Should we still be testing GCC 2.95.3?
by Beman Dawes 15 Feb '06

15 Feb '06

I'm gettng pestered by the automatic regression test failure notification system about Boost.Filesystem with GCC 2.95.3. Does anyone still care? I could just mark all the failures as expected, but if no one cares anymore then we ought to stop testing 2.95.3, free up the testing resources and stop pestering Boost developers about 2.95.3 failures. --Beman

16 30

[function] latest optimizations break Borland compiler
by AlisdairM 11 Feb '06

11 Feb '06

The latest optimizations in the function library break on the Borland compiler, which does not recognise a destructor when explicitly invoked through a typedef. I don't have a patch for this one yet, just a quick heads-up. In the worst case, could we add a BOOST_WORKAROUND with the old behaviour? I hope to have a better answer later this week though... -- AlisdairM

3 5

[typeof][spirit][msvc gurus] is it possible to work around this bug??
by Tobias Schwinger 10 Feb '06

10 Feb '06

Hi List, The code below fails to compile with MSVC8 when the macro MAKE_THINGS_FAIL is defined. I hope the code reads well enough to communicate the problem and why it would be quite hot to get it fixed ;-). Thanks a lot for your help, Tobias #include <boost/spirit/core.hpp> #include <boost/typeof/typeof.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(boost::spirit::anychar_parser) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::spirit::action, 2) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::spirit::positive, 1) #define an_expression +anychar_p[ a_placeholder ] typedef void (* fptr)(char const * from, char const * to); void echo(char const * from, char const * to) { // [...] } #ifndef MAKE_THINGS_FAIL using boost::spirit::anychar_p; class a_rule_parser : boost::spirit::parser<a_rule_parser> { fptr a_placeholder; struct __rule { // hide the placeholder member variable of the outer class with a static // variable of the same type static fptr & a_placeholder; typedef BOOST_TYPEOF( an_expression ) type; }; __rule::type __expr; public: a_rule_parser(fptr placeholder) : a_placeholder( placeholder ) , __expr( an_expression ) { } // [...] (it's stripped down code to show a bug) }; int main() { a_rule_parser x(& echo); return 0; } // so far, so good... #else // ...but the same code in templated form makes msvc8 do strange things // using boost::spirit::anychar_p; using namespace boost::spirit; // ADL doesn't seem to work, either but I could live with this problem ;-) template<typename T> class a_rule_parser_template : boost::spirit::parser< a_rule_parser_template<T> > { T a_placeholder; struct __rule { // hide the placeholder member variable of the outer class with a static // variable of the same type static T & a_placeholder; typedef BOOST_TYPEOF_TPL( an_expression ) type; }; typename __rule::type __expr; public: a_rule_parser_template(T const & placeholder) : a_placeholder( placeholder ) , __expr( an_expression ) { } // [...] (it's stripped down code to show a bug) }; int main() { a_rule_parser_template<fptr> x(& echo); return 0; } #endif

3 9

[Boost-bugs] [ boost-Patches-1157160 ] patch for boost::filesystem
by SourceForge.net 07 Feb '06

07 Feb '06

Patches item #1157160, was opened at 2005-03-04 23:23 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1157160&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Weiss (fotzor) >Assigned to: Beman Dawes (beman_dawes) Summary: patch for boost::filesystem Initial Comment: hi, when you try to get the branch path of this "c:\\some_dir\\some_file.txt" under windows the branch path should be "c:\\some_dir". what is returned instead is "c:" which isn't correct. so here's the fix: in path_posix_windows.cpp: std::string::size_type leaf_pos( const std::string & str, std::string::size_type end_pos ) // end_pos is past-the-end position // return 0 if str itself is leaf (or empty) { if ( end_pos && str[end_pos-1] == '/' ) return end_pos-1; std::string::size_type pos( str.find_last_of( '/', end_pos-1 ) ); # ifdef BOOST_WINDOWS if ( pos == std::string::npos ) pos = str.find_last_of( '\\', end_pos-1 ); // ADDED if ( pos == std::string::npos ) pos = str.find_last_of( ':', end_pos-2 ); # endif return ( pos == std::string::npos // path itself must be a leaf (or empty) # ifdef BOOST_WINDOWS || (pos == 1 && (str[0] == '/' || str[0] == '\\')) // or share // ADDED # endif ) ? 0 // so leaf is entire string : pos + 1; // or starts after delimiter } mfg steven ---------------------------------------------------------------------- Comment By: Steven Weiss (fotzor) Date: 2005-03-05 00:24 Message: Logged In: YES user_id=1124235 i forgot something... in branch_path() you must also change the condition of the if to: if ( end_pos && (m_path[end_pos-1] == '/' || m_path[end_pos-1] == '\\') && !detail::is_absolute_root( m_path, end_pos ) ) --end_pos; else it doesn't work proper. perhaps there are other functions depending on leaf_pos() that must be adjusted as well ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1157160&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[filesystem] Possible problem in copy_file
by G. Wade Johnson 07 Feb '06

07 Feb '06

I was looking in the code for copy_file() and noticed what may be a bug. In the loop that handles partial writes, the code makes multiple attempts reducing the amount of data written each time. Unfortunately, the offset into the data is not changed as well. See below. sz_write = 0; do { if ( (sz = ::write( outfile, buf.get(), sz_read - sz_write )) < 0 ) { sz_read = sz; // cause read loop termination break; // and error to be thrown after closes } sz_write += sz; } while ( sz_write < sz_read ); Unless I'm missing something, it looks like a partial write will result in the first part of the buffer being written multiple times. I checked the version in CVS and it appears to have the same code. Am I missing something or is this incorrect? G. Wade

2 2