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

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

26 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

1 0

boost::UNformat ...?
by Preston A. Elder 26 Apr '05

26 Apr '05

Hey all, I've been working on something to reverse boost::format, using regex mainly. So say you're working with IRC, and to create the server line, you use a boost::format of: SERVER %1% %2% :%3% The expanded string might be: SERVER test.neuromancy.net 1 :My test IRC server To un-do it you would need a regex of: SERVER ([-.[:alnum:]]+) ([[:digit:]]+) :(.*) My unformatter (right now, part of my Mantra project) allows you to specify the format string, and the expanded version of that string, and populate a map with what each formatting token is (assuming you have your formatting tokens numbered, it doesn't work if you don't). It does handle formatting args (ie. %1$3.2f% or %1|-20s|%), however it does not validate them, just handles them in the regex. It also allows you to specify your own regex's to be used to read certain arguments, so for example you could do: mantra::unformat fmt; fmt.ElementRegex(1, "[-.[:alnum:]]+"); fmt.ElementRegex(2, "[[:digit:]]+"); A 'default' unformatting regex may also be specified (it defaults to ".*") (which can be specified as a constructor argument, or using DefaultRegex). I've also made a convenient way to do all of the above more or less inline, inspired by boost::format, with: (mantra::unformat(".*") % "[-.[:alnum:]]+" % "[[:digit:]]+") My reason for posting this is, I wanted someone else to tell me if there is a better way than the way I am using to do all of this, or is there a better regex than what I'm using to pull out the formatting strings. You can see the source at (search for basic_unformat): http://www.neuromancy.net/viewcvs/Mantra-I/include/mantra/core/algorithms.h… You'll notice I use convert_string<C> a lot, this just converts between character types (because basic_unformat, like basic_format or basic_string can be passed an arbitary character type (though it usually gets char or wchar_t), I need to be able to convert my const char * regex strings into that character type so it will still work with wchar_t). The way it basically works now is in 5 steps. 1) It searches the format string for all the 'extended' %N% tags and goes through and remembers the order they are in. 2) It replaces the 'extended' %N% tags with --<<N>>-- tags (the "--<<" and ">>--" parts can be defined by the user if it conflicts with something in the input). 3) It replaces all regex-specific characters in the string so that they will not be evaluated when the input string is later used as a regex. 4) It replaces all the --<<N>>-- tags with either the user-defined element regex, or the 'default' regex. 5) It evaluates the new format string (now a regex) against the 'expanded' string, and pulls out each element (using the order it remembered from before). This step also checks to ensure that every instance of the same element are the same (ie. %1% should be the same every time it is used). This is a little involved, but using regex, its still quite quick. As always, comments, corrections, suggestions, etc. are appreciated, and in this case, solicited :) If you want to yoink the code for this for your own purposes, go ahead. PreZ :)

1 0

[Boost-bugs] [ boost-Bugs-1190394 ] vertex bundle properties do not work with VC++.NET 2003
by SourceForge.net 26 Apr '05

26 Apr '05

Bugs item #1190394, was opened at 2005-04-26 09: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=1190394&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: vertex bundle properties do not work with VC++.NET 2003 Initial Comment: This works for arbitrary graph: property_map<graph, edge_bundle_t>::type gEdgeBundleMap = get( edge_bundle, g ); This doesn't: property_map<graph, vertex_bundle_t>::type gVertexBundleMap = get( vertex_bundle, g ); How come? Does this mean one cannot use vertex bundle properties with VC++.NET 2003? michael(a)or.rwth-aachen.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1190394&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

RE: [boost] Logging Library -- Formal Review Request
by Bennett, Patrick 26 Apr '05

26 Apr '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Darren Cook > Sent: Tuesday, April 26, 2005 1:06 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Logging Library -- Formal Review Request > > > Depending on how the check is performed, the overhead is virtually > > nonexistent. > > But still there :-). [Bennett, Patrick] If you're concerned about a simple lookup, compare, and jump, sure. :) > >> BOOST_LOG(app,"testing " << i << '-' << j << '-' << k); > >> > > Well, you can count my vote against this method. For you, the entire > > point of doing it this way is so that the logging can be compiled out - > > It is also slightly shorter. It seems just as natural to me. [Bennett, Patrick] I suppose everybody has their preferences. I'm not one to discount that. :) ... > But I want to have both: I want some log statements I can insert while > debugging time-critical code and disable at compile time, and others > that are always there but that I can choose to switch on and off at > run-time. And I want both in the same project. > > Perhaps then BOOST_LOG_DBG() is a better name for the one that can be > compiled out. Or BOOST_LOGD(). [Bennett, Patrick] Sounds fine. I guess I just see the requirements quite a bit different than (probably) many. I see a logging/tracing library as something for diagnostics and debugging, not as a here-and-there std::cout<<xxx substitute. Many of the applications at the company I work at can easily log *gigabytes* of diagnostic data an hour per subsystem. Logging isn't an occasional nice to have for us, it's an absolutely necessity. Patrick Bennett

1 0

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