- Boost - lists.boost.org

few questions about regex V3 vs V4
by Bronek Kozicki 27 Apr '05

27 Apr '05

Few questions about regex V3 : 1. what parts of boost.regex are available in V3? I just found (to my embarassment during discussion with my boss) that regex_replace is not available in V3. 2. what compilers are known to not work with V4, or (more precisely) : is there any reason to force MSVC6 into V3? 3. assuming that we build regex library files in V4, is it OK (well-defined behaviour) to link these .dll and .lib with code compiled with regex V3? TIA -- Bronek Kozicki brok(a)rubikon.pl http://b.kozicki.pl/

3 3

Re: [boost] Any Interest in a 3-D Vector library?
by Ralf W. Grosse-Kunstleve 27 Apr '05

27 Apr '05

--- Stefan Koch <maillist(a)isolda.com> wrote: > Any interest in a templatized class for 3-Dimensional vectors? > (Similar in style to std::complex or boost math/octonion and > math/quaternion.) FYI: A few years ago I put together cooperating classes for 3-dim vectors, 3x3 matrices and 3x3 symmetric matrices (storing only the six unique elements): http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/vec3.h?vi… http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/mat3.h?vi… http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/sym_mat3.… See also: http://cctbx.sourceforge.net/ It is all open source (BSD style). Feel free to take what you find useful. Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 3

logos in boost image
by Stefan Slapeta 26 Apr '05

26 Apr '05

Hi all, I really wonder who is interested in shipping the images of the boost logo contest (in the more subdir). This increases the size of the boost by about 2 megs and is of no use for most of the boost users! Stefan

5 12

RE: [boost] Re: 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 Peter Simons > Sent: Tuesday, April 26, 2005 5:55 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Logging Library -- Formal Review Request > > Patrick Bennett writes: > > > Having worked on quite a few large-scale commercial > > software products using an extensive logging framework > > for quite a few years now, I can attest that, short of > > embedded deployment, there is almost never a reason to > > compile out tracing code. > > Except for, when the tracing code comes with serious > performance penalties. Then you really want to be able to > compile a version with all the debugging and tracing > statements removed. Nope, in the system we use, the tracing code isn't even called unless tracing is actually enabled (which can be done in realtime from other processes). The only overhead incurred for any logging statement currently not active is little more than a lookup, compare, and jump. >From the discussion I've seen, the proposed library should work the same way. Patrick Bennett

2 1

RE: [boost] Re: 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 John Torjo > Sent: Tuesday, April 26, 2005 3:12 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Logging Library -- Formal Review Request > > > > > Nope, in the system we use, the tracing code isn't even called unless > > tracing is actually enabled (which can be done in realtime from other > > processes). The only overhead incurred for any logging statement > > currently not active is little more than a lookup, compare, and jump. > >>From the discussion I've seen, the proposed library should work the same > > way. > > > > Yup, it does work the same way -- except that for my lib there's not > even a lookup. Every log internally is a reference to a variable of > boost::log::logger type, which contains a pointer to a > boost::log::logger_impl, which contains a boolean variable. > [Bennett, Patrick] By lookup, I was referring (very) loosely to a pointer indirection. The handles in this system are actually statically defined raw ('opaque' handles) pointers to shared memory structures, so comparisons are *extremely* cheap [as you well know]. Patrick Bennett

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 Jody Hagins > Sent: Tuesday, April 26, 2005 11:40 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Logging Library -- Formal Review Request > > On Tue, 26 Apr 2005 12:16:03 -0400 > Caleb Epstein <caleb.epstein(a)gmail.com> wrote: > > > > I think John's approach to having multiple log "levels" is to just use > > a separate log for each one (e.g. you might have logs called trace, > > debug, warning, info, and fatal). Logs are either enabled or > > disabled; there is no "level" or above-some-threshold-type checking as > > with some other common implementations. > > > Unfortunately, you lose relativity in logs, which is very important in > diagnosing failures. Suppose a problem occurs that gets logged to the > "fatal" log. Really, to find out all surrounding context, you need to > merge all logs. Unless there is a common sequence number or something > like that, you have no way of really knowing what sequence of events led > to the problem since they are scattered about in a number of logs. You > can make good guesses, but in large that handle multiple requests at the > same time, it becomes very difficult. > > I'd prefer a common log, which records levels. > > I also think the concept of multiple log variables is important in large > systems, where different subsystems may have different log levels (e.g, > turn on all logging for new subsystems, and only critical logging for > other subsystems). [Bennett, Patrick] Agreed. With the current system I use, there are have multiple logging 'topics,' each of which can be assigned real-time a 'current' tracing/verbosity level. Each logging macro is defined as being a particular verbosity level as well - so things like status/notes/warning/error/etc. break down into general verbosity level ranges. A specific message type is associated with the message as well, although it typically matches the verbosity definition. Specific topics can then be associated with one or more logging 'sinks.' Logging a message for any given topic will only happen if its currently set level is >= the level the message is defined to log at. The message then gets sent to all associated sinks (for output across the network, to disk, to the console, etc.). The topics are associated with the named 'subsystem' (typically a friendly version of the process name) [the subsystem/topic name is what defines a unique topic] and can be modified from other management processes by adjusting levels per subsystem or by topics used by it. In my mind at least, it would be nice to see the boost logging library adopt some of these concepts. Patrick Bennett

1 0

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