July 2006 - Boost - lists.preview.boost.org

Boost Exception
by Emil Dotchevski 29 Jul '06

29 Jul '06

Hello, Some time ago I wrote a Boost version of the exception library I've been using in my own programs for several months now. I just finished a somewhat extensive redesign of the library, partly in responce to the initial feedback I received here after my original posting, and partly as a result of my own experience and several discussions with Peter Dimov. I believe the library is now easier to use and explain, yet achieves the same major design goals of the original interface. Here's a link to the new documentation: http://www.revergestudios.com/boost-exception/boost-exception.htm Click "Download" to get a zip file with the source code, complete with boost-build jamfiles and a test suite. I am very interested in your feedback; please download the code and try it out. I still consider Boost Exception as an experiment, but I think this revision brings me very close to requesting a formal review for addition to Boost. Thanks, Emil

1 0

[Boost-bugs] [ boost-Bugs-1530683 ] cpp_regex_traits<charT>::toi() method fails in the MT case
by SourceForge.net 28 Jul '06

28 Jul '06

Bugs item #1530683, was opened at 2006-07-28 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1530683&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aleksey Sanin (lsh123) Assigned to: Nobody/Anonymous (nobody) Summary: cpp_regex_traits<charT>::toi() method fails in the MT case Initial Comment: cpp_regex_traits<charT>::toi() method fails to parse the string correctly when it is used in multi-threaded environment. Originally, I run into this problem in regex parser code and traced it down to cpp_regex_traits<charT>::toi() method (btw, this happens on Linux only, Windows code goes thru a different code path). I believe that the problem is caused by the fact that *buffered* m_pimpl->m_sbuf and m_pimpl->m_is are used inside cpp_regex_traits<charT>::toi() method without locking. Thus, if two threads are trying to use it in the same time, it fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1530683&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

lamda question
by Joe Van Dyk 28 Jul '06

28 Jul '06

I have Boost 1.33.1 installed. I'm trying to use Boost.Lamda. I included all the headers mentioned in the documentation as an attempt to fix the compile error. #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/lambda/loops.hpp> #include <boost/lambda/algorithm.hpp> #include <boost/lambda/if.hpp> #include <boost/lambda/switch.hpp> #include <boost/lambda/construct.hpp> #include <boost/lambda/casts.hpp> #include <boost/lambda/exceptions.hpp> #include <iostream> #include <list> int main() { using namespace std; using boost::lambda; list<int> v(10); for_each(v.begin(), v.end(), _1 = 1); } % g++ lambda.cpp lambda.cpp: In function `int main()': lambda.cpp:20: error: `_1' undeclared (first use this function) lambda.cpp:20: error: (Each undeclared identifier is reported only once for each function it appears in.) Using gcc 3.3.1. Any ideas? Thansk, Joe

3 5

Re: [boost] cvs authorization
by JOAQUIN LOPEZ MU?Z 28 Jul '06

28 Jul '06

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Viernes, Julio 28, 2006 4:23 pm Asunto: [boost] cvs authorization > I am having problem authorizing myself in boost cvs. Does anyone > know what could be the reason and how to fix it? Maybe it has to do with the following issue reported at http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 : ( 2006-07-13 09:23:52 - Project CVS Service, Project Shell Service, Project Subversion (SVN) Service, SourceForge.net Web Site ) A recent kernel exploit was released that allowed a non admin user to escalate privileges on the host pr-shell1. We urge all users who frequent this host to change their password immediately and check their project group space for any tampering. As a precaution, we have blocked access to all project resources by password until the user resets their password. After the password has been reset, project resources should be accessible within 5 minutes. > Gennadiy HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

cvs authorization
by Gennadiy Rozental 28 Jul '06

28 Jul '06

I am having problem authorizing myself in boost cvs. Does anyone know what could be the reason and how to fix it? Gennadiy

3 3

[mpl] Metafunction terminology - revival?
by David Bergman 28 Jul '06

28 Jul '06

Ok, I don't know what happened to the old discussion about naming of stuff that can be safely applied by mpl::apply. We have the following constructs: 1. "metafunctions," which are templates classes with a type identifier called 'type', 2. "metafunction classes," which are classes with a nested template class called 'apply', which is a "metafunction" in its own right, and 3. "lambda expression." Two of them - #2 and #3 - share a quite important trait: they can be passed as the first argument to mpl::apply. I suggest that we call anything applicable via mpl::apply a "metafunctor." And have "metafunctoid" denote that category extended with #1 - ordinary metafunctions - above. It is a bit boring not to be able to use a common name for these constructs, especially when trying to tech others about metaprogramming techniques in C++. And I do not see such common names in the MPL documentation (or book.) /David

5 8

Re: [boost] Exception Visitor
by Sohail Somani 28 Jul '06

28 Jul '06

I just don't see the point, except as an academic exercise > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Day > Sent: Tuesday, July 18, 2006 10:32 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Exception Visitor > > I don't think that I can get rid of the catch block entirely, > but I can make > it so that you always use catch(...). The catcher function > redirects the > exception handling to the class that you provide. > > Jeremy > > On 7/18/06, Sohail Somani <s.somani(a)fincad.com> wrote: > > > > Or how to implement try..catch? > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

9 28

[Boost-bugs] [ boost-Support Requests-1530168 ] Bjam build should support attachment of individual build ids
by SourceForge.net 28 Jul '06

28 Jul '06

Support Requests item #1530168, was opened at 2006-07-28 06:57 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=1530168&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Krügler (daniel_kruegler) Assigned to: Nobody/Anonymous (nobody) Summary: Bjam build should support attachment of individual build ids Initial Comment: The Boost library has very high reputation due to its code quality and is used in many companies and organizations as part of their own production code. Bug fixes are usually rarely necessary, but due (naturally understandable) longer release cycles, they tend to accumulate slightly, which raises the propability that individual organizations decide that they would like to use a non-official release version of boost: - They use selected parts from the current development code. - They use proposed fixes which were the result of newsgroup discussions. Due to these practices there exist need to extend the current naming scheme of boost libraries to allow the attachment of individual build id's to the current lib names, e.g. instead of the current example from http://boost.org/more/getting_started.html#Build_Install: libboost_date_time-gcc-mt-d-1_31.a I propose to extend the bjam action table with the option: -sBUILD_ID=string If this option is not used, the current naming scheme applies as usual, but if the proposed option is used, e.g. with -sBUILD_ID=M20060727-vgf3 the above output file is named to libboost_date_time-gcc-mt-d-1_31-M20060727-vgf3.a The very advantage of this proposal are: - Popular build id naming schemes tend to point themselves out of the regular version pattern and allow better discrimination from official boost release version. Build id do have a well-known tradition in many popular software products. - The proposal is non-intrusive and allows tagging boost output according to company-specific naming schemes. Users don't need to manually "hack" the current bjam input file to enforce such naming scheme. Users not interested in this scheme will not be influenced by this extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1530168&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] error in boost/config/platform/hpux.hpp (thread support)
by Oliver.Kowalke＠qimonda.com 28 Jul '06

28 Jul '06

Julien Delacroix wrote: > Maybe it will be necessary to check aCC version and set > BOOST_DISABLE_THREADS for old aCC version that do not have thread > suport... Boost did not compile under HP/UX 11.11 (PA-RISC) with aCC because only the old aCC version 3.x is shipped on PA-RISC systems. aCC 3.x is far away from the C++ standard - use instead gcc. regards, Oliver

1 0

pimpl pointer revisited
by Aljaz Noe 27 Jul '06

27 Jul '06

Hi! Recently there was a proposal to add a class template that simplifies the implementation of a PIMPL idiom to Boost. Unfortunately I missed the review deadline so I could not submit a proper review. But I do have some experience with PIMPL class template that I would like to share with you. I wrote similar class template a couple of years ago (see attached file). The basic idea is the same as in a proposed PIMPL class. I call it ImplWrapper, because it is used to wrap class implementation details. Besides automating the standard PIMPL functionality, it also addresses the following issues: 1. The Impl object can be allocated in a buffer that is provided by ImplWrapper class. The reason for this is to avoid unnecessary allocation of small objects on the heap and to increase performance. In fact, I believe that with proper compiler optimizations, there should be no difference between using ImplWrapper class and storing data members in class directly (additional pointer indirection normally associated with a PIMPL idiom is eliminated). The drawback is that the size of the Impl object must be known (guessed) in advance. Sometimes this is not possible, so there is also alternative implementation that allocates Impl object on the heap. 2. Arbitrary parameters can be passed to Impl constructor by wrapping them in a temporary struct. This struct Par, is forward declared within ImplWrapper class and can be specialized for each type of Impl class. There is no need for policies or other design complications. 3. Simplicity. The overall design seems simple, yet functional. But I do admit that this opinion may by biased. ;-) Since the above issues were not resolved within the proposed PIMPL class (I only quickly glanced over the implementation and a PIMPL thread in this list at the end of May, so I might have skipped something), I decided to post my implementation here. I believe that PIMPL idiom is so often used in C++, that it should have some support in Boost (maybe even in future versions of standard C++ library). Hopefully this post will contribute to that goal. Any comments are greatly appreciated. Regards, Aljaz

2 2