- Boost - lists.preview.boost.org

Boost.Tests: Unit test defines own main() function, why?
by Jens Seidel 17 Jan '08

17 Jan '08

Hi, I would like to know why Boost's unit test framework requires that the user defines init_unit_test_suite(int, char**) (or with char *[] argument???) instead of main(). I recently had again some trouble because of it: * It broke the general autoconf test in boost.m4 as the existance of a Boost library can normally easily be tested by using boost code in main() and not init_unit_test_suite(). (Will probably be fixed soon in boost.m4.) * According to http://lists.boost.org/Archives/boost/2007/05/121601.php linkers don't look into libraries (either static or dynamic) to find main so that unit tests cannot be cimpiled as shared library. * I noticed that Debian's Boost library doesn't work for me as main() is not found in the shared library (but in the static one). I found now beside my bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456863 also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432921 which mainly refers to the link above. I'm not sure whether my problem is an error in Debian's packages or not but I ask why is main handled differently in Boost.test? Wouldn't it be sufficient to ask the user simple to start init_unit_test_suite() from a user specified main() to make most problems go away? Maybe it would be even OK to just start init_unit_test_suite() in the constructor of a static variable (yes, I know that the initialisation order may cause trouble with other static data). http://www.boost.org/libs/test/doc/faq.html doesn't explain it! I will now use ifdef's to easily allow using boost/test/included/unit_test.hpp as alternative to the library. Jens

10 52

[interest] Egg, function object builders and adaptors
by shunsuke 17 Jan '08

17 Jan '08

Hi, all. In a recent discussion, a library named Egg possibly left a good impression on boosters, so I propose it. Introduction: It is not so easy to define FunctionObjects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Helpers to build FunctionObject: * egg::function and egg::function_facade provides the way to build FunctionObject which supports Boost.ResultOf and Lambda. * FunctionObject Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse emulates variadic templates in very limited way. * etc... The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda The document is on line: http://p-stade.sourceforge.net/boost/libs/egg/ svn repository: https://p-stade.svn.sourceforge.net/svnroot/p-stade/trunk/boost Tested under: trunk and Boost1.34.1. An example of currying in Egg: int plus(int x, int y) { return x + y; } typedef result_of_curry2<int (*)(int, int)>::type T_curried_plus; T_curried_plus const curried_plus = BOOST_EGG_CURRY2(&::plus); void test() { BOOST_CHECK( curry2(&::plus)(4)(9) == 13 ); BOOST_CHECK( curried_plus(4)(9) == plus(4, 9) ); BOOST_CHECK( uncurry(curry2(plus))(4, 9) == 13 ); } If interested enough, it might be enqueued to the review queue. Anyway, comments are most welcome. Regards, -- Shunsuke Sogame

6 9

Re: [boost] Boost.Tests: Unit test defines own main() function, why?
by Vectra17 17 Jan '08

17 Jan '08

This code needed #define BOOST_TEST_DYN_LINK and now works perfectly. Well almost perfectly, before I realised something rather strange: the compiler ask for a .LIB as well. I am sure it exectues the DLL because when I erase it, the program crashes(.dll not found). So why is the compiler still asking for a .LIB file when I specifeid DLL linking? -- View this message in context: http://www.nabble.com/Boost.Tests%3A-Unit-test-defines-own-main%28%29-funct… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Re: [boost] Is there any interest in a template geometry library?
by artemp 17 Jan '08

17 Jan '08

Barend Gehrels wrote: > > Is there any interest in a template geometry library? > I'm very interested! --Artem http://mapnik.org -- View this message in context: http://www.nabble.com/Is-there-any-interest-in-a-template-geometry-library-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

wave lexed_tokens sample gives an unexpected answer
by Leo Davis 17 Jan '08

17 Jan '08

Hello, I built the Wave preprocessing lib out of CVS head today using GCC 4.2.1 on Linux x86 box (openSUSE 10.3). I then built the lexed_tokens sample and ran it on the attached header file. The unexpected answer was how the 'defined' keyword was treated. I expected it to treat it as T_DEFINED, but it seems to return T_IDENTIFIER as shown by this output fragment: ... PP_IF (#370) at foo.h ( 4/ 1): >#if< SPACE (#393) at foo.h ( 4/ 4): > < IDENTIFIER (#381) at foo.h ( 4/ 5): >defined< SPACE (#393) at foo.h ( 4/12): > < IDENTIFIER (#381) at foo.h ( 4/13): >BAR< NEWLINE (#395) at foo.h ( 4/16): >\n< ... Leo #ifndef FOO_H #define FOO_H #if defined BAR #define BAZ #endif #endif /* FOO_H */

2 3

Globally Unique Identifier library by Andy Tompkins ?
by Janek Kozicki 16 Jan '08

16 Jan '08

Hello, I wasn't following boost development for about 8 months, now I'm slowly getting back on track (about 4000 unread emails had accumulated in my inbox, gotta look through them ;) I just looked at http://www.boost.org/more/formal_review_schedule.html and I didn't see any information about the mini review for Andy's library. Is it scheduled, was it already done, is it accepted? What's the status? best regards -- Janek Kozicki |

3 3

Re: [boost] Terminology:Type Unification? (was Re: RFC Generic data structure traversal / manipulation library
by dan marsden 16 Jan '08

16 Jan '08

Larry Evans wrote: >Page: > >http://spirit.sourceforge.net/dl_docs/traversal/html/traversal/quick_start_… > >contains a section titled: > >Type Unification > >however, it appears like what it describes is more like the stl's >accumulate or mpl's fold. Could you explain the reason for the >title and why a title using accumulate or fold wouldn't be >more intuitive to readers? The terminology is taken from the paper by Ren and Erwig, in the references section. I've borrowed a lot of the naming conventions and terminology from this paper. In the original there are 2 traversal types, type preserving which return a result of the same type as their input argument, and type unifying, which take all input types to the same (fixed) output type. In my library, I've currently replaced the type preserving traversals with inplace traversals, as C++ suits modification in place better than large amounts of copying. The 2 numbered points at the start of the Type Unification section attempt to explain this, but obviously this could be clearer. I'll have a look at rewording things. The operation is certainly not a fold, so I think it would be misleading to associate the example with fold like terminology. Cheers Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

3 2

[utility] initialized_value - a convenience class for value_init.hpp
by Niels Dekker - mail address until 2008-12-31 16 Jan '08

16 Jan '08

For the convenience of the end users, I would like to add a little class to value_init.hpp, called initialized_value, having a conversion operator as its one and only member. Because it's just an extra feature of value_init, and Fernando Cacciola (the owner of value_init) already agrees that this class is a useful addition, I don't think an officially review of the class is necessary. But please tell me if you think otherwise. Details: The following syntax should initialize an object in a generic way, assuming that its type T is CopyConstructible: T obj1 = T(); Unfortunately this object may *not* be initialized properly, because of value-initialization related compiler issues of various C++ implementations, including MSVC, Borland, and GCC. (Boost ticket #1217, #1459, and #1491.) Fernando Cacciola and I have recently reimplemented boost::value_initialized, to work around those issues. (value_init.hpp, release branch, changeset [42501].) So the next release version of boost::value_initialized can be used to properly initialize an object, even in the presence of those compiler issues, as follows: T obj2 = get( value_initialized<T>() ); Still this way of initializing an object is rather verbose, and it has a form of code duplication, because it mentions the type of the object (T) twice. Within user code, the type may of course look more like Namespace::Template<Arg>::Type. Therefore I would like to add a class, boost::initialized_value, supporting the following: T obj3 = initialized_value(); The class would be implemented as follows: namespace boost { class initialized_value { public : template <class T> operator T() const { return get( value_initialized<T>() ); } }; } Its conversion operator would provide an appropriate value-initialized object for any CopyConstructible type T. Any comments are welcome. If it's okay, I would like to add it to the trunk version of value_init.hpp, next week. Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

Re: [boost] [review] Fast track review of Boost.Utility/Singleton
by Tobias Schwinger 16 Jan '08

16 Jan '08

Nat, thanks for your very positive review. Nat Goodspeed wrote: > John Torjo wrote: > >> Today starts the formal Fast-Track review of the Boost.Utility/Singleton >> library. >> >> What to include in Review Comments >> ================================== >> >> Here are some questions you might want to answer in your review: >> >> * What is your evaluation of the design? > > Very strong. I like it! > I've implemented CRTP Singleton templates a few times before -- > highlighting the need for a Boost library. ;-) I'm pleased with the > deluxe functionality: >> * What is your evaluation of the documentation? > > Very clear, though not entirely complete, as described below. The > organization and style is excellent, and when polished, this > documentation will be exemplary. I like the examples. Pointing out the > ability to bind() instance and/or lease, and the semantics of each, is > great. Also the multiple-inheritance example to graft Singleton behavior > onto an existing class. > I didn't fully understand the thrust of the example described as: "We > might as well have a static facility use the Singleton internally, by > using non-public inheritance". A few more words about that example would > be useful; maybe a bit of the implementation of static void message(). I might have kept it so brief since I'm not too sure it's good practice. I think I'll better just remove it. > It appears that the third template parameter SubsystemTag was a > recent introduction. The documentation (especially the reference > material) doesn't describe it enough, and often fails to mention it > entirely. Yes. > The first paragraph under > http://torjo.com/tobias/index.html#boost_utility_singleton._singletons_and_… > seems to want to be a bullet list that got flowed instead. Yes. > Very little is said about BOOST_SINGLETON_PLACEMENT and > BOOST_SINGLETON_PLACEMENT_DECLARATION. The reference material mentions > them without any explanation. That "Singletons and dynamic libraries" section explains their purpose. What exactly is missing? I'm not too fond of specifying what those macros expand to and I don't really want to mention them in the introductory section either, as for me they are kind-of workarounds for the imperfect ABIs we have to deal with. > The example > http://torjo.com/tobias/index.html#boost_utility_singleton._singletons_and_… > appears to be inconsistent: shouldn't mylib_tag and library_tag be the > same, one way or the other? They should. My head must had been on vacation revising the docs. > Also, that example combines three different > mechanisms: BOOST_SINGLETON_PLACEMENT, destroy_singletons() and > SubsystemTag. More explanation of the role of each (why are we using > that mechanism here?), and how they interact -- or remain orthogonal -- > would clarify. Yes. Regards, Tobias

1 0

RFC Generic data structure traversal / manipulation library
by dan marsden 15 Jan '08

15 Jan '08

Hi All I'm posting an early version of a library for manipulating hierarchical data structures, for example the parse trees that are produced by Spirit2. The library enables traversals, and local modifications of complex data structures, without the need to implement large amounts of repetitive traversal code. The library is in a very early state, but has a pretty large introduction and quick start guide, which (hopefully) will help get people started with the library. Formal documentation is unfortunately non-existent at this point. The library is based on techniques from the Haskell community, links to relevant papers are provided in the documentation. The library is intended to play well with the rest of Boost, it already contains support for structures built with Boost.Optional and Boost.Variant, and Boost.Fusion, and will support other Boost libraries in future releases. The library makes heavy use of function objects, and is intended to work with Boost.Lambda, Phoenix, and other function object libraries in Boost. Online documentation can be found at: http://tinyurl.com/2eyjeh A gzip copy of the latest source is available for download at. http://tinyurl.com/2h2tb6 I've also detailed some of the directions that future implementations of the library make take. Any feedback gratefully accepted. Thanks Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

6 9

[result_of][borland-5.9.2] BOOST_NO_RESULT_OF
by Jonathan Turkanis 15 Jan '08

15 Jan '08

Hi, I make one fairly modest use of result_of in Boost.Iostreams. My initial implementation included result_of.hpp and guarded the use of result_of with the macro BOOST_NO_RESULT_OF. I then discovered that Borland 5.9.2 and Borland 5.9.3 don't support result_of well enough for my needs, but that result_of.hpp header doesn't set BOOST_NO_RESULT_OF for these toolsets (since they supposedly support SFINAE). So I added checks for Borland version to the guard around result_of. This worked until yesterday. Now it seems that simply including the result_of header fails on Borland (see std_test_result_of_header: http://tinyurl.com/26umcr) I'd like to patch Iostreams as soon as possible, so I'm wondering whether this regression will be resolved by making the header includable by Borland or by marking std_test_result_of_header as an expected failure. It seems to me that result_of.hpp either has to be unconditionally includable, or BOOST_NO_RESULT_OF has to be defined in boost/config.hpp so I can tell whether to include it. If result_of is now really unusable on Borland (and if late model Borland really supports SFINAE), then it's no longer true that BOOST_NO_RESULT_OF is simply the disjunction of two existing config macros, and so it seems natural to define it in config.hpp instead of in result_of.hpp. (It could be defined in config/compiler/borland.hpp and also in config/suffix.hpp if BOOST_NO_SFINAE or BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is defined.) Thanks, -- Jonathan Turkanis CodeRage http://www.coderage.com

1 1

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

15 Jan '08

Eric Niebler wrote: >dan marsden wrote: >> Hartmut Kaiser wrote: >>> Is the used concept extensible in a way allowing for _structural_ >>> changes of the traversed data structure? This would make it usable >>> for tree transformations, which would be especially interesting if >>> used with Spirit.Qi (parsing) and Spirit.Karma (generation). ><snip> >> As for arbitrary transforms from type A to type B, this is probably >> the biggest open question for the library (IMO). > >This is the sort of thing that Proto's tree transformations handle >naturally, but Proto transforms only work when the tree nodes can be >differentiated at compile time. Perhaps there is some synergy between >these two libraries. > >I'm working on the documentation for Proto's new tree transformation >framework right now. Dan, we should talk. Yes, from what I understand of Proto, it is basically providing case analysis on the parse trees for expression template expressions. Its also nicely composable, it's that sort of case analysis type structure that I had in mind. I'd be glad to discuss whether possibly synergies between the 2 approaches. Cheers Dan __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

1 0

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

15 Jan '08

Hartmut Kaiser wrote: >IIUC, the traversal library is designed to help traversing arbitrary data >structures and to apply local _value_ changes. My question is: >Is the used concept extensible in a way allowing for _structural_ changes of >the traversed data structure? This would make it usable for tree >transformations, which would be especially interesting if used with >Spirit.Qi (parsing) and Spirit.Karma (generation). Currently, the most straightforward way to make structural changes to the tree is at nodes where variants are present. Obviously then switching to a subtree of a different type is straightforward. Optional and pointers provide limited scope for eliminating subtrees in a similar way. As for arbitrary transforms from type A to type B, this is probably the biggest open question for the library (IMO). Currently local value changes are pretty well supported within a framework of standard traversals which can be tweaked for certain types. To what extent the library can / should support traversals in which custom behaviour is required at the majority of the nodes is an area I'm currently giving thought to. Ideally I'd like to support at lot more use cases than this first iteration can manage, as things mature, and I incorporate feedback. Cheers Dan __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

2 1

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