- Boost - lists.preview.boost.org

lexical_cast<wstring>(string)
by Jared McIntyre 05 Apr '04

05 Apr '04

Some time ago I read a discussion about possibly adding the ability to perform a lexical_cast of a regular to a wide string, and vice-versa. There was also discussion of possibly adding similar functionality to string_algo (though I tend to like the lexical_cast better for this). Has anyone looked more deeply into solving this problem? I've found these operations to be extremely common in my work on applications that are written in unicode, but may have to talk with non-unicode network protocols, libraries, etc. Jared

1 0

Review Result: Indexed Set
by Pavel Vozenilek 04 Apr '04

04 Apr '04

Indexed set library by Joaquín Mª López Muñoz has been accepted into Boost. Thanks Joaquín for innovative and professional work and for keeping up during moments when feedback was rather low. Review of the library was very positive. Thanks to all people who spent time contributing. Several points to improve had been identified during review. Consistent names for the library were discussed and hopefully identified. Some points Joaquín did or plans to address: _________________________________________ FUNCTIONAL REQUESTS 1. Issue BOOST_STATIC_ERROR if duplicate tags. This I've already done in my local version. Works OK. 2. Extend operator== and familiy to support indices over elements of different types (Gary Powell). I've done it in my local version, no problems arose. 3. Improve efficiency of equal_range (Arkadiy). 4. Include bimap in the roadmap. 5. Include ranked indices in the roadmap. 6. Include serialization support in the roadmap (it's already there.) 8. compose_key and lex_compare promoted to the library (they are implemented in examples now.) No problem from my part. 9. Include a concepts section for multi-indexed containers. David accepted that this be delayed. STYLISTIC REQUESTS 1. Navigation bar in the docs. 2. Limit source code to 80 chars per row (already done.) 3. Limit source code in the docs to 80 chars per row. 4. Rename "far pointer" to "chained pointer". I don't like this. 5. Other stylistic improvements that I've already applied. As for header organization, I'll move to a fine-grained policy. _________________________________________ New features and usage techniques are identified and will likely be implemented and documented. Care is taken keep the library easy to use. /Pavel PS: could someone try to run test "test_all_main.cpp" with VC 6.5 or 6.6. and report result exit code, please?

1 0

boost/graph/push_relabel_max_flow::is_flow() bug?
by Arun Bhalla 04 Apr '04

04 Apr '04

Hi, I'm not really a user of Boost, but I've been referring to the Boost Graph Library code for another project. In particular, I've been looking at push_relabel_max_flow.hpp. I was writing a unit test which followed the same ideas of the is_flow() test, and it was failing on what should be a flow network with a valid maximum flow. The code in question: // a is an edge_descriptor if (capacity[a] > 0) if ((residual_capacity[a] + residual_capacity[reverse_edge[a]] != capacity[a]) || (residual_capacity[a] < 0) || (residual_capacity[reverse_edge[a]] < 0)) return false; I contend the test should actually be: // a is an edge_descriptor if (capacity[a] > 0) if ((residual_capacity[a] + residual_capacity[reverse_edge[a]] ! != capacity[a] + capacity[reverse_edge[a]]) || (residual_capacity[a] < 0) || (residual_capacity[reverse_edge[a]] < 0)) return false; I refer to an example network in CLR (1st ed.), p.589. There are several vertices, but I focus on vertices v1 and v2. In this graph, we have capacities c(v1,v2) = 10 c(v2,v1) = 4 and residual capacities cf(v1,v2) = 11 cf(v2,v1) = 3 With the above (original) test, it would fail because 11 + 3 (the sum of residual capacities) != the capacity of either edge. This would hold true if the sum of residual capacities were compared with the sum of capacities. Ordinarily this test would work if reverse_edge[a] has a capacity of 0, which would be the case if the edge (a) is in the flow network, but its reverse is not. I'm not a graph theory expert, though, so I defer to anyone who is. :) Thanks, Arun

2 1

License oddity
by David Abrahams 04 Apr '04

04 Apr '04

I just noticed something strange about the license. It seems to require that derivative works and copies don't use the "by reference" technique we're using to refer to the license in our own sources: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software... I'm beginning to wonder if the current "by reference" technique is really compatible with the license. Will the intrigue never end? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Re:Re: [boost] Serialization: versioning and XML.
by Robert Ramey 04 Apr '04

04 Apr '04

Anatoli Tubman wrote: >It absolutely certainly will be a new archive class. Sorry if it wasn't >clear from the start. >I just think such an archive/serialization library is (a) useful enough >to bea part of boost and (b) similar enough to the existing boost >library to share the namespace with it. I've got no problem with this. >I understand fully that this idea works only with tagged formats (not >necessary just XML), that's why I'm saying that it should probably >use a different syntax or maybe a sub-namespace under boost::serialization. Within the boost::archive namespace I've got things like: basic_xml_iarchive xml_iarchive xml_wiarchive etc. I would think there is plenty of room for something like: basic_tagged_iarchive basic_tagged_xml_iarchive tagged_xml_iarchive tagged_xml_wiarchive etc. >I'm staying within program-structure-drives-data-format school of >thought. As long as you can stick with this, I think you can be successful. I briefly considered this approach. I imagined that upon archive creation the XML input could be parsed into a node tree. (insert plug for spirit here) The load_override function would be altered to search the correct part of the tree. So this would work and be pretty clean. I'm sure other approaches such as using SAX or DOM to parse the tree would work as well. Maybe there's another way I never thought of. The main reason I rejected the idea was that I didn't see it working with arbitrarily size streams. I envision serialization being used with stream much larger then available memory. This suggested to me an "on the fly" loader rather than a "pre-loaded". My implementation does require that tags remain in sequence and are all anticipated. Your proposal wouldn't have this restriction and might be preferred in certain applications. So I'm happy to encourage your efforts. I also hope that other users will be inspired to address more particular needs by creating their own archives class variations. In the long run, I'm trying to get out of the archive creation business in the same way I'm trying to get out of the class serialization business. >I don't precisely understand how going in the other direction >is ever useful. Okay, given a DTD, you can generate a program that could >read and write a bunch of data structures; but what will it *do* with >them? I can see the need for and utility of this. It's just that it's a whole different problem than what serialization addresses. Good Luck with this. Robert Ramey

2 1

Bug fix for BCP
by Edward Diener 04 Apr '04

04 Apr '04

Evidently I either don't have access to the Boost CVS repository on SourceForge or I still can't figure out how to use CVS, so here is a fix to a serious problem with John Maddock's BCP program, and someone else can make the fix. In bcp_imp.cpp, line 17 needs to be changed from: : m_list_mode(false), m_cvs_mode(false), m_unix_lines(false), m_scan_mode(false) to : m_list_mode(false), m_licence_mode(false), m_cvs_mode(false), m_unix_lines(false), m_scan_mode(false)

2 1

Re: [boost] Re: Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 04 Apr '04

04 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Jueves, Abril 1, 2004 8:35 pm Asunto: Re: [boost] Re: Formal Review: Indexed Set > I believe you should leave in the support for multiple tags per index. > Possible use cases include: > > - Including the key type as an index tag. > > - Using tags to flag various fields for some other algorithm -- in > this case, different fields could be flagged for use by various > different algorithms. If I'm understanding you, the case use you propose could be illegal. Do you mean something like: indexed_set< int, index_list< unique<tag<first,marked>,...>, non_unique<tag<second>,...>, non_unique<tag<third,marked>,...> > > So that "marked" can be taken advantage of by some algorithm? If so, this clashes with a request by Brian McNamara that duplicate tags be not allowed. If you mean something else, I'd appreciate if you could ellaborate. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-929094 ] patch for boost::filesystem
by SourceForge.net 04 Apr '04

04 Apr '04

Bugs item #929094, was opened at 2004-04-04 04:17 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=929094&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: patch for boost::filesystem Initial Comment: /usr/local/include/unit++.h: In member function `virtual void unitpp::exception_test<E>::operator()()': /usr/local/include/unit++.h:163: error: there are no arguments to `fail' that depend on a template parameter, so a declaration of `fail' must be available /usr/local/include/unit++.h:163: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=929094&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Proposed change to license references
by David Abrahams 03 Apr '04

03 Apr '04

Given recent advice from Diane Cabell, director of Harvard's Berkman Center for Internet and Society, I propose we change the way that boost source files refer to the bost license from: // Use, modification, and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy // at http://www.boost.org/LICENSE_1_0.txt) to: // Distributed under the Boost // Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) The earlier license reference, by referring explicitly to "use, modification, and distribution", legally excludes important issues like "display", which are covered by the license itself and are intended to apply to source files. I'm posting this now to give people a chance to come up with any other issues -- **with the license reference comment**, not the license itself -- that may need to be addressed before we make a change. If there are no new issues within a week or so, we'll make it official. -- Dave Abrahams Boost Consulting www.boost-consulting.com

8 13

Suggestion: link to the libraries page not easy to find
by Marcello Pietrobon 03 Apr '04

03 Apr '04

Hi Boost team, I don't know where to put this suggestion. Even if boost is now well known, I think in the boost's home page there should be a well visible, easy to find, link to http://www.boost.org/libs/libraries.htm because this is exactly what boost is about, I think. Best Regards, Marcello

5 12