- Boost - lists.preview.boost.org

[metagraph] definition
by Gordon Woodhull 07 Jul '08

07 Jul '08

I just have to share this little insight: finally, a concise definition. A metagraph is a system of objects where the types of the objects (classes) and the relations between them (e.g. pointers, mappings, containers) can be described in a graph called a pattern. In the C++ implementation, the patterns are metadata, which allows static typing and static polymorphism and moves the abstraction penalty to compile time (when the pattern is known at coding time). Patterns and their implementation code are combined into larger patterns; the "total pattern" is what actually gets instantiated. The library allows implementation of hypergraphs, subgraphs, various nested/mixed/ clustered layout schemes, constraints on graphs, and generally graphs- of-graphs, hence the name metagraph. Can any static analysis fans out there tell me if there's already a name for this? Note that in this definition, metagraph is something which already exists in lots of forms. This library proposes (for now) to implement the data structures in a nicer way and (in the future) to describe and access existing structures in a consistent way. My profuse apologies for continuing to talk about code that doesn't yet exist. Soon, soon. Cheers, Gordon

2 2

Re: [boost] [integer] Can anyone double-check this test?
by Vladimir Prus 07 Jul '08

07 Jul '08

Daryle Walker wrote: > I'm trying to tweak Boost.Integer, and I noticed that only 3 of the 6 > test files there are being used. I changed the jam-file there, but I > don't use Boost.Build myself, so can someone here confirm that the > changes work. You can check out the exact changes with Change-set > 47123 at <http://svn.boost.org/trac/boost/changeset/47123>. In other words, you've checked in something, and you don't know if that works? You really better learn how to use Boost.Build -- for the mainstream toolsets and operating systems, it's trivial. - Volodya

3 7

Graph library noise in logs
by Emil Dotchevski 07 Jul '08

07 Jul '08

Isn't it a good idea to remove these messages from the Graph library Jamfile? warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. IMO this information belongs in the documentation. At present it is displayed every time I build anything that uses Boost, even if it doesn't use Graph. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[test][darwin][trunk] using some undefined signal macros on Power PC
by JOAQUIN M. LOPEZ MUÑOZ 07 Jul '08

07 Jul '08

Hello, I guess it is pretty apparent by now, but Boost.Test is causing a lot of regressions in the Sandia-darwin-ppc regression runner with the following: http://tinyurl.com/689u7x ../boost/test/impl/execution_monitor.ipp: In member function 'void boost::detail::system_signal_exception::report() const': ../boost/test/impl/execution_monitor.ipp:292: error: 'ILL_ILLOPN' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:297: error: 'ILL_ILLADR' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:312: error: 'ILL_PRVREG' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:317: error: 'ILL_COPROC' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:322: error: 'ILL_BADSTK' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:332: error: 'FPE_INTDIV' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:337: error: 'FPE_INTOVF' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:367: error: 'FPE_FLTSUB' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:397: error: 'BUS_ADRERR' was not declared in this scope ../boost/test/impl/execution_monitor.ipp:402: error: 'BUS_OBJERR' was not declared in this scope AFACIS <signal.h> does not define these macros in Power PC architectures, further confirmation of this fact here http://source.winehq.org/source/dlls/ntdll/signal_powerpc.c I guess it's easy enough to conditionally #define the offending parts out relying on defined(__POWERPC__). I'd propose a patch mysel but I don't have the appropriate environment to test locally with. And unfortunately we don't have a Darwin/PPC champion yet: http://svn.boost.org/trac/boost/wiki/PlatformChampions HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

[flyweight] rw_locking policy patch for review
by Tim Blechmann 06 Jul '08

06 Jul '08

i have implemented a rw_locking policy for flyweight factories, based on boost::shared_mutex. to achieve that, i had to adapt the factory interface ... joaquín, would it be possible for you to review the patch? it is based against the version of flyweight from the boost sandbox svn ... best, tim -- tim(a)klingt.org http://tim.klingt.org Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs

2 3

BGL: Graph edges with greater than 2 vertices
by Aman Sinha 06 Jul '08

06 Jul '08

I am looking to build a graph where an edge can be incident on multiple vertices. I believe this is also called a hypergraph. The boost archives have some discussion of hypergraphs from way back in year 2002. Does anyone know what is the status of that? If is is not supported, is there a reasonable workaround to build such graphs? Thanks, Aman

4 4

[utility/swap] Okay to add array support to Boost.Swap (sandbox/swap)?
by Niels Dekker - mail address until 2008-12-31 06 Jul '08

06 Jul '08

Hi Joe, hi Steven, Would it be okay to you if we would add support for array types to the Boost.Swap utility that is located in the sandbox? I'm asking now, because I wrote an issue, asking the C++ Standards Committee to add an overload of std::swap for array types. And Howard Hinnant just mailed me the other day that the issue has reached status Ready. :-) LWG issue 809, "std::swap should be overloaded for array types" http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.h… Of course, it will still take a while before STL implementations will actually add such an std::swap overload. It isn't yet part of the Standard, officially. So I would very much appreciate if boost::swap would already start supporting array types. And I think it would be helpful when implementing swap member functions for templates like boost::value_initialized<T>. Array support could easily be added to swap/boost/utility/swap.hpp (http://svn.boost.org/trac/boost/browser/sandbox/swap/boost/utility/swap.hpp) by overloading boost_swap_impl::swap_impl, as follows: template<class T, std::size_t N> void swap_impl(T (& left)[N], T (& right)[N]) { for (std::size_t i = 0; i < N; ++i) { ::boost_swap_impl::swap_impl(left[i], right[i]); } } Please tell me what you think. I do have SVN write access, so I wouldn't mind committing the necessary changes. :-) Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

7 26

Question about boost::asio's design
by Yingfeng 06 Jul '08

06 Jul '08

I am using asio to my software and i have some design issue about asio and hope could get your idea about it. I plan to develop a server based on asio, which could support high concurrency with complicated back end tasks to be provided, that is to say, when received a request from a client, there exists a task involved with lots of disk io and many cpu cycles to serve that request. Therefore, some concurrency design pattern would be used together with a thread pool, such as Half-Asyn/Half-Syn or Leader/Followers. I have read some sources of Asio, i think the idea of using Reactor to implement Proactor is pretty cool. Here is what I have got from the code about the working flow: Take asyn_receive as an example: 1. A functor of receive_handler together with the socket descriptor is added to the read operation queue. 2. Reactor is blocked on the demulplex call such as select 3. When read is available, Reactor retrieves the read op from the read operation queue and invoke the functor named receive_handler 4. Reactor receive the data 5. After the data has been finished reading, another event with the handler which could be customed by users is posted to the read operation queue. ... According to the above flow, I can see that there exist two kinds of events in the operation queue: events to handle socket IO and events with completion handler customed by users. In the users' eye, the process of retrieving operation from queue and then invoke handler is proceeded within io_service::run(), therefore a thread pool should be binded with io_service::run(), which is just shown in the example of Http server 3. In the design pattern of Half-Asyn/Half-Syn or Leader/Followers, the working flow is: after retrieving an operation from the queue, then dispatch a thread to process that operation handler. However, in the asio's design, if I used the threadpool to io_service::run(), then both events of processing socket IO and completion handler will occupy the thread. I think this will cause more threading overhead. I think it is reasonable that only one thread to process the network IO, and other threads to process the task of completion handler. However, it is difficult to do that in the current design. Do you have any opinion about my situation? Very grateful! Yingfeng

1 0

problems with boost exception in trunk?
by Robert Ramey 06 Jul '08

06 Jul '08

Current testing shows two compilers failing to link tests for the wide character version of the seriliazation library. For Comeau - the error is symbol already defined. It appears that certain symbols are instantiated in both the serialization library and its wide character brother. This results in a failure to link the tests. For Intel, there is a cryptic message related to symbol count - so it might or might not be the same issue. I would appear that the same code is getting instantiated in both libraries. If my analysis is correct, this problem could appear for any application which links to two or more boost libraries which use boost exception. Since we don't explicitly test for this, this we would generally have no way of knowing about this. Could whoever is responsible for the exception library please look into this? I hope that the version in the trunk has not yet been merged into the release. Robert Ramey

2 5

[integer] Can anyone double-check this test?
by Daryle Walker 06 Jul '08

06 Jul '08

I'm trying to tweak Boost.Integer, and I noticed that only 3 of the 6 test files there are being used. I changed the jam-file there, but I don't use Boost.Build myself, so can someone here confirm that the changes work. You can check out the exact changes with Change-set 47123 at <http://svn.boost.org/trac/boost/changeset/47123>. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

more filesystem questions :)
by Emil Dotchevski 05 Jul '08

05 Jul '08

Without boost::filesystem, it is quite common for programs to take a path as user input and pass it to the OS without caring much if it's valid native path or not. If it isn't, the OS function call will fail. I don't think that this common use case would change much if it's ported to use boost::filesystem. This leads to my questions: if I can store any string into a path object, how are the semantics of boost::path different from the semantics of a string? What is the path type invariant? Does it give me any guarantees about the stored string? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

Inspection report and non-ASCII characters
by John Maddock 05 Jul '08

05 Jul '08

Would it be possible for the inspection report to print out the line containing the non-ASCII characters? There are a few files that are being flagged up, where I just can't find anything wrong with them :-( Thanks, John.

8 17

[dynamic_bitset] bug in to_ulong() in dynamic_bitset.hpp
by Boris Gubenko 05 Jul '08

05 Jul '08

A failure of dynamic_bitset library test dyn_bitset_unit_tests3 on Tru64/cxx and HP-UX/aCC revealed what appears to be a bug in <boost/dynamic_bitset/dynamic_bitset.hpp> introduced after Boost 1.34. The bug affects platforms where 'long' type is larger than 'int'. On both Tru64 and HP-UX, 'int' is a 32-bit type. On Tru64, 'long' is a 64-bit type. On HP-UX, 'long' is a 64-bit type in 64-bit data model (+DD64, which is how Boost testing is done on this platform) and 32-bit type otherwise. The test also fails on other platforms and while I cannot verify it, from the test output it apears that these platforms are affected by the same bug. What fails is the two testcases below in b.to_long() suite in boost/libs/dynamic_bitset/dyn_bitset_unit_tests3.cpp invoked with run_test_cases<unsigned int>() : { std::string str(ul_width - 1, '1'); boost::dynamic_bitset<Block> b(str); Tests::to_ulong(b); } { std::string ul_str(ul_width, '1'); boost::dynamic_bitset<Block> b(ul_str); Tests::to_ulong(b); } The code in <boost/libs/dynamic_bitset/bitset_test.hpp> converts dynamic_bitset<unsigned int> argument to unsigned long and checks that the appropriate bits in the result are set: result_type num = lhs.to_ulong(); // Be sure the number is right if (sz == 0) BOOST_CHECK(num == 0); else { for (std::size_t i = 0; i < sz; ++i) BOOST_CHECK(lhs[i] == (i < n ? nth_bit(num, i) : 0)); } This check fails for the bits in the upper half of the result. Here is an excerpt from dynamic_bitset<Block, Allocator>::to_ulong() function in <boost/dynamic_bitset/dynamic_bitset.hpp> in the trunk: result_type result = 0; for (size_type i = 0; i <= last_block; ++i) { assert((size_type)bits_per_block * i < (size_type)ulong_width); result |= (m_bits[i] << (bits_per_block * i)); } In our case, last_block = 1 and bits_per_block = 32. m_bits[i] has 'unsigned int' type. On the second loop iteration, a 32-bit integer is left-shifted by 32 bit positions. This triggers undefined behaviour. From 5.8 - Shift operators [expr.shift] : "The behavior is undefined if the right operand is [...] greater than or equal to the length in bits of the promoted left operand." With cxx and aCC, such shift results in zeroing of all bits of the left operand. Here is the code from <boost/dynamic_bitset/dynamic_bitset.hpp> in Boost 1.34 : unsigned long result = 0; for (size_type i = 0; i <= last_block; ++i) { assert((size_type)bits_per_block * i < (size_type)ulong_width); // gps unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); } Here on the second loop iteration, a 64-bit long is left-shifted by 32 bit positions which yields the intended result. x.cpp below illustrates the difference between trunk and Boost 1.34: x.cpp ----- #include <stdio.h> #include <limits.h> int main() { unsigned int m_bits[] = { UINT_MAX, UINT_MAX }; unsigned int bits_per_block = sizeof(int) * CHAR_BIT; unsigned long result = 0; for(int i = 0; i <= 1 ; ++i) { #ifndef Boost_1_34 result |= (m_bits[i] << (bits_per_block * i)); #else unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); #endif printf("result = %llx\n", result); } } cxxosf.zko.hp.com> cxx x.cpp && a.out result = ffffffff result = ffffffff cxxosf.zko.hp.com> cxx x.cpp -DBoost_1_34 && a.out result = ffffffff result = ffffffffffffffff cxxosf.zko.hp.com> Replacing result |= (m_bits[i] << (bits_per_block * i)); with unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); on the trunk makes the test succeed: verified on Tru64/cxx and on HP-UX/aCC. In <http://lists.boost.org/Archives/boost/2007/12/131126.php> I said: > It looks like a regression in boost/dynamic_bitset/dynamic_bitset.hpp > introduced in 1.35, but even in 1.34.1, it seems to me that the code in > to_ulong() is relying on undefined behaviour. What I was referring to is the code in 1.34 applying bitwise shift operator to a long operand. It would trigger an undefined behavior in C where "The operands shall have integer type", but it is legal in C++ where "The operands shall be of integral or enumeration type". So, I no longer claim that the code in 1.34 is relying on undefined behaviour. And the last thing: why the bug affects only platforms where 'long' type is larger than 'int'? Because if they are the same, as is the case on VMS or HP-UX in 32-bit data model, last_block = 0 and the single iteration of the for loop just assigns m_bits[0] to the result: the right operand of the shift operator is zero. To fix the problem, I suggest to replace the buggy code in <boost/dynamic_bitset/dynamic_bitset.hpp> in the trunk with that in 1.34. If there are no objections, I can do it. Thanks, Boris

3 3

[math] pow redux and observations
by John Moeller 05 Jul '08

05 Jul '08

I noticed that the trunk now has corrections for pow<N> to reduce template instantiations. However, the "N=1" specialization isn't correct. The second template parameter (bool odd) should be "true," not "false." I could be mistaken that 1 is an odd number, though. :-) As it is now, the whole template would work, but would ignore the 1/false specialization and create a new 1/true specialization that just multiplies "base" by the result of 0/false. Changing 1/false to 1/true will just cause it to return "base," as desired. Note also, please, that positive_power<0,false> returns 1 when base is 0. Since 0^0 is technically undefined, the "N=0" case should probably be handled at a higher level (in power_if_positive, perhaps), and cause an error, just like negative powers of 0. If that is done, the 0/false case could be removed from positive_power.

9 50

[filesystem] Function name changes
by Beman Dawes 05 Jul '08

05 Jul '08

All the changes mentioned below leave the current names in place as synonyms, so will break no existing code. * Change is_regular() to is_regular_file(). Dave Abrahams and several other people, including me, have found that the name of the is_regular() function is too obscure. It was chosen over is_regular_file() for brevity, but isn't holding up well with experience. The status name is already "regular_file" and the term "regular file" is used by the POSIX standard. * Change leaf() to base_name(). * Change branch() to base_path(). In the long thread '[filesystem] "leaf"', several people found the current names obscure or invoking the wrong metaphor. Many alternative names were discussed, with an eye to making the names more obvious, conforming to names such as "basename" used in other programming languages, and/or using names already in use by the STL. Not breaking existing code was also a major concern, given that "basename" is already used in Boost.Filesystem. The mental model for the new names is that for a path, p: p == p.base_path() / p.base_name() Thus if p == "foo/bar/boo.txt", p.base_path() == "foo/bar", and p.base_name() == "boo.txt". * Change basename() to base_name_prefix(). * Change to extension() to base_name_extension(). This change is to avoid confusion with base_name(). The mental model for the new name is that for a path, p: p.base_name() == base_name_prefix(p) + base_name_extension(p) Thus if p == "foo/bar/boo.txt", base_name_prefix(p) == "boo", and base_name_extension(p) == ".txt". Comments? --Beman

10 41

filesystem question
by Emil Dotchevski 05 Jul '08

05 Jul '08

What is the rationale for providing path and wpath types instead of using a single path type? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 3

libs/dynamic_bitset/bitset_test unmerged changes?
by David Abrahams 05 Jul '08

05 Jul '08

Should these be in the trunk? Index: bitset_test.hpp =================================================================== --- bitset_test.hpp (revision 40672) +++ bitset_test.hpp (working copy) @@ -1006,7 +1006,8 @@ bool did_throw = false; try { - s << b; + static_cast<void> + (s << b); } #if defined BOOST_OLD_IOSTREAMS catch(...) { @@ -1081,7 +1082,8 @@ const std::ios::iostate except = is.exceptions(); bool has_stream_exceptions = true; try { - is >> b; + static_cast<void> + (is >> b); } catch(const std::ios::failure &) { did_throw = true; -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

Finding algorithms returning ranges?
by Mathias Gaunard 04 Jul '08

04 Jul '08

Finding algorithms (find, find_if, max_element, and others) usually return an iterator to the found position, or the past-the-end iterator. While enough, it can be quite annoying when used with range adaptors and the like. Imagine something like this: auto r = some_range | some adapters...; auto it = max_element(r, comparison_function); if(it != end(r)) { do_something; } Without auto, it is simply unusable. If such algorithms returned the range [found, end), we would be able to write: if(!empty(max_element(some_range | some adapters..., comparison_function)) { do_something; } Particularly, I find it practical to use it with a function like that: optional<typename range_value<Range>::type> deref_opt(const Range& r) { typedef typename range_value<Range>::type T; return empty(r) ? optional<T>() : optional<T>(*begin(r)); } or like that: typename range_value<Range>::type deref_def(const Range& r) { typedef typename range_value<Range>::type T; return empty(r) ? T() : *begin(r); } For compatibility, maybe returning a range type that implicitly converts to the beginning iterator could work. Do people think this is a good idea?

2 1

Re: [boost] Any interest in generic sequence searching through single-pass iterators?
by dpxguard-boost＠yahoo.gr 04 Jul '08

04 Jul '08

Jim Xochellis wrote: > > I have written in my free time the "single_pass_search" C++ template function, which performs generic sequence searching similarly to the std::search STL algorithm. The most important quality of single_pass_search and its main advantage over std::search > > is its capability to search for a sub-sequence in a search-range that is accessed through a pair of single-pass (input) iterators, while std::search requires that the search-range must be accessed via forward iterators at least. Mathias Gaunard wrote: > I guess it could be interesting to overload std::search to work with > input iterators too. > There is no need to give it a different name. Unfortunately, I cannot think of a way to "overload" std::search to work with input iterators, without changing its behavior significantly. Please see the section "Oddities and drawbacks" of the Home/Algorithms/single_pass_search/single_pass_search.html documentation file in the "Boost File Vault", for more details. Best regards, Jim Xochellis ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

1 0

Any interest in generic sequence searching through single-pass iterators?
by dpxguard-boost＠yahoo.gr 04 Jul '08

04 Jul '08

Hi list, I have written in my free time the "single_pass_search" C++ template function, which performs generic sequence searching similarly to the std::search STL algorithm. The most important quality of single_pass_search and its main advantage over std::search is its capability to search for a sub-sequence in a search-range that is accessed through a pair of single-pass (input) iterators, while std::search requires that the search-range must be accessed via forward iterators at least. For example, single_pass_search can easily search a file directly through a pair of istream iterators, while std::search requires the interference of an intermediate container in order to obtain the file data via a pair of forward iterators at least. With data sources like istream, using single_pass_search instead of std::search is by far simpler, more efficient and less memory consuming as well, because the std::search algorithm additionally requires an intermediate container and some stream buffering logic. Anybody interested? For more information, I have uploaded in the "Boost File Vault" the following files: Documentation: Home/Algorithms/single_pass_search/single_pass_search.html Implementation: Home/Algorithms/single_pass_search/single_pass_search.h Example: Home/Algorithms/single_pass_search/Example..cpp Best regards, Jim Xochellis ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

2 1

[1.36.0] Final requirements for directory and file names
by Beman Dawes 04 Jul '08

04 Jul '08

The final requirements for directory and file names are now posted at http://beta.boost.org/development/requirements.html#Directory_structure These are now stable for 1.36.0. Hopefully they will also be stable for quite some time beyond 1.36.0. The inspect program has been updated accordingly. --Beman

7 12

Compile time maths/square root?
by Joseph Gauterin 04 Jul '08

04 Jul '08

Does boost have a library of compile time maths functions? I've only been able to find GCD and LCM algorithms (boost/math/common_factor.hpp) If such a library exists, it would be worth adding a summary of them to /libs/math/doc/html/index.html In paticular, I was looking for a compile time integer square root function.

2 1

[extension] load_single_library() - silent failure?
by Robert Dailey 04 Jul '08

04 Jul '08

When calling load_single_library(), if the 3rd parameter, which is the name of the export factory function, is incorrect, load_single_library() will silently fail and return as if nothing went wrong. However, since the name of that function was mistyped (in my case), I had to debug into the boost.extensions library to figure out the actual source of the problem. I think this should have thrown an exception. For example, I called the function like below: factory_map fm; load_single_library( fm, "my_library.dll", "my_export_method_typo" ); And my function, as defined in the DLL source, is as follows: extern "C" void BOOST_EXTENSION_EXPORT_DECL my_export_method( boost::extensions::factory_map& fm ) { } As you can see, the string (in the first code example) is clearly mistyped/misnamed. This results in silent failure. Opinions on this would be useful.

2 2

[property_tree] XML parser errors
by Preston A. Elder 03 Jul '08

03 Jul '08

Hey, This is not a new issue, but a quick search sees it not reported. Each of the XML parsers that are available for property_tree has a problem, with the exception of the TinyXML version (which is annoying because it requires an external lib). - RapidXML (the default) Lines 95 and 98 of xml_parser_read_rapidxml.hpp need to be changed from this: if (flags & no_comments) doc.parse<parse_normalize_whitespace>(&v.front()); else doc.parse<parse_normalize_whitespace | parse_comment_nodes>(&v.front()); to this: if (flags & no_comments) doc.template parse<parse_normalize_whitespace>(&v.front()); else doc.template parse<parse_normalize_whitespace | parse_comment_nodes>(&v.front()); Without this change gcc 4.2 won't compile them (not sure about other versions of gcc). - PugXML Line 1827 of pugxml.hpp looks like: class xml_iterator : public std::_Ranit<_Ty,_Diff,_Pointer,_Reference> I don't know about anyone else, but my STL doesn't have a _Ranit class, and depending on non-standard components is a bad idea for portable code. - Spirit It fails to parse some XML that is perfectly valid under the RapidXML and and TinyXML versions. On the plus side, it compiles out of the box ;) I'm not 100% sure what it is, I get this error: terminate called after throwing an instance of 'boost::property_tree::xml_parser::xml_parser_error' what(): <unspecified file>: invalid character entity Aborted Here is a trimmed down XML file that should work fine, and does under rapid and tiny: <log> <formatter type="literal" name="BEGIN"> <string>TEMP</string> </formatter> <appender type="file" name="FILE"> <filename>test.log</filename> <formatter>BEGIN</formatter> <truncate>true</truncate> </appender> <logger name="test"> <threshold>10</threshold> <appender>FILE</appender> </logger> <fallback>test</fallback> </log> I don't see anything specifically wrong with this. Note however, that using spirit on a DIFFERENT xml file that imho is significantly more complex and larger parses just fine with spirit (I would paste it, but it >2.5k). PreZ :)

1 1

[filesystem] Change "remove" function's return to void?
by Beman Dawes 03 Jul '08

03 Jul '08

The remove(p) function is currently specified to return a bool with a value of exist(p) before the post-condition is established. The post-condition is !exists(p). The original thought in providing this was that the return value might be useful and would cost nothing. It turns out that providing this return value does have several costs: * A call to exists() could be omitted if the actual system removal call succeeds. exists() is surprisingly expensive on some operating systems. * It makes the remove() function less reliable in that it introduces a potential race condition. * It makes flow of control more complex (and thus harder to test) for some implementations. Thus I'd like to change the return to void. Although that will break some code, the breakage will result in a noisy compile-time error that is easy to fix by inserting a call to exits() before the call to remove(). Comments? --Beman PS: This was precipitated by ticket #1972, but doesn't affect the resolution of the remove() issue it raises. That will be fixed for 1.36.0 regardless.

4 4