- Boost - lists.boost.org

[string_algo] Small documentation inconsistency regarding replace_all
by Eelis van der Weegen 21 Aug '05

21 Aug '05

The documentation for boost::algorithm::replace_all (at http://boost.org/doc/html/replace_all.html) lists void as the return type for the function, but further down mentions: "Returns: A reference to the modified input" Regards, Eelis

1 0

Re: [boost] asio networking proposal
by Dave Gomboc 21 Aug '05

21 Aug '05

> Sorry, I wasn't really clear before. The presence or not of the handler > parameter is the difference in the function *signatures*. How the > function actually behaves is quite different (a synchronous call blocks > the calling thread, an asynchronous call never blocks). It is not the > handler parameter that determines whether the operation is synchronous > or asynchronous; the handler is just the function that is called when > the asynchronous operation completes. Actually, I understood how you intended it to work, but I had been trying to convince myself that it's truly better for the asynchronous calls to have a different signature than the synchronous call, and I wasn't able to convince myself. So I was hoping that you'd do it. ;-) The devil's advocate position remains: synchronous operation is merely the particular case where the handling policy prevents the function from returning control to the caller until the operation has completed; no unique function signature is warranted. > What do you think of my proposal in my email earlier today where > basically I use "read" and "write" for the operations that are in the > *Stream concepts (and so could equally apply to pipes, files and so > on), but retain "send" and "receive" (and "send_to" and "receive_from") > for operations that are specific to sockets? It would be better if use of "read" and "write" were ubiquitious, but if there's an overloading clash, I guess you have to do what you have to do. Dave

2 1

[Wave] Does it do phases?
by Daryle Walker 20 Aug '05

20 Aug '05

Wave is our C++ preprocessor, but preprocessing is the third phase of translating a file. (Looking at section 2.1 in the standard). I have a gut feeling that all the compilers out there mush the first three phases together in parsing a file. Glancing over the Wave docs gives me the same impression about it. Are either one of these feelings accurate (this requires a separate answer for each parser)? If the answer for Wave is "yes", could we separate them, at least as an option? I feel that this is important so we can gain full understanding of each phases. It may be more complicated[1], and most likely slower, but it could represent a clean implementation. (BTW, what phases does Wave act like?) The first two[2] phases are: 1. Native characters that match basic source characters are converted as so (including line breaks). Trigraphs are expanded to basic source[3]. Other characters are turned into internal Unicode expansions (i.e. act like "\uXXXX" or \Uxxxxxxxx"[4]). 2. The backslash-newline soft line-break combination are collapsed, folding multiple native lines into one logical line. We should spit out an error if the folding creates Unicode escapes. For non-empty files, we need to spit out errors if the last line is not a hard line-break, either a non-newline character or a backslash-newline combination is forbidden. [1] Our "Wave-1" would convert the original text (iterators) into phase-1 tokens. Our "Wave-2" would convert phase-1 token (iterators) into phase-2 tokens, etc. Remember that any file-name and line/column positions will have to be passed through each phase. [2] I thought Wave just did phase-3, with phases 1 and 2 thrown in at the same time. But now I'm not sure which phase Wave stops at. I don't think it can go past phase-4, because doing phase-5 needs knowledge of the destination platform. [3] Only '?' characters that are part of a valid trigraph sequence are converted; all others are left unchanged. [4] But actual "\uXXXX" resolution doesn't happen until phase 5! -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Random access and memoization in TMP
by Bruno Martínez 20 Aug '05

20 Aug '05

Hi. I was pondering the other day about the unique built in memoization capabilities of templates. It ocurred to me that if one could share more between different instantiations the compilation process would be sped up. For example, take drop :: Int -> [a] -> [a] defined so that (drop 0 list) is (list) (drop 1 list) is (tail list) (drop 2 list) is (tail (tail list)) in Haskell this would be written drop 0 list = list drop n list = drop (n-1) (tail list) So that the last clause exploits last call optimization. However, another way would be drop 0 list = list drop n list = tail (drop (n-1) list) Now, take at :: Int -> [a] -> a at n list = head (drop n list) If I construct a list in O(n) and then take the last element with at, also in O(n), then access to every element becomes O(1), because traversing to the last element precalculated all the other positions. I made a test with gcc, in which I traverse a list in forward direction but naively use at to get to the current position. There are four variants. homemade_slow uses the first drop definition. homemade_fast uses the second. mpl_vector and mpl_list use those sequence classes. The times were, in seconds: homemade_slow 41 homemade_fast 0.7 mpl_vector 4 mpl_list 11 I've been thinking the past days of other functions like drop that could be improved in a similar way, but they have eluded me. I didn't find mention of similar techniques in the MPL book, so I wonder if I'm making any sense. Regards, Bruno

3 11

[date_time] Constructor causes syntax error
by Markus Schöpflin 20 Aug '05

20 Aug '05

The latest CVS contains the following code in boost/date_time/date_generator_parser.hpp: date_generator_parser(const date_generator_parser<date_type,charT>* dgp) ------------------------------------------------------------------^ { this->m_element_strings = dgp.m_element_strings; -------------------------------^ } This is a typo, isn't it? Shoudn't this be a copy constructor? Markus

5 5

Boost regression notification (2005-08-20)
by Douglas Gregor 20 Aug '05

20 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-20T15:26:15Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 61 failures in 5 libraries: graph (11) parameter (7) python (22) serialization (20) wave (1) |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 msvc vc-6_5 vc-6_5-stlport |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Who is using Boost? - 2 Submissions
by Andreas Pokorny 20 Aug '05

20 Aug '05

Hi, I am maintaining and refactoring two GPL applications at the department of bioinformatics (read: computer science and biology) at the University of Würzburg. The upcoming release of Porfdist is using a boost in many places, and the already released CBCAnalyzer is also boost powerd. It might be nice to have them mentioned on the "Who is using Boost" page. Name: CBCanaylzer Developed by: Department of Bioinformatics, at the University of Wuerzburg CBCAnalyzer (CBC = compensatory base change) is a tool to create ``small'' phylogenetic trees from sequence alignments. To measure the distance of sequences the compensatory base changes are detected and counted. The bionj algorithm is then used to construct a tree. CBCAnalyzer is available on Windows, Linux and partly works on MacOSX. Libraries: Program Options - creates really nice output, and is both easy to extend and simple to handle. Iterator, Spirit - Saved a lot of my time, and makes the vast amount of biological file formats simple to support, Shared Pointer, Lambda, URL: http://www.biozentrum.uni-wuerzburg.de/index.php?id=524 Name: Profdist Developed by: Department of Bioinformatics, at the University of Wuerzburg Profdist is a tool for the construction of large phylogenetic trees based on profile distances. The input alignment data gets extended by random picking of rows, and a clustering technique is used to create profiles of the most frequent subtrees. The iterative approach allows working on large datasets. Currently the application is very limited by the quality of wxWidgets, and only available for Windows and Linux. Libraries: String Algorithms, Ref, Iterator, Spirit, Shared Pointer, Lambda, URL: http://www.biozentrum.uni-wuerzburg.de/index.php?id=523 Regards Andreas Pokorny

2 1

boost::detail namespace
by Marcin Kalicinski 20 Aug '05

20 Aug '05

Hi, Most boost projects use boost::detail namespace to implement hidden, private functionality. What prevents name clashes in that namespace? Marcin

5 11

Re: [boost] Interest for a perl6-like-junctions-class?
by Rob Stewart 20 Aug '05

20 Aug '05

I uploaded some fixes to multivalues.zip: - Workaround for BCB's lack of EBO - Fixed some overzealous searches/replaces - Eliminated SFINAE from test program - Moved some tests out of the macros to assist in debugging, should anyone have problems with support in a particular compiler. Some questions: - What operator(s) should we use to delimit user-defined predicates? Here are some interesting candidates: if (any_of(...) << some_predicate() >> 5)... // 1 if (any_of(...) < some_predicate() > 5)... // 2 if (any_of(...) ^ some_predicate() ^ 5)... // 3 if (any_of(...) / some_predicate() / 5)... // 4 1 seems pretty good because the two-character operators stand out well. 2 works pretty well, but I'm concerned that the operators may get lost if the predicate is a specialization of a template type; the template argument list uses the same tokens. (1 is better in that case because of the doubled tokens.) 3 is an unusual operator to overload, so it is largely unique to this context. 4 works, but I'm concerned that it is gross misuse of the operator (overloading it for division and filesystem path manipulation are sensible; is this?). - Should we attempt VC6 support? If so, some functionality or syntax will have to be sacrificed. It may be that the iterator pair support is all that we must sacrifice. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

4 7

[serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs
by Kim Barrett 20 Aug '05

20 Aug '05

I've been reading this thread with increasing alarm. I agree with Martin Ecker and Vladimir Prus that the synchronization in question belongs inside the serialization library. The system we are building will have several inter-process communication mechanisms, which I'm hoping to be able to build on top of Boost.Serialization. (As noted in another thread, I've run across some performance issues, which might be addressed by resetting and reusing archives, rather than constructing new archives all the time.) It is expected in our system design that it will be possible to dynamically load DLLs containing new types which support serialization, and then create new IPC connections (with associated archives) to/from which instances of those newly loaded types can be serialized. It is not a requirement that previously existing IPC connections (and their associated archives, either presently in use, or available for reuse if archive resetting is used) support these new types, since the type information for the connection is specified at connection creation time. We expect a substantial number of such connections to exist at any one time, with many threads involved, and they have some latency requirements. We presently plan to punt support for unloading DLLs, on the basis that the benefit (in our system) would be small compared to the design / implementation / documentation cost for supporting unloading safely and correctly. (We might revisit the decision about unloading, but for now supporting it is not a requirement for us.) I'm pretty sure that intertwining runtime DLL loading with all of our clients of the serialization library is just not going to fly. I think that making it a configuration option whether the library protects its internal data structures is a reasonable approach, since some applications won't need it (either because they are single-threaded or are willing to deal with the issues at the application level) and might not want to pay the cost. But for some applications, having the library be responsible for the consistency of its internal data structures is really the only realistic option. I think the only way I will be able to sell the use of the serialization library for our project is to either convince you to change on this issue, or to obtain or develop a patch and carry it forward. The latter might be less work in the long term than developing the subset of serialization features that we actually need, but the long-term maintenance headache for a patch is worrisome.

2 2