- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1498778 ] operator<< for gregorian::date_duration not found
by SourceForge.net 01 Jun '06

01 Jun '06

Bugs item #1498778, was opened at 2006-06-01 12:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1498778&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: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zak Kipling (zak-k) Assigned to: Jeff Garland (az_sw_dude) Summary: operator<< for gregorian::date_duration not found Initial Comment: The operator<< for boost::gregorian::date_duration (aka gregorian::days) is not found by name lookup. This appears to be because: * boost::gregorian::date_duration is a typedef to: boost::date_time::date_duration< boost::gregorian::date_duration_rep > where boost::gregorian::date_duration_rep is a typedef to boost::date_time::duration_traits_adapted (defined in date_time/gregorian/greg_duration.hpp) * operator<< for boost::gregorian::date_duration) is defined in the gregorian namespace (defined in date_time/gregorian/gregorian_io.hpp) However, since only the typedef names are in the gregorian namespace, argument-dependent lookup doesn't find it there unless you add: using gregorian::operator<<; to your code, after which the operator works as expected. This occurs for me using both gcc 3.4.5 and 4.0.3, and both with Boost 1.33.1 and current CVS trunk. A possible solution would be to either move the definition of operator<< to the date_time namespace, or pull it into that namespace with a using declaration. I haven't checked all the other gregorian types, but it's possible that similer problems exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1498778&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Random: exponential_dsitribution requires a [0, 1) engine?
by Alan Stokes 01 Jun '06

01 Jun '06

Maybe I'm missing something, but the implementation of the exponential dsitribution looks like this: template<class Engine> result_type operator()(Engine& eng) { return -result_type(1) / _lambda * log(result_type(1)-eng()); } That seems to assume that the Engine has a rane of [0, 1). Certainly if I pass it in (say) a mt19937 engine it goes rather badly wrong, attempting to take the log of a large negative number. But the documentation contains no such requirement - it merely says it needs a UniformRandomNumberGenerator, which explicitly allows for any range. - Alan

1 0

[tr2][filesystem][asio] header <boost/system_error.hpp> roadmap?
by Beman Dawes 01 Jun '06

01 Jun '06

The Filesystem proposal accepted by the C++ committee's LWG for TR2 includes components for reporting system errors from library functions that depend on operating system API's. There are error_code and system_error classes, four free functions, etc. They will go in a TR2 header named <system_error>. Presumably for Boost it will be called <boost/system_error.hpp> or similar. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Diagnost… Boost.Filesystem is the first Boost library to use <boost/system_error.hpp>. Chris Kohlhoff is planning to use it in asio, and has suggested improvements that I'll incorporate. Presumably the header will be used by other Boost libraries in the future. What should the roadmap be for moving this header into Boost? Should it be a separate library? Seems smallish for that. Does it need a formal review? A mini-review? Is it OK if I put in CVS now in boost/detail? Opinions? --Beman

3 2

Bug list status
by Marshall Clow 01 Jun '06

01 Jun '06

Low point: 54 bugs Time before: 60 bugs Last time: 61 bugs Today: 66 bugs Let's try to knock these bugs down for 1.34! If anyone would like to integrate the "Fixes for build on IBM pSeries for AIX and Linux" currently assigned to "Nobody", please let me know! [ In fact, please take a look at the "nobody" bugs, and let me know where they should be assigned ] If you think that a bug has been assigned incorrectly, please let me know. Thanks! Bug counts per assignee: Nobody 8 Jeff Garland (az_sw_dude) 7 Jeremy Siek 6 Doug Gregor 5 Stephen Cleary (shammah) 5 Beman Dawes 3 Eric Friedman (ebf) 3 Mike Glassford 3 Samuel Kremp 3 John R. Bandela 2 Joel de guzman (djowel) 2 Jens Maurer 2 Thorsten Ottosen (nesotto) 2 Rene Rivera (grafik) 2 Roland Schwarz (speedsnail) 2 Jonathan Turkanis 2 Marshall Clow 1 Aleskey Gurtovoy (agurtovoy) 1 Kevlin Henney 1 Hubert Holin 1 Jaakko Jurvi (urzuga) 1 John Maddock 1 Vladimir Prus 1 Daniel Wallin 1 Darryl Walker 1 Here are the bugs, sorted by assignee: Assignee: agurtovoy <http://sourceforge.net/users/agurtovoy/> Summary: mpl::remove compile error with gcc 4.1.0 Bug #: 1453180 <http://sourceforge.net/tracker/index.php?func=detail&aid=1453180&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: wrong usage of ios_base::narrow Bug #: 989487 <http://sourceforge.net/tracker/index.php?func=detail&aid=989487&group_id=75…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: date_time type conversion warning Bug #: 1069225 <http://sourceforge.net/tracker/index.php?func=detail&aid=1069225&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: local_adjustor::utc_to_local throws 'Time label invalid' Bug #: 1220011 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220011&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: bjam don`t copy lib & dll files to stage Bug #: 1402743 <http://sourceforge.net/tracker/index.php?func=detail&aid=1402743&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: from_ftime incorrectly processes FILETIME filled with zeros Bug #: 1471025 <http://sourceforge.net/tracker/index.php?func=detail&aid=1471025&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: time_from_string silently misreads date Bug #: 1482703 <http://sourceforge.net/tracker/index.php?func=detail&aid=1482703&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: memory leak with boost::gregorian::date_facet Bug #: 1486232 <http://sourceforge.net/tracker/index.php?func=detail&aid=1486232&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: linker error mingw 3.4.5 Bug #: 1426819 <http://sourceforge.net/tracker/index.php?func=detail&aid=1426819&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: VC8 can't find windows.h even though environment is correct! Bug #: 1468124 <http://sourceforge.net/tracker/index.php?func=detail&aid=1468124&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: Log level names wrong in documentation Bug #: 1475886 <http://sourceforge.net/tracker/index.php?func=detail&aid=1475886&group_id=7…> Assignee: daniel_wallin <http://sourceforge.net/users/daniel_wallin/> Summary: [Parameter] Docco error section 2.7.2 Bug #: 1378446 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378446&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: LEDA graph adaptors do not handle hidden nodes properly Bug #: 1168431 <http://sourceforge.net/tracker/index.php?func=detail&aid=1168431&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: random_vertex/random_edge are unnecessarily inefficient Bug #: 1204684 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204684&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Document copy_component Bug #: 1204688 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204688&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: reverse_graph and constness of property maps Bug #: 1246336 <http://sourceforge.net/tracker/index.php?func=detail&aid=1246336&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Bundled graph properties Bug #: 1420498 <http://sourceforge.net/tracker/index.php?func=detail&aid=1420498&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Miss ' = ParserT()' Bug #: 907299 <http://sourceforge.net/tracker/index.php?func=detail&aid=907299&group_id=75…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: spirit insert_key_actor.hpp Bug #: 1059936 <http://sourceforge.net/tracker/index.php?func=detail&aid=1059936&group_id=7…> Assignee: dlwalker <http://sourceforge.net/users/dlwalker/> Summary: boost/crc.hpp uses non-standard conforming syntax Bug #: 1478435 <http://sourceforge.net/tracker/index.php?func=detail&aid=1478435&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: boost::blank - missing operators Bug #: 1191356 <http://sourceforge.net/tracker/index.php?func=detail&aid=1191356&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: [variant] Bug in recursive_wrapper_fwd.hpp Bug #: 1359257 <http://sourceforge.net/tracker/index.php?func=detail&aid=1359257&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: ambiguous overloads in boost::variant source code Bug #: 1456780 <http://sourceforge.net/tracker/index.php?func=detail&aid=1456780&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: condition::timed_wait doesnt take amount of time to wait Bug #: 1468789 <http://sourceforge.net/tracker/index.php?func=detail&aid=1468789&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: object destructor called four times when using thread Bug #: 1477354 <http://sourceforge.net/tracker/index.php?func=detail&aid=1477354&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: USES_CONVERSION is used in once.cpp Bug #: 1489362 <http://sourceforge.net/tracker/index.php?func=detail&aid=1489362&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost jam problem with parallel builds Bug #: 1234224 <http://sourceforge.net/tracker/index.php?func=detail&aid=1234224&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost.build needs fixes for HP/UX Bug #: 1395924 <http://sourceforge.net/tracker/index.php?func=detail&aid=1395924&group_id=7…> Assignee: hubert_holin <http://sourceforge.net/users/hubert_holin/> Summary: Cannot compile octonion_test.cpp because of bug in sinc.hpp Bug #: 751289 <http://sourceforge.net/tracker/index.php?func=detail&aid=751289&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Compiler error for tokenizer on Solaris Bug #: 976241 <http://sourceforge.net/tracker/index.php?func=detail&aid=976241&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: token_iterator::at_end() result is inversed Bug #: 1338326 <http://sourceforge.net/tracker/index.php?func=detail&aid=1338326&group_id=7…> Assignee: jmaurer <http://sourceforge.net/users/jmaurer/> Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Bug #: 1115124 <http://sourceforge.net/tracker/index.php?func=detail&aid=1115124&group_id=7…> Assignee: jmaurer <http://sourceforge.net/users/jmaurer/> Summary: uniform_01 copies engine instead of using a reference Bug #: 1464566 <http://sourceforge.net/tracker/index.php?func=detail&aid=1464566&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Adding boost::is_complex to type_traits.hpp Bug #: 1315712 <http://sourceforge.net/tracker/index.php?func=detail&aid=1315712&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: invalid result for File Dependency Examp Bug #: 551110 <http://sourceforge.net/tracker/index.php?func=detail&aid=551110&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Spelling of Edmonds-Karp-Algorithm Bug #: 1226292 <http://sourceforge.net/tracker/index.php?func=detail&aid=1226292&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: g++ v3.2.3 inker error for read_graphviz ih boost v1.33.1 Bug #: 1378907 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378907&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Calling subgraph::global_to_local on a root graph Bug #: 1444271 <http://sourceforge.net/tracker/index.php?func=detail&aid=1444271&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Calling subgraph::global_to_local on a root graph Bug #: 1444293 <http://sourceforge.net/tracker/index.php?func=detail&aid=1444293&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: strange compiling problem for transitive_closure Bug #: 1489545 <http://sourceforge.net/tracker/index.php?func=detail&aid=1489545&group_id=7…> Assignee: kevlin <http://sourceforge.net/users/kevlin/> Summary: lexical_cast & pure virtual functions & VC 8 STL Bug #: 1358600 <http://sourceforge.net/tracker/index.php?func=detail&aid=1358600&group_id=7…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: Solaris - once.cpp compile error Bug #: 549162 <http://sourceforge.net/tracker/index.php?func=detail&aid=549162&group_id=75…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: boost.range and 'const char[]'. Bug #: 1272315 <http://sourceforge.net/tracker/index.php?func=detail&aid=1272315&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: [Boost.Range]boost::const_begin calls non-qualified 'begin' Bug #: 1361686 <http://sourceforge.net/tracker/index.php?func=detail&aid=1361686&group_id=7…> Assignee: nobody Summary: Fixes for build on IBM pSeries for AIX and Linux Bug #: 1446471 <http://sourceforge.net/tracker/index.php?func=detail&aid=1446471&group_id=7…> Assignee: nobody Summary: Non-basic-source-character-set characters conflict with MSVC Bug #: 1461533 <http://sourceforge.net/tracker/index.php?func=detail&aid=1461533&group_id=7…> Assignee: nobody Summary: Boost Jam, and non english directorys Bug #: 1480900 <http://sourceforge.net/tracker/index.php?func=detail&aid=1480900&group_id=7…> Assignee: nobody Summary: Numeric Conversion Documentation minor bug Bug #: 1480954 <http://sourceforge.net/tracker/index.php?func=detail&aid=1480954&group_id=7…> Assignee: nobody Summary: insignificant boost::array bug Bug #: 1484104 <http://sourceforge.net/tracker/index.php?func=detail&aid=1484104&group_id=7…> Assignee: nobody Summary: bug in boost::range_detail Bug #: 1484477 <http://sourceforge.net/tracker/index.php?func=detail&aid=1484477&group_id=7…> Assignee: nobody Summary: program_options: format_paragraph assert fails on long line Bug #: 1485069 <http://sourceforge.net/tracker/index.php?func=detail&aid=1485069&group_id=7…> Assignee: nobody Summary: boost 1.33.1 build error Bug #: 1487256 <http://sourceforge.net/tracker/index.php?func=detail&aid=1487256&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: format: assert when parsing invalid pattern Bug #: 1326132 <http://sourceforge.net/tracker/index.php?func=detail&aid=1326132&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: boost::format parse method doesn't work Bug #: 1439607 <http://sourceforge.net/tracker/index.php?func=detail&aid=1439607&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: 64 bit compile warning/error for boost::format Bug #: 1451470 <http://sourceforge.net/tracker/index.php?func=detail&aid=1451470&group_id=7…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: ct_gcd_lcm.hpp compilation error Bug #: 558174 <http://sourceforge.net/tracker/index.php?func=detail&aid=558174&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: pool::purge_memory() does not reset next_size Bug #: 984124 <http://sourceforge.net/tracker/index.php?func=detail&aid=984124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: Borland compiler error with Pool, boost::pool_allocator Bug #: 988124 <http://sourceforge.net/tracker/index.php?func=detail&aid=988124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: perfomance: memory cleanup for pool takes too long Bug #: 995270 <http://sourceforge.net/tracker/index.php?func=detail&aid=995270&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: boost::pool_allocator breaks with vector of vectors Bug #: 1179641 <http://sourceforge.net/tracker/index.php?func=detail&aid=1179641&group_id=7…> Assignee: speedsnail <http://sourceforge.net/users/speedsnail/> Summary: BCB6 throw EExternelException Bug #: 596149 <http://sourceforge.net/tracker/index.php?func=detail&aid=596149&group_id=75…> Assignee: speedsnail <http://sourceforge.net/users/speedsnail/> Summary: Exception safety in class \'thread\' Bug #: 1305885 <http://sourceforge.net/tracker/index.php?func=detail&aid=1305885&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational operator&lt; can overflow Bug #: 798357 <http://sourceforge.net/tracker/index.php?func=detail&aid=798357&group_id=75…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: problem with boost::iostreams when compiled with Visual C++ Bug #: 1365752 <http://sourceforge.net/tracker/index.php?func=detail&aid=1365752&group_id=7…> Assignee: urzuga <http://sourceforge.net/users/urzuga/> Summary: [boost::lambda] Compile error with libstdc++ debug mode Bug #: 1444052 <http://sourceforge.net/tracker/index.php?func=detail&aid=1444052&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: multitoken broken in program_options 1.33 Bug #: 1266877 <http://sourceforge.net/tracker/index.php?func=detail&aid=1266877&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

4 3

Re: [boost] Infinite precision integer draft
by Sohail Somani 31 May '06

31 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Bronek Kozicki > Sent: Wednesday, May 31, 2006 3:12 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Infinite precision integer draft > > Maarten Kronenburg wrote: > > For using mixed expressions with > > different types, run-time polymorphism > > is required. > > does the library need something that runtime-polymorphism > delivers and that > cannot be done with templates? Not that I'm such a big fan of > templates, but > they proved useful. Maybe not that much in domain-specific > applications, but > in interface part of many libraries they work pretty well > (Boost is good > example here). I'd also argue that they usually proved more > extensible than > libraries designed around OOP. Actually pretty useful in domain specific libraries (I guess applications applies too).

1 0

[BGL] Fruchtermann-Reingold: grid
by Jens Müller 31 May '06

31 May '06

My questions are concerning this part: > std::size_t adj_start_row = row == 0? 0 : row - 1; > std::size_t adj_end_row = row == rows - 1? row : row + 1; > std::size_t adj_start_column = column == 0? 0 : column - 1; > std::size_t adj_end_column = column == columns - 1? column : column + 1; > for (std::size_t other_row = adj_start_row; other_row <= adj_end_row; > ++other_row) > for (std::size_t other_column = adj_start_column; > other_column <= adj_end_column; ++other_column) > if (other_row != row || other_column != column) { > // Repulse vertices in this bucket > bucket_t& other_bucket > = buckets[other_row * columns + other_column]; > for (v = other_bucket.begin(); v != other_bucket.end(); ++v) > apply_force(*u, *v); > } In the code above, where repelling forces inside a bucket are computed, each pair of nodes is considered only once, and then apply_force(*u, *v); apply_force(*v, *u); are called. Wouldn't something like this be more efficient here, too? We have +------+------+------+ | | | | | 1 | 2 | 3 | | | | | |------|------|------| | | | | | 4 | X | 6 | | | | | |------|------|------| | | | | | 7 | 8 | 9 | | | | | +------+------+------+, where X is the bucket u resides in, and the others are the adjacent buckets considered. For every u, all nodes from all other buckets are considered. My proposal: Consider only 1, 2, 3 and 4 and do apply_force(*u, *v); apply_force(*v, *u); again 6, 7, 8 and 9 will be considered when those buckets are processed. Shouldn't this be (at least a bit) more efficient?

2 4

Re: [boost] [array] optional constructors in Boost.Array
by Martin Bonner 31 May '06

31 May '06

Thorsten Ottosen wrote: > Maybe you should just wrap boost::array: > > template< class T, unsigned N > > struct my_array : boost::array<T,N> > { > // provide constructors here How? > }; You can't construct the base boost_array in the base class initialization list of the constructor (because boost_array doesn't have a constructor that takes arguments), and by the time you get into the body of the my_array constructor it is too late - the boost_array is already default constructed. Having said which, personally I think that a seperate class with constructors would be better than adding another template class to boost::array. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

6 12

[format] %d with char types
by Luke Elliott 31 May '06

31 May '06

I previously posted this to the users group (http://search.gmane.org/search.php?group=gmane.comp.lib.boost.user&query=%5…) with no response - I thought I'd try here before giving up, so sorry for repeating myself... Anyway, using %d, %u etc. with char types prints the character rather than the integral value. I've had a quick hack around with the code, adding the following to feed_args.hpp: template< class Ch, class Tr> inline void put_last( BOOST_IO_STD basic_ostream<Ch, Tr> & os, const char& x ) { if (os.flags() & (std::ios_base::dec | std::ios_base::hex | std::ios_base::oct)) os << static_cast<int32_t>(x); else os << x ; } (ditto for unsigned char) and modding internals.hpp: template<class Ch, class Tr> inline void stream_format_state<Ch,Tr>:: reset(Ch fill) { // set our params to standard's default state. cf § 27.4.4.1 of the C++ norm width_=0; precision_=6; fill_=fill; // default is widen(' '), but we cant compute it without the locale flags_ = std::ios_base::skipws; // the adjust_field part is left equal to 0, which means right. exceptions_ = std::ios_base::goodbit; rdstate_ = std::ios_base::goodbit; } (i.e. remove std::ios_base::dec from flags_) 'works' (vc71) for the very few limited cases I've tried. I'm sure that's horribly broken for any number of reasons, but I'm more interested in whether this is considered a problem or not? It seems a shame to have to cast arguments to format if they happen to be char and %d is specified in the format string (also obviously making writing generic code more difficult!). Thanks in advance Luke Elliott.

1 0

Re: [boost] Endian library - request for comments
by Benaka Moorthi 31 May '06

31 May '06

Beman Dawes wrote: I think the names for the types might be a little bit too cute. "bin" makes me think binary, not signed big-endian. That being said, I'm not sure I have any good name that isn't far too verbose. unsigned_littleendian_aligned<4> is admittedly starting to push convenience, though bigendian<5> isn't too bad. I'm often amazed at the clever names Boosters suggest, so I think it is worthwhile to speculate a bit about better names. But the everyday use typedefs really do need to be short and memorable. I've been using the "bin2", "bun3", etc. since 1984 or so, with several hundred programmers now using them all the time, and never had a request to change the names. How about using namespaces: namespace endian { namespace big { typedef ... unum1; typedef ... snum1; ... } namespace little { typedef ... unum1; typedef ... snum1; ... } typedef big::unum1 bun1; typedef big::snum1 bin1; ... } -- http://www.fastmail.fm - Does exactly what it says on the tin

1 0

Re: [boost] Infinite precision integer draft
by Jarrad Waterloo 31 May '06

31 May '06

Sorry for confusing us both! When I say heap I was referring to memory allocated dynamically via the POSIX methods or C++ new/delete. Although the majority of my background has been in a Win32 environment when I deal with standard C++ and boost the word Microsoft doesn't enter into my vocabulary. I was working/speaking under the mistaken assumption that each instance of integer has its own allocator by type as in the standard library or at runtime as many but not all wish it. As such I thought integer_allocator was an interface or close to one and there was a separate class that implements that interface or abstract class that had the code for the dynamic memory allocations. I totally missed the following sentences in the spec. > The abstract class integer allocator provides the interface to provide a > user-defined derived allocator class for class integer. Classes derived > from this class can only be used as static allocators for other classes > derived from class integer. > Makes the static allocator active for all integer memory allocations. What I was hoping to be able to do was something like this? integer<stack_allocator<T> > or integer(stack_allocator<T>) or integer<T> where T is the minimum number of bits, minimum number of bytes or minimum number of longs (bits may be better as the internal implementation may very from processor to processor). The implementation is simple because the size of the stack_allocator or stack_integer is allocated at compile time on the stack. As allocate will just return the already allocated memory and deallocate will do nothing. The demand for this is the need/preference for large finite precision numbers. Currently C++ provides the ability to work with small finite numbers and integer provides infinite precision numbers. This addition would fill in the gap between the two with many of the strength and advantages of both worlds without negating the need to be able to go to either extreme. Your code is capable of filling this gap it just needs the ability to limit itself to stack operations on a per instance basis. This request is similar to the differences between std::bitset<T> and boost::bitset. Sure boost::bitset can do everything std::bitset can do but users will still use std::bitset for efficiency when they know the size up front since it is created on the stack and the other is dynamically allocated. Users just want the two to have a common base class which can't currently be done as that will change the std. However as yours is a new library, I was hoping it would handle this need and do it correctly from the beginning. With the current design how would one do this? Deriving from integer_allocator is straight forward but what must one do to a derived integer to use this new allocator? If you do concur that this is a need wouldn't it be good to go ahead and provide an implementation of stack_integer and stack_integer_allocator that can do this so users don't have to keep reinventing the wheel. Further could there be any changes to the allocator architecture to make things easier not from its interface standpoint but from from how it is used and stored to get better reuse especially with all this talk on unsigned integer and modulus integer. I would hate to see stack variants for all three. -----Original Message----- From: Maarten Kronenburg [mailto:M.Kronenburg@inter.nl.net] Sent: Tuesday, May 30, 2006 3:46 PM To: Jarrad Waterloo Subject: Re: Infinite precision integer draft Jarrad, Thanks for your reply. The default integer_allocator used by integer use the standard POSIX malloc, realloc and free functions. You are right that I should add this remark to the spec document. The making of a heap_allocator is trivial, using HeapCreate and HeapDestroy, and HeapAlloc, HeapReAlloc and HeapFree. But this only works on Win32 systems, so this cannot be added to the spec. Your stack_integer_allocator<size_t>, how would that allocate, reallocate and deallocate look like? Do you have such an implementation ? Or a literature reference where I can find it ? When I have an implementation, then I feel safe to add it to the spec. Regards, Maarten. ----- Original Message ----- From: "Jarrad Waterloo" <jwaterloo(a)dynamicquest.com> To: "'Maarten Kronenburg'" <M.Kronenburg(a)inter.nl.net>; <boost(a)lists.boost.org> Sent: Tuesday, May 30, 2006 5:12 PM Subject: RE: Infinite precision integer draft > Thanks for the welcome of all the other enhancements, especially in the area > of conversion, to make your integer library easy to use for everyone. > > Further, don't get discouraged as your colleagues discuss the meaning of 0, > life and the universe while people who actually would use it already > understand what 0 means because we have been without, 0, this library for so > long. > > 'Feed a mouse a cookie and he will ask for a glass of milk.' > > > Creating integers with variable size on the stack, > > that is in any case something that I will not > > specify, but users that want to use these tricks > > can just override the integer_allocator. > > Currently you have an integer class which takes an integer_allocator base > class. Even though the spec doesn't mention this or I glossed over reading > it but you probably are going to provide a heap_integer_allocator class that > could be named whatever but exists as the default integer_allocator for the > integer class. This way users can just start using the library right away > instead creating there own allocator the first time they use this library. > > What I was suggesting was not a change to the integer, integer_allocator > base class or the currently unnamed heap_integer_allocator! Rather the > addition of a stack_integer_allocator<size_t> : public integer_allocator. > > The reasons for the library to provide this instead of the end user is as > follows: > 1) Performance, stack based allocations are faster than heap based and in > some field domains one will know the upper limit on size. This generates the > need for multiple people wanting to do this especially when performance > matters. > 2) Standardization, if you foresee that many people are going to need this > functionality than your library becomes easier because you can go ahead and > provide the class instead of a large unsigned integer of people having to > reinvent the wheel and create the exact same class themselves. > 3) Maintain ease of use as complexity increases, in just this one area this > library could suffer from the opposite problem of the standard library. The > standard library algorithms was all passing 2 iterators around which allows > for maximum flexibility for more complicated scenarios but lacked the > overrides like boost Range where you could pass the collection and the > algorithm uses begin and end for the more common and simple scenarios. > Integer library does the opposite which is mostly good, it provides the heap > allocator for the most common and general use but as complexity increases > and someone needs stack based allocator the user is left in the lurch and > have to right there own, over and over again from user to user. I just > believe this library would be more feature complete if it would just go > ahead and provide the both implementations up front. > 4) Architectural consistency, this library is designed to behave like > existing integer types that can be created both on the stack and on the > heap. > > > > >

3 2