- Boost - lists.boost.org

Review Status - Policy Pointer
by Tom Brinkman 26 Apr '05

26 Apr '05

I have in my notes that the Policy Pointer library review has been delayed. On 7-Apr-2005, David B. Held at (dheld(a)codelogicconsulting.com) requested another month for preperation. Gennadiy at (gennadiy.rozental(a)thomson.com) is scheduled to be the review manager for this library.

1 0

[sockets] layers concept
by Iain K. Hanson 26 Apr '05

26 Apr '05

Hi I created the layers concept for the C++ Networking boost library. The layers I defined are: Layer 1 :- Light weight wrappers arround predominantl BSD socket concepts. Layer 2 :- Acceptor, Connector, Reactor, and Svc_Handler concepts ala ACE. Layer 3 :- An optional iostreams interface if desirable? Layer 4:- Applications layer - includes ftp, telent, http/s And user applications Please note there is no Layer 0 ( zero ) it does not exist. These layers are a key to understandable discussion on the list and avoidance of confusion. This makes Don G's propasal a Layer 2 porpasal IIUC. There have been other proposals at Layer 2. Boris has also been atempting bto model Layer 1 but keeps calling itlayer 0. we need a common nomenclture or confusion will reign. /ikh

2 1

Re: Formal Review: FOREACH macro
by Johannes Brunen 26 Apr '05

26 Apr '05

> Do you think the library should be accepted as a Boost library? Be sure to > say this explicitly so that your other comments don't obscure your overall > opinion. Yes, it should be accepted. > What is your evaluation of the design? Convincing. I like the simple user interface most. What I dislike is the upper case spelling of the macro, because it is so much keyword like. However, I'm unsure what counts more: the upper case spelling rule for macros or the wish to have a foreach keyword undistinguishable from the other C++ keywords. So this is actually no point at all. > What is your evaluation of the implementation? It is amazing what can be done with C++. However, I'm not qualified to make any comments about the implementation. > What is your evaluation of the documentation? It is short and to the point. What I'm missing is an example for using BOOST_FOREACH with the std::map container. As Michael Toksvig already said, the documentation should mention as many pitfalls as possible. > What is your evaluation of the potential usefulness of the library? This is a very useful library. It is unfortunate that there isn't a build in keyword 'foreach' in the C++ language. If the library is going into boost I will starting to use it for my daily work. > Did you try to use the library? With what compiler? Did you have any > problems? Yes, with MinGW (gcc 3.4.2). I did not have any problems. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I tried some examples (std::list, std::deque, std::set, std::map, int[]) with no problems. I read the documentation and looked into the powerpoint presentation. However, I did not study the source code (foreach.hpp) in-depth. > Are you knowledgeable about the problem domain? Yes, form the user's point of view. With best regards Johannes Brunen ____________ Virus checked by G DATA AntiVirusKit Version: AVK 15.0.4483 from 26.04.2005 Virus news: www.antiviruslab.com

1 0

Any Metrowerks experts? (getting ready for 1.33)
by John Maddock 26 Apr '05

26 Apr '05

Can any experts in MWCW take a look at why libs/type_traits/extent_test.cpp fails all the tests? The implementation of the extent type trait is pretty simple, and Metrowerks is the only compiler that doesn't like it for some reason. Many thanks, John.

2 2

RE: [boost] SmartPtrs: Making Code Self-Describing. Do we need mo re SmartPtrs?
by Martin Bonner 26 Apr '05

26 Apr '05

----Original Message---- From: Pavel Chikulaev [mailto:pavel.chikulaev@gmail.com] Sent: 25 April 2005 16:36 To: boost(a)lists.boost.org Subject: [boost] SmartPtrs: Making Code Self-Describing. Do we need more SmartPtrs? > Please consider the following code which we IMO too often see in other > libraries: > class Foo; > Foo * Bar(Foo *); > > What can we say about this pretty C-like function? It gets pointer > Foo and returns pointer Foo. That's all we can be sure about it. > But that's not enough to start working with it. But without looking at > documentation we can't say whether we should delete these pointers > or function Bar will handle it. What if even documentation says > anything about it, what to do then? Discuss the lack of documentation with the original developer. (A 2x4 may be useful). ... You can't use a function if you don't know what it does. The documentation might as well discuss lifetimes. > Example 1: > We are the developer of function Foo. And we need to mark somehow > that returned pointer is property of Foo internals and it shouldn't be > deleted by the client function. We can achieve this using weak_ptr, but > what if Foo internals doesn't have any shared_ptr's ? What to return then? What's wrong with returning a reference here? > Example 2: > > We are developer of function Foo again. And now we need to mark that > pointer argument is needed only for time of execution of Foo (it > wasn't collected anywhere), and user cares about deallocation. How > are we going to write such code and make it self-describing at the same > time? Plain pointer? No Way! That would be a C-style, but we need > something like C++-style... This time we don't have even one std or > boost candidate for such job. Reference definitely. > Do we need them? I don't think so. > Or we've already have some alternative solution I didn't find? I think so. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

[FOREACH, Range] Slight documentation typos.
by Jurko Gospodneti� 26 Apr '05

26 Apr '05

Hi. Just some documentation typo reports: Typo: 'rannge_iterator' in one example comment on http://boost-sandbox.sourceforge.net/libs/foreach/doc/html/boost_foreach/ex…. 'must rely of range_result_iterator' should read 'must rely on range_result_iterator' on http://boost.org/libs/range/doc/portability.html. Hope this helps. Jurko Gospodnetiæ

1 0

Review Wizard Status Report
by Tom Brinkman 26 Apr '05

26 Apr '05

Review Wizard Status Report According to my notes, the following five libraries are up for review in the following weeks. The Typeof, Function Types and Logging libraries still need review manager volunteers. I'm sorry if I missed your email or posting about volunteering and I have not included you here, please email me again at reportbase(a)google.com. I'll make shur that I keep this status report up to date. I will try to post this document weekly until this set of libraries have completed their reviews. I will also try to respond to questions about this schedule in the developers message board, rather than through private emails. Keep your suggestions coming about how to improve the review process. 1) FOREACH Macro (Starts: 25-Apr-2005; Ends: 1-May-2005) 2) Typeof (Review Manage Needed) 3) Singleton 4) Function Types (Review Manage Needed) 5) Logging (Review Manage 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) 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. 3) 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. 4) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: Needed 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: Needed 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

2 1

[1.33 release] pdf doc generation
by Jeff Garland 26 Apr '05

26 Apr '05

I'm not sure who to ask, so I'll just throw this out there. For the 1.33 release I'd like to fix whatever it was that kept date-time docs from being included from the 1.32 pdf file. I don't think there was a full accounting after 1.32 as to what stopped date-time from being included. Given that I am still unable to generate a full boost pdf (fails in the fo processing step) I'm not really able to help diagnose and fix the problem. I'm aware that this works for others, so there's something wrong with my setup... So here's what would be really helpful: 1) whomever is going to generate the pdf docs would generate and post a pre 1.33 version soon 2) if there is a problem with date-time we can work on correcting it 3) we can re-run at least once a week as we put release doc changes in Thx, Jeff

2 2

GOOD DAY
by witt＠acm.org 26 Apr '05

26 Apr '05

Mail transaction failed. Partial message is available.

1 0

[iostreams] error in docs
by JOAQUIN LOPEZ MU?Z 26 Apr '05

26 Apr '05

The main page of Boost.Iostreams docs says "Note: This library has been accepted as part of Boost, but is not part of the current Boost distribution..." I understand this disclaimer should now be removed. Joaquín M López Muñz Telefónica, Investigación y Desarrollo

2 1