July 2007 - Boost - lists.boost.org

[filesystem] building for cygwin
by frederic.bron＠alcan.com 09 Jul '07

09 Jul '07

Maybe the developpers list can help? I try to have the POSIX behaviour under cygwin but get only the windows behaviour even if I compile the library and program with -DBOOST_POSIX_API. What should I do? Regards F. Bron frederic.bron(a)alcan.com Envoyé par : Pour : boost-users(a)lists.boost.org boost-users-bounces@list cc : (ccc : Frederic Bron/Alcan) s.boost.org Objet : [Boost-users] Réf. : [filesystem] building for cygwin 07/07/2007 15:13 Veuillez répondre à boost-users Unbelievable! It does not work anymore!!! I have rebuild again the library to be sure that g++ received well -DBOOST_POSIX_API and it does. However, here is the output of the small program printed below: $ g++ -DBOOST_POSIX_API -I/cygdrive/d/Softs/boost_cyg/include -o toto toto.cc /cygdrive/d/Softs/boost_cyg/lib/libboost_filesystem.a $ ./toto ..\toto\x.xml \cygdrive\d\toto\x.xml should be ../toto/x.xml /cygdrive/d/toto/x.xml What should I do? F. Bron #include <iostream> #include <boost/filesystem.hpp> namespace fs=boost::filesystem ; int main() { fs::path x("../toto/x.xml") ; std::cout << x.file_string() << std::endl ; fs::path y("/cygdrive/d/toto/x.xml") ; std::cout << y.file_string() << std::endl ; return 0 ; } Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 3

thread abort exception - continued
by Ninel Evol 09 Jul '07

09 Jul '07

Sorry, I'm a little late - here goes: Anthony Williams wrote: > The current C++0x thread library proposal (http://www.open- > std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) includes > request_cancellation(), which requests a thread cancel at > the next call to cancellation_point() or one of the standard > cancellation points (such as waiting on a condition > variable). I intend to add this facility to Boost.thread > once the move to subversion is complete. Yes - and it's useful. I would like to see both possibili- ties! The cancellation by "polling" is most useful when writing server- or lib-code. A GUI friendly approach has to be different however. If you have to poll anyway - why go through all the thread trouble anyhow - just poll the GUI event loop instead. Creating worker threads is usually done for convenience. Polling is inconvenient. I read the proposal. One thing that stroke me was the list of recommended cancellation points. They all somehow imply that the thread is already "on hold" (if not polling). Let's look at real life examples: 1. You have an editor or whatever application; the user has selected a file that is to be read in. For convenience, the reading takes place in a background thread. The user has the possibility to cancel the operation. Suppose the file is large and being read over a dead slow NFS connection. So (s)he chooses to cancel. Where is you cancellation point in there? Is the application supposed to get stuck (as many do)? 2. The classical worker thread pattern: You have a really tight loop computing something. You just don't want to poll in there as it hurts. The com- pare operation for checking out of the loop every once in a while already costs too much. What do you do? Currently only "dirty killing" is what I could think of and that usually means that you have to do the cleanup in the main thread (not object-oriented). Those patterns can be found in many (if not the majority) of GUI applications. Sure, you can write around it (see Qt) - but that's rather ugly coding... > This is very messy --- it's asynchronous, so will break all > sorts of stuff. POSIX asynchronous thread cancellation has > successfully demonstrated that it's a bad idea, except for > very specific cases. Posix' threads came late - too late. And as usual they didn't really go for a "pragmatic approach". The old saying: "Posix is better than nothing". I agree that it's a bit messy behind the scenes. However, you can have it the easy way. If you put the thread to sleep first - your patient is in a coma; operating on it is not so tricky then. That was only a bare example, you can of course synchronize it (and you might want to do that in many cases;o). Again, let's take a look at an example: A trickier one - cancellation while retaining data: For example the application has computed for hours and you want to abort the operation and let it finish tomorrow 'coz you need to phone ant Hermine and you only have one line... Silly code example: // either declared in the object or on the heap: map< BigUInt, answer_type > *war_dial; // then in the thread you have to put those // critical accesses within a "critical section": noAbortBegin(); war_dial[ number ] = answer; noAbortEnd(); // or for the forgetful as an object: { noAbort na; war_dial[ number ] = answer; } Behind the scenes this basically increments an atomic variable (check and set). So if you have a cancellation request from another thread (say the main thread), the worker thread is put to sleep. Then the no-abort variable is checked, if not zero a flag is set to indicate to the thread to throw an abort-request itself the next time it ends a "critical section" and the counter is zero (nesting). If the no-abort is unchecked (count of zero) you can fix the instruction pointer to let the thread throw an abort-request when it wakes up. Then you wake the sleeping thread and either wait for it to die, wait with a timeout - or (in case it's all on the heap) simply not care anymore. For the latter you have to make sure not to leave any children running while the parents go dead of course... Very much like C++ exceptions this is not that efficient. It's meant for exceptions - and only exceptions. "Abort requested by user" is one of those (and a very common one too). So I would still like to see both approaches implemented (they complement one another). The possibility to cause an exception within a thread no matter what operation it's doing is very powerful. Asking a programmer to protect critical accesses on persistent data/objects with "critical sections" if using that feature is not too much (and incrementing a variable is rather cheap as well). Hope I don't seem to stubborn about this, but I really think that once it would be there C++/C-0x programmers wouldn't want to miss such a feature anymore. --- about wx: Scott McMurray wrote: > > I read that some folks thought about the wxWidgets and the > > Boost (C-0x) team joining forces. > > I think that would be a marvelous idea! > > I think they'd come to blows, given how reluctant wx seems > to be to use any feature added to C++ in the past 17 years > or so :| > > I don't think that's an ezaggeration, either. Have you > looked at the wx developer guidelines lately? Looks like > they want nothing from after the ARM... Hahaha, yes - arrays, maps and the like as preprocessor macros... also when it comes to posting bug reports it seems very much like someone there is "running a camp"! X-O It is supposed to be about "backward compatibility" with some compilers from the Jurassic period. However, it looks as if "they" intent to start over with version 3. C-0x is going to end up in the same swamp as C++ without a useable GUI support. Sure, you can have second party libraries. But then you also need support for the second party libs (like GUI builders, usually not integrated) and the swamp sets in deep when debugging non-native objects. "Do it by hand Luke"... Like this, C-0x won't stand a chance against free all-in-one Java or C# (reads: "C crooked") alternatives (not that I would use them - coming from the Assembler countries). Despite the reasonable disbelieves I think that there should be a debate with the wx folks. The problem with C-0x seems to be a lack of resources for something as complex as a proper GUI support. With the wx team maybe willing to start all over (they certainly didn't do a bad job!) joining forces could bring C-0x to new highs. It's worth a try, someone cast the first stone PLEASE! :-) > ... Last I looked, gtkmm was the closest to providing C++- > style interfaces and such, so maybe there's hope. Hmmm... I think the mingw part is somewhat chasing away programmers and the last time I looked into gtkmm it read "TODO" almost everywhere... Same problem as C-0x it seems. ;-{ > Unfortunately, http://www.omgui.org/, which was trying for a > real C++ GUI lib, seems rather dead. Lack of resources - how I hate this song... > The STL is also quite useful, all by itself. I'm using it > heavily in my research. I have no use for GUIs or sockets. > I tried threads, but my bottlenecks are all I/O, so they > don't make a difference. I do most of my the output to > console, with some OpenGL for visualization. No QT, wx, or > other ancient frameworks needed, nor would they be helpful. If the bottlenecks are all I/O then the STL (iostreams in particular) could be one of them. If I recall it correctly the STL was a lot slower than the C counterparts in that area. X-| Well, that's it from me - gotta puff up my belly... Regards, LC (myLC(a)gmx.de) -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

2 1

read_write_mutex
by luca regini 09 Jul '07

09 Jul '07

Hi i am working toghether with Andrey Semashev on the implementation of the new boost logging library. This library depends on the boost read_write_mutex that is abandoned on the current version of the library ( 1.34 ). I would like to know if someone is actively developing it otherwise i can take care of developing the windows version. Greets, Luca

2 1

extern placeholders and MSVC 8
by Dean Michael Berris 09 Jul '07

09 Jul '07

Hi Everyone, I've encountered a problem with MSVC which I have no idea how to go around with regards to using extern placeholders for template method type deductions. Let me give an example: template <class T> struct some_type { }; struct a_type { } ; extern a_type placeholder ; template <class T> some_type<T> method(T) { return some_type<T>(); }; // ... { method(placeholder); } The code works (compiles fine) in GCC -- it doesn't bother looking for the placeholder during link time. However MSVC 8 throws a fit and doesn't want to link the executable because it keeps looking for the implementation of placeholder -- where the code obviously doesn't require linking to it in any way, except for the purposes of type deduction in the template method. Am I encountering an MSVC bug? Is there a better way of going about this? Insights would be most appreciated. Thanks in advance! -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

4 7

Some problems about singleton_pool
by Wei FENG 09 Jul '07

09 Jul '07

When using the "singleton_pool" to allocate the new space, I found there is a limitation in this pool. If I want to allocate 16KB memory space,I can do it by call 65503 times( about 1GB space has been used ). Then, I established another singleton_pool object to allocate 1KB space ,this time I succeed 524255 times( about 500MB memory space). I want to know whether there is a limitation in that? thx. ps : the sample codes: typedef boost::singleton_pool<PieceMemoryPoolTag, UDP_BIG_BUFFER_SIZE+1> BigPool; void* BigMemPool::malloc(void) { void *pbuf = BigPool::malloc(); assert(pbuf); if (pbuf != NULL) { memset(pbuf, 0, UDP_BIG_BUFFER_SIZE+1); bigmalloctimes++; char str[128]; sprintf_s(str, "BigMemPool::malloc %lu", bigmalloctimes); } return pbuf; }

1 0

[IBD] Request for Comment, Objectives
by Matias Capeletto 09 Jul '07

09 Jul '07

Hello Boost, The Improving Boost Docs project is starting to have real man power. There are more than twelve developers right now working on different parts of it, and we are actively trying to get more people involved. Since we want to build a long term subcommunity which main purpose is to continuously improve the quality of Boost documentation, we would like that our main directives be aligned with the Boost community as a whole. Anticipating some recurring critics we have seen during the last two weeks we would like to include a little FAQ before discussing our objectives. A) Why do we need IBD? -------------------------------------------------------------------- We believe that documentation is a first class citizen in a project, on par with the code. An incredible library is useless with out good docs. Although Boost has one of the greatest documentation available in Open Source projects, we think that it can be improved. For example, a consistent look and feel through Boost libraries will help users to understand that Boost is not simple a collection of quality pieces, but an amazing always evolving maze that must be seen as whole. IBD main purpose is to be another quality reassurance mechanism, trying that Boost Docs be in the better shape possible for each release. B) IBD is a waste of resources, that will be better expended on new libraries and bug fixes. -------------------------------------------------------------------- This is an interesting critic that has pop up in a few threads. We encourage you to check: http://svn.boost.org/trac/boost/wiki/ImprovingBoostDocs#People IBD is offering a place where people that is not a C++ guru (yet) has the opportunity to collaborate with the Boost community. Working with Boost docs will inevitably make us better C++ programmers, and augment the possibilities to become a Boost author or help with patches. We are not wasting Boost resources, we are getting more hands to make Boost a better place. C) IBD new style and resources have a less sober aspect than other Boost resources, lowering the quality of Boost as a whole. -------------------------------------------------------------------- We like to "enjoy quality". Our idea is that having fun and produce quality products are orthogonal process, and since we will invest a lot of our time at IBD we prefer to enjoy or work. We go one step further with this and think that a happy developer produces better quality products. We think that this discussion is very important for the health of our project. Your feedback will be really appreciated. King regards The IBD crowd --------------------------------------------------------------------------- Here are the project objectives reproduced in the thread to comfortably discuss each of them. IBD objectives http://svn.boost.org/trac/boost/wiki/ImprovingBoostDocs#Objectives * Build up a long term community of people that cares and constantly improve boost documentation and tools. * Achieve an unified look and feel between docs and Boost resources, integrating them as much as possible. * Quality documentation - Provide correct, current and readable documentation for the Boost C++ libraries, tools, environment and organization. - Generate Glue docs that sees boost as one tied entity, providing real-world examples, best practices for common tasks and tutorials about how to combine Boost libraries together to build high-quality C++ applications. - Provide a publicly available, vendor-neutral reference manual for the Standard C++ library, STL concepts, data types and algorithms as part of the Boost library documentation. - Make it easier for users to navigate through the enormous amount of boost documentation. - Use latest version of standards and support old browsers. - Include nice looking logos and diagrams. Although Boost libraries are so great that they do not need any marketting at all, lets face it: people are attracted like flies to catchy names and fancy pictures. * Documentation tools and support - Improve the docs tool chain, simplifying and integrating it lowering the barrier for people willing to help us. - Develop tools to automate common task, and to make life easier to boost authors. Docs writers should concentrate on generating content and not on figthing with tools. - Work to make doc tools boost-agnostic. We believe that they are useful beyond the boost community, and would welcome anyone who wishes to use, extend or support them. * Generate formal documents about C++ documentation best practices. * Offer our help to libraries authors. This include translations, proof-reading, proposing examples and tutorials for their libraries and helping them with the docs tool chain. * Offer a place where not C++ experts can help the Boost community. In general the tasks we do here does not involve template metaprogramming or others complex C++ machinery. Dessigners, artists, teachers, web experts, Python programmers and Boost users are very welcome along our lines. * Write docs, include rationales, use our own tools. If we want to improve boost docs, we should start by showcasing best practices in this project. * Enjoy our work. If we are not having fun while improving boost docs something has gone terribly wrong.

4 7

[Proto] Access to member in proto expression tree
by dan marsden 09 Jul '07

09 Jul '07

Hi Does proto support member access in its tree generation in any way. I'm looking at a few of the phoenix statement forms, particularly: if_(pred)[statements].else_[statements] and try_[statements].catch_<exception_type>()[statements].catch_call[statements] I need to specify member access to else_ and catch_<exception_type> etc. Is this something I'll have to hand roll, or does proto have some extension mechanism I've missed that will let me add these to the expression tree generation process? As phoenix expressions have operator(), I'm already using an expression wrapper around all my proto expressions, so I presume that is where I would add any special member support? Cheers Dan ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

4 11

shared_ptr ticket #398, "Support for embedded VC++ 4.0"
by Peter Dimov 08 Jul '07

08 Jul '07

#398, "Support for embedded VC++ 4.0", http://svn.boost.org/trac/boost/ticket/398 complains that shared_ptr doesn't compile under eVC++ 4.0 because "'type_info' is not a member of 'std'". Can someone who uses or has access to eVC++ 4.0 look at it? Is the ticket still relevant? Can shared_ptr.hpp be made to compile on this platform?

3 3

<OT>, was thread abort exception - continued
by Scott McMurray 08 Jul '07

08 Jul '07

On 08/07/07, Ninel Evol <myLC(a)gmx.de> wrote: > If the bottlenecks are all I/O then the STL (iostreams in > particular) could be one of them. If I recall it correctly > the STL was a lot slower than the C counterparts in that > area. X-| > iostreams are often slightly slower than the C versions, but both are faster than the disk, so that's not really a problem. The abstraction gain is usually worth it. And I'm using memory-mapped files anyways, which goes the complete opposite way on the overhead/abstraction scale. Reading GiB of data from disk just takes a long time, no matter what you do. ~ Scott

1 0

Re: [boost] Trac bugs - by assignee
by Robert Ramey 08 Jul '07

08 Jul '07

I've tried to login - but I don't know what to put in as a password. I've tried the password I usually use for boost stuff but it doesn't seem to work. Robert Ramey "Marshall Clow" <marshall(a)idio.com> wrote in message news:<p06210202c2b56c27384a(a)[192.168.16.228]>... > [ 309 open tickets today, 319 yesterday ] > [ Thanks to Peter Dimov (and others) for their work yesterday ] > > If you are maintaining a library, and have not logged into the trac system > at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, > no tickets can be assigned to you, and will remain under "None". > > Instructions on working with tickets can be found at: > <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> > > > 48 None > 22 dgregor > 20 grafik > 17 vladimir_prus > 17 nobody > 16 jsiek > 16 johnmaddock > 15 az_sw_dude > 11 turkanis > 11 beman_dawes > 7 speedsnail > 7 samuel_k > 7 rogeeff > 7 dave > 6 shammah > 6 pdimov > 6 nesotto > 6 jbandela > 6 anthonyw > 6 agurtovoy > 5 witt > 5 <Blank> > 4 urzuga > 4 mark_rodgers > 4 fcacciola > 4 djowel > 3 jmaurer > 3 ebf > 3 dlwalker > 3 danielw > 2 ramey > 2 hubert_holin > 2 alnsn > 1 nmusatti > 1 mistevens > 1 kevlin > 1 hkaiser > 1 garcia > 1 eric_niebler > 1 danieljames > 1 aaron_windsor > > None 1080 boost::interprocess win32 global file mapping issue > None 1079 boost-1.34.0 fails to compile. concept checks not satisfied. > None 1076 compile error: disconnecting struct with operator()() > doesn't work in VS2005 SP1 > None 1074 FreeBSD specific patches to boost 1.34.0 > None 1073 operations.cpp_ dummy_first_name lifetime > None 1072 assertion failed in dijkstra algorithm > None 1070 [iostreams]boost\iostreams\copy.hpp line80 copy_impl > None 1069 _InterlockedExchange_ _InterlockedExchangeAdd have wrong signature > None 1068 Mersenne twister disables streaming for Visual C++ > None 1066 Patch to make Boost.Python compile on SunCC > None 1065 cannot find -lboost_filesystem > None 1061 boost::filesystem::basic_recursive_directory_iterator fails > on empty directories. > None 1060 no example sources in online docs for Boost::Test > None 1059 random_on_sphere can be made 10 times faster! > None 1058 Cygwin libraries & GNU libtool > None 1056 commentary typo fixes for wave; make jam compile > None 1055 boost build system uses wrong `ar` for cross compilation. > None 1051 MPL header ordering triggers bug > None 1050 BOOST_CHECK_CLOSE_FRACTION documentation missing > None 1049 Getting mpl/has_xxx.hpp to compile on AIX > None 1047 Small Problem with the getting started guide making the > whole build fail > None 1042 Build: Incorrect parameters for IA64 architecture in MSVC toolset > None 1038 "<" and ">" should be excaped in xml_oarchive > None 1037 boost.serialization : invalid pointer dependant upon > serialization order > None 1036 assert failure in oserializer.hpp:418 > None 1033 iostreams::restrict doesn't work on an iostreams::file_source > None 1032 typo in Boost.Test documentation > None 1027 [ptr_container] optional serialization support > None 1023 inspect > None 1021 [Graph][reverse_graph] Problem using reverse_graph adapter > with an adapted user defined graph > None 1020 Boost.Iterator proposal to add is_constant_iterator > None 1019 iterator_facade::pointer should be the return type of > operator-> (DR 445) > None 1014 rename throws an exception that is not documented > None 1006 No mingw.jam > None 1003 [iostreams] copy-paste error in typedefs for wchar multichar_filters > None 1002 [iostreams] close_impl<closable_tag> does not comply with spec > None 995 'multiply defined symbols' when including > <boost/filesystem.hpp> in different source files > None 991 [pool] > None 987 configure passes wrong toolset to bjam > None 982 x64 documentation for windows > None 980 boost.format vc8/win32 compilation warning > None 975 empty weak_ptr throws upon serialization > None 969 basic_binary_iprimitive::load_binary bug > None 968 xml_grammar - incorrect define char > None 962 Missing links in Test library documentation > None 961 boost::basic_binary_oprimitive not instantiated correctly > None 960 [random] lognormal_distribution problem > None 956 Doc error in test examples. > <Blank> 1011 amd64: #error Boost.Numeric.Interval: Please specify > rounding control mechanism. > <Blank> 1001 gcc 4.1.2 segfaults on mpl/test/apply.cpp > <Blank> 999 prg_exec_fail3 fails on release variant > <Blank> 924 Convenience function for const map read > <Blank> 907 gccxml compilation error under Windows > aaron_windsor 778 top-level configure is broken > agurtovoy 861 [mpl] Detect nested template members with has_template_xxx > agurtovoy 816 duplicat initial members -> erase_key postcond. fail > agurtovoy 761 [mpl] evc4 port > agurtovoy 640 documentation mistake > agurtovoy 637 Adjusts mpl::pair concept to be compatible with STL pairs > agurtovoy 588 mpl::remove compile error with gcc 4.1.0 > alnsn 839 lexical_cast - local variable shadow patch > alnsn 754 boost::any - typeid comparison across shared boundaries > anthonyw 1053 Error using boost::mutex and C++/CLI > anthonyw 659 provide an abstract "Task" type based on Boost.Threads > anthonyw 881 errors when build with Apache stdcxx > anthonyw 876 xtime documentation incomplete > anthonyw 868 [thread] thread_specific_ptr::element_type ? > anthonyw 802 [thread] MSVS: Allow use of thread headers with /Za > az_sw_dude 1078 from_iso_string cannot read the output from to_iso_string > az_sw_dude 1028 typo in boost header: date_time/time_defs.hpp > az_sw_dude 224 Extensions to std::string: compareIgnoreCase()_ trim()_ ... > az_sw_dude 187 locale > az_sw_dude 17 Socket wrapper class > az_sw_dude 890 date_time library supports only the current dst rule > az_sw_dude 889 Insane Dependencies > az_sw_dude 827 Unused variable in format date parser > az_sw_dude 642 operator<< for gregorian::date_duration not found > az_sw_dude 614 new timezone db file for #1471723 - 2007 DST support > az_sw_dude 605 support new 2007 DST rules for timezone db > az_sw_dude 604 from_ftime incorrectly processes FILETIME filled with zeros > az_sw_dude 596 make timezone csv file C/C++ compatible > az_sw_dude 316 date_time type conversion warning > az_sw_dude 287 wrong usage of ios_base::narrow > beman_dawes 897 exists() throws exeption on existing but locked file on wind > beman_dawes 842 typo in auto_unit_test.hpp Revision 1.17 > beman_dawes 824 BOOST_IOSTREAMS_HAS_LSEEK64 on Mac OS X > beman_dawes 823 Seekable file_descriptor_source /sink? > beman_dawes 752 directory_iterator doesn't work with catch > beman_dawes 680 significantly different timer class behaviour on Win and Lin > beman_dawes 662 [filesystem] portable_posix_name() may fail on premain call > beman_dawes 607 Log level names wrong in documentation > beman_dawes 600 VC8 can't find windows.h even though environment is correct! > beman_dawes 559 linker error mingw 3.4.5 > beman_dawes 222 Code analysis_ flaw detection_ debugging > danieljames 1064 problem on platforms with no errno.h header file > danielw 1054 Parameter takes an "infinite" amount of time to compile > with the Intel compiler. > danielw 1044 Argument pack inaccessable in a functions return type > danielw 863 [parameter] fix operator|| for lazy binding > dave 1010 linking boost.python on freebsd > dave 918 __doc__ strings > dave 916 BPL Support for Python Callable Objects > dave 910 gcc strict-aliasing problems with python > dave 903 inconsistent usage of function pointer typedefs > dave 865 Use of C++0x keyword as identifier > dave 857 add shared_ptr< const T> support > dgregor 954 boost::dynamic_properties has no copy-constructor > dgregor 862 [utility] Make result_of handle lambda expressions > dgregor 746 max flow with lower bounds (capacities) > dgregor 1067 Function needs to use pass-by-reference internally > dgregor 891 Bunch of compilation error reported while using function.hpp > dgregor 870 boost::graph::graph_utility.hpp is_connected() bad call > dgregor 852 Problem with Boost and GCC 4.1 > dgregor 829 Implicit graph not implement > dgregor 738 Memory leaks with signal::connect? > dgregor 736 Const correctness violation > dgregor 735 Fruchterman-Reingold grid performance can be improved > dgregor 733 Numbered headers don't work with "preferred" syntax > dgregor 732 Johnson All-Pairs needs better "no path" information > dgregor 708 Dijkstra no_init version should not require VertexListGraph > dgregor 556 Bundled graph properties > dgregor 447 reverse_graph and constness of property maps > dgregor 403 Document copy_component > dgregor 402 random_vertex/random_edge are unnecessarily inefficient > dgregor 395 BGL graph types do not support allocators > dgregor 375 LEDA graph adaptors do not handle hidden nodes properly > dgregor 373 LEDA graph adaptors for undirected graphs > dgregor 372 adjacency_matrix should model BidirectionalGraph > djowel 664 crash in boost::spirit::parse > djowel 543 Embedded python won't compile > djowel 314 spirit insert_key_actor.hpp > djowel 241 Miss " = ParserT()" > dlwalker 766 "Bug" in comment (x2) > dlwalker 653 [integer] add support for integers longer than long > dlwalker 613 boost/crc.hpp uses non-standard conforming syntax > ebf 993 Variant should use least common multiple of alignments_ > rather than maximum > ebf 965 [doc] boost::variant tutorial - final example uses v1_v2 > should be seq1_seq2 > ebf 547 [variant] Compile time checked getter > eric_niebler 1071 Request for BOOST_REVERSE_FOREACH and rationale > fcacciola 818 No zero-argument in_place() > fcacciola 765 optional documentation > fcacciola 617 Numeric Conversion Documentation minor bug > fcacciola 282 boost::optional<enum> fails with /CLR > garcia 1045 [multi_array] Need a proper swap operation > grafik 1040 boost.devel archive at ActiveState disconnected > grafik 1031 AmigaOS fixes for bjam > grafik 989 Boost build does not support building universal binaries > on macintosh > grafik 714 [jam] HardLink rule on NT platform > grafik 121 toolset initialization > grafik 94 Better reporting of failed expectation. > grafik 93 Testing problems on AIX and OSF > grafik 1062 Cygwin install stage fails with combination of patches > grafik 977 bjam crashes when compiled with gcc 4.2 > grafik 959 linking fails when Boost is compiled with STLport 5.1.* on > Linux (names mismatch) > grafik 896 <native-wchar_t>off does not work when build with vc-8.0 > grafik 798 bjam: always define OSPLAT > grafik 721 Generated files "@()" don't work in regular expressions. > grafik 683 libraries won't build > grafik 616 Boost Jam_ and non english directorys > grafik 552 Building universal binary on MacOSX > grafik 546 boost.build needs fixes for HP/UX > grafik 497 Unable to build boost with Dinkumware STL version 4.02 > grafik 481 Linker Problems with VC .NET 2003 / STLPort / Boost > grafik 431 boost jam problem with parallel builds > hkaiser 1077 Spirit integer parser does not always detect integer overflow > hubert_holin 647 octonion documentation bug > hubert_holin 162 Cannot compile octonion_test.cpp because of bug in sinc.hpp > jbandela 665 bug in char_separator > jbandela 501 token_iterator::at_end() result is inversed > jbandela 306 Visual C++ "Language Extensions" support > jbandela 283 Compiler error for tokenizer on Solaris > jbandela 279 SLOOOWW tokenizer compilation on VC++6.0 > jbandela 259 Problem compiling :/ > jmaurer 920 Proposed extension to random library > jmaurer 819 uniform_int<> with type's maximum availaible range error > jmaurer 351 Diff in state of mersenne_twister gen between GCC3.41 & CW9 > johnmaddock 1081 Empty string rejected as perl-style regex > johnmaddock 1075 [doc] incorrect comment > johnmaddock 1008 Undocumented type traits. > johnmaddock 871 Problem build boost 1.33.1 on Aix 4.3.3 > johnmaddock 883 errors when build with Apache stdcxx > johnmaddock 812 Crash on RH machine with gcc < 3.4 > johnmaddock 775 Warnings on MSVC 2005 > johnmaddock 764 [regex] add support for a BOOST_NO_CREGEX mode > johnmaddock 679 regex - perl syntax affects what gets matched > johnmaddock 633 [config] evc4 port > johnmaddock 591 make portable stdint.h from boost code > johnmaddock 540 Please add support for Borland C++ Builder 2006 > johnmaddock 502 Problem running configure for unsupported platform > johnmaddock 492 Adding boost::is_complex to type_traits.hpp > johnmaddock 360 Regex > johnmaddock 315 Implement operator[] for Tokenizer > jsiek 900 graphml reader namespace handling is broken > jsiek 875 No iterator based constructor for adjacency_matrix > jsiek 815 remove_edge core dumps on self-circle > jsiek 813 concept_check.hpp unused variable warning > jsiek 694 Add Maximum Common Subgraph (MCS) algorithm > jsiek 693 Add clique detection algorithms DFMax_ Bron-Kerbosch > jsiek 636 strange compiling problem for transitive_closure > jsiek 580 Max Flow Algorithm > jsiek 575 Calling subgraph::global_to_local on a root graph > jsiek 541 [concept_check.hpp] remove unused variable warning in msvc > jsiek 416 Spelling of Edmonds-Karp-Algorithm > jsiek 193 Check ordering for mutexes > jsiek 182 Support aspect-orientation > jsiek 116 creating my own properties > jsiek 100 more use of the concept "allocator" > jsiek 69 Boost with Dinkumware C++ Library !? > kevlin 913 Specialization of lexical_cast > mark_rodgers 821 allow_unregistered improvement > mark_rodgers 558 add database library? > mark_rodgers 87 function to get the size of a array > mark_rodgers 30 parser > mistevens 688 ublas: bug in mapped_vector_of_mapped_vector > nesotto 807 boost::assignment documentation: mathematical "typo" > nesotto 730 The ptr_map iterator cannot be dereference to value type > nesotto 723 local_time_facet error in VS2005 Win2003 > nesotto 624 bug in boost::range_detail > nesotto 518 [Boost.Range]boost::const_begin calls non-qualified 'begin' > nesotto 471 boost.range and "const char[]". > nmusatti 285 Borland compiler error with Pool_ boost::pool_allocator > nobody 930 iostream and zlib > nobody 922 Lexical cast and wide characters > nobody 908 gccxml compilation bug under Windows > nobody 905 Assertion failed in token_iterator.hpp > nobody 902 patch for Visual Studio 8 + Windows x64 (AMD64) > nobody 884 [iostreams] workaround for the boost + stdcxx on MSVC 7.1 > nobody 874 Ability to partially specialize implementation_level > nobody 825 PocketPC 2003/2005 MSVS8 > nobody 800 [filesystem] chdir() > nobody 796 [ublas] vector::back() > nobody 795 [ublas] vector::back() > nobody 621 filesystem::path as a template > nobody 590 mkstemp > nobody 513 darwin 64 bit support > nobody 366 handle double '/' in the boost::filesystem > nobody 310 Stand-alone ternary state tree > nobody 294 unicode support in boost::filesystem > pdimov 997 error in boost::bind doc > pdimov 974 spurious warning suppression code useful in shared_ptr.hpp > pdimov 911 [bind] inline placeholder macro > pdimov 810 support for weak_ptr binding > pdimov 445 Can't delete automatically in circularly included object. > pdimov 398 Support for embedded VC++ 4.0 > ramey 878 error C2039: 'mbstate_t' : is not a member of 'std' > ramey 877 'NULL' undefined in basic_serializer_map.cpp > rogeeff 1030 execution_monitor.ipp #warning directive breaks > compilation on MSVC 8.0 > rogeeff 998 prg_exec_fail2 fail on ppc > rogeeff 893 grammatical error in error message > rogeeff 847 [Test Library] How to init/free a singleton > rogeeff 762 [test] evc4 issue with SEH support > rogeeff 747 failing on 6 targets in MacOS X > rogeeff 645 [test] no eh exception handling functions on evc4 > samuel_k 859 boost::format ignores a user defined locale > samuel_k 849 boost::format and operator priority rule > samuel_k 713 Boost.Format doesn't work on MSVC with /vd2 compiler option > samuel_k 704 format zero length string msvc-8 > samuel_k 585 64 bit compile warning/error for boost::format > samuel_k 570 boost::format parse method doesn't work > samuel_k 493 format: assert when parsing invalid pattern > shammah 840 pool allocator - local variable shadow patch > shammah 836 warning using pool.hpp > shammah 386 boost::pool_allocator breaks with vector of vectors > shammah 290 perfomance: memory cleanup for pool takes too long > shammah 284 pool::purge_memory() does not reset next_size > shammah 88 ct_gcd_lcm.hpp compilation error > speedsnail 615 thread identification and getting the id > speedsnail 204 Add a monitor class > speedsnail 194 Exchange results between several thread calls > speedsnail 174 cooperation with ACE framework > speedsnail 173 more synchronization primitives for the threads classes > speedsnail 172 cooperation with ZThread package > speedsnail 171 class for function calls that are not thread safe > turkanis 869 [iostreams] patch for building by BBv2 > turkanis 856 iostreams file_descriptor::write fails under Win32 > turkanis 822 Incorrect usage of bad_write()_ bad_seek() etc. > turkanis 817 Performance problem in iostreams > turkanis 791 iostreams::tee_filter is for output only > turkanis 786 bug in iostreams/copy.hpp line 81 > turkanis 699 Changing size of memory-mapped file on Windows > turkanis 586 iostreams // file_descriptor::seek BUG on files > 4 GB > turkanis 579 boost.iostreams file_descriptor and sharing > turkanis 525 problem with boost::iostreams when compiled with Visual C++ > turkanis 484 Boost.Iostreams and newline translation > urzuga 864 [lambda][utility] Make lambda support result<> > urzuga 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile > urzuga 574 [boost::lambda] Compile error with libstdc++ debug mode > urzuga 426 lambda vs pure virtual functions > vladimir_prus 1041 Cygwin requires PATH setting. > vladimir_prus 985 can't use bjam to disable specific VC warning > vladimir_prus 984 using 'define=XYZ' as bjam command line argument doesn't work > vladimir_prus 879 Building Boost with Apache C++ Standard Library (STDCXX) > vladimir_prus 853 path with spaces not always handled > vladimir_prus 687 [program_options] Allow unrecognized options in configfile > vladimir_prus 428 Please add support for PDSK compilers for x64 and IA64 > vladimir_prus 418 Please add support for Intel 9 WIN32 > vladimir_prus 898 [program_options] improper guess > vladimir_prus 887 Duplicate target name bug on Cygwin > vladimir_prus 850 program_options strips off escaped quotes in some situations > vladimir_prus 808 [program_options] parse_config_file documentation bug > vladimir_prus 689 [program_options] Endless loop with long default arguments > vladimir_prus 674 find-library for boost decorated names > vladimir_prus 644 Boost.Build v2 build script help for evc4 > vladimir_prus 469 multitoken broken in program_options 1.33 > vladimir_prus 342 program_options Can one have options with optional values? > witt 1046 Boost.Python quickstart instructions mention nonexistent target > witt 973 zip_iterator has value_type == reference > witt 957 The "Getting Started" page does not mention the stdlib option > witt 834 Homepage regression links > witt 145 filter iterator adaptor should be able to be bidirectional > > -- > -- Marshall > > Marshall Clow Idio Software <mailto:marshall@idio.com> > > It is by caffeine alone I set my mind in motion. > It is by the beans of Java that thoughts acquire speed, > the hands acquire shaking, the shaking becomes a warning. > It is by caffeine alone I set my mind in motion. > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1