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

Re: [boost] RFC Generic data structure traversal / manipulation library
by dan marsden 15 Jan '08

15 Jan '08

Larry Evans wrote: >Larry Evans wrote: >> dan marsden wrote: <snip> >> Page: >> >> http://spirit.sourceforge.net/dl_docs/traversal/html/traversal/quick_start_… >> >> contains: >> >> BOOST_FUSION_ADAPT_STRUCT(demo::dept, >> (std::string, name) >> (std::vector<demo::unit>, units)) >> >> I'm assuming demo is a namespace; yet, there's no declaration on that >> page. Also, although I could guess what >> >Sorry, hit wrong button. Continuing: > >Although I could guess what BOOST_FUSION_ADAPT_STRUCT does, it would >help to provide the reference: > >http://spirit.sourceforge.net/dl_more/fusion_v2/libs/fusion/doc/html/fusion… > >I couldn't find any doc on my local copy of fusion, and the boost.org >docs: > >http://www.boost.org/libs/libraries.htm > >had nothing; so, I had to search the mailing list for some location >before I found adapt_struct.html. Thanks for the various bits of feedback, I'm incorporating them into the documentation. If people are interested in the latest stuff, its current hosted in the Spirit Subversion repository at: https://spirit.svn.sourceforge.net/svnroot/spirit/branches/traversal/ I'll also aim to keep the online docs / source reasonably up to date as the library progresses. Cheers Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

1 0

Re: [boost] [gacap]Is any interesting to "Generating All Combinations and Permutations"？
by hervebronnimann＠mac.com 15 Jan '08

15 Jan '08

Ben, Phil: happy new year. Yes, ben, proposal will only have functions, but boost can (and should) accept more. You can go ahaed and start integrating gacap into proposed boost library. I put it on the prviously mentioned web site, and can do a check into the subversion repo with my version and your changes when all is ready. HB Sent via BlackBerry from T-Mobile

1 0

[Interval] Bug when constructing from an unsigned integer type
by John Maddock 15 Jan '08

15 Jan '08

This compiles: boost::interval<double> in(1u); but creates a nonsense interval. IMO this should work? Likewise the same problem manifests itself when constructing from an unsigned long long (and in this case you really do want a true interval to be created). John.

2 6

Additions to Random/Math
by Andrew Sutton 15 Jan '08

15 Jan '08

I finally got around to committing my additions to the Random and Math libraries this morning. I haven't been able to make much progress since early december due to a) the holidays and b) a burning desire to graduate some time this decade - I've been working on my prospectus. Here's a quick summary of the commit. = Random = - Added 6 or 7 new distributions for random number generation - Added a new gamma distribution that correctly takes 2 parameters - Added a fixed lognormal distribution that correctly allows for a negative mean - Added a new program in libs/generator that will generate random numbers given a distribution and some parameters. Results are printed to cout and comparisons with the statistical distribution (in Boost.Math) are printed to cerr. Works nicely with gnuplot = Math = Added 2 new stubs of distributions (skew normal and geometric). Implemented an alternative version of the extreme_value distribution that supports both min and max variations. This is called extreme_value_i_distribution (i == 1). = What's Missing = Formal testing (outside of the generator tool above). Documentation I'll try to add missing features over the next couple months, but I can't make any guarantees. If authors are worried about "polluting" an existing project, I can easily re-extract them into a new top- level directory in the sandbox since there were no modifications to existing code. Andrew Sutton asutton(a)cs.kent.edu

2 3

[Threads] Dropped support for VC7.0 and earlier?
by John Maddock 15 Jan '08

15 Jan '08

Looks like Boost.Threads no longer compiles with VC7.0 and earlier, is this a deliberate change, or was it unintentional? Just checking, thanks, John.

2 1

the review of the switch library ends today, January 13th
by Stjepan Rajko 15 Jan '08

15 Jan '08

The review of the Switch library submitted by Steven Watanabe ends today (Sunday, January 13th). I would like to thank Steven for submitting a very useful library, as well as all those who have submitted reviews and/or contributed to the discussion (especially Tobias Schwinger and Joel de Guzman who have put in quite a bit of effort towards enhancing the design of the library). I will send a more detailed summary of the review as well as a decision in the following days. I currently have only 3 reviews to base a decision on, so any additional votes that anyone would like to contribute in the very near future would be very welcome. Regards, Stjepan

3 2

Re: [boost] [Boost-users] [switch_] Compound Cases [was Case Concept]
by Steven Watanabe 15 Jan '08

15 Jan '08

AMDG Joel de Guzman wrote: > Tobias Schwinger wrote: > > >>>> (c0,c1,...,cN) being just another 'Case' rather than a 'Sequence'. >>>> >>> o..k... Hmm.. so how would the resulting case object for this >>> expression look like: >>> >>> case_c<1>(f1), case_c<2>(f2) >>> >>> ? >>> >> template< class SeqCases > >> struct sequenced_case >> { >> <snip> >> > > Sounds good to me! I like it. So, this involves the variation where > a case has an MPL sequence of labels. I knew there's something in > that that I like. Intuition, I guess. That is also why I use the > name case_ regardless of number. A compound case is just another > case anyway. Does not matter how many labels it serves. > > Not sure how, implementation-wise, this works for Steven. Steven? > If this pans out, I'll refine the concept one more time. > It's trivial to implement: #define BOOST_SWITCH_CASE(z, n, data)\ case mpl::at_c<typename C::labels, n>::type::value: return(c.apply<R>(mpl::int_<n>())); My concern is 1) fall-through can't easily be added to the interface. 2) It seems like just another interface for a fusion sequence. Is sequenced_case to be public? If so, we need another concept for its interface... In Christ, Steven Watanabe

2 4

Re: [boost] Is there any interest in a template geometry library?
by 吴黄 15 Jan '08

15 Jan '08

------------------ 吴黄 2008-01-15 ------------------------------------------------------------- 发件人：Barend Gehrels 发送日期：2008-01-14 21:36:12 收件人：抄送：主题：[boost] Is there any interest in a template geometry library? Hi, Is there any interest in a template geometry library? I am a Chinese graduate student majoring CAD/CG in Hefei University of Technology, and I'm very interest in the template geometry library. The library we are developing is basic 2D geometry library. In this library, data structures are small and simple (but polygons can still have holes). Nevertheless, the library provides a lot of useful algorithms such as point-in-polygon, line intersections and polygon clipping. We at Geodan are developing our library since 1995, and recently restructured, simplified and enhanced the geometry core. Now that it is clean and well designed, and still with years of experience, we aim to publish it in Boost under the Boost Software License. How about is your experience now? How long to publish the library? I want to have a sight on the library as soon as possible. To give some impressions, points are like this: template <typename T> class point { (...) inline const T& x() const (...) inline const T& y() const (...) }; and lines are completely empty, like this: template <typename P> class linestring : public std::vector<P> { }; (Besides that you can also specify another container). Data and algorithms are separated, Why not to put the data and algorithms together for encapsulation? Because I think the parameter type which algorithm operates is very limited, not generic, just one or two. so there are algorithms like: template <typename P, typename POL> bool point_in_polygon(const P& p, const POL& pol); and like this: template <typename S1, typename S2, typename MP> intersection_result intersection_segment(const S1& segment1, const S2& segment2, MP& multipoint); but also generic wrappers like a "within" algorithm which is defined for all relevant geometry types template <typename P1, typename P2> inline bool within(const P& p, const polygon<P2>& poly) Because the library is completely templatized, you can use your own geometry types, and/or container types (provided that they follow the basic interface). The library follows std:: and boost:: standards and conventions, as well as the OGC (The Consortium on Standards in Geographical Information Systems) conventions. I know there have been discussions before on geometry libraries and on CGAL, e.g. http://lists.boost.org/Archives/boost/2007/03/117582.php. We are using boost in our library since about 2000. Where could i get the library and documentation from? If there is interest I will complete the documentation and examples according to Boost standards, and prepare a submission. Barend Gehrels ------------------------------------- Barend Gehrels ------------------------------------- Geodan Holding b.v. President Kennedylaan 1 1079 MB Amsterdam, the Netherlands ------------------------------------- E-mail: barend.gehrels(a)geodan.nl Website: www.geodan.nl ------------------------------------- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[random] uniform_int is biased
by Peter Dimov 14 Jan '08

14 Jan '08

I've observed that the sum of one million [-1..+1] random numbers produced by boost::uniform_int<> is consistently negative, usually between -3000 and -5000. Looking at the source reveals that the [0..N) -> [0..2] case, where N is 2^32, appears to be done with return (r / F) % 3, where F is 2^24. So, unless I'm missing something, this only uses 8 bits of the engine, and since 256 is not evenly divisible by 3, there is a slight bias of 1/256 which corresponds to -3906.25. Leaving aside the aggressive trimming of the low-order bits, which I believe is unnecessary when using mt19937 (is there ever a reason to use any other engine?) I still don't understand why we don't just use return r / K; where K is N / 3 and the values that exceed the target range are rejected to eliminate the bias entirely. This appears to simplify the code since (a) the separate "do we need rejection" test no longer needs to be done and is folded into the main case and (b) it uses the high-order bits, so it should work for LCGs as is.

1 0

Re: [boost] [boost::logging] using rolling files failed
by John Torjo 14 Jan '08

14 Jan '08

Hi Benjamin, Sorry for that. It's because I introduced a breaking change: after you initialize the log, call: g_logger->turn_cache_off(); That should do the trick. Best, John > Hi John, > > I'm working on integrating your last modifications about flushing > rolling files, but I encounter some problems. > > With version V0.11.7, I change rolling_file.hpp (see attached file) to > flush logs each time. It works fine. > > /destination::rolling_file_settings settings; > settings.file_count( 10 ); > settings.max_size_bytes( 5242880 ); > destination::rolling_file loggerFile( logFile.GetPath(), settings ); > g_logger->writer().add_destination( loggerFile ); > / > > With last version (revision 42765), I just add one line. / > / > > /destination::rolling_file_settings settings;/ > /settings.file_count( 10 );/ > /settings.max_size_bytes( 5242880 ); / > */=> settings.flush_each_time(true); // add this line/* > /destination::rolling_file loggerFile( logFile.GetPath(), settings );/ > /g_logger->writer().add_destination( loggerFile );/ > > Then it doesn't work. > I put a break point in rolling_file_info#write but my program does not > enter in it anymore ! > I think that rolling file objects are not instanciated because output > files are MY_FILE.txt and not MY_FILE.txt.1 > > Even if it will not compile alone, I give you my class Logger to see > my implementation. > > Regards, > Benjamin > > > ------------------------------------------------------------------------ > > // destination_rolling_file.hpp > > // Boost Logging library > // > // Author: John Torjo, www.torjo.com > // > // Copyright (C) 2007 John Torjo (see www.torjo.com for email) > // > // Distributed under the Boost Software License, Version 1.0. > // (See accompanying file LICENSE_1_0.txt or copy at > // http://www.boost.org/LICENSE_1_0.txt) > // > // See http://www.boost.org for updates, documentation, and revision history. > // See http://www.torjo.com/log2/ for more details > > > #ifndef JT28092007_destination_rolling_file_HPP_DEFINED > #define JT28092007_destination_rolling_file_HPP_DEFINED > > #if defined(_MSC_VER) && (_MSC_VER >= 1020) > # pragma once > #endif > > #if defined(_MSC_VER) > #pragma warning ( disable : 4355) > #endif > > #include <boost/logging/detail/fwd.hpp> > #include <boost/logging/detail/manipulator.hpp> > #include <boost/logging/format/destination/convert_destination.hpp> > #include <fstream> > #include <string> > #include <sstream> > #include <boost/filesystem/path.hpp> > #include <boost/filesystem/operations.hpp> > > namespace boost { namespace logging { namespace destination { > > > /** > @brief Settings you can pass to the rolling file. To see how it's used, see @ref dealing_with_flags. > */ > struct rolling_file_settings { > typedef boost::logging::detail::flag<rolling_file_settings> flag; > > rolling_file_settings() > : max_size_bytes(this, 1024 * 1024) > , file_count(this, 10) > , initial_erase(this, false) > , start_where_size_not_exceeded(this, true) > {} > > /// maximum size in bytes, by default 1Mb > flag::t<int> max_size_bytes; > /// how many files has a rolling file, by default, 10 > flag::t<int> file_count; > /// if true, it initially erases all files from the rolling file (by default, false) > flag::t<bool> initial_erase; > /// if true, it starts with the first file that hasn't exceeded the max size; > /// otherwise, it starts with the first file (default = true) > flag::t<bool> start_where_size_not_exceeded; > }; > > namespace detail { > template<class convert_dest > > struct rolling_file_info { > > rolling_file_info (const std::string& name_prefix, rolling_file_settings flags ) > // many thanks to Martin Bauer > : m_name_prefix(name_prefix), m_flags(flags), m_cur_idx(0) { > namespace fs = boost::filesystem; > > if ( m_flags.initial_erase()) { > for ( int idx = 0; idx < m_flags.file_count(); ++idx) > if ( fs::exists( file_name(idx) )) > fs::remove( file_name(idx) ); > } > > // see what file to start from > if ( m_flags.start_where_size_not_exceeded() ) { > for ( m_cur_idx = 0; m_cur_idx < m_flags.file_count(); ++m_cur_idx ) > if ( fs::exists( file_name(m_cur_idx) )) { > if ( fs::file_size( file_name(m_cur_idx)) < m_flags.max_size_bytes() ) > // file hasn't reached max size > break; > } > else > // file not found, we'll create it now > break; > > } > > recreate_file(); > } > > std::string file_name(int idx) { > std::ostringstream out; > out << m_name_prefix << "." << (idx+1); > return out.str(); > } > > void recreate_file() { > m_out = boost::shared_ptr< std::basic_ofstream<char_type> >(new std::basic_ofstream<char_type>( file_name(m_cur_idx).c_str(), > std::ios_base::out | std::ios_base::app)); > m_cur_size = 0; > } > > template<class msg_type> void write( const msg_type& msg) { > convert_dest::write(msg, (*m_out) ); > > // bdd 2007-12-10 : flush each time > m_cur_size += static_cast<int>( msg.size() ); > m_out->flush(); > > // bdd > //if ( m_out->tellp() > m_flags.max_size_bytes()) { > if ( m_cur_size > m_flags.max_size_bytes()) { > m_cur_idx = (m_cur_idx + 1) % m_flags.file_count(); > recreate_file(); > } > } > > boost::shared_ptr< std::basic_ofstream<char_type> > m_out; > std::string m_name_prefix; > rolling_file_settings m_flags; > // the index of the current file > int m_cur_idx; > > // bdd 2007-12-10 : flush each time > //size_t m_cur_size; > int m_cur_size; > }; > } > > /** > @brief Writes to multiple files: name_prefix.1, name_prefix.2, ... name_prefix.N, and then restarts from 1. > > We first write to name_prefix.1. > > The log has a max_size. When max_size is reached, we start writing to name_prefix.2. When max_size is reached, we start writing to name_prefix.3. > And so on, until we reach name_prefix.N (N = file_count). When that gets fool, we start over, with name_prefix.1. > */ > template<class convert_dest = do_convert_destination > struct rolling_file_t : is_generic, non_const_context<detail::rolling_file_info<convert_dest> > { > typedef non_const_context<detail::rolling_file_info<convert_dest> > non_const_context_base; > > /** > Constructs a rolling file > > @param name_prefix the name to be used as prefix for the files > > @param flags [optional] extra settings to pass to the rolling file. See rolling_file_settings and @ref dealing_with_flags. > */ > rolling_file_t(const std::string & name_prefix, rolling_file_settings flags = rolling_file_settings() ) : non_const_context_base(name_prefix, flags) {} > > template<class msg_type> void operator()( const msg_type & msg) const { > non_const_context_base::context().write(msg); > } > > bool operator==(const rolling_file_t & other) const { > return non_const_context_base::context().m_name_prefix == other.context().m_name_prefix; > } > }; > > /** @brief rolling_file_t with default values. See rolling_file_t > > @copydoc rolling_file_t > */ > typedef rolling_file_t<> rolling_file; > > > > > }}} > > #endif > > > ------------------------------------------------------------------------ > > > > //============================================================================= > // Includes > //============================================================================= > #include "StdAfx.h" > #include "common/log/Logger.h" > > //----- MEDCommon ----- > #include "common/system/ApplicationHelper.h" > #include "common/io/Directory.h" > #include "common/system/Time.h" > > //----- boost ----- > #pragma warning(disable: 4541) > > #include "boost/logging/tags.hpp" > #include "boost/logging/defaults.hpp" > #include "boost/logging/format.hpp" > #include "boost/logging/format_all.hpp" > #include "boost/logging/format_fwd.hpp" > #include "boost/logging/format_ts.hpp" > #include "boost/logging/logging.hpp" > #include "boost/logging/detail/error.hpp" > #include "boost/logging/detail/filter.hpp" > #include "boost/logging/detail/find_gather.hpp" > #include "boost/logging/detail/format_msg_type.hpp" > #include "boost/logging/detail/format_write_detail.hpp" > #include "boost/logging/detail/forward_constructor.hpp" > #include "boost/logging/detail/fwd.hpp" > #include "boost/logging/detail/level.hpp" > #include "boost/logging/detail/log_keeper.hpp" > #include "boost/logging/detail/logger.hpp" > #include "boost/logging/detail/macros.hpp" > #include "boost/logging/detail/manipulator.hpp" > #include "boost/logging/detail/scenario.hpp" > #include "boost/logging/detail/template.hpp" > #include "boost/logging/detail/use_format_write.hpp" > // raw_doc ? > #include "boost/logging/detail/ts/ts.hpp" > #include "boost/logging/detail/ts/ts_boost.hpp" > #include "boost/logging/detail/ts/ts_none.hpp" > //#include "boost/logging/detail/ts/ts_posix.hpp" > #include "boost/logging/detail/ts/ts_resource.hpp" > #include "boost/logging/detail/ts/ts_win32.hpp" > #include "boost/logging/detail/tss/tss.hpp" > #include "boost/logging/detail/tss/tss_ensure_proper_delete.hpp" > #include "boost/logging/detail/tss/tss_impl.hpp" > //#include "boost/logging/detail/tss/tss_impl_pthread.hpp" > #include "boost/logging/detail/tss/tss_impl_win32.hpp" > #include "boost/logging/format/array.hpp" > #include "boost/logging/format/op_equal.hpp" > #include "boost/logging/format/optimize.hpp" > #include "boost/logging/format/destination/convert_destination.hpp" > #include "boost/logging/format/destination/defaults.hpp" > #include "boost/logging/format/destination/file.hpp" > #include "boost/logging/format/destination/rolling_file.hpp" > #include "boost/logging/format/destination/shared_memory.hpp" > #include "boost/logging/format/formatter/convert_format.hpp" > #include "boost/logging/format/formatter/defaults.hpp" > #include "boost/logging/format/formatter/tags.hpp" > #include "boost/logging/format/formatter/thread_id.hpp" > #include "boost/logging/format/formatter/time.hpp" > #include "boost/logging/gather/ostream_like.hpp" > #include "boost/logging/tag/defaults.hpp" > #include "boost/logging/writer/format_write.hpp" > #include "boost/logging/writer/on_dedicated_thread.hpp" > #include "boost/logging/writer/ts_write.hpp" > > using namespace boost::logging; > > //----- Step 3 : Specify your logging class(es) ----- > //typedef logger_format_write< > log_type; > // thread safe > typedef logger_format_write< default_, default_, writer::threading::ts_write > log_type; > //typedef logger_format_write< default_, default_, writer::threading::on_dedicated_thread > log_type; > > //----- Step 4: declare which filters and loggers you'll use (usually in a header file) ----- > // filter > BOOST_DECLARE_LOG_FILTER(g_log_level, level::holder ) > BOOST_DECLARE_LOG_FILTER(g_audit_filter, filter::ts ) > > // logger > BOOST_DECLARE_LOG(g_logger, log_type) > BOOST_DECLARE_LOG(g_audit, log_type) > BOOST_DECLARE_LOG(g_debug, log_type) > > //----- Step 5: define the macros through which you'll log ----- > > //----- Step 6: Define the filters and loggers you'll use (usually in a source file) ----- > // filter > BOOST_DEFINE_LOG_FILTER(g_log_level, level::holder ) // holds the application log level > BOOST_DEFINE_LOG_FILTER(g_audit_filter, filter::ts ) > BOOST_DEFINE_LOG_FILTER(g_debug_filter, filter::ts ) > //BOOST_DEFINE_LOG_FILTER(g_audit_filter, filter::no_ts ) > // logger > BOOST_DEFINE_LOG(g_logger, log_type) > BOOST_DEFINE_LOG(g_audit, log_type) > BOOST_DEFINE_LOG(g_debug, log_type) > > using namespace common::log; > > //============================================================================= > // Global functions > //============================================================================= > void > Audit( const std::ostringstream & msg ) > { > Info( msg ); > BOOST_LOG_USE_LOG_IF_FILTER(g_audit, g_audit_filter->is_enabled() ) << "\t[AUDIT]\t" << msg.str(); > } > > void > Debug( const std::ostringstream & msg ) > { > BOOST_LOG_USE_LOG_IF_FILTER(g_debug, g_debug_filter->is_enabled() ) << "\t[DEBUG]\t" << msg.str(); > } > > void > Trace2( const std::ostringstream & msg ) > { > Debug( msg ); > common::log::Logger::s_traces.Push( msg.str() ); > } > > void > Info( const std::ostringstream & msg ) > { > BOOST_LOG_USE_LOG_IF_LEVEL(g_logger, g_log_level, info ) << "\t[INFO]\t" << msg.str(); > BOOST_LOG_USE_LOG_IF_FILTER(g_debug, g_debug_filter->is_enabled() ) << "\t[INFO]\t" << msg.str(); > } > > void > Warning( const std::ostringstream & msg ) > { > BOOST_LOG_USE_LOG_IF_LEVEL(g_logger, g_log_level, warning ) << "\t[WARN]\t" << msg.str(); > BOOST_LOG_USE_LOG_IF_FILTER(g_debug, g_debug_filter->is_enabled() ) << "\t[WARN]\t" << msg.str(); > } > > void > Error( const std::ostringstream & msg ) > { > if ( ! common::log::Logger::IsInitialized() ) > { > common::log::Logger::Init( "INIT" ); > } > if ( ! common::log::Logger::s_traces.IsEmpty() ) > { > // > vector<string> traces = common::log::Logger::s_traces.ToArray(); > for ( size_t i=0; i < traces.size(); i++ ) > { > BOOST_LOG_USE_LOG_IF_LEVEL(g_logger, g_log_level, error ) << "\t[TRACE]\t" << traces[i]; > } > } > BOOST_LOG_USE_LOG_IF_LEVEL(g_logger, g_log_level, error ) << "\t[ERROR]\t" << msg.str(); > BOOST_LOG_USE_LOG_IF_FILTER(g_debug, g_debug_filter->is_enabled() ) << "\t[ERROR]\t" << msg.str(); > } > > void > Exception( const std::ostringstream & msg ) > { > if ( ! common::log::Logger::IsInitialized() ) > { > common::log::Logger::Init( "INIT" ); > } > if ( ! common::log::Logger::s_traces.IsEmpty() ) > { > // > vector<string> traces = common::log::Logger::s_traces.ToArray(); > for ( size_t i=0; i < traces.size(); i++ ) > { > BOOST_LOG_USE_LOG_IF_LEVEL(g_logger, g_log_level, fatal ) << "\t[TRACE]\t" << traces[i]; > } > } > BOOST_LOG_USE_LOG_IF_LEVEL(g_logger, g_log_level, fatal ) << "\t[FATAL]\t" << msg.str(); > BOOST_LOG_USE_LOG_IF_FILTER(g_debug, g_debug_filter->is_enabled() ) << "\t[FATAL]\t" << msg.str(); > } > > > > //============================================================================= > // Class attributs > //============================================================================= > bool Logger::s_isInitialized = false; > bool Logger::MODE_DEBUG = false; > common::container::RollingStack<string> Logger::s_traces( 15 ); > > //============================================================================= > // Class methods > //============================================================================= > void > Logger::SetLevel( LEVEL level ) > { > g_audit_filter->set_enabled(true); > g_debug_filter->set_enabled(false); > switch ( level ) > { > case LEVEL_DEBUG : > Logger::MODE_DEBUG = true; > g_debug_filter->set_enabled(true); > g_log_level->set_enabled(level::debug); // debug > break; > case LEVEL_INFO : > g_log_level->set_enabled(level::info); // info + warning + ... > break; > case LEVEL_ERROR : > g_log_level->set_enabled(level::error); // error + fatal + ... > break; > default: > g_log_level->set_enabled(level::info); > break; > } > > } > > bool > Logger::IsInitialized() > { > return s_isInitialized; > } > > void > Logger::Init( const string & product ) > { > if ( s_isInitialized ) > { > return; > } > > // check log dir > common::system::ApplicationHelper ah; > common::io::Directory dir( ah.GetPath() + "logfiles" ); > dir.CheckAndCreate(); > > // init file names > //string date = common::system::Time::GetTime( common::system::Time::FORMAT_AAAA_MM_JJ ); > //common::io::File logFile( dir.GetPath() + date + "_" + product + ".txt" ); > //common::io::File auditFile( dir.GetPath() + date + "_AUDIT_" + product + ".txt" ); > common::io::File logFile( dir.GetPath() + product + ".txt" ); > common::io::File auditFile( dir.GetPath() + "AUDIT_" + product + ".txt" ); > common::io::File debugFile( dir.GetPath() + "DEBUG_" + product + ".txt" ); > > // Step 7: add formatters and destinations > // That is, how the message is to be formatted... > g_logger->writer().add_formatter( formatter::time("$dd/$MM/$yyyy - $hh:$mm.$ss ") ); > g_logger->writer().add_formatter( formatter::idx() ); > g_logger->writer().add_formatter( formatter::append_newline() ); > //g_log_err->writer().add_formatter( formatter::tag::module() ); // tag::file_line() ); > //g_log_err->writer().add_formatter( formatter::tag::level() ); > > g_audit->writer().add_formatter( formatter::time("$dd/$MM/$yyyy - $hh:$mm.$ss ") ); > g_audit->writer().add_formatter( formatter::idx() ); > g_audit->writer().add_formatter( formatter::append_newline() ); > > g_debug->writer().add_formatter( formatter::time("$dd/$MM/$yyyy - $hh:$mm.$ss ") ); > g_debug->writer().add_formatter( formatter::idx() ); > g_debug->writer().add_formatter( formatter::append_newline() ); > > g_logger->writer().add_destination( destination::cout() ); > > // bdd : rolling file : pb de flush (garde les donnees en cache) > destination::rolling_file_settings settings; > settings.file_count( 10 ); > settings.max_size_bytes( 5242880 ); // bytes = 5M > //settings.flush_each_time(true); > destination::rolling_file loggerFile( logFile.GetPath(), settings ); > g_logger->writer().add_destination( loggerFile ); > > g_debug->writer().add_destination( destination::dbg_window() ); > > destination::rolling_file_settings settingsD; > settingsD.file_count( 30 ); > settingsD.max_size_bytes( 10000000 ); // ~10M > //settingsD.flush_each_time(true); > g_debug->writer().add_destination( destination::rolling_file( debugFile.GetPath(), settingsD ) ); > > // bdd xml : en attente > //g_log_err->writer().add_destination( as_xml("logerror.xml") ); > > g_audit->writer().add_destination( destination::file( auditFile.GetPath() ) ); > > #ifdef _DEBUG > SetLevel( Logger::LEVEL_DEBUG ); > #else > SetLevel( Logger::LEVEL_INFO ); > #endif > s_isInitialized = true; > // Step 9 : Enjoy! > } > > > //============================================================================= > // Constructor and destructor > //============================================================================= > Logger::Logger(void) > : common::app::Object("common::log::Logger") > { > } > > Logger::~Logger(void) > { > } > > //============================================================================= > // Public methods > //============================================================================= > > > ------------------------------------------------------------------------ > > //* Step 1: (optional) Specify your format message class and/or destination message class. By default, it's std::(w)string. You'll use this when you want a optimize string class. > //* Step 2: (optional) Specify your formatter & destination base classes > //* Step 3: Specify your logger class(es) > //* Step 4: Declare the filters and loggers you'll use (in a header file) > //* Step 5: Define the macros through which you'll do logging > //* Step 6: Define the loggers and the filters you'll use (in a source file). We need this separation (into declaring and defining the logs/filters), in order to make compilation times fast. > //* Step 7: Add formatters and destinations. That is, how the message is to be formatted... > //* Step 8: Use it > //* Step 9: Enjoy the results! > > //* debug (smallest level), > //* info, > //* warning , > //* error , > //* fatal (highest level) > > #ifndef _COMMON_LOG_LOGGER_H_ > #define _COMMON_LOG_LOGGER_H_ > #pragma once > > //============================================================================= > // Includes > //============================================================================= > //----- MEDCommon ----- > #include "../commonIncludes.h" > #include "../app/Object.h" > #include "StackLog.h" > #include "common/txt/StringHelper.h" > #include "common/container/RollingStack.h" > > void MEDCOMMON_API Audit( const std::ostringstream & msg ); > void MEDCOMMON_API Debug( const std::ostringstream & msg ); > void MEDCOMMON_API Trace2( const std::ostringstream & msg ); > void MEDCOMMON_API Info( const std::ostringstream & msg ); > void MEDCOMMON_API Warning( const std::ostringstream & msg ); > void MEDCOMMON_API Error( const std::ostringstream & msg ); > void MEDCOMMON_API Exception( const std::ostringstream & msg ); > > #define MED_FUNCTION \ > common::log::StackLog log( __FUNCTION__ ); > > #define MED_FUNCTION2( msg ) \ > ostringstream s; \ > s << msg; \ > common::log::StackLog log( __FUNCTION__, s ); > > #define MED_METHOD( object ) \ > common::log::StackLog log( object,__FUNCTION__ ); > > #define MED_METHOD2( object, params ) \ > ostringstream s; \ > s << params; \ > common::log::StackLog log( object,__FUNCTION__, s ); > > #define MED_AUDIT( module, msg ) \ > { \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg; \ > Audit( s ); \ > } > > #define MED_DBG2( module, msg ) \ > { \ > if ( common::log::Logger::MODE_DEBUG ) \ > { \ > string file = __FILE__; \ > string fileName = common::txt::StringHelper::LastToken(file,"\\"); \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg \ > << " (" \ > << fileName \ > << "#" \ > << __FUNCTION__ \ > << " L." \ > << __LINE__ \ > << ")"; \ > Debug( s ); \ > } \ > } > > #define MED_TRC2( module, msg ) \ > { \ > string file = __FILE__; \ > string fileName = common::txt::StringHelper::LastToken(file,"\\"); \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg \ > << " (" \ > << fileName \ > << "#" \ > << __FUNCTION__ \ > << " L." \ > << __LINE__ \ > << ")"; \ > Trace2( s ); \ > } > > #define MED_INF2( module, msg ) \ > { \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg; \ > Info( s ); \ > } > > #define MED_WARN2( module, msg ) \ > { \ > string file = __FILE__; \ > string fileName = common::txt::StringHelper::LastToken(file,"\\"); \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg \ > << " (" \ > << fileName \ > << "#" \ > << __FUNCTION__ \ > << " L." \ > << __LINE__ \ > << ")"; \ > Warning( s ); \ > } > > #define MED_ERR2( module, msg ) \ > { \ > string file = __FILE__; \ > string fileName = common::txt::StringHelper::LastToken(file,"\\"); \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg \ > << " (" \ > << fileName \ > << "#" \ > << __FUNCTION__ \ > << " L." \ > << __LINE__ \ > << ")"; \ > Error( s ); \ > } > > #define MED_EXC2( module, msg ) \ > { \ > string file = __FILE__; \ > string fileName = common::txt::StringHelper::LastToken(file,"\\"); \ > ostringstream s; \ > s << "[" << module << "]\t" \ > << msg \ > << " (" \ > << fileName \ > << "#" \ > << __FUNCTION__ \ > << " L." \ > << __LINE__ \ > << ")"; \ > Exception( s ); \ > } > > namespace common > { > namespace log > { > class MEDCOMMON_API Logger : public common::app::Object > { > > > > //============================================================================= > // Constants > //============================================================================= > public: > enum LEVEL { > LEVEL_DEBUG , > LEVEL_INFO , > LEVEL_ERROR }; > > //============================================================================= > // Class attributs > //============================================================================= > public: > static bool MODE_DEBUG; > // traces > static common::container::RollingStack<string> s_traces; > > private: > static bool s_isInitialized; > > //============================================================================= > // Class methods > //============================================================================= > public: > static void SetProduct( const string & product ); > static bool IsInitialized(); > static void Init( const string & product ); > static void SetLevel( LEVEL level ); > > //============================================================================= > // Attributs > //============================================================================= > private: > > > //============================================================================= > // Constructor and destructor > //============================================================================= > private: > Logger(); > virtual ~Logger(); > > //============================================================================= > // Public methods > //============================================================================= > public: > > //============================================================================= > // Other methods > //============================================================================= > protected: > > }; > } // namespace log > } // namespace common > > #endif // _COMMON_LOG_LOGGER_H_ > > -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

1 0

Re: [boost] [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed
by Stjepan Rajko 14 Jan '08

14 Jan '08

On Jan 10, 2008 7:58 PM, Joel de Guzman <joel(a)boost-consulting.com> wrote: > Tobias Schwinger wrote: > > Joel de Guzman wrote: > >> > >> Single function: > >> > >> I'm a strong advocate of smaller is better. Modularity matters. > >> Big classes (or in this case function objects), metaprogram blobs > >> (i.e. traits), humongous enums, and all such sort of dinosours :-) > >> are best avoided. They are convenient up to a certain extent and > >> becomes unmanageable beyond a certain limit. > >> > >> In all of my use cases, I have N functions that are provided > >> elsewhere and I have no control over (e.g. parser functions). > >> I insist that this is the more common use case. Grouping > >> them into a single big struct is an unnecessary and cumbersome > >> step. > >> > >> Still, if people insist, I outlined a way to convert the big > >> function object to smaller 'bound' objects, in another post. > >> Just bind 'em into smaller function chunks. > >> > > > > I think it's a misconception to assume that a single function object > > will be inherently big. > > It's not about "big". It's about modular vs. monolithic. The > best designs, IMO, are modular. > > > It's just another degree of freedom (namely what to look up) exposed to > > the user. Whether one can appreciate it seems a matter of taste to me... > > > > > >>> A ---> B: function := L(I): functions[I]() > >>> B ---> A: transform(cases, L(I): make_pair<I>(bind(function,I()))) > > > > ...and I happen to prefer the first transform. > > I guess that reasoning is due to your thinking that the one > monolithic automation functor is more common. That's where I > disagree, vehemently(!). I've got lots of use cases that show > otherwise. I assert that the more common case is to have as > input N functions (member/free function pointers, binded > functions, boost.functions, etc) and the switch_ is used to > dispatch. > > Let me emphasize this to the strongest extent: A single monolithic > function for the cases in a switch facility is simply and utterly > wrong, wrong and wrong! :-P If the design stands as it is, I > better write my own. But it won't get my vote. > FWIW, I have a use case in which a single function is used for all the cases, but it doesn't seem monolithic. Structurally it is very similar to the example given in the proposed library's documentation - the case function looks something like this: // get_port_c behaves similarly to fusion::at_c // port_t<T> is a run-time polymorphic class derived from port // the goal of this whole thing is to return a port * (port is the base class of a run-time polymorphic class hierarchy) from an object of some type T (T is required to model a certain concept - Port) template<typename Component> struct get_port_case { typedef void result_type; template<class Case> void operator()(Case) const { ret.reset(new port_t< typename result_of::get_port_c< Component, Case::value, >::type >(get_port_c<Case::value>(c))); } get_port_case(Component& c, std::auto_ptr<port> &ret) : c(c), ret(ret) {} Component &c; std::auto_ptr<port> &ret; }; It is used like this (the number of ports is known at compile time but not at "coding time"): template<typename Component> std::auto_ptr<port> get_port(Component &c, int port_num) { std::auto_ptr<port> ret; typedef mpl::range_c< int, 0, mpl::size< typename traits_of<Component>::type::ports> ::value> range; boost::switch_<range>(port_num, detail::get_port_case<Component>(c, ret)); return ret; } "A" seems ideal for this use case. I have trouble seeing how to use "B" for it (easily) without making it so that the index is passed to the function object and allowing something like case<range>(...). But I might not be seeing all the possibilities. How can I implement this using "B"? Regardless of this example, if there isn't a "one size fits all" interface that can be implemented in a lightweight enough fashion to satisfy everyone, * should the Switch library provide both interfaces in separate functions (even if they are both implemented with their own PP)?; or * maybe the submitted library should have a different name/more clearly stated scope, as Tobias has suggested? Kudos to all of you for trying so hard at finding a solution for this! Stjepan

4 13

[Math] Feedback wanted on design issue.
by John Maddock 14 Jan '08

14 Jan '08

Hi folks I'd like some user feedback on an error-handling design issue if you're all willing :-) To the Sandbox "development" version of Boost.Math I've recently added equivalent functionality to the C99 round/trunc/modf functions: these convert floating point values to integers or to integer and fractional parts. However, there are two possible error conditions: 1) The input value is not a number (NaN). 2) The input value is outside the range of the integer type. We could handle these using the existing error handlers for domain_error's and overflow_error's respectively, but there's a problem: Users may legitimately turn off the throwing of exceptions from domain or overflow errors and prefer the functions to return NaN's and infinities instead. But this clearly wouldn't make as much sense for these particular conversion functions given that integers don't support either of these states.... So I'm tempted to add another error handler specific for integer conversion failures: the question then is whether this is starting down a slippery slope to too many error types making the library too hard to understand/use. Currently we already have: Pole Errors. Domain Errors. Overflow Errors. Underflow Errors. Denorm Errors. Internal Evaluation Errors. See http://svn.boost.org/svn/boost/trunk/libs/math/doc/sf_and_dist/html/math_to… for the details. So am I going overboard with error types, or worrying about nothing? Thanks for any thoughts/user experience you may have, Regards, John Maddock.

2 1

Trac open bugs - by assignee
by Marshall Clow 14 Jan '08

14 Jan '08

[ 195 open bugs today, 195 Friday ] If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> and a mapping of user names to "real names" can be found at: <http://svn.boost.org/trac/boost/report/16> Bug summary 18 az_sw_dude 17 dgregor 15 djowel 12 doug_gregor 12 agurtovoy 11 grafik 11 dave 11 None 8 vladimir_prus 8 jsiek 7 johnmaddock 7 anthonyw 6 rogeeff 5 witt 4 bemandawes 3 pdimov 3 nesotto 3 jmaurer 3 igaztanaga 3 ebf 3 danielw 2 urzuga 2 turkanis 2 pavol_droba 2 nasonov 2 matias 2 danieljames 2 <Blank> 1 t_schwinger 1 speedsnail 1 shammah 1 samuel_krempp 1 marshall 1 kaalus 1 hljin 1 hkaiser 1 dlwalker 1 burbelgruff 1 aaron_windsor <Blank> 1307 [lambda] invalid boostbook <Blank> 1434 Boost.Preprocessor_ small fix for the documentation None 1068 Mersenne twister disables streaming for Visual C++ None 1094 Finding the correct library to link (feature request for pkg-config support)h None 1222 lambda::ret<T> should declare result_type. None 1247 Typos in "boost/random/additive_combine.hpp"_ lines 68-69 None 1270 uniform_smallint doesn't compile with lagged_fibonacci random number generators None 1407 Boost is doesn't install on MacPorts using Leopard None 1493 SVN files making it through to install None 1515 [lambda] C4512 warnings from VC8.0 None 1544 uniform_01 w/ref template param causes ref to ref error None 1546 Method boost::random::uniform_int::operator()(engine_ value) is missing None 1548 [variant][docs]typo: formal arg_ operand_ should be v in times_two arglist aaron_windsor 778 top-level configure is broken agurtovoy 1001 gcc 4.1.2 segfaults on mpl/test/apply.cpp agurtovoy 1051 MPL header ordering triggers bug agurtovoy 1099 unable to iterate through a "non-explicitly-declared" mpl::set agurtovoy 1215 Boost 1.34.1_ mpl: Wrong workaround detection using MinGW32 (or.hpp_ line #33) agurtovoy 1317 has_xxx randomly broken in msvc agurtovoy 1469 [mpl] nested typedef of set has two different meanings agurtovoy 1476 always<> is not nullary. agurtovoy 1528 g++ 4.3.0 reports error because of redeclaration of next agurtovoy 1549 Boost.MPL: 'index_of' algorithm is not documented agurtovoy 1568 duplicate include guards agurtovoy 588 mpl::remove compile error with gcc 4.1.0 agurtovoy 640 documentation mistake anthonyw 1154 tss destruction segfaults in conjunction with dlopen/dlclose anthonyw 1168 [thread] tss crashes randomly anthonyw 1268 xtime_cmp changes to deal with overflow were reverted anthonyw 1470 Boost.Thread: Compilation errors with non-__cdecl calling convention anthonyw 1547 [thread] error C2065: 'NULL' : undeclared identifier in thread_primitives.hpp anthonyw 876 xtime documentation incomplete anthonyw 881 errors when build with Apache stdcxx az_sw_dude 1028 typo in boost header: date_time/time_defs.hpp az_sw_dude 1078 from_iso_string cannot read the output from to_iso_string az_sw_dude 1098 Urgent libboost-date-time1.33.1 : bugs on ia64 ? az_sw_dude 1147 date_time library contains global #define ERROR az_sw_dude 1160 warning: month_format shadows a member of this az_sw_dude 1162 warning: ticks shadows a member of this az_sw_dude 1289 posix_time::time_facet forgets to pass a_ref argument to base class az_sw_dude 1299 change in typedef stringstream_type in format_date_parser.hpp causing compilation error az_sw_dude 1306 invalid docbook in date_period.xml az_sw_dude 1384 Linking problem with date_time library on Visual C++ 2008 Express az_sw_dude 1386 date_time documentation Jamfile breaks building of boost docs az_sw_dude 1524 format_date_parser.hpp(221) : cannot convert parameter 1 az_sw_dude 287 wrong usage of ios_base::narrow az_sw_dude 316 date_time type conversion warning az_sw_dude 604 from_ftime incorrectly processes FILETIME filled with zeros az_sw_dude 642 operator<< for gregorian::date_duration not found az_sw_dude 889 Insane Dependencies az_sw_dude 890 date_time library supports only the current dst rule bemandawes 1378 filesystem path invalid name for hidden files (LINUX) bemandawes 1389 filesystem::ostream << boost::format generates operator ambigious error (in MSVC++) bemandawes 1458 Darwin Tiger throws std::runtime_error: locale::facet::_S_create_c_locale name not valid bemandawes 752 directory_iterator doesn't work with catch burbelgruff 1503 typeof bug (big integral constant) danieljames 1554 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support new string types. danieljames 1555 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support boost::system::error_code danielw 1044 Argument pack inaccessable in a functions return type danielw 1054 Parameter takes an "infinite" amount of time to compile with the Intel compiler. danielw 1097 keyword.hpp generates many warnings C4180: qualifier applied to function type has no meaning; ignored dave 1010 linking boost.python on freebsd dave 1019 iterator_facade::pointer should be the return type of operator-> (DR 445) dave 1085 Python rules for compiling in Mac OS X dave 1179 [boost.python] can not export a union in VC2005sp1 dave 1181 [boost.python] can modify enum value dave 1387 Review / update docs to reflect changes dave 1460 Python classes with multiple bases are convertible only to the first class in the lists dave 1482 boost::python::throw_error_already_set should be marked noreturn dave 1516 [python] Failing VC9 regression tests dave 865 Use of C++0x keyword as identifier dave 910 gcc strict-aliasing problems with python dgregor 1003 [iostreams] copy-paste error in typedefs for wchar multichar_filters dgregor 1139 [iostreams] Regex filter segfaults when zero matches found dgregor 1140 boost::iostreams linked_streambuf bug dgregor 1149 Minor doc error in basic_null_device dgregor 1164 Floyd Warshall broken with unsigned edge weights dgregor 1185 iostreams::direct_streambuf<T_Tr>::is_open always returns false if output iterator is not null dgregor 1192 [boostbook] problem when two files have the same name dgregor 1199 configure doesn't work with path containing whitespaces (MacOS X) dgregor 1232 mapped_file_source::is_open() is broken under windows dgregor 1310 [result_of] const-qualified function pointer doesn't work dgregor 1326 Unable to check graph isomorphism using LEDA adapter dgregor 1391 dominator_tree_test on Borland/CodeGear outputs overly long line dgregor 1394 Translate libs/graph/build/python/Jamfile to BBv2 dgregor 1395 Write Tests for Python Bindings dgregor 556 Bundled graph properties dgregor 732 Johnson All-Pairs needs better "no path" information dgregor 736 Const correctness violation djowel 1170 Emit Warnings instead of # symbols in the syntax highlighter djowel 1171 Quickbook title output djowel 1172 non-utf djowel 1176 Space after inline code djowel 1206 Escaping from within code? djowel 1273 CR+LF newlines in position_iterator djowel 1276 spirit problem with _GLIBCXX_DEBUG djowel 1277 Closing section like [pre with } causes Quickbok to crash djowel 1280 sections in imported source files get put inside <para> elements in docbook output djowel 1281 Quickbook produces invalid BoostBook/DocBook XML djowel 1324 tuple should have a swap() that operates element-by-element djowel 1396 wrong result_of invocation around transform_view djowel 1436 [quickbook] inline code inside headings djowel 1484 Quickbook produces illegal docbook for some docinfo fields. djowel 1500 [Spirit/Phoenix] C4512 Compiler warnings from VC8 dlwalker 613 boost/crc.hpp uses non-standard conforming syntax doug_gregor 1021 [Graph][reverse_graph] Problem using reverse_graph adapter with an adapted user defined graph doug_gregor 1076 compile error: disconnecting struct with operator()() doesn't work in VS2005 SP1 doug_gregor 375 LEDA graph adaptors do not handle hidden nodes properly doug_gregor 402 random_vertex/random_edge are unnecessarily inefficient doug_gregor 403 Document copy_component doug_gregor 447 reverse_graph and constness of property maps doug_gregor 708 Dijkstra no_init version should not require VertexListGraph doug_gregor 733 Numbered headers don't work with "preferred" syntax doug_gregor 735 Fruchterman-Reingold grid performance can be improved doug_gregor 738 Memory leaks with signal::connect? doug_gregor 829 Implicit graph not implement doug_gregor 852 Problem with Boost and GCC 4.1 ebf 1507 [variant] C4512 warnings from VC8.0 ebf 965 [doc] boost::variant tutorial - final example uses v1_v2 should be seq1_seq2 ebf 993 Variant should use least common multiple of alignments_ rather than maximum grafik 1041 Cygwin requires PATH setting. grafik 1062 Cygwin install stage fails with combination of patches grafik 1322 trac rejects patch attachment as spam grafik 1417 Regresson tests hang in Darwin (Tiger) grafik 1430 Regression fails under Cygwin grafik 1433 Trac's spam detection rejects too many valid messages grafik 1512 Broken link to vacpp in bjam docs. grafik 1513 Broken link to bcpp in bjam docs. grafik 616 Boost Jam_ and non english directorys grafik 959 linking fails when Boost is compiled with STLport 5.1.* on Linux (names mismatch) grafik 986 Problem building Python modules on boost 1.34.0 hkaiser 1079 boost-1.34.0 fails to compile. concept checks not satisfied. hljin 1522 bit_range friend decl in bit_aligned_pixel_reference.hpp needs to be fully qualified for gcc 4.3 mainline igaztanaga 1080 boost::interprocess win32 global file mapping issue igaztanaga 1210 interprocess::barrier hangs during second use under linux (boost 1.33.1) igaztanaga 1390 Interpocess: managed shared memory failing completely under OS X jmaurer 351 Diff in state of mersenne_twister gen between GCC3.41 & CW9 jmaurer 599 uniform_01 copies engine instead of using a reference jmaurer 819 uniform_int<> with type's maximum availaible range error johnmaddock 1081 Empty string rejected as perl-style regex johnmaddock 1314 Using SSE-intrinsics in VC8 causes static assert in type_with_alignment.hpp johnmaddock 1411 Fix BOOST_PARTIAL_SPECIALIZATION_EXPLICT_ARGS johnmaddock 1440 libs/config/test/link/Jamfile.v2 confuses process_jam_log johnmaddock 1446 POSIX API doesn't use C locale johnmaddock 1451 error: use of C99 long long integer constant johnmaddock 1511 Non latin symbols in regexp jsiek 1531 segfault in dynamic_bitset::reference assign operator jsiek 1540 Poisson distribution very slow for large mean (and may also overflow). jsiek 416 Spelling of Edmonds-Karp-Algorithm jsiek 575 Calling subgraph::global_to_local on a root graph jsiek 636 strange compiling problem for transitive_closure jsiek 815 remove_edge core dumps on self-circle jsiek 875 No iterator based constructor for adjacency_matrix jsiek 900 graphml reader namespace handling is broken kaalus 1184 property_tree assignment (operator) bug marshall 1252 [pool] severe overhead with unaligned sizes. matias 1406 Understanding the Tables outdated matias 1539 Missing semi-colon in random library quitck start example nasonov 1220 lexical_cast requires RTTI nasonov 754 boost::any - typeid comparison across shared boundaries nesotto 1284 [range] sub_range assignment issue nesotto 1464 boost_range_array unused in several array_size() functions nesotto 1565 iterator_range disables msvc warning 4996 pavol_droba 1152 rle_example fails pavol_droba 1385 begin must be boost-qualified pdimov 1106 shared_ptr<T> should not convert to shared_ptr<U> when T* doesn't convert to U* pdimov 1444 scoped_ptr::operator== should be equivalent to a.get()==b.get()_ but is currently !!a==!!b pdimov 779 gcc-4.2 atomicity.h location rogeeff 1383 signal.h features not found on Mac OS rogeeff 1489 BOOST_CHECK_CLOSE fails to compile with templated value type rogeeff 1542 [test] compiler errors when building with stdcxx library rogeeff 1560 Performance testing with boost::test rogeeff 1561 Using BOOST_AUTO_TEST_CASE with boost::program_options rogeeff 1566 Missing example files in documentatio samuel_krempp 859 boost::format ignores a user defined locale shammah 386 boost::pool_allocator breaks with vector of vectors speedsnail 1138 Problems with TSS and static thread library t_schwinger 1100 Building boost.function_types fails cvs rev-1.1_ no chdir command in bash turkanis 1523 [iostreams] VC8/VC9 compiler warnings turkanis 1545 [boost/rational.hpp] 'noskipws' is not a member of 'std' urzuga 574 [boost::lambda] Compile error with libstdc++ debug mode urzuga 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile vladimir_prus 1165 more quoting problems vladimir_prus 1274 Useless error message vladimir_prus 1321 invalid docbook in tool documentation vladimir_prus 1527 [program_options] Second (and subsequent) lines in tabbed text not aligned correctly vladimir_prus 1530 Program options documentation - Overview - Syntactic Information example typo vladimir_prus 1537 no value given in 'mysql_password =' vladimir_prus 469 multitoken broken vladimir_prus 689 [program_options] Endless loop with long default arguments witt 1046 Boost.Python quickstart instructions mention nonexistent target witt 583 Fixes for build on IBM pSeries for AIX and Linux witt 834 Homepage regression links witt 957 The "Getting Started" page does not mention the stdlib option witt 973 zip_iterator has value_type == reference -- -- Marshall Marshall Clow Qualcomm, Inc. <mailto:mclow@qualcomm.com> The famous British scientist, Lord Kelvin, said: "When you measure what you are speaking about and express it in numbers, you know something about it, but when you cannot (or do not) measure it, when you cannot (or do not) express it in numbers, then your knowledge is of a meagre and unsatisfactory kind."

1 0

testing , please ignore
by John Torjo 14 Jan '08

14 Jan '08

-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

1 0

[asio] subtle bug in win_iocp_io_service?
by Roland Schwarz 14 Jan '08

14 Jan '08

First I have to apologize for cross - posting, but I really do not know which is the correct list to ask this. This is a follow up to my first attempt that was of subject "Stopping active open connections". I know it would be ideal if I was able to post a code snippet that clearly shows the bug I suspect. But unfortunately I am not able to do so. The "bug" seems to be so time dependent, that I cannot manage to isolate it from my code. Instead I submit a reasoning and a fix that worked in my case. I am doing this in the hope that someone (chris possibly you ? ) can assert it really is a bug or give me a hint what I might do wrong. 1) What is happening: In code similar to the http server3 example I have one client connection open (waiting for a read) and one pending incoming connection. Shuting down the server (Ctrl-C) shows inconsistent behaviour: *) Either everything works well or *) the open connection socket gets closed, but the connection objects dtor does not get called or *) there is an access violation, with odd stack frame (somewhere from biolsp.dll ?!) 2) What change made it work for me? In the file win_iocp_io_service.hpp on line 94 in function shutdown_service I changed the timeout value from zero to 10 msec. To me the problem looks as if it was not possible to reliably find out the number of outstanding operations. Since 10 msec is as arbitrary a number as 0 I guess the proposed change is not a solution but only masking the error in a different manner. This would mean that it would be necessary to record the outstanding operations in a separate list and call the destructors on all that have not been retrieved by GetQueuedCompletionStatus. In the hope that someone cares, Roland aka speedsnail

2 3

[regex] unknown escape sequence in libs/regex/test/regress/test_perl_ex.cpp
by Boris Gubenko 14 Jan '08

14 Jan '08

regex library tests regex_regress[_threaded] fail to compile on gcc-4.2.1_hpux_ia64 because for a character string "(?<=*|\B)" gcc 4.2.1 emits a hard error "unknown escape sequence". gcc 3.4 series issues a warning, as well as EDG-based compilers. See reproducer below. The character string in question should, probably, be: "(?<=*|\\B)". Ok to change? Thanks, Boris x.cpp ----- char s[] = "\B"; bash-2.03$ g++ --version | head -1 ; g++ -c x.cpp g++ (GCC) 4.2.1 x.cpp:1: error: unknown escape sequence '\B' bash-2.03$ bash-3.00$ g++ --version | head -1 ; g++ -c x.cpp g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) x.cpp:1:12: warning: unknown escape sequence '\B' bash-3.00$ bash-2.04$ eccp --version -c x.cpp Edison Design Group C/C++ Front End, version 3.5 (Dec 20 2004 13:57:48) Copyright 1988-2004 Edison Design Group, Inc. "x.cpp", line 1: warning: unrecognized character escape sequence char s[] = "\B"; bash-2.04$

2 3

TR1 beta for MSVC 9 RTM
by Peter Dimov 13 Jan '08

13 Jan '08

http://blogs.msdn.com/vcblog/archive/2008/01/08/q-a-on-our-tr1-implementati… Sounds like some pretty nice work.

3 2

[Intel 10.1] Needs to be configured
by Beman Dawes 13 Jan '08

13 Jan '08

I'm getting this from Intel 10.1: Unknown compiler version - please run the configure tests and report the results I'm traveling for the next two days and can't do anything about it. I'd appreciate it if someone could make the needed config changes. --Beman

2 2

[random] failure of random_test on Red Hat Linux 2.6.9 ia64
by Boris Gubenko 13 Jan '08

13 Jan '08

Boost.Random library test random_test fails on linux_ia64_gcc: see <http://tinyurl.com/32hqlu> . It fails with the similar errors on Sandia-pathscale: see <http://tinyurl.com/2va9tz>. Both platforms are Red Hat Linux 2.6.9 ia64: . linux_ia64_gcc is Red Hat Linux 2.6.9-42.EL . Sandia-pathscale is Red Hat Enterprise Linux 2.6.9-34.0.2.ELsmp The test does NOT fail on Sandia-gcc-64 which is a Red Hat Enterprise Linux 2.6.18-8.el5. x.cpp below is a reduced reproducer. It passes on every platform I tried it on, including Debian GNU/Linux ia64, except Red Hat Linux 2.6.9-42.EL. On the latter, it fails for long double which is how the original test random_test fails on linux_ia64_gcc. On the platforms where it passes it outputs: *** testing float *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing double *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing long double *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** On Red Hat Linux 2.6.9-42.EL it outputs: *** testing float *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing double *** g = 1.353399e+00 g2 = 1.353399e+00 *** passed *** *** testing long double *** g = nan g2 = 1.000000e+00 *** failed *** The comment in explicit-failures-markup.xml for random_test for intel-linux-9.0 toolset says: Reported to Intel as issue 409291, and confirmed as a problem. Probably this relates to a specific Linux-Kernal or GLibC version." I'm wondering: is this problem specific to a Linux Red Hat 2.6.9 ia64 Kernal or GLibC version on this platform? Thanks, Boris x.cpp ----- #include <cmath> #include <stdio.h> #include <boost/random.hpp> template<class URNG, class Dist> void instantiate_dist(URNG& urng, const Dist& dist) { boost::variate_generator<URNG, Dist> gen(urng, dist); boost::variate_generator<URNG&, Dist> genref(urng, dist); long double g = gen(); long double g2 = genref(); printf("g = %Le g2 = %Le\n", g, g2); if ( std::abs(g - g2) < 1e-6 ) puts("*** passed ***"); else puts("*** failed ***"); } template<class T> void test() { boost::rand48 urng; urng.seed(); instantiate_dist(urng, boost::triangle_distribution<T>(1, 1.5, 7)); } int main() { puts("*** testing float ***"); test<float>(); puts("*** testing double ***"); test<double>(); puts("*** testing long double ***"); test<long double>(); }

1 2

Re: [boost] [Boost-users] Review: Switch library
by Hartmut Kaiser 13 Jan '08

13 Jan '08

Joel de Guzman wrote: > Richard wrote: > > [Please do not mail me a copy of your followup] > > > > boost(a)lists.boost.org spake the secret code > > <fmblls$ees$1(a)ger.gmane.org> thusly: > > > >> I also urge Steven to pursue the dynamic_switch idea I > posted which > >> employs perfect hashing at compile time whereby allowing > equivalent > >> or faster than a switch dispatch at runtime where the cases are > >> dynamic (instead of compile time constants). > > > > I just want to say that I think this approach is so > amazingly cool, my > > socks are not only blown off, but orbiting the planet :-). > > Yes, it's so cool. I believe it can be done. A well designed > compiler implements switch using perfect (or near perfect) > hashing anyway. Seems though that some compilers still don't. > > Here's the relevant link (with attached experiment code): > > http://lists.boost.org/Archives/boost/2004/08/69787.php FWIW, I did a lot of work related to perfect hash generation lately (up 100 million entries in the hash table) and I second Joels request. Perfect hashs are a _very_ fast alternative to sequenced if/else if chains. The beauty of this is, that it is possible to generate perfect hashs for any type of key, not only for integer values, which again is of particular interest in dynamic switch scenarios. And I'ld be happy to help with this. Regards Hartmut

1 0

Re: [boost] [Boost String Algorithms library] ireplace_all bug with character arrays
by Thorsten Ottosen 13 Jan '08

13 Jan '08

shunsuke skrev: > Richard Turrin wrote: >> Hi, >> >> I've encountered a bug with ireplace_all from the Boost String Algorithms library for version 1.35. If I pass a character array for the Format argument, the function ignores the null terminator and instead uses the entire array minus the last character to replace the occurrences of the Search string in the Input parameter. However, if I provide a pointer to a character array, the string replacement is done as expected. >> >> When I stepped into the code, I came across the following lines (excerpt from /trunk/boost/range/as_literal.hpp): >> >> template< class Char, std::size_t sz > >> inline iterator_range<const Char*> as_literal( const Char (&arr)[sz] ) >> { >> return boost::make_iterator_range( arr, arr + sz - 1 ); >> } >> >> There is no check for a null terminator. Nor did I find one after this function returned. I think the author here assumed that a caller would always pass in a character array of the right size. > > Character array seems to have three views. > > 1. array: SIZE("ab\0c") == 5; > 2. literal: SIZE("ab\0c") == 4; > 3. null-terminated: SIZE("ab\0c") == 2; > > Both 2. and 3. is forced into boost::as_array. > "One name, two facilities" usually makes trouble. > IMO, `as_c_str` should have been added for 3. I agree we could add a new function. Can we come up with a better name than as_c_str()? Or should we simply make as_literal() scan the array? -Thorsten

1 0

Re: [boost] Review: Switch library
by Joel de Guzman 13 Jan '08

13 Jan '08

Tobias Schwinger wrote: > Joel de Guzman wrote: >> Richard wrote: >>> [Please do not mail me a copy of your followup] >>> >>> boost(a)lists.boost.org spake the secret code >>> <fmblls$ees$1(a)ger.gmane.org> thusly: >>> >>>> I also urge Steven to pursue the dynamic_switch idea I posted >>>> which employs perfect hashing at compile time whereby allowing >>>> equivalent or faster than a switch dispatch at runtime where >>>> the cases are dynamic (instead of compile time constants). >>> I just want to say that I think this approach is so amazingly cool, my >>> socks are not only blown off, but orbiting the planet :-). >> Yes, it's so cool. I believe it can be done. A well designed >> compiler implements switch using perfect (or near perfect) >> hashing anyway. Seems though that some compilers still >> don't. > > Another interesting approach could be "adaptive switch" as explained here: > > http://osdir.com/ml/parsers.spirit.devel/2006-05/msg00025.html > > (a self-optimizing alternative parser). Maybe it can be combined with > hashing techniques. Yeah, it's a very interesting idea! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

Re: [boost] Review: Switch library
by Joel de Guzman 13 Jan '08

13 Jan '08

Joel de Guzman wrote: >> And finally, every review should answer this question: >> >> * Do you think the library should be accepted as a Boost library? >> Be sure to say this explicitly so that your other comments don't >> obscure your overall opinion. > > Not at the moment. I think we need a more thorough discussion on > alternative interfaces. We also need to discuss the issues > that were raised in the review. I'm eager to hear Steven's > replies. He seem to be a bit too quiet? > > I'm really tempted to say "yes" and let Steven address the concerns > raised (including mine). I'm very confident in Steven's abilities. > He's one of those who still gives me the "oooh" feeling with his > code. And, I really *NEED* such a switch utility now and not later. > > So, please take this as a soft "no" vote for now. I encourage > Steven to get more involved in the discussion and consider > all the issues raised. As soon as these matters are ironed out, > fire up another review ASAP. Oh, perhaps I'd like to ask a review extension. If Steven can reply to my concerns and is willing to address them, I might still change my vote to a yes. I really need this facility now! Bottom line: more discussion please! This is a small library, yet it is (to me) very important. Let's get the design correct. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 3

Re: [boost] [Range] Misc comments
by bwood 13 Jan '08

13 Jan '08

Thorsten Ottosen wrote: >brass goowy skrev: >> utility_class.html says, "Recall that many default >> constructed iterators are singular..." >> >> I didn't find other uses of the word singular in the >> documentation and am not sure what you mean. Are you >> saying they are not meant to be range endpoints? > > From the standard 24.1: > >"Iterators can also have singular values that are >not associated with any container. [ Example: After the declaration of >an uninitialized pointer x (as with int* x;), x >must always be assumed to have a singular value of a pointer. ?end >example ] Results of most expressions are undefined >for singular values; the only exceptions are destroying an iterator that >holds a singular value and the assignment of a >non-singular value to an iterator that holds a singular value. In this >case the singular value is overwritten the same way >as any other value. Dereferenceable values are always non-singular." > OK, thanks. >> I think the "sub" in the class name sub_range is kind of >> misleading. The documentation has the following: >> "Imagine that we have an algorithm that searches for a >> sub-string in a string. The result is an iterator_range, >> that delimits the match. We need to store the result from >> this algorithm. Here is an example of how we can do it with >> and without sub_range >> >> std::string str("hello"); >> iterator_range<std::string::iterator> ir = find_first( str, "ll" ); >> sub_range<std::string> sub = find_first( str, "ll" );" >> >> The docs also say, "The iterator_range class is templated on an >> Forward Traversal Iterator and should be used whenever fairly >> general code is needed. The sub_range class is templated on an >> Forward Range and it is less general, but a bit easier to use >> since its template argument is easier to specify. The biggest >> difference is, however, that a sub_range can propagate >> constness because it knows what a corresponding const_iterator is." >> >> The sample code that has a sub-string with either an >> iterator_range or sub_range and the description of the >> two classes don't give much basis for sub being in the >> name. > >So you would just call it range? Possible, but difficult to do now. > I prefer range to sub_range. It isn't that important to me, but I suggest you make some comment in the documentation about the matter. That might lead to some further ideas. >> I didn't find anything about serialization in the docs. >> iterator_range has an operator<<, but understandably no >> operator>>. Do you plan to add something in this area? > >No. Don't Boost.Serialization have support for serializing a [begin,end) >range? Not to my knowledge. Even if B.Ser had that, I think using it would require what you are encouraging people to get away from with the Range library: passing around iterators. Brian Wood Ebenezer Enterprises www.webebenezer.net

1 0

Switch library review - summary of discussion so far
by Stjepan Rajko 12 Jan '08

12 Jan '08

I will try to summarize the discussions happening so far on the Switch library under review - maybe this will be helpful to those considering joining the discussion and submitting a review. * Documentation All reviewers have noted that the documentation could be improved - e.g., additional examples, performance stats, as well as more explanation of the types involved and how they are used. * Return type Tobias Schwinger suggested that the return type should be specified explicitly in the switch_ call, rather than inferring it from the function object, and this is now a part of the recent designs being discussed. Joel de Guzman also suggested that if a version of switch_ should infer the return type, that return type should be a Boost.Variant of the types returned by each of the cases. * Default default behavior If the default behavior is left unspecified, switch_ should invoke the default constructor of the return type in the default case, rather than throwing an exception. This was suggested by Tobias Schwinger after the issue was raised by Dan Marsden. Alexander Nasonov has also indicated that a throwing default case can cause inefficiency, even when it is guaranteed not to be invoked. * Fall-through Alexander Nasonov pointed out the lack of fall-through capability in the submitted implementation. Fall-through has been incorporated into the recent designs being discussed. * Allowing void-returning function objects for the default case with a non-void returning switch Tobias Schwinger mentioned the possibility of allowing default case function objects of void return type even when the switch return type is non-void, as long as the function object call does not return. This would be useful, for example, if the function object is guaranteed to throw. There is still some discussion on whether determining if the return type is void can be done efficiently. * Design There has been a lengthy discussion on the underlying design of the library, what it should offer, and whether the name of the library is appropriate. There are two types of designs that have been put forward as being appropriate and/or necessary for a Boost.Switch library. On one hand, there is the submitted design (labeled "A" in recent postings), which takes the switch cases in an MPL sequence and a single function object containing implementations of all cases. Joel de Guzman has proposed another design (labeled "B"), in which the switch cases are specified separately and allow a different function to be used for each case. Design "A" is better suited for situations in which the number of cases is determined by a compile time constant, while "B" is more appropriate for many use cases, and provides more flexibility and a more familiar syntax. It seems that a consensus has been reached that this library could offer either both interfaces in different layers, or an interface that can be used in different ways for different uses (based on a common concept capturing case sequences). (Apologies if I have missed or misinterpreted something) More reviews/votes would be extremely welcome! Regards, Stjepan

2 2