March 2004 - Boost - lists.preview.boost.org

patch: boost/math/special_functions => compile error in asinh.hpp, acosh.hpp and atanh.hpp
by Huber, Carsten 10 May '04

10 May '04

Hello boost developers, this is my first mail to boost(a)lists.boost.org and it is already a bug that I found in the latest release 1.31.0 :-( I tried to compile boost::math::asinh, boost::math::acosh and boost::math::atanh recently and got a compile error "C2039 'abs' : is not a member of '_STL'" on my MSVC6 compiler. I have STLPort 4.5.3 installed and thought, this might be the problem, but then I found out that boost::math::sinc_pi and boost::math::sinhc_pi compile with no errors. To make it short: asinh, acosh and atanh are using ::std::abs, ::std::sqrt and ::std::log - which are not part of the STL. To fix this problem, I have created a patch - see attached files. Best regards, Carsten Huber ------------------------------------------------- Dipl.-Ing. Carsten Huber (Member of the VDE) Software Development Engineer Product Line Diagnostics (PDG) Vector Informatik GmbH Ingersheimer Str. 24 D-70499 Stuttgart Phone : +49 711 80670-0 Fax : +49 711 80670-299 Mailto : carsten.huber(a)vector-informatik.de Internet: http://www.vector-informatik.de -------------------------------------------------

2 1

Ok to commit?
by Gennaro Prota 13 Apr '04

13 Apr '04

Sort of administrative question :) I'm going to commit an improved version of dynamic_bitset, in the next days. The version, which is in the sandbox, has finally had Jeremy's approval. My question is: to implement find_first and find_next, two new functions I have added, I use a simple lowest_bit<T> template, which in turn requires integer_log2<T>; so there are two new header files: a) http://tinyurl.com/36zsj b) http://tinyurl.com/2lb26 I think they provide two useful facilities in themselves. Would it be ok to commit them in the boost/ folder? Or should they belong to boost/detail/? Or maybe boost/pending/? -- Genny.

4 5

cref(_1)
by David Abrahams 12 Apr '04

12 Apr '04

Hi, I have this code that isn't compiling because of the "forwarding problem" limitation of boost::bind: std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, _1)); The problem is that an implicit conversion is required between the reference type of the difference_iterator and the argument type of writeVInt. It seems to me that, since I know that binding to an rvalue is required, we ought to have a way to say "force this to be a const ref". I thought of something like std::for_each( make_difference_iterator(p->second.begin()) , make_difference_iterator(p->second.end()) , boost::bind(&fu::writeVInt, &prox, boost::cref(_1))); ^^^^^^^^^^^^ ^ I know it's not pretty, but it sorta does what we want. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 7

RE: [boost] Re: Numeric conversions lib comments
by Rozental, Gennadiy 07 Apr '04

07 Apr '04

> > In most part proposed design looks reasonable. I have only > one major > > IMO concern. > > > > Issue: (Major) Why traits are template parameter of > converter? I've > > expressed my opinion in the matter before: Traits - as name suggest > > could not be policy. IOW should not be template parameters. > Traits are > > type specific and an ability to supply them independently to the > > primary type in most cases leads to invalid/too complicated design. > > Traits are not only template parameters of public > converter class > > but many other classes. IMO all of them should use S and T > as template > > parameters instead. > > > I have to disagree. > Traits are used as policies in too many designs, including > the STL itself, and I don't see a problem with that. I agree I don't say I like it either. Major issue with basic_string design IMO is that char_traits is template parameter > that traits classes are type specific, but they are used as > policies precisely because of that: if the user of a > parametrized facility wants a different treatment for a given > type, she can't change *the* traits for the type, all she can > do is pass in a different traits as a policy. Here is how I see it. Trait is something type specific, IOW specific to type, IOW uniquely defined by type. If you could provide trait along with the type as a template parameter, that mean you could change it independently from the type, IOW you could define different value for trait still using the same type. For example if you have component C defined like: template<typename T, typename Trait> struct C { ... }; You could instantiate it like C<MyT,TraitValue1> or C<MyT,TraitValue2>. So as you could see trait value is not uniquely defined by the type. Proper design would be to have trait stand alone class, like this: template<typename T> struct Trait { value = ... }; template<typename T> struct C { here we are using Trait<T>::value, where we used to use Trait. }; Now if the user needs to define trait value (or change from using default value provided by most traits designs), she just need to define explicit/partial specialization for this type or types family. On the other hand policy is something that is orthogonal to the primary type (actually in policy based design there may not be any primary type, but just an orthogonal policies), IOW you could use different policies in conjunction with the same type. And natural place for the policy is along with type in component definition among the template parameters. > If this were > not a policy, users would be stuck with the definition of the > default traits class. I agree that this opens a window to all > sort of problems in case a user plugs in an invalid traits, > but I think that should not constitute a reason for fixing > the traits into the converter. As always, "trust the programmer" So again Trait is not a Policy and let's not mix them > > 4. converter<>::convert converts only rvalue. Why? > > IMO we need second operation that works with lvalues. > What if I want > > to convert int& into char&? > This requires the target lvalue as a parameter instead of a > return value. It could be done yes, but I don't see the > reason. Why would want to do that? For example for [de]serialization solutions. What is in your opinion is problem domain for numeric conversion? Gennadiy.

11 50

Uploaded/checked in Wave V 1.1.4
by hartmutkaiser＠t-online.de 07 Apr '04

07 Apr '04

Hi all, I've just uploaded a new version of the Wave preprocesor library (V1.1.4) to the yahoo files section here: http://tinyurl.com/yul67. The same version is checked into the boost-sandbox CVS. There were a lot of changes recently: - Adjusted to use the new version of the program_options library. - Fixed a bunch of minor bugs in the expression evaluation engine. - Made a lot of other rather unrelated bug fixes (see in the ChangeLog file contained inside the distribution). Besides passing its own test suite Wave now passes 98% of the preprocessor validation suite published here: http://tinyurl.com/yul67. The remaining open issues are in the field of wide character and multibyte character handling, which are implementation depended anyway. But I'm still working hard on fixing the remaining issues. Regards Hartmut

2 2

[BGL] forced client complexity
by Provisional Dissonance 05 Apr '04

05 Apr '04

If one accepts the axiom that "a picture is worth a thousand words," then it naturally follows that discussion of graphs is always overly prolix. Sadly, the same reasoning is also applicable to the code of graph libraries. Boost.Graph seems to expose and require an unnecessarily large amount of complexity, though. Whereas libraries like Spirit go to great lengths to make hard things easy, BGL seems to try only to make hard things possible. The amount of scaffolding required to use BGL for even the simplest of projects often dwarfs the code size of a naive, yet functional, special-purpose implementation. While I understand that the BGL is deeply entrenched in boost culture, certain academic circles, and even publications, I nonetheless suggest that BGL lacks the ease of use necessary for widespread adoption. Even knowing that ease-of-use is not a criterion for acceptance into boost, looking at what is required of the client to use the BGL always leaves me feeling perplexed. Is there any particular reason that a simplified interface is not made available? Perhaps a container adapter could be packaged with the library allowing a compromise of functionality and flexibility for simplicity? If a graphing problem is trivial, shouldn't BGL provide a trivial solution? Why are the simplest useful examples several hundred lines of code? I apologize for all of my vague criticisms - my intention is not to flame but rather to test the waters. It is difficult for me to assess whether the simplicity I yearn for isn't present for stylistic reasons or whether it would rather necessitate a sacrifice of flexibility, functionality or implementation clarity. Nor is it clear to me to what extent these criteria can be compromised to promote clarity of client code. For what it is worth, the kind of ease-of-use I'm imagining might look like: #include <less_than_10_graph_headers> ... digraph<some_node_type,some_edge_context_type> g; g << "vertex" << make_pair("vertex", "implicit_vertex"); g.add_edge("brother", "sister", "sibling"); if(g.find(make_pair("brother", "sister"))) related = true; Could someone please elucidate on why it is impossible/impractical/unnecessary/whatever for a graph library to have such an interface? Should I accept that the BGL is not the magic bullet graph library and move on, or can this kind of simplicity be somehow found within? Thanks in advance, prs __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

3 7

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

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

Nightly CVS not using current BoostBook L&F
by Reece Dunn 02 Apr '04

02 Apr '04

A while back, Doug Gregor mentioned that the metacomm Nightly CVS did not use the new BoostBook L&F. This has since been updated, and the problem has persisted -- the Nightly CVS does not reflect the latest XSL:T. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

4 8