- Boost - lists.boost.org

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

DLL/SO loading library.
by Vladislav Lazarenko 03 May '05

03 May '05

Greetings, dear developers. I have some simple idea to write platform independed library to provide users with ability to load DLL/SO files (i.e. to develop plugin system etc.). Is there any library in boost? I've found nothing. Maybe we need it? Let's discuss, I am interested in your comments. Thank you very much in advance.

14 32

GCC 4.0 Compiler Review \ Performance Tests
by Brian Braatz 03 May '05

03 May '05

http://www.coyotegulch.com/reviews/gcc4/index.html The review is interesting, but of most relevant interest to boosters would be the following: "The C++ compiler is now faster, particularly on code heavy with templates; the Standard C++ library has improved stream and strings classes, and it includes preliminary new classes from the recent C++ Technical Report 1 (an update to Standard C++)." The review is interesting. For those who don't wish to read through it, basically 4.0 is more of an incremental version, no real performance leaps in compilation or performance.

3 2

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

03 May '05

In-Reply-To: <d55r5q$9h2$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > > Adding #defines is adding complexity. > > I think it's a kinda an attitude issue: you see all macros as enemies. No. Adding almost anything is adding complexity. It's another layer. And of course a rather powerful layer - a macro can do almost anything. Also you snipped the context. Your proposal here was, if I understand correctly, to use conditional compilation to switch off FOREACH's support for corner cases. So we are adding more options and configurability, and the potential for my corner cases not to work because support for them has somehow been switched off (where - in the makefile?). Even if I know how FOREACH works in my project, it might work differently on my colleague's project. And I have yet more code to read when I look at the header. It's as if we were trying to build the most complex thing that could possibly work. > I see some of them as friends. Macros in general (and FOREACH in > particular) are in most cases only usability helpers (there is also > configuration switched domain, but it's beside the point). And until > language provide as-convenient alternatives I am ready to accept the > macro nature of these tools. I'm ready to accept them too, when they do something worth while. This one doesn't. -- Dave Harris, Nottingham, UK.

2 1

The View concept
by Maciej Sobczak 03 May '05

03 May '05

Hi, There is a thread on comp.lang.c++.moderated where the problem of manipulating with "heavy" data in STL containers was raised. The name of the thread is "Messign with expensive objects in containers". I have posted a solution with the help of a simple view adaptor class that I wrote a while ago. The code with examples and documentation is here: http://www.msobczak.com/prog/bin/view.zip (11kB) Alberto Barbati suggested to post it here for review. It is different from boost::multi_index in that view operates on already existing objects or sequences. Note: the view class itself is very simple and as a concept is only a fraction of what is available in the View Template Library: http://www.zib.de/weiser/vtl/ I would like to know your opinion about the view as a concept, and its simple implementation that I referenced above. It might fit into the Containers category of Boost libraries. Regards, -- Maciej Sobczak http://www.msobczak.com

2 1