- Boost - lists.boost.org

Re: [boost] LVALUE_TYPEOF to be dropped
by Bulygin, Sergey 15 Feb '06

15 Feb '06

Dear Arkadiy, My implementation of result_of heavily relies on BOOST_LVALUE_TYPEOF. Is it a big problem just to let it stay in the library? Even being not documented in public interface. Best Regards, Sergey Bulygin "Arkadiy Vertleyb" <vertleyb(a)hotmail.com> wrote in message news:<dstku0$2ic$1(a)sea.gmane.org>... > Hi. > > It turned out that we can't provide the portable implementation of > LVALUE_TYPEOF that would be both safe and useful. > > The primary purpose of this feature would be to assist in creation of > wrapper functions (possibly through the result_of). The current > implementation cannot distinguish between const rvalues and lvalues, and so > yields const T& instead of const T (on VC7.1+, for UDT, it's also volatile& > instead of volatile, and volatile const& instead of volatile const). If > used in a wrapper function, this would lead to a dangling reference. > > An alternative would be to yield rvalue for anything other than T&, but this > would not work with const T& where T is non-copyable (again, on MS for > UDT -- also with volatile [const] T&). > > There are some (non-portable) ways to do better, but those work only for vc > and gcc. Returning different results on different compilers would make it > useless for generic code which is the primary target of this feature. > > I am pretty sure nobody depends on LVALUE_TYPEOF in 1.34... > > So, unless there are some serious objections, we are not including > LVALUE_TYPEOF into 1.34. If, at some point in the future, a better way is > found to determine lvalueness, this feature can be added again. > > Regards, > Arkadiy > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Mailing-list for the standardization of interval arithmetic
by Sylvain Pion 15 Feb '06

15 Feb '06

Dear Boost members, Some of you may already be aware that the authors of Boost.Interval (Herve Bronnimann, Guillaume Melquiond and myself) are working on a proposal to standardize interval arithmetic in C++. This work has several facets which require different kinds of expertise : - floating point semantic aspects, - C++ library design aspects, the topic of boost, - expertise in all kinds of interval arithmetic usage. We have already issued an initial version of the proposal, which was presented in Mont-Tremblant, and which you can find here : http://www-sop.inria.fr/geometrica/team/Sylvain.Pion/cxx/ This version already received a lot of comments, and we will prepare a revision to integrate these comments. We invite interested people to join a mailing-list that we have just created to discuss this project : http://compgeom.poly.edu/mailman/listinfo/std-interval The list is open and (for now) unmoderated. In addition, please feel free to forward this announcement to anyone you think may be interested in the discussion. -- Sylvain Pion, Herve Bronnimann, Guillaume Melquiond.

1 0

[test] Warning messages
by Iulian M 15 Feb '06

15 Feb '06

Hi, Compiling the file boost/test/impl/execution_monitor.ipp with gcc-3.4 ( freebsd ) with the following : g++ -O2 -Werror -Wall -W test.cpp ( test.cpp contains only #include <boost/test/impl/execution_monitor.ipp> ) produces two warnings: boost/test/impl/execution_monitor.ipp:422 warning: variable 'result' might be clobbered by `longjmp' or `vfork' boost/test/impl/execution_monitor.ipp:423 warning: variable 'ec' might be clobbered by `longjmp' or `vfork' Moving the two variables declarations a few lines down, after the volatile int sigtype = sigsetjmp( signal_handler::jump_buffer(), 1 ); solves the problem. Regards, Iulian M. -- Tonight's the night: Sleep in a eucalyptus tree.

2 1

[test] Unused variable warning
by Iulian M 15 Feb '06

15 Feb '06

Hi, There is an unused variable in boost/test/progress_monitor.hpp line 49 void assertion_result( bool passed ) {} I noticed it using v1.33.1 but i've also seen that in the CVS-HEAD is still there Compiling with all warnings and warnings as errors stops there. Is there any point for keeping the variable there ? The file includes <boost/test/detail/suppress_warnings.hpp> but that file only suppreses warnings on MSVC. -- Time and tide wait for no man.

2 1

[Boost] [program_options] additional parser bug
by Alexander Kondratyuk 15 Feb '06

15 Feb '06

Have a problem with using additional parser feature: I want to allow user to use double dashes for short options, so user will use "-h" or "--h". But using additional parser the code throws an error about syntax. It seems there is a bug in additional parser wrapper - in case then my option has no parameters defined and declared in description it adds an empty value to the vector of values when additional paser returns pair of strings. Here is an example that illustrates the problem: #define BOOST_WHATEVER_DYN_LINK #define BOOST_LIB_DIAGNOSTIC #include <boost/program_options/variables_map.hpp> #include <boost/program_options/options_description.hpp> #include <boost/program_options/parsers.hpp> #include <boost/program_options/detail/utf8_codecvt_facet.hpp> #include <boost/token_iterator.hpp> #include <boost/shared_ptr.hpp> using namespace boost::program_options; #include <string> #include <vector> using namespace std; pair<string, string> parserDashDashShort(const string& s) { string str = s.substr( 0, s.find('=') ); if( str.length()==3 && str[0]=='-' && str[1]=='-' && str[2]<='z' && str[2]>='a') { string val = s.substr(str.length()); return make_pair( str.substr(1), val ); } return make_pair(string(), string()); } int _tmain(int , _TCHAR* argv[]) { int style = command_line_style::allow_short| command_line_style::allow_dash_for_short | command_line_style::short_allow_adjacent; options_description desc; desc.add_options() ("help,h", "help message") ; char* args[]={"program.exe", "--h"}; int argc = sizeof( args ) / sizeof( args[0] ); parse_command_line<char>( argc, (char**)args, desc, style, parserDashDashShort ); return 0; }

1 0

[config] math_info test issue
by Vladimir Prus 15 Feb '06

15 Feb '06

Hi, I'm looking at libs/config/test/Jamfile, and it starts with this: # *** DO NOT EDIT THIS FILE BY HAND *** However, looking at the libs/config/tools/generate.cpp I don't see any "math_info" test being generated. Further, changelog contains this: 2005-12-06 20:01 johnmaddock * test/Jamfile: Added new file math_info to probe for known or suspected math-related problems and setup. There's no associated change to generate.cpp. See seems like the file was edited by hand. Am I wrong? - Volodya

2 6

[config hash, set, ... and gcc library]
by Robert Ramey 15 Feb '06

15 Feb '06

There have been some changes to config which I really haven't been understood in detail but it seems that the extension namespace isn't setup right and the serialization library tests from these collections are failing. Strangly, stlist tests seem to work OK. Could someone who is more familiar with these changes please take a look at this? Robert Ramey

2 1

Boost date_time question
by Serguei KOLOS 15 Feb '06

15 Feb '06

Hello In order to pass boost::posix_time::ptime objects over network, I want to convert them to some data of one of the basic C types on sender host and be able to do the backward conversion on receiver host. Both conversions should preserve the time with microseconds precision. Could somebody suggest the correct way of doing that? Cheers, Sergei

1 0

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