April 2005 - Boost - lists.preview.boost.org

Re: [boost] Re: Boost to the rescue
by Bjørn Roald 27 Apr '05

27 Apr '05

Ummf... the damn touchpad on my laptop sendt my last message without asking me first. I finish it below: "Bjørn Roald" <bjorn(a)4roald.org> wrote: > One concern I have is that the boost project developers should focus on creating great proposals for the C++ standard, not becomming a market leading tool provider. Others could fill that role to avoid draining the developer team of attention to their important work. Bjørn

2 1

[Boost-bugs] [ boost-Bugs-1191322 ] copy ctor for empty() regex throws bad_expression
by SourceForge.net 27 Apr '05

27 Apr '05

Bugs item #1191322, was opened at 2005-04-27 14: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=1191322&group_… Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: copy ctor for empty() regex throws bad_expression Initial Comment: in boost 1.32: regex A; regex B = A; // throws bad_expression ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1191322&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

SmartPtrs: Making Code Self-Describing. Do we need more SmartPtrs?
by Pavel Chikulaev 27 Apr '05

27 Apr '05

Hi boosters, 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? Thanks C++, we've got auto_ptr. Now we explicitly mark that who should care about pointers. So, if we have auto_ptr<Foo> Bar(auto_ptr<Foo>) we do know how to work with it even without looking at the documentation. 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? Plain pointer? No Way! We need a way to explicitly say that we return copy of pointer that can't be deleted and no synchronization is needed. So, IMO We need another smart pointer type. Unfortunately, I didn't think of a good name for it, so it's still unnamed, but I think you understand what I am proposing. 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. So we need one more smart_ptr. Again, this one needs a good name too. --- So, anybody interested? Do we need them? Or we've already have some alternative solution I didn't find? Please let me know. Just wanted make code a bit more self-describing, there is no place for dumb pointers at all in high-level C++ programming. And Is there any place for such smart pointers in Boost? As always any comments are welcome. P.S. Description of boost.smart_ptr on libraries page still says that there are 5 smart pointers, instead of actual 6. -- Pavel Chikulaev

4 3

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 27 Apr '05

27 Apr '05

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Miércoles, Abril 27, 2005 9:20 pm Asunto: [boost] Re: [test][comeau] problem with va_list > > 2. Is it ok to commit an obvious patch to > > boost/test/impl/test_tools.ipp so as to work around > > this problem? > > Could you first to post a patch here? > Of course, I won't touch the CVS before exposing here the patch --this'll be tomorrow, though, as I'm away from my IDE noew. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

How to cast type with vector
by zlf 27 Apr '05

27 Apr '05

Hi, I have to classes. class Car; class Limousine : public Car{ ... }; And two vector vector<Car> Cars; vector<Limousine> Limousines; I want to set vector Limousines's to vector Cars( Cars = Limousines ). One method is: vector<Limousine>::iterator pos; for ( pos = Limousines.begin() ; pos != Limousines.end() ; ++ pos ){ Car car; car = static_cast <Car>(*pos); Cars.push_back ( car ); } However, I think it is to clumsy :0 .Who can provide me with a easier method(e.g:using copy() or other std function).thx zlf

6 5

[optional] operator << left out in 1.33 :(
by Fernando Cacciola 27 Apr '05

27 Apr '05

Hi People, I'm really sorry but I totally forgot about the request to add operator<< to optional<> I know new features are frozen, but this is a fairly small and uninfluencial one, isn't it? Doug, can I added that to HEAD? Or shall I leave it for 1.34? TIA Fernando Cacciola

1 0

singleton documentation
by Jason Hise 27 Apr '05

27 Apr '05

The singleton documentation can now be browsed online at http://www.ezequal.com/chaos/docs/html/singleton/ -Jason

1 0

Re: Boost Digest, Vol 1075, Issue 2
by Jeffrey Williams 27 Apr '05

27 Apr '05

> Date: Wed, 27 Apr 2005 08:40:13 -0400 > From: Edward Diener <eddielee(a)tropicsoft.com> > Subject: [boost] Re: TR2 and C++0x heads up <snip> > > I disagree on this. It is clearly wrong, in my eyes, to propose any > library to the C++ standard committee when that library is someone > else's work. I greatly respect Mr. Ramey for the work he has done and is > doing to make the Boost serialization library as good as it is but I > would never want to propose such a library for inclusion as a standard > library unless the creator of the library wanted to promote it also. It > is also unfair to put that creator in such a position of extra work > which standardizing a library might entail. First paragraph of boost license: Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: Therefore, I must ask why you think it is inappropriate to propose someone else's work (which is part boost), if they had or have a problem with that, that should not of released their work under the boost license which clearly would allow such an activity. Jeff

1 0

regex docs match_flag_type.html
by Karsten Sperling 27 Apr '05

27 Apr '05

Just a minor thing I noticed in the regex++ docs: In match_flag_type.html it says that match_single_line is "Equivalent to Perl's s/ modifier". That is wrong, match_single_line is actually the inverse of Perl's /m modifier. Perl's /s causes "." to also match newlines, making it the inverse of match_not_dot_newline. - Karsten

2 1

[serialization] Patch for Tru64
by Markus Schöpflin 27 Apr '05

27 Apr '05

Attached is a patch which makes the serialization library compile on Tru64/CXX65. It seems the compiler somehow gets lost in the anonymous namespace, replacing it with a named namespace fixes the compilation problem. Markus Index: extended_type_info.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/serialization/src/extended_type_info.cpp,v retrieving revision 1.4 diff -u -w -r1.4 extended_type_info.cpp --- extended_type_info.cpp 24 Apr 2005 05:12:22 -0000 1.4 +++ extended_type_info.cpp 27 Apr 2005 07:58:12 -0000 @@ -30,7 +30,7 @@ // remove all registrations corresponding to a given type void unregister_void_casts(extended_type_info *eti); -namespace { // anonymous +namespace detail { // it turns out that at least one compiler (msvc 6.0) doesn't guarentee // to destroy static objects in exactly the reverse sequence that they @@ -179,13 +179,13 @@ BOOST_SERIALIZATION_DECL const extended_type_info * extended_type_info::find(const char *key) { - return ktmap::find(key); + return detail::ktmap::find(key); } BOOST_SERIALIZATION_DECL void extended_type_info::self_register() { - tkmap::insert(this); + detail::tkmap::insert(this); } BOOST_SERIALIZATION_DECL void @@ -193,7 +193,7 @@ if(NULL == key_) return; key = key_; - ktmap::insert(this); + detail::ktmap::insert(this); } BOOST_SERIALIZATION_DECL @@ -206,8 +206,8 @@ extended_type_info::~extended_type_info(){ // remove entries in maps which correspond to this type BOOST_TRY{ - tkmap::purge(this); - ktmap::purge(this); + detail::tkmap::purge(this); + detail::ktmap::purge(this); unregister_void_casts(this); } BOOST_CATCH(...){} @@ -228,7 +228,7 @@ BOOST_SERIALIZATION_DECL const extended_type_info * extended_type_info::find(const extended_type_info * t) { - return tkmap::find(t); + return detail::tkmap::find(t); } bool BOOST_SERIALIZATION_DECL

2 1