- Boost - lists.boost.org

Factory library new version
by Federico Stella 04 May '05

04 May '05

I've uploaded a new version for factory library [1] whit these changes: o Added some tutorial on library use. o Ported 3 example from Rob Geiman's object factory. o More documentation. o Fixed some bugs. o Now uses boost directory structure. o Big architectural changes. o Boost.Singleton is now optional. I've checked the object factory from Rob Geiman and I think the main differences between implementations are that mine could use an allocator and call any constructors without limiting to just one. Rob's library has an allocation policy but it embed even "creation" policy so changing the policy requires writing the some same code. Rob am I right? Up to now it lacks: o test cases. o some optimizations. o the documentation is still doxygen generated, but I plan to test "doxygen autodoc". Ideas? Comments? Bugs? Fede. [1] http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&fi…

1 0

[Boost-bugs] [ boost-Support Requests-1194877 ] Download boost_1_32_0.tar.bz2
by SourceForge.net 04 May '05

04 May '05

Support Requests item #1194877, was opened at 2005-05-03 17:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1194877&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Download boost_1_32_0.tar.bz2 Initial Comment: Hi, I've downloaded boost_1_32_0.tar.bz2, and unzipped the files. Tried installing it with the ./configure or ./install commands. but was not able to do it. I'm pretty new to linux and i dont know the alternative commands to install it. Was not able to get anything from the readme file. It'll be great if someone can let me know where i can find more details of installation of this particular file. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1194877&group_… ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

range_value
by David Abrahams 04 May '05

04 May '05

I don't understand why there are so many implementations of the range_value metafunction. It seems to me that it should always be defined to be: template <class R> struct range_value : boost::iterator_value< typename range_iterator<R>::type >::type {}; What am I missing? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 2

Re: [boost] Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 03 May '05

03 May '05

In-Reply-To: <d4j89a$cd7$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > BOOST_FOREACH By the way, is there a rationale for the name? I'd have expected BOOST_FOR_EACH, with a word separator between FOR and EACH because, well they are separate words. This also matches the precedent of std::for_each. Word separators are especially important for names that are all in capitals. Is there a compelling reason to omit the second underline? -- Dave Harris, Nottingham, UK.

6 5

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 03 May '05

03 May '05

In-Reply-To: <20050430145039.A20350(a)titan.hansons.demon.co.uk> ikh(a)hansons.demon.co.uk (Iain K. Hanson) wrote (abridged): > I really don't like macros. I too have a strong antipathy to macros. I don't reject them absolutely, but they need a very good justification. I can't see myself ever using BOOST_FOREACH because the problem it is solving isn't hard enough to warrant the obfuscation. Comparing: BOOST_FOREACH( int i, vec ) cout << i; with: for (iterator i = vec.begin(); i != vec.end(); ++i) cout << *i; the macro just doesn't seem worth it. I find it scary. When I look at the implementation I am not reassured. This is replacing something I understand with something I frankly don't. I have looked at the documentation and found it a bit superficial. For example, I can't tell whether the example above is actually supported. All the examples in the documentation have braces around the loop body: are those just the author's preferred style, or are they required by the macro? I looked at the implementation and I still can't tell. I prefer to omit braces when they are not required. I have not tried to use the macro. From the source, it looks like it injects a largish number of local variables into the code, and these will show up in the debugger and need to be understood to follow how the loop is progressing. For what it's worth, I think the design is impressive and if I had come up with it I'd be very proud. Congratulations. The problem is that it is too clever. It is using a sledgehammer to crack a nut. I am not sure how one is supposed to vote in these circumstances - for a proposed library that one wouldn't use oneself. I don't necessarily want to prevent other people from using it if they want. I think it could help demonstrate both the usefulness of type inference and how yucky type inference is to achieve in C++ at present. It is an argument for language change. However, I guess it doesn't need to be part of Boost to do that. I vote against accepting BOOST_FOREACH into Boost. I hope the Review Manager pays more attention to my reasons than my vote. -- Dave Harris, Nottingham, UK.

7 9

FOREACH macro review is over
by Gennadiy Rozental 03 May '05

03 May '05

Hi, FOREACH macro review is officially finished. I'll post a results shortly. Fell free to express any additional comments, but I couldn't promise I will take them into an account ;o) Gennadiy

1 0

Review Schedule
by Tom Brinkman 03 May '05

03 May '05

If there are no objections, I have moved the "Singleton" library to next in the review queue. The review manager for the library will be Pavel Vozenilek. Tentatively: I have set the review start date for 5-May-2005. However, Paul Vozenilek will make the official announcement when the review will begin. The Typeof library has been moved back one in the review queue because it still needs a review manager volunteer. Contact Tom Brinkman at reportbase(a)gmail.com to volunteer. Review Schedule as of May 2, 2005 1) FOREACH Macro (Starts: 25-Apr-2005; Ends: 1-May-2005) 2) Singleton (To be Confirmed: Starts: 5-May-2005; Ends: 15-May-2005) 3) Typeof (Review Manager Needed) 4) Function Types 5) Logging 6) Policy Pointer Possible Future Reviews: 7) Fixed Strings (Review Manager Needed) 8) Intrusive (Review Manager Needed) 9) TR1 (Review Manager Needed) 10) Fusion (Review Manager Needed) 1) FOREACH Macro Author: Eric Niebler eric(a)boost-consulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler, foreach.zip BOOST_FOREACH is a macro that makes it simple to iterate over STL containers, ranges, arrays and null-terminated strings. Its performance approaches that of the hand-coded equivalent loop. BOOST_FOREACH uses Boost.Range can be extended to iterating user-defined collections by extending Boost.Range. Documentation is at http://boost-sandbox.sourceforge.net/libs/foreach 2) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 3) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com Review Manager: Needed Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 4) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 5) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser HartmutKaiser(a)t-online.de Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 6) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 7) Fixed Strings Author: Reece Dunn Review Manager: Needed Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 8)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease.

5 5

request: CVS commit access
by Caleb Epstein 03 May '05

03 May '05

I'm not sure what it takes to get commit access to the Boost CVS repository on sourceforge, but I'd like the ability to fix the occasional bug, etc. that I find in my testing on SunOS without having to beg some other Booster to apply a patch by sending to the list. Is this available with "Tester" access or only "Developer"? I'm a member of the project (cepstein) but not given any role: http://sourceforge.net/project/memberlist.php?group_id=7586 -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 03 May '05

03 May '05

In-Reply-To: <d55q7o$4g5$1(a)sea.gmane.org> SeeWebsiteForEmail(a)moderncppdesign.com (Andrei Alexandrescu (See Website For Email)) wrote (abridged): > > Comparing: > > > > BOOST_FOREACH( int i, vec ) > > cout << i; > > > > with: > > > > for (iterator i = vec.begin(); i != vec.end(); ++i) > > cout << *i; > > > > the macro just doesn't seem worth it. > > In fairness, it's > > for (vector<ArbitrarilyComplexType>::iterator i = vec.begin(); i != > vec.end(); ++i) > cout << *i; No, I meant what I wrote. I usually have a suitable iterator typedef in scope. In the worst case it is more like: typedef vector<ArbitrarilyComplexType> MyVec; for (MyVec::iterator i = vec.begin(); i != vec.end(); ++i) cout << *i; where "MyVec" is some meaningful name (and is probably itself worth putting at some larger scope - after all, where did the vec come from?). And I see adding a typedef as clearer, transparent even, compared to the BOOST_FOREACH macro. > I think the part of the discussion that focuses on arguments for or > against macros is misplaced. Agreed. As I said earlier, I am not absolutely against macros; I won't automatically vote against any proposal that uses them. I am also objecting to BOOST_FOREACH because it is taking something simple and making it complicated. -- Dave Harris, Nottingham, UK.

2 1

[wave] Compilation hangs on Tru64
by Markus Schöpflin 03 May '05

03 May '05

Hello, after recent fixes to the pool library the wave tests passed on Tru64/cxx. But currently the compiler chokes when compiling instantiate_cpp_grammar.cpp. It just sits there for hours consuming all available CPU resources without making any visible progress. This behaviour seems to be related to changes checked in over the weekend. Does that ring a bell with anyone? Markus

2 2