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

[typeof] help needed with porting
by Arkadiy Vertleyb 27 Apr '05

27 Apr '05

Hi everybody, If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what the results are? You can take the library at its usual place: http://boost-sandbox.sourceforge.net/vault/, typeof.zip Thanks a lot in advance. Regards, Arkadiy

6 14

Boost to the rescue
by Fernando Cacciola 27 Apr '05

27 Apr '05

Hi people, A link to this was recently posted in c.l.cpp.m but I thought you all would like to read it... http://www.neward.net/ted/weblog/index.jsp?date=20050413#1113402903230 Enjoy Fernando Cacciola

13 16

[Boost-bugs] [ boost-Support Requests-1190931 ] bcc55 internal error compiling example simple_ls.cpp
by SourceForge.net 27 Apr '05

27 Apr '05

Support Requests item #1190931, was opened at 2005-04-27 04:40 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=1190931&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bcc55 internal error compiling example simple_ls.cpp Initial Comment: I have environment variable BCCROOT set properly. Yet, I get many warnings and internal error in the end. Warnings are of three types: 1. Warning W8097 ...../boost/config/auto_link.hpp 240: Not all options can be restored at this time 2. W8062 ...../boost/config/abi_prefix.hpp 22 (and 25 - the same) : Previous options and warnings not restored 3. W8026 ...../boost/limits.hpp 86: Functions with exception specifications are not expanded inline (this one I understand what it means) Fatal F1004 simple_ls.cpp 74: Internal compiler error at 0x40638d with base 0x400000 in function main(int, char * *) Fatal F1004 simple_ls.cpp 74: Internal compiler error in function main(int, char * *) ---------------------------- I need some help... please. Does anyone know how to compile anything with bcc 5.5.1 and boost libraries ? Thank You. Holy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1190931&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

[program_options] Recent changes
by Vladimir Prus 27 Apr '05

27 Apr '05

Hello, just before feature freeze, I've committed some changes to program_options: - the command line parser was refactored. For historic reasons, it has its own data structures for representing options, and now it uses the options_description class. The internals were also cleaned up. - the 'implicit' option flag was removed. I've asked for comments on this some time ago, and no objections was raised. - some methods of 'options_description' and 'option_description' classes were removed - In 1.32, the 'additional_parser' could return only a single option. There's a new method of command line parser -- 'add_style_parser', which can be used to specify a function that can return vector<option>. This might be convenient, for example, for parsing response files Except for 'implicit' removal, those changes should not affect users of the library. However, I'd appreciate if user test the new version and report any problems. - Volodya

5 21

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

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

how to use boost in VC6
by sanduoren 25 Apr '05

25 Apr '05

I'm a learner of boost.But the boost make me head ache.for example, I can't use /boost/algorithm/string.The VC6 compiler gives hints: yes_no_type.hpp(22) : error C2265: '<Unknown>' : reference to a zero-sized array is illegal yes_no_type.hpp(23) : see reference to class template instantiation 'boost::algorithm::size_descriptor<I>' being compiled who can tell me how to use boost in VC6

9 10

Re: Logging Library -- Formal Review
by Tom Brinkman 25 Apr '05

25 Apr '05

Thanks for your submission John. I've added your library to the review queue. Contact my private email to make further arrangements about a review manager and review start date. If you feel that it is ready, we should be able to get it reviewed within the next month or two. Tom Brinkman reportbase(a)gmail.com Boost Review Wizard

2 1

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 25 Apr '05

25 Apr '05

On Sun, 2005-04-24 at 14:13 -0700, Don G wrote: > Hi Peter, > > Can you give an example of a developer that absolutely > > insists on a single-threaded implementation (not > > interface)? > > I think Iain Hanson is that camp. Could be wrong. > Yes. To support platform that do not have preemptive multi-tasking. /ikh

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 25 Apr '05

25 Apr '05

On Mon, 2005-04-25 at 00:50 +0300, Peter Dimov wrote: > Don G wrote: > >> This doesn't make any of these streams networks, > >> and neither is a communication port a network. > > > > I won't debate semantics here (too much<g>): Once the line is up, > > communications between A and B occur in exactly the same way as they > > would with TCP/IP. Both ends "listen" for incoming stream connections > > on multiple ports (each for a different "service"), each can accept > > one or more datagrams on different ports, again for different > > services. In a nutshell, they are abstractly identical. The big > > difference is that the entire network consists of two hosts. > > Yes, I see. I was thinking of a different scenario, however, one in which > you communicate with a device over a serial line (not with another host) > using a specified protocol. Since serial lines are relatively slow, > asynchronous communication is a good thing. > > >> This of course leads to the obvious question: > >> which network gives me a stream over COM1? > > > > network_ptr com1 = > > new net_over_stream( > > new stream_over_serial("com1")); > > Wait a minute. Which network creates the stream_over_serial? Assume that I > don't need the outer network since I'll be communicating with a printer, for > example. > > >> LPT1? > > > > network_ptr lpt1 = > > new net_over_stream( > > new stream_over_lpt("lpt1")); This is wrong IMHO. These are devices. If you want to implement a network over them then it should be done with device drivers. E.g you could implement PPP over COMn and then access it via socket or net:: lib via TCP or UDP. /ikh

1 0

boost::function and boost::serialize
by mysticdevil＠gmail.com 25 Apr '05

25 Apr '05

I would like to be able to serialize boost::function objects with the boost::serialize library, and i really don't know anything about the internal structure of boost::function nor how it works, and when trying to read the headers i really get lost there. So could anyone give me a hint or something on how to make a wrapper for boost::function (i know that function address might change from executable to executable, and also for run to run, that's why i thought "adding" a translator, that i assing a name to each function i have a pointer to, and when it serializes it it saves the name, and when loading, it search the address of the function with that name)... if you know how this could be done, or have any hint i will greatly appreaciate it... Also i would like to know how boost::serialize handles the shared pointers, because i my own designed objects with reference counting, and i don't know how to serialize them (to preserve shared behavior), and also i have the doubt, what happens, if i have an object shared 8 times in memory, and i only serialize it 4 times, so when i load it again, the counter will say 8 or 4?. Thanks you very much...

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 25 Apr '05

25 Apr '05

On Sun, 2005-04-24 at 17:45 -0700, Don G wrote: > Hi Mats, > > It's good to have someone with experience in non-TCP environments! > Glad you're here. > > > The X.25 API doesn't provide the equivalent to the tcp > > listen(2) backlog parameter. To drive an X.25 acceptor > > to be capable of accepting incoming calls at a high > > rate, one has to implement the backlog oneself. This is because you are doing this in the wrong place IMHO. ( see below ). > > Perhaps this is something that should be part of the impl of the > acceptor for X.25. That would make X.25 and TCP the same in this > sense (there are no doubt other differences of which this is just > one). No. You are comparing apples and oranges. TCP is a transport layer protocol and X.25 is predominantly a Network layer protocol. A connection Oriented equivalent to IP. The correct place to do this is with a device driver 99.9% of the time. /ikh

1 0

[threads] read_write_mutex performance
by Peter Dimov 25 Apr '05

25 Apr '05

What are the design goals of read_write_mutex? (Lock proliferation aside for a moment.) My understanding has always been that read/write locks are an optimization, that is, a read/write lock-based algorithm should deliver better performance than the same algorithm with "ordinary" locks. Right? Wrong. The program at the end of this message demonstrates that in this specific (contrived?) case ordinary mutexes outperform a read/write mutex by a factor of 2.5 or more in almost every scenario, even when no writers are active! In some scenarios (16 readers, 4 writers, 10,000,000 iterations) the ordinary mutex case completes in under 8 seconds on my machine, but the read/write case exceeded my patience threshold. Am I missing something? -- Peter Dimov http://www.pdimov.com #include <boost/thread.hpp> #include <boost/thread/read_write_mutex.hpp> #include <iostream> #include <vector> #include <time.h> //#define RWLOCK int const n = 1000000; int const n_readers = 16; int const n_writers = 0; std::vector<int> v; #ifdef RWLOCK boost::read_write_mutex mtx( boost::read_write_scheduling_policy::alternating_many_reads ); #else boost::mutex mtx; #endif void reader_thread() { int m = 0; for( int i = 0; i < n; ++i ) { #ifdef RWLOCK boost::read_write_mutex::scoped_read_lock lock( mtx ); #else boost::mutex::scoped_lock lock( mtx ); #endif m += v[ i ]; } std::cout << m << std::endl; } void writer_thread() { for( int i = 0; i < n; ++i ) { #ifdef RWLOCK boost::read_write_mutex::scoped_write_lock lock( mtx ); #else boost::mutex::scoped_lock lock( mtx ); #endif v[ i ] += i; } } int main() { v.resize( n ); boost::thread_group group; clock_t t = clock(); for( int i = 0; i < n_writers; ++i ) { group.add_thread( new boost::thread( writer_thread ) ); } for( int i = 0; i < n_readers; ++i ) { group.add_thread( new boost::thread( reader_thread ) ); } group.join_all(); t = clock() - t; std::cout << static_cast<double>( t ) / CLOCKS_PER_SEC << '\n'; }

5 5

Build Dimov's simple Boost.Threads test without bjam...
by Sam Ferland 25 Apr '05

25 Apr '05

Hi, I have used various boost-libraries before but now, when I am trying to build the simple Boost.Threads test application posted by Peter Dimov on this list the other day (http://tinyurl.com/aotq7) I am stuck :-( I copied and pasted Peter's code into an empty Win32-Console-project in my development environment - which happens to be VC++7.1... When trying to get the build through, I get the error: "Mixing a dll boost library with a static runtime is a really bad idea...". This message is probably more than enough for most experienced Boost and Windows developers to say - Oh yes, my stupid #¤*@£¤ I must of course do that and that too, to get the build through. However, poor me is left clueless. I have once built all of boost using bjam so I have two different boost_thread- vc71-mt-*.dlls and the corresponding lib-files within the boost/lib-folder. But I do not know how to set-up my project to first get the compile and then the link through. And I cannot find any helpful information in the Boost.Threads documentation?! Even Google didn't provide any help... So I'd be very glad for any help from you guys! Regards, Sam

4 3

Yet Another Network Library
by Giovanni P. Deretta 25 Apr '05

25 Apr '05

Hello fellow boosters, after months of lurking on this list and seeing how everybody seems to have its own network library, i've finally decided to put online mine. I will upload it under the vault as nanostream.tar.gz, it is unix/linux only currently. You may want to skip the library code and read the pdf under the doc directory where the library is shortly presented and some examples are given. These are the main features/peculiarities of my library: - There is no socket concept because i don't really think it is natural, at least not for a C++ programmer. I use the acceptor, connector and stream concepts. - User is not required to reference streams by pointer, streams are stack allocated or are simply members of another object. Internally they have a smart pointer to an implementaion handle. Consider them stack-based proxies. The acceptor and the connector return the handle that is asigned to the stream. - The preferred way to do input output is to use standard-like algorithms (i.e. copy) with buffered stream adaptors and specialized input/output iterators. I believe that an efficient library can be written this way and be very C++-user-friendly. Classic read/write are still available, but their semantics might be surprising. - All classes are concrete, no polymorphism is used (i.e. no virtuals). Polimorphic behaviour must currently be achieved with some external mean (i.e using the external polymorphism pattern. I think that the boost::IDL library would be great). - Errors can be reported both with exceptions and with error codes. Exceptions are used by default unless error callbacks are passed. This seems to work quite well. Internally only error codes are used and exceptions are thrown only at the most external abstracion layer. Note that the library does not actually use error codes, but error types using a specialized variant object. This is just an experiment and i might remove it. I will probably add status bits a-la iostreams. - File streams. The library actually try to be a generalized i/o framework, and file streams are provided for completeness. - The library can be extended simply by creating new handles. In addition to TCP streams there are Unix streams (come almost for free :-) and file streams. SSL/TLS was present but did get broken some time ago and didn't have the time to fix it. - Input/Output buffer. This is very similar to a std::deque<char>. It has segmented iterators support (the same interface presented in the Austern paper), and it is the preferred input/output buffer, it can be easilly grown on both directions (usefull if you need to add an header) and can be efficiently read/written with scatter-gather operations. While i have yet to implement it, i think that moving data from a buffer to another can be done extremely efficently by splicing the internal pages. The buffer is also used to implement the buffered adapter. boost::arrays, vectors and plain arrays also work fine, while other containers require a bounce buffer and thus slower operations. - Addresses are logically defined by a triplet <domain, host, service>, where the domain is implicit in the acceptor, address, or connector type, host and service are two strings. This is inspired by the getnameinfo(3) interface. - A multithreaded stream adaptor and an http module are also included. These are just proof of concept and not really part of the library (yet). Missing (definitelly not complete list): The library is fully sinchronous for now. I'm still considering how to add asynch support. I think i will implement it in the buffered adaptor I/O is done asynchronously to the internal buffers that can grow as much as it is necessary. Timeouts are definitelly a must-have. Final notes: I've have seen that the current consens is to encode the the stream type in the address, so to allow a dynamic behaviour: the actual transport is selected only at runtime, based on the address string. I think this is a bad decision (i considered doing it while implementing my library) and this is why: - C++ is a static language, let's leave these niceties to more dynamic languages. I have found myself weeks hunting a bug in the http code because i thought that it would be cool if i could access http properties using a map instead of proper accessor functions. I spent weeks hunting persistent connection bug. It was a simple typo inside a http property string that would have been caught immediately by the compiler if i were using functions or costants [1]. - It mimics standard library usage. You cannot open the input stream instead of a file by using the "input:" file name. (well under Unix you might actually do it, but i don't think this was the intention of the standard library authors and it is not portable any way). - It is extremely insecure. In a network library security must be paramount. If the transport type were encoded in the address, it would be much harder to validate externally received addresses. A similar argument can be made for the port numbers. It is better to keep these things separated. The library user can create its own indexed factory collection if it really needs to. Sorry for the long post, just tryin' to be usefull :-). -- Giovanni P. Deretta 1 - I did write "Content-Length" instead of "Content-Lenght".

9 15

[1.33] weak_ptr_timing_test.cpp, OK to commit?
by Peter Dimov 25 Apr '05

25 Apr '05

I've created a new timing test, libs/smart_ptr/test/weak_ptr_timing_test.cpp. It tests the performance of weak_ptr in a single-threaded scenario. This test is not referenced by a Jamfile and is not intended to be run by default. OK to commit? -- Peter Dimov http://www.pdimov.com

1 0

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Boris, > on what part of the network library are you working? It > seems like you are in level 1 without I/O streams - > whatever this part could be called. :) If I understand the levels right: 1 - Socket API wrappers (RAII, type-safety mostly; minimum overhead) 2 - Connector, Acceptor, Connection 3 - iostream integration Then, I guess I would place the ideas I proposed at level 1.5 :) > If I look at the extremes - wrapper classes for the > C API and an acceptor-connector pattern with service > handlers like in ACE - where is your library? You are > somewhere in between if I am right: I don't see any > socket class but see classes reminding me of network > functions. The crux of what I am proposing is a layer that encapsulates sockets behind an abstraction, which would place it between sockets and ACE-like designs or whatever else. Many, but not all, implementations of that abstraction would be based on sockets, select, epoll, kqueue, etc.. At my work, where this design was born, we have a direct serial implementation and an HTTP-tunnel implementation. We have also implemented the stream abstraction for NT named pipes and SSL (using OpenSSL). By virtue of the abstract nature of things, we can use SSL over named pipe for example. Or SSL over serial line (you get the idea<g>). > Do you think we need another layer? Personally, I think the layer I proposed is vital to higher level designs that can be reused (on different platforms or over different network implementations). Not only designs, but also protocol libraries. For example, (if it weren't for proxy servers<g>) the code needed by an HTTP client to support HTTPS would be something on this order of complexity: void http_get (net::network_ptr net, const net::url & url) { net::stream_ptr stream; stream = net->new_address(url)->new_stream(); stream->connect(); // handle SSL: if (url.get_scheme() == "https") stream = ssl::new_client_stream(stream); // now using SSL - or not! } Lower level ideas (like socket and fd_set) imply an implementation that may be completely inappropriate. A bidirectional stream is an idea; it is not a socket. So, yes, I do think we need this layer or one much like it. And it must be much lower level than <iostream>. The abstraction I proposed is a direct rendering of general network concepts (influenced by TCP/IP, which might mean it needs some further generality). It imposes only the overhead necessary to adapt sockets to C++ ways of thinking. > Shall we drop the acceptor-connector pattern? I have acceptor in my proposal, but connector didn't seem (to me) to be an entire class/object. I have an address object as the Abstract Factory for a stream object, which is similar to a connector concept except that the connection process begins with a method on the stream object. In other words, the stream is created in an unconnected state and it is that stream that we want to connect. This felt like a much better fit to the problem at hand (again, to me<g>). > Is your library which belongs to level 1 a neighbour > of an acceptor-connector based package with different > goals? My goal is to iron out a behavior contract that satisfies various possible and desired implementations, so that a library user can know what are safe and portable practices. One could say that the sockets API does this, but there are two central issues: one cannot create a new type of socket (to layer protocols); not all forms of I/O completion are portable. So, underneath my proposal are many implementation choices. Likewise, on top of it can be abstract ideas about services or request/response patterns and the like. The layer is conceptually complete (or should be made so by adding new abstractions). The only reasons I see for going around the layer I propose would be: use of platform-specific features or performance. I believe it is too early for performance conclusions of what I am proposing. That is a job best left for measurement, which is why I wanted to proceed with things at SourceForge. I can say that based on my previous implementation of this design, I know it can perform very well. Perhaps not as well as some direct-sockets approaches. Certainly not as well as feeding the network driver directly from the file system driver's disk cache, but life is full of trade-offs. :) I hope I have answered your questions. Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

5 19

more \r\r\n found in files
by Victor A. Wagner Jr. 25 Apr '05

25 Apr '05

I edited and committed the following files: boost/none.hpp boost/none_t.hpp boost/iostreams/character.hpp boost/iostreams/operations.hpp boost/iostreams/positioning.hpp boost/iostreams/reverse.hpp boost/iostreams/detail/system_failure.hpp boost/iostreams/detail/streambuf/linked_streambuf.hpp boost/iostreams/detail/vc6/operations.hpp boost/iostreams/filter/symmetric_filter_adapter.hpp libs/iostreams/src/mapped_file.cpp libs/optional/test/optional_test.cpp libs/optional/test/optional_test_common.cpp libs/optional/test/optional_test_ref.cpp because they all had lines ending in \r\r\n Two thoughts occur to me regarding this situation. We should publish widely the names of the person(s) who write editors that create such files and the person(s) at Microsoft who decided to make VC8.0 do: error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format After we publish their names widely we should hold them up to public ridicule. I point out that there is no legitimate defense for the behavior of the VC8.0 compiler. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Peter, > I like the proposal. It shows a certain polish that only > comes with real-world experience with a design. ;-) Thanks! > I have the following comments for now, based on a > not-very-deep look at the document and the header: Thanks for all the feedback. > 1. network root class > > In my opinion, this class is not needed and should be > removed. It complicates the design, forces a global > variable on the user, and is not library-friendly. For > example, if lib1 and lib2 use the network, the user > can't pass an address created by lib1 to lib2. The > global state modeled by the network class should be an > implementation detail. In many of my uses, I have multiple network-derived types in use at the same time (serial, HTTP tunnel, TCP/IP). I agree that it can be an issue, so perhaps there should be a way to associate code with a particular kind of network and not need the network object. Having said that, though, I think this assumed context should only be a default to be used when the calling code has no network object in hand. All libraries should accept and pass along the context. Otherwise, one could not reuse protocols over different networks in the same app. While this can be seen as an issue, most of the time I find that I need to pass something along already: an address object or a stream, for example. That is sufficient to get back to the network object. It is also OK to create multiple network instances of the same type, though it should not be done with impunity<g>. > 2. address > > The address should be a standalone class and not tied > to a particular network. I think different networks (in my uses anyway) have different expectations (data size, textual form, etc.). This lead me to the conclusion that an address is an abstract idea. Its primary role is a factory for other objects related to the address it describes, which is again not something a concrete type would be able to handle (at least w/o indirection hidden inside). > It should be a simple entity and not a hierarchical > container. Logical to physical resolution should take > a source logical address and produce a container of > physical addresses. This container is often needed internally and, in my experience, seldom needed by the user. It is helpful for the logical address object to know the corresponding physical addresses and not have to repeat the resolution process. I see no fundamental problem exposing this collection as std::vector<address_ptr> (or whatever) and not providing an interface to encapsulate it, but I was trying to keep things purely abstract. > The address should not be created with an URL, that is, > a TCP connection to www.example.com should be represented > by the address tcp:/www.example.com:80, leaving > http://www.example.com reserved for the stream obtained > by the HTTP GET / query, not for the raw protocol stream. > A connection to the serial port should probably be > represented by "com1:/38400,n,8,1", and so on. This scheme morphing seems to fit with the idea that network instances are behind the scenes, but creates complexity for the user as well since these transformations must be done at that level. For serial use, it is not sufficient to say "com1" (that was a concept I had early on as well). That would address an entire network, not a specific "port"-like concept. I think the "U" in URL is really fitting for this model. There is a lot of thought behind URL's and they have the right level of generality. IMHO, we do not need another textual form for addresses. > I think that the UDP broadcast address should be > represented by udp:/0.0.0.0, and the TCP loopback > should be tcp:/127.0.0.1, as usual. But I may be > wrong. All of these are forcing TCP/IP (IPv4 even<g>) concepts to the user. The central idea of the abstraction I proposed is that "datagram" and "stream" are the behavior-bundles to which one should write protocols, not TCP/UDP or sockets. The notion of loopback and broadcast can carry over from one network type to another, but these textual forms do not. That said, this will work given an IPv4 network object in my proposal: strm = net->new_address("127.0.0.1:80")->new_stream(); It is just not portable to IPv6 or any other network type. Hence, one is better off saying: strm = net->new_loopback_address()->new_stream(); > 3. Minor stylistic issues > > p->get_X() should be p->X() Personally, I go back and forth on this<g>. I suppose that std::basic_string<>::length is the right form to follow. I currently like the get_X/set_X symmetry, but will change back in the proposal. > p->new_Y() should probably be p->create_Y() Is that a preferred verb for Abstract Factory? I should reread that chapter... :) I chose "new" because it advertised exactly what must happen: a new instance is made. Not that I am wedded to it, if there is ample precedent for "create". > although it might be better to move to > net::create_Y( p ) or even to Y( p ) and reference > semantics under the hood. The approach I took (based on shared_ptr <g>) allowed for clear ownership, copy and layering semantics. In other words: net::stream_ptr stream = ...; stream = ssl::new_client_stream(stream); At this point, the new SSL stream impl drives the original stream which it can rely upon to exist until it is done with it. From the user's point of view, the SSL stream is now _the_ stream. > The destructors should be protected. Agreed. > 4. MT-centric model > > The general idea of an asynchronous callback dispatcher > is sound, but the threading decision should be left to > the user. The library should provide > > void net::poll( timeout tm ); > > that delivers any pending callbacks from the context of > the thread that called poll, and > > void net::async_poll( error_callback ); > > that acts "as if" it executes net::poll( infinite ) > repeatedly in one or more background threads. > (error_callback will be called on errors; the > synchronous variant will probably throw an exception > instead.) The threading choices are certainly the most complex. Having said that, these are mostly implementation choices, not interface choices though one might need to extend the interface to support ideas like the one you propose. The complexity really shows up when one wants to write protocol libraries. For each choice presented to the network user, the protocol library probably needs to provide similar support. For example, an HTTP library would need to provide sync and async under my proposal. Adding more styles of notification to the network layer probably makes this job more difficult. Not to pass final judgment here; just a consideration. In my work on this, I attacked thread affinity outside the network layer for the most part. In particular, what you called net::poll() I had as a different object that handled a queue of boost::function<>-like objects. That way, the main thread was not forced to be only a network thread. I do see room for this approach in cases where the main thread wants to be a network-only thread and the queue approach feels too heavy. I think that this would fit in my proposal as a different concrete network-derived class as long as the abstraction is the same: sync and async (with other rules TBD). > Whether the library uses multiple threads under the > hood, or how many, is implementation defined, even if > async_poll is not called; this depends on which model > delivers the best performance on the specific platform. While I agree to some extent, the user must know the context in which callbacks will be made. Or at least, they need to know a set of rules to follow that will keep their code working for all implementations. Forcing a single-threaded view of the network on the user imposes its own penalty. At the top-most level, the programmer should have some (hopefully small<g>) number of concrete network objects to pick amongst. Once chosen, all mid-level libraries need to know that their expectations of behavior are still going to be met. At the bottom, we do what seems best to implement the abstraction on a given platform. > 5. read_later, etc > > I think that read_later should be dropped. async_read > is enough, in my opinion. Personally I have little use for non-blocking style, but there is a lot of desire for it. And it does have its merits for buffering data. > The functionality of write_later should be achievable > with a call to async_write with size 0; write_later > can be dropped, too. I debated this myself, but decided to apply the axiom "don't parameterize behavior" and ended up with the x_later approach. Under the covers, they will be very much like async_x with no buffers on which to operate. > async_read should not take a buffer; instead, the > callback should receive a pointer to a buffer managed > by the library that is guaranteed to be valid for the > duration of the callback. (Not by default, at least.) > > async_write (by default) should not assume that the > passed buffer stays valid after async_write returns. > > Rationale: buffer management is a pain with multiple > callbacks active ;-) Others I believe have commented on this, but my take is that this level should not make assumptions about the ultimate destination of data. This approach, would in many cases, force data to be copied "one more time". I agree that this can be a painful process, but perhaps this is where higher level abstractions come into play, or possibly (as you suggest) optional additional features for this abstraction. Maybe passing (NULL,0) for I/O requests, or some sort of set_buffer() mechanism. Don't know. > That's it for now. Please don't take these as criticisms > and wherever you see "should" read "in my humble opinion, > the design probably could be enhanced by". Please understand my responses in the same way. :) I (try<g>) to never take criticism of designs personally, and I do feel that all criticism, especially constructively phrased as yours, is only beneficial to everyone. > Thanks for reading. Nope - thank you for taking the time read my proposal and then respond with so many ideas! Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 16

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Peter, >>> This of course leads to the obvious question: >>> which network gives me a stream over COM1? >> >> network_ptr com1 = >> new net_over_stream( >> new stream_over_serial("com1")); > > Wait a minute. Which network creates the > stream_over_serial? Assume that I don't need > the outer network since I'll be communicating > with a printer, for example. Serves me right for being glib. :) Here's what I meant: class stream_over_serial : public net::stream { public: stream_over_serial (string comport); }; This is a net::stream impl over the named COM device. On Windows, this might use lineOpen. Now that we have a stream, we wrap it in a network: class network_over_stream : public net::network { public: network_over_stream (net::stream_ptr strm); }; The caller of all this is whom so ever wanted a network running over the COM port. (glib again, I know<g> but this is just a sketch). FWIW: We use host names like "g" and "h" for "guest" and "host" where the "guest" is the initiator/active open and "host" is the acceptor/passive open. The new_local_address() would return "g" as a physical address on the side that did the above. > My point was that different network objects can > interpret the same address to mean different > things, at least in theory. URIs are supposed to > be context-independent. I see your point. Your suggestion of encoding the network as part of the URI would solve this. That could be a global map/table or a multi-net impl of net::network (one that was a net::network and wrapped a collection of network's; not that I want to go there<g>). But, these schemes would still compete with the set defined for the Internet (the http:// form should work since it is universal). The issue was that I wanted user visible addresses to be familiar (such as the now infamous "http://www.boost.org"). Given that desire, and the fact that our most heavily used network impl was TCP/IP, I had no problem with this level of abuse. ;) Also, the same protocol can run over multiple nets, so "foo://G" or "foo://10.0.0.7" just made some (twisted<g>) sense to me and I never worried about the ambiguity. Do you see this as an acceptable abuse, or as doing violence to the RFC? :) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: Yet Another Network Library
by Don G 25 Apr '05

25 Apr '05

Hi Michel, > Even if we go for a interface/inheritance based > approach is would like to expose tcp_stream/ > tcp_connector/tcp_acceptor/udp_stream et al and > the like so the user could instantiate a concrete > implementation and not going through the address, > dynamic factory thingy. There might be specifics > in these classes that you care for if you only > support tcp eg. Do you have any specifics in mind? If they are general in nature, they really belong in the interface. Many things can be optionally meaningful even if they are not universal (eg: flush). Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[1.33.0] Please update index.htm for new libraries, updated libraries, etc.
by Douglas Gregor 25 Apr '05

25 Apr '05

There are several new libraries in Boost for the 1.33.0 release, and many that have changed. Developers: please update index.htm in CVS to announce your changes. Also update libs/libraries.htm if you haven't done so already. Doug

3 2

RE: [boost] Use of Other Languages in Boost Tools
by Martin Bonner 25 Apr '05

25 Apr '05

----Original Message---- From: Allen [mailto:yaozhen@ustc.edu] Sent: 23 April 2005 07:28 To: boost(a)lists.boost.org Subject: [boost] Use of Other Languages in Boost Tools > The obvious two attitudes I can imagine are: > > (1) Prohibit *extensive* use of other programming languages in Boost > tools, for example writing a complex tool in Python completely. > (Convenient and small scripts are acceptable.) For we are establishing > the Best Practice *in* C++ and *for* C++. In addition, the tools can > be extensible and reusable with an API for C++ programmers as > *developers* not just as *end-users*. > > (2) Allow extensive use of any convenient and reasonable programming > languages in Boost tools. Maybe there should be a list for acceptable > languages other than C++, for example shell scripts, Perl, Python, > Ruby, etc. For they are just *tools*, not C++ *libraries*. They are > just black boxes to C++ programmers, and we do *not* provide the > tools as an extensible tool platform/framework with API for C++ > developers/programmers for further extension or reuse. > > I tend to support (1) I tend to support (2). On the other hand we should avoid using TOO many languages (because that is yet another thing to download and install to get the tool running). -- 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

RE: [boost] Re: Proposal: Design by Contract / Pre &Postconditionslibrary
by Brian Braatz 25 Apr '05

25 Apr '05

General 2 cents: About a year ago I built a library for internal use along the lines being discussed in this thread. (for the curious what I did was hook logging and tracing to the Precondition and postcondition) After I got it all done, I said to myself, OK I am now going to USE this code and abide by it's rules. I found that very difficult to do, because of my OWN difficulties in doing that I have shelved this library for our internal usage. (i.e from a practical nature it would be hard to get people (myself included) to continue to use it) I ask the people thinking about this lib, to sit down and try to write 10 or so functions and get a sense for if you would actually USE it. I am not trying to be a downer, more I am sharing my experience. There may be a place for this lib in the same regard as scope guards are used. Scope guards are nice when you need them, but you don't need them everywhere.... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jarl Lindrud > Sent: Sunday, April 17, 2005 11:47 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Proposal: Design by Contract / Pre > &Postconditionslibrary > > Yariv Tal <yariv_tal2003 <at> hotmail.com> writes: > > > > Do you check at compile time that the used gave all of the variables > > participating in the expression or do you just let the user state which > > variables they want to be displayed in the error message? > > The user just states which variables he'd like to see printed, if the > condition > were to fail, and its fine not to specify any variables at all. > > > > > One thing though, I didn't see any handling of disabling testing post > > conditions when > > an exception is thrown. > > Did I miss something? > > No you didn't... guilty as charged :) > > > > > > > > > Since these macros are part of the function implementation, maybe one > > shouldn't > > > borrow the name "Design By Contract", since that implies a contract > > external to > > > the function. Proper DbC contracts need to be stated at the level of > > function > > > declarations, and would apply to overrides in derived classes as well. > > Point taken. > > Originally I was hoping to add invariants etc., but I didn't get to it. > > Of course, even with invariants it will still be more at the function > level. > > In general, I think there's a lot to do (temporal invariants as in > "keystone > > ", for example) > > and since it is so useful (a fact I discover every time a condition in > my > > code is invalidated) > > it think, IMHO, it should be a library for all to use and for many to > > contribute to. > > Agreed. Formalizing the PRECONDITION and POSTCONDITION macros would be > quite > useful, I think. But I wouldn't be too worried about trying to emulate > DbC, > that's a different concept altogether. > > /Jarl. > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Mats, > >Don G wrote: >> Yes. The "generic async library" I keep mentioning is >> where this is handled w/o the user A) being called in >> the wrong thread or B) the user manually doing any >> posting. > > Sorry if this is covered somewhere, but would the user > have any say in what goes down if an async_read and an > async_write on the same socket complete more or less > simultaneously? (In the presence of multiple worker > threads) > > Sometimes the application logic calls for serializing > the callbacks and sometimes it would be better to > allocate each callback to a different thread, > possibly allowing them to run in parallel. In the approach I was describing, yes, each callback can be bound to a different channel. > I have recently had to deal with synchronization/ > starvation issues caused by this kind of design > (simultaneous pending async_read and _write on > the same socket) in an application using Windows' > OverlappedCompletionPort mechanisms. > > If the callbacks for the read and write operations > both race to lock the same resource (e.g. the > session object mutex), one of the completed > operations will obviously have to wait for the > other. This wastes one precious working thread, > because it is just sitting there waiting while it > could be serving other connections instead. It sounds like you would prefer that both go to the same thread in this case? Again, either would be supported using the design I am proposing. > I tried to alleviate this waste by transferring > the "completion-token" to the first thread. Once > the first thread was done with its first callback > (e.g 'on_read'), it would proceed to handle the > transferred callback (e.g 'on_written') before > returning itself to the pool. > > This made the situation much better, but somehow > tended to cluster related operations, since each > thread would do comparatively more work on one > socket before allowing another session's callbacks > to be processed. > > It made better use of the threads, but possibly on > the expense of fairness. I suppose it always will depend on what happens in the callback whether it is best to have lots of threads banging away or serialize them or plod along with a pool of 1/CPU. All are valid, but a library would be unable to chose which is best. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[testing] Buildbot setup status.
by Rene Rivera 25 Apr '05

25 Apr '05

Just a status update for those that care about my Buildbot efforts. My testing setup is working and recently finished it's first full set of tests which can be seen on the meta-comm pages (runner = RSI-SoL). From this point onward I'll try and keep it running continuously. So if you check something in you can go look at the Buildbot status page and watch when your changes get tested. http://build.redshift-software.com:9990/ BuildBot: Boost C++ Libraries I know it's got some minor glitches, like the platform name is incorrect, but just having it running is more important. And I have the "OnDemand" functionality but not an interface to let people request builds. And I won't have time until much later to write up that web interface. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 3

typeof internals document updated
by Arkadiy Vertleyb 25 Apr '05

25 Apr '05

Hi all, A new section, that describes details of template template parameters support, has been added to this document. I thought this information might be usefull during the upcomming review (still have no idea when it's supposed to happen nor whether we go before or after Eric). Regards, Arkadiy

1 1

Re: [network] An RFC - updated
by Don G 25 Apr '05

25 Apr '05

Hi Mats, It's good to have someone with experience in non-TCP environments! Glad you're here. > The X.25 API doesn't provide the equivalent to the tcp > listen(2) backlog parameter. To drive an X.25 acceptor > to be capable of accepting incoming calls at a high > rate, one has to implement the backlog oneself. Perhaps this is something that should be part of the impl of the acceptor for X.25. That would make X.25 and TCP the same in this sense (there are no doubt other differences of which this is just one). Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 24 Apr '05

24 Apr '05

On Fri, 2005-04-22 at 14:23 +0300, Peter Dimov wrote: > Iain Hanson wrote: > > On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote: > > [ snip ] > > This would give a significant performance hit as there will now be two > > copies of the data. The 1st from kennel space to the library and the > > second in the callback from the library to the user. > > Sometimes, yes, but not always. You don't have to make a copy in the > callback, and for small packets and low bandwidth, the extra copy may not be > significant. Also note the "by default" in the above. I am not against > manual buffer management, just against the absence of automatic buffer > management. > I really don't see this as workable in the general case. The library has to guess the size of the read buffer. It would also prevent reading a complete record on a stream by reading a header up to the length field and then making a 2nd read call for that length with the correct size buffer. It would also add dynamic memory allocation to the library and be a source of runtime errors as a result a user not copying the buffer and trying to use it after its lifetime expired. I know we can't always protect users from themselves but we do try to not make it easy for them to make mistakes. /ikh

4 5

TR2 and Boost fixed_string
by Tanton Gibbs 24 Apr '05

24 Apr '05

With regards to TR2 and Boost, I would like to see a string class that allows a user specified length. For instance boost::fixed_string<100> fs; // synonymn for boost::fixed_basic_string<char, 100> Whether the rest of the class was monolithic like std::string or broken out as proposed by Herb Sutter, I wouldn't care. I often come across uses for this where I don't want to dynamically allocate memory, but I also want the functionality of the string class. Tanton

1 0

Re: [testing] Buildbot setup status.
by Rene Rivera 24 Apr '05

24 Apr '05

Robert Ramey wrote: > It looks like it runs even before I finish getting a whole group of changed > checked in. It's on a 10 minute trigger. So it waits for 10 minutes where it hasn't gotten CVS notifications before proceeding. Looks like you had the commits spaced out in 20, or so, minutes. This is one of those, tweak until we get what's appropriate for Boost development. Should I make that longer? 20, 30, 60 minutes? I don't want to make it feel unresponsive though. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Regression testing and BuildBot discussions
by Beman Dawes 24 Apr '05

24 Apr '05

Dave Abrahams, Doug Gregor, Thomas Witt, and I had a discussion last week at the C++ committee meeting about how to improve Boost regression testing, and the whole process of getting ready for releases. Much of what we talked about has already been discussed on this list, so our conclusions shouldn't be much of a surprise: * Making Boost regression testing as robust, automatic, distributed, and timely as possible is the best way to help developers, release managers, testers, and eventually, users. * BuildBot (http://buildbot.sourceforge.net/) looks like best way to achieve those goals, based on experiments to date. * It would be very helpful if a team coalesces around Rene Rivera to develop BuildBot regression testing for Boost. They will need to stay coordinated with the MetaCommunications folks, of course. The rationale behind the "robust, automatic, and distributed" goals is that many people are willing to volunteer machine resources for Boost regression testing, but they say that other than downloading (and perhaps answering a very few startup wizard questions) they don't have any of their own time available. Thus the vision is of something like the SETI@home project which lets people contribute spare machine cycles without burdening them further. The rationale behind the "timely" goal is that developers will benefit tremendously from faster feedback, both for HEAD and active branches. Automating the feedback will free developers from having to track what is happening on many different platforms. The rationale behind encouraging a team to work on BuildBot regression testing is that this is important to Boost, so it will benefit from a team forming. That should improve and speed development, and ensure that several people understand the system and can maintain the internals. Rene is the logical leader since he has already stepped into that role for BuildBot. --Beman

4 6

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > FD_SETSIZE only applies to select, and nobody > uses select except in "quick and dirty" servers > (as I did recently). Sadly, select is by far the most portable solution. On Windows, it is the only solution for 9x/Me. We can and should write more efficient impls for platforms that support poll() or epoll() or kqueue, etc.. > The idea of an explicit poll() call is to allow > the implementation to use a single-threaded > dispatch mechanism (select/epoll/kqueue), if one > is available. Without poll() you are forced to > use worker thread(s) and a callback queue to > support a single-threaded application, and this > can be considerably less efficient than > epoll/kqueue (or select in the < FD_SETSIZE > case) (in theory). Yes, indeed. Though I may be missing something in your idea about net::poll(). How would it avoid a queue? > Of course, if the threaded model can be > demonstrated to achieve comparable performance, > there would be no need to complicate the > interface with poll(). The "need" is performance and familiarity (IMO). If performance were taken out of the picture, it would be hard to argue for it. I don't know how the comparison would go which is why I was writing some stuff to try it out and get some measurements. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > I see that you are slowly moving away from your network-centric > scheme after you've already convinced me of its merits. ;-) Not exactly. Just trying to explore it completely :-) In other posts I state that my thinking is still as I originally proposed. I just see some use cases where your approach has merit; perhaps it is best left to the app but could be provided as a library of its own. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: TR2 and C++0x heads up
by JOAQUIN LOPEZ MU?Z 24 Apr '05

24 Apr '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Sábado, Abril 23, 2005 11:32 pm Asunto: [boost] Re: TR2 and C++0x heads up > "Beman Dawes" <bdawes(a)acm.org> wrote in message > news:6.0.3.0.2.20050422110501.042b2a20@mailhost.esva.net... > > | So far there are plans to propose Boost.Threads, > Boost.Filesystem, and > | Boost.Signals. As well as proposals for some of the more major > libraries, I > | personally hope someone will do a sweep through Boost looking at > some of > | the smaller utilities and helpers for a possible "Small Additions" > | proposal. > > I believe Alisdair was considering to work on boost.format. > > Besides, boost.date_time I think these other libs are good > candidates (maybe > with slight modifications): > > 1. conversion > 2. optional > 3. string algorithms > 4. utility > 5. variant > 6. iostreams > I'd add a tokenizer to the bunch. Not specially sexy but massively helpful --the typical impulse of a beginner is to do the tokenizing stuff by hand, many a time resulting in off-by-one errors, mishandling of unexpected separators etc. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Patch for bug in boost/boost/iterator/zip_iterator.hpp
by mstone＠cs.swarthmore.edu 24 Apr '05

24 Apr '05

boost/iterator/zip_iterator.hpp has an incomplete #include guard. This patch adds the necessary define to avoid redefinition errors when zip_iterator.hpp is included more than once. Michael

2 1

lists.boost.org not updated
by Peter Dimov 24 Apr '05

24 Apr '05

http://lists.boost.org still links to the old archives. -- Peter Dimov http://www.pdimov.com

1 0

[smart_ptr] sp_counted_base_cw_x86.hpp for release?
by Rene Rivera 24 Apr '05

24 Apr '05

Peter, Should I add the sp_counted_base_cw_x86.hpp implementation in or not? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 3

como toolset failures
by Bronek Kozicki 24 Apr '05

24 Apr '05

I think that big part of failures in como toolset are due to --a (strict mode) option. This unfortunatelly prevents windows headers from being included. Or more precisely, the exact reasult of including windows headers with --a option on is that compiler chokes on __declspec, which is exactly what I see in results. I'd rather not update como toolset to remove this option, maybe someone more familiar with bjam will do this. B.

3 3

Is there an IRC channel discussing boost?
by Schrom, Brian T 24 Apr '05

24 Apr '05

I did a modest amount of Googling and looked through the website for an IRC channel. Did I just miss it, or is there not one? Thanks. Brian S.

3 2

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Michel, >> The reason I suppose that I preferred not-yet-connected >> as a state of stream (vs. a separate class) is that it >> is logically a 1-to-1 relationship (and even the same >> socket) whereas acceptor is a 1-to-N relationship (the >> acceptor socket never becomes something else). > > I don't see connector as 1 to 1 concept. You can use a > connector to establish several connections to the same > address or endpoint if that is needed. The connector > pattern can be used to model fail over between > different endpoints providing the same servcie, by > having a service_connector implementation that wraps > and coordinates several alternate connectors to > different end points over potentially different > transports. This also hides/abstracts the fail over > strategy new endpoint selection in a nice way from > the protocol handler and stream. I see this as something useful, but at higher level than what I am proposing. That may be just because I have never needed anything like it. ;) In all my own uses of connection establishment, it has been one-off connections. Occasionally, I need to reconnect to the same server, but I have always done that with the address object in my proposal. >> The other reason I went with the approach I have is >> that there is only one object to deal with for cancel. >> I don't need to worry about the transition from >> connecting to connected when I want to abort. > > The exact ownership of the socket/handle is always > clear either the connector owns it during the > connection phase and when it's connected the > ownership is transferred to the stream. So I don't > see this as a potential problem. The scenario I am describing goes along with the above statements on single use: I want to do an HTTP get. I first connect, then write, then read. If I decide to cancel, especially with threads in the mix and using blocking style, I must know that I am blocked on the connector, not the stream. But this is not so easy to "know". I cannot hold a lock while I am blocked on connect. What this does is create a race: the entity wanting to cancel cannot know if the blocking call has just finished or not. Which is why I don't like sync programming anymore! ;) I see the granularity as not getting along well with the desire to cancel a specific operation that required a connection. This is especially true for reuse of the connector in the environment I just described. I hope this clarifies my concern. I really feel that a granular cancel feature has to be part of the design. Preferably in a way that is MT friendly. :) > Seperating the connection establishment would make the > stream more stateless and have fewer concerns and it > separates responsibility keeping the interfaces easier. > I also doesn't imply inheritance as is the case whit a > connectable stream. You also don't have to handle > questions such as if a stream can be connected again > after it is closed and so forth (and i guess this could > be different in different implementations). The stream still has many states; this eliminates only one. Also, I don't see any (good<g>) reason to reuse streams. That would be particularly bad in a MT scenario. >> Some platforms have socket features that aren't available >> on other platforms. Unix has signal-driven I/O, while >> Windows does not. Windows has event object based I/O, >> completion ports, HWND messages, etc. which are unique >> to it. The common intersection is blocking, non-blocking >> and select. One can write 99% portable sockets code based >> on that subset. > > So basically layer 0 should support this portable subset. Well, I would mostly agree, but I don't think everyone will. One of the goals several people have expressed is the ability to use level 0 wrappers in non-portable ways. What I am proposing is that there be a level 1 that provides a less bumpy, more easily handled, but conceptually very similar interface. This was another reason I don't have a connector object; that concept has no association with layer 0. > You can define FD_SETSIZE to some arbitrary number. On > my FC1 including select.hpp FD_SETSIZE is 1024 so we > will have to handle arbitrary limits in the interface. > On windows select could be implemented using > WSAEventSelect and WaitForMultipleObjects but this will > have to be cascaded to other threads if the set is to > big and in that case handles can be mixed. So either we > have to cater for arbitrary limits, letting the user > implement on top of the limitst. Or remove arbitrary > limits at cost of complexity and probably increased > threadswitching. On Windows, you cannot increase the fd_set size limit, but I think you are correct on Unix that you can increase it. I have never tried because I wasn't sure if that would require kernel recompile<g> and it wouldn't solve my problem even if it were possible. I would not want to do the thread cascade approach (ala Cygwin). I think a much better approach is what I am proposing: hide this detail completely. I am still scratching around in my head for a way to allow true single threaded use (similar to Peter's net::poll suggestion). > Yes the rules must be really clear, and the library > should probably never hold any kind of lock when > calling a user defined callback since that i > genreally very error prone and deadlock creating, but > this also makes it really hard to implement ;) but > also interesting. Yes, quite "interesting" :) And you can remove the "probably" between the "should" and the "never"... ;) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Use of Other Languages in Boost Tools
by Allen 23 Apr '05

23 Apr '05

Dear All Boosters, I am glad to read about Buildbot on the boost.devel group. It is definitely important for improving the regession test of Boost. However, A question comes into my mind then. As we all known, Boost is a pre-standard versatile C++ library for C++ programmers. Obviously all the Boost libraries are written in C++ themselves. However, for tools used in Boost (such as the Boost.Jam, Boost.Build, Boost.Book, etc.), the point is not clear, for they are not intended to be included or invoked by C++ programs directly. I saw that Buildbot is written almost completely in Python, for example. I am confused that shall we consist of writing all the Boost tools in C++? Or they can be written in any other languages such as shell scripts, Perl, Python, or even Java, C# or whatever convenient? I must declare that I am not a C++ purist or monomania.:) I have no intent to depreciate any of the languages other than C++, nor depreciate any of the valuable work done by Boosters. I just *wonder* what is the distinction between Boost libraries and tools exactly, and whether there is a rule we should follow for the development of Boost tools. For example, we now use the Boost.Jam and Boost.Build for our "official" build system. I believe that the goal of the Boost.Jam and Boost.Build is to provide a convenient, best and "standard" way for building C++ programs. However, as a *tool* (which is different from a *library*), one may not care about what language the Boost.Jam itself is written in. Nevertheless, suppose we were using Java Ant for building later, will it be acceptable? (of course, take Java Ant as an example here may be inappropriate.) The obvious two attitudes I can imagine are: (1) Prohibit *extensive* use of other programming languages in Boost tools, for example writing a complex tool in Python completely. (Convenient and small scripts are acceptable.) For we are establishing the Best Practice *in* C++ and *for* C++. In addition, the tools can be extensible and reusable with an API for C++ programmers as *developers* not just as *end-users*. (2) Allow extensive use of any convenient and reasonable programming languages in Boost tools. Maybe there should be a list for acceptable languages other than C++, for example shell scripts, Perl, Python, Ruby, etc. For they are just *tools*, not C++ *libraries*. They are just black boxes to C++ programmers, and we do *not* provide the tools as an extensible tool platform/framework with API for C++ developers/programmers for further extension or reuse. I tend to support (1), it seems to me more attractive. Boost.Wave is a good example in my opinion. It is both a practical *tool* related to C++ and an excellent extensible and reusable C++ *library*. I know that we should do the correct thing using the appropriate tool. There is no one language can rule them all.:) I am not crazy to imagine rewriting everything using C++. However, I do believe that we should concentrate on developing C++ libraries and *C++ tools* in our C++ Boost Project. As for Buildbot for example, maybe it is unwise to seek for a C++ replacement for it (for interpreted languages / scripts may be the correct choice), however I worry about that it has nothing to do with C++ or most Boost C++ programmers except that it is used by Boost Regression Test. Any comments are welcome, but NO flames or language-wars pls.:) Best regards, Allen

2 1

[ptr_container] more operators?
by Pavel Chikulaev 23 Apr '05

23 Apr '05

Thorsten, So we're going to have comparison operators in ptr_container, despite possible polymorphism-related errors. Let me show you some problems with them: e.g. class Base{}; class Derived : public Base {}; bool operator == (const Base &, const Base &); //Handles correctly Base and Derived //then user add class DerivedAgain : public Derived {}; and forget update operator == then all operations == on DerivedAgain objects will use Derived operator ==. And AFAIK user just can't automate reminder about forgotten operator == without registering DerivedAgain somewhere, so all DerivedAgain wrong comparasions will get green light. And I do believe it's undesirable behavior. My vision of the problem: provide all comparison operators, but with compile-time checking that ensures user defined specialization of some traits class: template<> struct has_proper_polymorphic_equal_operator<Base> { enum { value = true; } }; while by default has_proper_polymorphic_equal_operator<T>::value returns false. Second if you provide comparasion operators (with concept checking or not) it's quite strange that ptr_containers aren't CopyConstructible and Assignable. Using the same technique we can provide them: template<> struct is_clonable<Base> { enum { value = true }; }; template<> struct clone<Base> { Base * do_clone(Base * pb) { return pb->CloneMe(pb); //or any other name } }; And I believe that operator = is much needed than comparison operators in real-life applications. So what do you think? P.S. What do you think about my post Proposal: is_swapable, is_nothrow_swapable, nothrow_swap,swap dated 04/12? -- Pavel Chikulaev

2 3

Any Interest in a 3-D Vector library?
by Stefan Koch 23 Apr '05

23 Apr '05

Any interest in a templatized class for 3-Dimensional vectors? (Similar in style to std::complex or boost math/octonion and math/quaternion.) The most recent uses I have had for it are in ray tracing of scattered light through an experimental setup, and in calculating the bending parameters for a pipe of a certain shape. Basic Features: Constructor and component access. Addition and subtraction of vectors. Multiplying and dividing vectors with scalers. Dot and Cross products of vectors. Length (norm) calculation an conversion to unit vectors. Stream I/O. More Advanced Features: Spherical coordinates Cylindrical coordinates Rotations (around principle axes and general axes) Reflection by a surface Refraction across an interface (Snell's law). Rotations are specified by the axis about which the rotation is to be done, and the angle through which to rotate. There is no support for general rotation matrices. What do you think? Stefan

1 0

[optional] End-of-lines problem.
by Rene Rivera 23 Apr '05

23 Apr '05

Please be careful when "fixing" EOL problems you encounter so as not to create additional ones. This change: http://build.redshift-software.com:9990/changes/514 Caused the EOLs to be duplicated: http://tinyurl.com/b6h3r Causing a variety of failures like this one: http://tinyurl.com/bdqrj -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Michel, > Is it a problem that the special or specific adresses is > represented by different textual representations for > different networks? I guess a textual representation > could be devised that makes these look the same with > some psuedo notation. > Like broadcast tcp:/[broadcast]:1234, > tcp6:/[broadcast]:1234, local tcp:/[local]:1234, > tcp6:/[local]:1234, any > tcp:/[any]:1234, tcp6:/[any]:1234 this would i guess > alleviate some of the eventual problems. The pseudo-tokens would work as long as they weren't ambiguous with allowed machine names in that network. I think a simple layer to register network objects (so you don't get them all linked in<g>), plus a fully general text-to-address object mapping would be a reasonable facility. Again, though, I view this as a (good) simplified use case and would still want control over the life-time of these objects (see other posts for the sad story<g>). I do recognize my concerns here are probably not too common, but all this might mean is that an http_get wrapper would be overloaded on url and address_ptr. The former would call the later after a lookup. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Serialization: docs addition
by Darren Cook 23 Apr '05

23 Apr '05

Hi, Can I suggest adding another example to: http://www.boost.org/libs/serialization/doc/special.html#objecttracking I had this code: void mycallback(const BigClass &BC){ const SomeData *d=BC.get_data(); ... archive & BOOST_SERIALIZATION_NVP(d); } My archive was smaller than intended and I discovered that the data only got saved the first time. XML version showed me it was using: object_id_reference. It turns out the fix was to dereference the pointer: archive & BOOST_SERIALIZATION_NVP(*d); That is an easy to write bug; I cannot see how the serialization library can catch it, so all I can think of is to make people aware of it in the docs. Also please mention "object_id_reference" in the objecttracking section of the docs, as that was the first thing I googled on and it got no useful hits. Darren

2 2

[website] Fluid layout.
by Rene Rivera 23 Apr '05

23 Apr '05

OK I've done more changes/improvements. It's now a fluid layout. Since no one except Dave had suggestions on what to I went with his idea of two (mostly equal) columns. In this case the left is fluid the right is fixed. I also removed everything except the latest release information. For the simple reason that more than that make the page unnecessarily long. After all anything older than the latest version isn't "Latest News". http://redshift-software.com/~grafik/boost/index.htm -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

11 26

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi guys, > Peter Dimov wrote: >>Michel Andr� wrote: >> Should several pending reads be allowed? I have >> leaned back and forth on this issue in a previous >> platform specific async com library I wrote. > > Definitely; a server that has N active connections > might have up to N reads active at any time. Not > on the same socket, of course. :-) If I understood Michel's question correctly, then your answer would be "no". As would mine. There's the question of need (which, IMO is close to 0) plus the added complexity of explaining/managing FIFO read order; and don't forget multiple threads making simultaneous reads - just say NO. :) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

New Singleton Release!
by Jason Hise 23 Apr '05

23 Apr '05

I'm pretty confident that this is the last major update before the review starts. All new library features and changes are explained in the documentation. The new library is available here: http://tinyurl.com/6qvrd -Jason

1 2

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Michel & Peter, --- Peter Dimov wrote: > Michel Andr� wrote: >> This means we have one global dispatcher for the library >> (completion queue in asynch case). Isn't there a need to >> have several dispatchersto be able to group connections >> to several dispatchers/pollers. > > You can probably guess that I think that the answer is no. ;-) And I would agree. :) I can see no particular reason to expose the arbitrary grouping of network objects to the user. I can see the need for multiple dispatchers, but at most one per thread. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Iain, > A connector sets socket options that can not be set after a call to > connect on a TCP connection! In the proposal I am making, the stream is created without being connected. So, it could offer pre-connection configuration. Of course, those methods would just be sitting there (temptingly<g>) after connect was performed. But, so I suppose would the connector if it were an object. If there are some significant options to be set, I could see them effectively becoming ctor arguments. Perhaps packaged in a stream_options bundle. Just some ideas. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Thu, 2005-04-21 at 19:30 -0700, Jeff Garland wrote: > I notice we don't have a buffer concept in any of our net/socket writeups on > the wiki. I think that's a big omission. I also wonder if the abstraction > doesn't already exist --> std::basic_streambuf. Let the socket class write > into the streambuf and then you can trivially wrap a stream around it to do > sophisticated i/o if you wish -- or simply pull out the raw chars.... > A buffer concept is absolutely essential for TCP. Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk! Streambuf makes sense for the iostream concept. For lower layers the buffer concept needs to be a model of contiguous container. Iterator type can only be guessed at because I don't know what goes on inside the 'C' socket lib or the kernel but first guess would be forward iterator. /ikh

4 4

VC 7.0 template specialization problems
by Jason Hise 22 Apr '05

22 Apr '05

The following specialization fails to compile on .NET 2002. Is there a good reason as to why, and if not, is there a suggested work around? template < typename T > class A { }; template < typename T > class B { }; template < typename T > class A < B < T > > // this is the specialization { }; -Jason Hise

3 4

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 12:06 -0300, pedro.lamarao(a)mndfck.org wrote: > Iain Hanson wrote: > > [SNIP] > > > A buffer concept is absolutely essential for TCP. Without it you will > > run into delays with Nagle, delayed ack and slow start all combine-ing. > > Yuk! > > > > Streambuf makes sense for the iostream concept. For lower layers the > > buffer concept needs to be a model of contiguous container. Iterator > > type can only be guessed at because I don't know what goes on inside the > > 'C' socket lib or the kernel but first guess would be forward iterator. > > Well, if you think about it, the streambuf *is* the lower layer buffer > concept (unless you consider ir a buffer over the "kernel buffer"). The > methods it offers are simple: get char, put char, and the like. > > Exposing a "socket" class is a requirement only if the proposed library > wants to try to interface with old, "hybrid" code, provide the > possibility for some kind of "extension" I really can't think of. A > C++-only library could just not have a "socket" class, or consider it > "private", and expose as the most basic thing the stream buffer. If you > don't need the buffering itself, call pubsetbuf(0, 0). I agree that the socket class may be private detail for an iostreams implementation but I do not agree that all network i/o should be done this way. I don't think that iostreams as a model works well for packet protocols. BTW do you use path MTU or MSS to set your streambuf size? /ikh

2 1

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 20:03 +0300, Peter Dimov wrote: > Iain Hanson wrote: > > I really don't see this as workable in the general case. The library has > > to guess the size of the read buffer. It would also prevent reading a > > complete record on a stream by reading a header up to the length field > > and then making a 2nd read call for that length with the correct size > > buffer. > > This is a good point, but async_read can take a size parameter, even when > the client does not supply a buffer. True. > > > It would also add dynamic memory allocation to the library > > I'm not sure that you can beat the library from the client side with respect > to the number of memory allocations. With N asynchronous reads active you > need to keep N buffers alive. The library can manage with just one in the > select case. > pre-allocate a set of buffers and hold them in condition variable protected queue. > > and be a source of runtime errors as a result a user not copying the > > buffer > > and trying to use it after its lifetime expired. > > I'm fairly confident that manual buffer management will introduce even more > runtime errors. ;-) (That's been my experience with async reads/writes, at > least.) And use the active object pattern instead of callbacks ( producer/consumer ) :-). /ikh

1 0

About refactoring C++ program
by zlf 22 Apr '05

22 Apr '05

Hi, Manually refactor C++ program is anonying and inefficient. Who can tell me some refactoring tool working on C++ code. I have searched google, but nothing valuable found:( Thx zlf

5 5

[ptr_container] comparison operators
by Fredrik Blomqvist 22 Apr '05

22 Apr '05

I can't find any code or docs dealing with comparison in the current CVS. Weren't ptr_container supposed to have deep comparison semantics? Regards // Fredrik Blomqvist

4 10

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 12:17 -0300, pedro.lamarao(a)mndfck.org wrote: [snip] > I don't think it is necessary to throw an exception from the stream to > signal it, for the same reason the stream can signal other kinds of > errors without throwing exceptions. The standard basic_ios base class is > even nice enough to offer the exceptions(iostate) "property" for you to > choose if you want or don't want exceptions to be thrown. Nothing new here. > > I believe a non-blocking mode is possible for std::iostream, but I'm > unsure of how... elegant would it be to use it. > > But should we offer the possibility for the user to set socket options, Yes. > or merely offer a blocking(bool) method? > > Also, how should the stream object behave in case of EWOULDBLOCK? Set > failbit? Even if we use a wouldblockbit, we still need to set failbit, > as the only thing clear is that the operation was *not* successful. > I don't think you want to set failbit as it is sticky and must be manually reset and EWOULDBLOCK is not an error. /ikh

1 0

Visual Studio 2005 Beta 2 + Multi Index
by Gordon Smith 22 Apr '05

22 Apr '05

The following stdafx.h for a vanilla console app kills the beta 2 compiler (I think it creates a corrupt PCH file): #pragma once #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers #include <windows.h> #include <tchar.h> // BOOST --- #include <boost/multi_index/sequenced_index.hpp> #include <boost/multi_index/ordered_index.hpp>

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 16:24 +0200, Peter Simons wrote: > Iain Hanson writes: > > >>> This would give a significant performance hit as there > >>> will now be two copies of the data. > > >> Not if the callback doesn't make any copies. > > > That is a long way from being the common case. > > Maybe, maybe not. My point is that whether or not data has > to be copied depends on the _callback_, not on the I/O > driver. Your original statement made it appear as if copying > of data would be inevitable in a callback-driven design -- > and it is not. > No. Copying the data becomes probable when the lib provides the buffer. Nothing to do with callbacks. > > > I really don't see this as workable in the general case. > > The library has to guess the size of the read buffer. > > No, the caller can provide the capacity (or the buffer). > > > > It would also prevent reading a complete record on a > > stream by reading a header up to the length field and > > then making a 2nd read call for that length with the > > correct size buffer. > > Why exactly would that be impossible in a callback-driven > design? > > > > It would also add dynamic memory allocation to the > > library [...]. > > Let the user pass the buffer when calling the driver, and > then there's no memory management at all. This is what I was arguing for. /ikh

1 0

Re: [boost] Re: Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 13:26 +0300, Boris wrote: > Caleb Epstein wrote: > > [...] > > concise, which is a tribute to the your implementation. At the same > > time, it is missing asynchronous and/or non-blocking operations and > > any means for doing single-threaded I/O multiplexing (e.g. > > select/poll/etc). > > But these don't belong to a streams library anway - at least I wouldn't know > how to support these I/O models without changing the stream interface. > Sorry, but I think that they do. At least both non-blocking and a reactor. I don't see why just because you are using iostreams that these become excluded. /ikh

1 0

BGL::johnson_all_pairs_shortest_path question
by Andreas Fabri 22 Apr '05

22 Apr '05

Hello, What is the non-named parameter version of this algorithm. In the online manual it says Weight (and this is probably a typo, as there is a template parameter WeightMap). Also what are the arguments id1 and zero good for? andreas

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 13:07 +0200, Peter Simons wrote: > Iain Hanson writes: > > >> async_read should not take a buffer; instead, the > >> callback should receive a pointer to a buffer managed by > >> the library that is guaranteed to be valid for the > >> duration of the callback. (Not by default, at least.) > > >> async_write (by default) should not assume that the > >> passed buffer stays valid after async_write returns. > > > This would give a significant performance hit as there > > will now be two copies of the data. > > Not if the callback doesn't make any copies. > That is a long way from being the common case. /ikh

2 1

bgl at boost.org and bostconsulting
by Andreas Fabri 22 Apr '05

22 Apr '05

Hello, When comparing the tables of content of the BGL http://www.boost.org/libs/graph/doc/table_of_contents.html http://www.boost-consulting.com/boost/libs/graph/doc/table_of_contents.html I see that the latter offers more algorithms. Are they also distributed ??? andreas

2 1

[Spirit + Graph] Request for help!
by Doug Gregor 22 Apr '05

22 Apr '05

The new GraphViz parser in the Graph library is implemented as an ultra-slick Spirit grammar from Ron Garcia. It works fine on newer versions of GCC and EDG, but Visual C++ 7.0 completely croaks with an internal compiler error. I've moved around code, eliminated some templates from the equation, etc., but I don't have a feel for how to fix the compiler, especially when Spirit is concerned. Are there any Spirit jockeys that could give me a few hints on how to deal with this or, better yet, get it working on VC 7.1? Cheers, Doug

4 6

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote: > async_read should not take a buffer; instead, the callback should receive a > pointer to a buffer managed by the library that is guaranteed to be valid > for the duration of the callback. (Not by default, at least.) > > async_write (by default) should not assume that the passed buffer stays > valid after async_write returns. > > Rationale: buffer management is a pain with multiple callbacks active ;-) > This would give a significant performance hit as there will now be two copies of the data. The 1st from kennel space to the library and the second in the callback from the library to the user. /ikh

4 3

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 09:01 +0200, Michel André wrote: > I see no problem with this. The only thing an connector gives you is the > possibility to do some hand shaking or whatever before handing the > stream to the handler and this handshacking wouldn't be relevant to the > protocol handler. > A connector sets socket options that can not be set after a call to connect on a TCP connection! /ikh

2 1

Re: [boost] (Named) Parameter Library
by Cromwell Enage 22 Apr '05

22 Apr '05

>From my understanding of the new interface: boost::keyword is now boost::named_params::keyword, boost::keywords is now boost::named_params::parameters, and boost::named_param<KW,boost::mpl::true_,Restriction> and boost::named_param<KW,boost::mpl::true_,Restriction> are replaced by boost::named_params::required<KW,Restriction> and boost::named_params::optional<KW,Restriction>. Am I correct? The type-extraction functionality I mentioned earlier has now been reimplemented in terms of the current code base, as is the BOOST_NAMED_PARAMS_MEMBER_FUN macro I proposed a while back. I also discovered an extraneous #define in <boost/named_params/aux_/arg_list.hpp> that prevents me from increasing the maximum arity of a function. The files I added and/or fixed are in the new File Vault, subdirectory "expaler", filename "named_params.zip". Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [boost] Boost serialization: 'serialize' : is not a member of 'std::vector<_Ty>'
by Vishnu Mahadevan Menon 22 Apr '05

22 Apr '05

Thanks for your reply! Yes, I did try including <boost/serialization/string.hpp>, but the error is still there. The strange thing is, I do not get this error everytime I try to serialize STL collections - it seems to pop up only in certain places. Regards, Vishnu. --- Felipe Magno de Almeida <felipe.almeida(a)ic.unicamp.br> wrote: > I dont know if has anything with this error, but > Have you included <boost/serialization/string.hpp> ? > > Vishnu Mahadevan Menon wrote: > > Hello! > > > > I seem to be getting the following compilation > error > > even after I've included > > <boost/serialization/vector.hpp> in the source > file. > > I'm using VS.net 7.1 to compile. > > > > [QUOTE] > > > > > c:\Boost\include\boost_1_32_0\boost\serialization\access.hpp(106) > > : error C2039: 'serialize' : is not a member of > > 'std::vector<_Ty>' > > with > > [ > > _Ty=std::string > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\serialization\serialization.hpp(78) > > : see reference to function template instantiation > > 'void > > > boost::serialization::access::serialize<Archive,T>(Archive > > &,T &,const unsigned int)' being compiled > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\serialization\serialization.hpp(121) > > : see reference to function template instantiation > > 'void > > boost::serialization::serialize<Archive,T>(Archive > &,T > > &,const unsigned int)' being compiled > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\archive\detail\iserializer.hpp(159) > > : see reference to function template instantiation > > 'void > > > boost::serialization::serialize_adl<Archive,T>(Archive > > &,T &,const unsigned int)' being compiled > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > > c:\Boost\include\boost_1_32_0\boost\archive\detail\iserializer.hpp(109) > > : while compiling class-template member function > 'void > > > boost::archive::detail::iserializer<Archive,T>::load_object_data(boost::archive::detail::basic_iarchive > > &,void *,const unsigned int) const' > > with > > [ > > Archive=boost::archive::xml_iarchive, > > T=std::vector<std::string> > > ] > > > > [Long dump.. UNQUOTE] > > > > Could anyone tell me why the above is happening > and > > how to get around the problem? I'll post the > > source-code if that'll help! > > > > I also searched and stumbled into > > (http://lists.boost.org/boost/2005/02/19606.php) > which > > *seems* to be saying that the issue is addressed > > somewhere in the serialization documentation, but > was > > unable to locate where. > > > > Thanks and regards, > > Vishnu. > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > -- > Felipe Magno de Almeida > UIN: 2113442 > email: felipe.almeida at ic unicamp br, > felipe.m.almeida at gmail > com, felipe at synergy com > I am a C, modern C++, MFC, ODBC, Windows Services, > MAPI developer > from synergy, and Computer Science student from > State > University of Campinas(UNICAMP). > To know more about: > Unicamp: http://www.ic.unicamp.br > Synergy: http://www.synergy.com.br > current work: http://www.mintercept.com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[type traits] problem on MSVC 7.1 with is_base_and_derived
by JOAQUIN LOPEZ MU?Z 22 Apr '05

22 Apr '05

Hello, Jochen Hammann has stumbled onto a problem which can be reduced to the following: In MSVC 7.1, if setting the compiler option /vmg, is_base_and_derived crashes when dealing with instantiations of template classes that have pointers to members as template params. The attached code, if compiled with /vmg, ICEs as follows: d:\...\boost\type_traits\is_base_and_derived.hpp(127) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information (I don't know if the problem persists in MSVC 8.0.) Is there any hope that this can be solved? Thanks in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

Iostreams filter buffering policy leads to extremely small reads.
by George M. Garner Jr. 21 Apr '05

21 Apr '05

Johnathan, The Iostreams library provides for built in buffering of filters which in principle should permit efficient use of filters even with streams that do not support filtering. However, in practice it does not appear to live up to expectations. More specifically, the following line in indirect_streambuf.hpp can lead to extremely fragmented reads to lower filters or devices: std::streamsize indirect_streambuf<T, Tr, Alloc, Mode>::xsgetn (char_type* s, std::streamsize n) { [...] streamsize amt = obj().read(s + avail, n - avail, next_); // n - avail may equal 10 or less [...] } This is true even if the filter buffer size is set to 1MiB or more. Large buffer sizes (> 2 MiB) greatly enhances read and write performance on many modern operating systems. This is particularly felt when reading and writing large files (> 4 GiB). Ideally, if you set a filter buffer policy (e.g. to 1 MiB) you would like all reads to lower filters and devices to request that value, except possibly for the last read. Fortunately, it is relatively trivial to disable Iostreams buffering altogether and write a buffering_shim_filter. But then I do not understand what purpose Iostreams buffering serves. I Googled through the online documentation and I didn't find a detailed discussion of its objectives, though there were some comments that touched on the subject matter during the review process. Perhaps you can further elaborate this subject matter. Regards, George.

2 5

Linking to shared library
by Gander 21 Apr '05

21 Apr '05

Hi, I get an error linking the example program days_alive to the shared library libboost_date_time. g++ -L/usr/lib -lboost_date_time -odays_alive days_alive.o days_alive.o(.gnu.linkonce.t._ZN5boost9date_time19month_str_to_ushortINS_9gregorian10greg_monthEEEtSs+0xec): In function `unsigned short boost::date_time::month_str_to_ushort<boost::gregorian::greg_month>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': /usr/include/boost/token_functions.hpp:587: undefined reference to `boost::gregorian::greg_month::get_month_map_ptr()' collect2: ld returned 1 exit status Platform is FC2 gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) I built Boost from the SRC RPM boost-1.32.0-3.src.rpm with no special switches. I found a comment in the boost mailings advising linking to static library. This was successful. Is the general advice to only use the static libraries? Giles Anderson

3 8

RE: [boost] Re: Boost to the rescue
by Victor A. Wagner Jr. 21 Apr '05

21 Apr '05

At Tuesday 2005-04-19 08:41, you wrote: >----Original Message---- >From: Victor A. Wagner Jr. [mailto:vawjr@rudbek.com] >Sent: 19 April 2005 16:03 >To: boost(a)lists.boost.org >Subject: Re: [boost] Re: Boost to the rescue > > > > I've been using 7.1 since it became available, and haven't > > bumped into any optimization problems, and we compile debug with > > none, and about everything we can find to turn on in release. > > Granted there are only 4 of us, but I don't recall any gotchas. > >I have. We compile "minimize size", and when bitshifting it gets things >wrong. We have found this twice (the first time confirmed by Microsoft), >and have had to revert to releasing the existing product with VC5 (Yes: 5 >not 6. We never upgraded to VC6 because it was expensive, a resource hog, >didn't seem to offer many new features, and a change to how #import work >broke huge swathes of our code). I've never heard of #import, is that some MS unique thing? It's certainly NO standard C++ >-- >Martin Bonner >Martin.Bonner(a)Pitechnology.com >Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, >ENGLAND Tel: +44 (0)1223 441434 >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

type traits Comeau 4.3 problem
by Robert Ramey 21 Apr '05

21 Apr '05

As part of my homegrown testing I like to run comeau 4.3. I find this compiler helpful in sorting out very stick C++ language issues and see it as a compiler addressing a small but important niche. The serialization library currently won't build with this compiler. It fails with the error message "C:\BoostMainCVS\boost/type_traits/detail/is_mem_fun_pointer_tester.hpp", line 61: error #457: "is_mem_fun_pointer_tester" is not a function or static data member yes_type is_mem_fun_pointer_tester(R (__stdcall T::*)()); Is there any chance someone might address this? I would much like to see comeau added to the test suites? Robert Ramey

2 1

[network] An RFC - updated
by Don G 21 Apr '05

21 Apr '05

Greetings All, After many discussions over the past week or two on this topic, I've made some changes to the abstraction I proposed (more along the lines of the Wiki stuff). Hopefully tonight/this_weekend I will get around to adding thoughts to the HTML file that describes the proposal. I've had trouble replacing files in the sandbox, so I started a SourceForge project where I could post more stuff than just a zip. http://netiphany.sourceforge.net http://sourceforge.net/projects/netiphany If there is a way to "evolve" a posting to the sandbox, I would be happy to do that as well. I've noticed that the Browse CVS area is many hours behind. I guess that is by design... None the less, many updates were posted just prior to this email and I don't see them yet. Also, the CVS stats in the project page are all 0. Ignore that :) New since last time: - network hierarchy refactored by adding some base classes (the leaf classes are effectively the same). - socket classes - address_family classes - url class defined - timeout class defined (microsecs) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Boost test and borland
by Robert Ramey 21 Apr '05

21 Apr '05

Whenever I run my tests for borland compilers in release mode using the boost test system, the executable run forever. Is there any hope this might get addressed? Robert Ramey

2 5

Re: std::string <-> std::wstring conversion
by Mihalca Bobby 21 Apr '05

21 Apr '05

I can�t claim that I invented string conversion, however I didn�t seen your code before you pointed it. If you look closer you will see this resembles very well with some code in boost::regex and for codecvt just look at Strustrop�s chapter 3 on locales. The name is string_cast because seems to me a good and natural name. The fact that other peoples wrote similar things and previous topics on the subject proves that something like this is needed. My code is public domain and can be used by anyone who find it useful, I can only hope it will make it to boost library. Note that is a bug I have to fix. The size of returned string is the size of the old string and this is not always true. Example: L�\r\n� is 1 char ( I think ) while when converting to ascii needs to be 2 chars. prez(a)neuromancy.net wrote: On Wed, 20 Apr 2005 09:29:27 -0700, Mihalca Bobby wrote: > I needed some std::string <-> std::wstring conversion and after > Here is the code: <-- SNIP --> Surprisingly, it looks like the code I wrote for Mantra (though I did not use the code below to write it), look here: http://www.neuromancy.net/viewcvs/Mantra-I/include/mantra/core/algorithms.h… It is also contained as a function (or series of functions) called string_cast. I guess there really are only so many ways to skin a cat ;) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: Boost to the rescue
by brangdon＠cix.compulink.co.uk 21 Apr '05

21 Apr '05

In-Reply-To: <6.2.0.14.2.20050417185958.0459b5a0(a)mail.rudbek.com> vawjr(a)rudbek.com (Victor A. Wagner Jr.) wrote (abridged): > do you keep all versions of your compiler around forever? Pretty much. We don't keep them in VCS though. We don't treat them as source code because, well, they are not source code. (Switching to a different compiler vendor would be a much bigger deal than adopting boost so this comparison probably isn't helping your case.) > >I didn't want to include anything I couldn't see an immediate use for. > > a true forward looking point of view. That sounds like sarcasm. I've already explained how it is easier to add stuff that was missed that to delete stuff that shouldn't have been added. Also, with broadband internet, the boost documentation so accessible from the web site that it doesn't need to be added locally. > actually you don't need to "understand it" to use it, anymore than you > need to understand the workings of the transmission in the auto you > drive. I do need to understand the documentation before I use it, and in the example I cited the documentation is long and complex. Also, I need to debug code, and that often does require understanding how it works. I must be a car mechanic as well as a driver. > I find it difficult to believe that min and or max got "redefined" such > that they became unusable (I'm pretty sure it would have shown up in > the regression testing. I recall no such incident). The root problem, as I thought we'd agreed, is that Microsoft wrongly defines them as macros. This means code like: long x = max( 1L, 1 ); works. I found that #including boost reverted to the standard-conforming definition, which meant the above became ambiguous as the 2 arguments have different types. Don't let's pay this issue more attention than it deserves. I doubt boost can do any better than it is doing, here. -- Dave Harris, Nottingham, UK.

5 12

[Boost-bugs] [ boost-Support Requests-1187143 ] Boost 1.29.1 for Mac OS ?
by SourceForge.net 21 Apr '05

21 Apr '05

Support Requests item #1187143, was opened at 2005-04-20 23:42 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=1187143&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost 1.29.1 for Mac OS ? Initial Comment: Does somebody have a binary version of boost for Mac OS 10.3? Please contact me at: Heinz.Stockinger(a)univie.ac.at Thanks, Heinz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1187143&group_… ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

std::string <-> std::wstring conversion
by Mihalca Bobby 21 Apr '05

21 Apr '05

Hi. I needed some std::string <-> std::wstring conversion and after searching web for something like this found nothing except a thread with this name here on boost. So I made one myself, maybe if you think is worth something you will include it in boost. Here is the code: template<class _RetString,class _SourceString> _RetString string_cast(const _SourceString &src,std::locale Loc=std::locale()) { _RetString dst; typedef _SourceString::value_type _SrcValType; typedef _RetString::value_type _DstValType; typedef std::codecvt<_SrcValType,_DstValType,mbstate_t> CodeCvt; const CodeCvt & cvt= use_facet<CodeCvt>(Loc); std::mbstate_t state = std::mbstate_t(); _SrcValType * next_in=NULL; _DstValType *next_out=NULL; dst.resize(src.size()); while(true) { switch(cvt.out(state, src.c_str(), src.c_str() + src.size(),next_in,const_cast<_DstValType *>(dst.c_str()),const_cast<_DstValType *>(dst.c_str())+dst.size(), next_out)) { case std::codecvt_base::ok: case std::codecvt_base::partial: case std::codecvt_base::error: // not much we can do here but guess: case std::codecvt_base::noconv: return dst; } } return dst; } and I used like this: std::string strA = string_cast<std::string>( std::wstring(L"dummy example") ); Bobby __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [boost] Re: [circular_buffer] comparison operators
by Jan Gaspar 20 Apr '05

20 Apr '05

Hi Fredrik, I'm attaching the discussion during the formal review regarding the comparison operators. But before you dip into the reading, I'd like to say that my intension was to write STL compliant container nothing less or more and I'd like to stick with this. Jan Subject: RE: [boost] Formal Review: Circular Buffer Date: Tue, 9 Mar 2004 09:44:34 -0800 From: "Powell, Gary" <powellg(a)amazon.com> To: boost(a)lists.boost.org Shouldn't the comparison functions allow the types to differ? I mean don't they still lexigraphically compare as long as there is a comparison function F that a F b for each element exists circular_buffer<T, MyAlloc> x; circular_buffer<S, YourAlloc> y; bool b = x == y; for where the operator T == S is valid? And what does the allocator have to do with it? Therefore IMO, all of the comparison functions should change from template< typename T, typename Alloc> bool operator F ( circular_buffer<T, Alloc> &lhs, circular_buffer<T, Alloc> &rhs); to template< typename T1, typename Alloc1, typename T2, typename Alloc2> bool operator F ( circular_buffer<T1, Alloc1> &lhs, circular_buffer<T2, Alloc2> &rhs); Yours, -Gary- ----------------------------------------------- To: boost(a)lists.boost.org From: "Pavel Vozenilek" <pavel_vozenilek(a)hotmail.com> Date: Tue, 9 Mar 2004 20:52:29 +0100 Subject: [boost] Re: Formal Review: Circular Buffer Hmm, do you know a STL implementation/some container with this feature? It may be often bug to compare containers with different types. /Pavel ----------------------------------------------------- Subject: RE: [boost] Re: Formal Review: Circular Buffer Date: Tue, 9 Mar 2004 13:55:15 -0800 From: "Powell, Gary" <powellg(a)amazon.com> To: boost(a)lists.boost.org No, but just because the standard libraries scr*wed up is no reason to perpetuate the mistake. It's the rule of unexpected consequences. Is circular_buffer<int> x = { 1, 2, 3}; circular_buffer<short> y = { 1, 2 ,3}; x == y ?? or not? Sure looks like it should work. The VTL library does it IMO correctly, allowing that if there is an operation T1 F T2, then V1 F V2 compiles. Otherwise you just force the user to write what should be library code. --------------------------------------------- Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1