April 2007 - Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1693642 ] xtime documentation incomplete
by SourceForge.net 03 Apr '07

03 Apr '07

Bugs item #1693642, was opened at 2007-04-03 07:00 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=1693642&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: xtime documentation incomplete Initial Comment: The documentation for boost/thread/xtime.hpp only lists the "sec" member of the xtime struct, and not the "nsec" member. Also, it would be great if the documentation for xtime_get() had a link to or mention of the xtime_clock_types enum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1693642&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Guid library
by Andy 03 Apr '07

03 Apr '07

I have uploaded a new version to the Boost Vault. It is now a header only library. It can be downloaded (guid_v6.zip) at: http://www.boost-consulting.com/vault/ or direct download link: http://www.boost-consulting.com/vault/index.php? action=downloadfile&filename=guid_v6.zip&directory=& Andy Tompkins

3 4

[pointer_container] ptr_map_iterator::key() gone in 1.34 ?
by Paul Rose 03 Apr '07

03 Apr '07

There seems to be a substantial interface change between 1.33 and 1.34 of ptr_map. I'm trying to move a largeish project from 1.33 to 1.34. The only unsolved problem is that it has 21 separate declarations of a ptr_map, each with a dozen or so uses of iterator where *iter has to be replaced with *iter->second and iter->key() has to be replaced with iter->first. The 1.34 documentation at http://www.boost-consulting.com/boost/ doesn't seem to mention this, and my searches can't seem to turn up where this was discussed. I can see why the new interface might be preferred, but can anybody provide a reference to the discussion (or other insight) that led to this code-breaking change? Ideally I'd like my code to work with both 1.33 and 1.34. Any hints on how to do this elegantly? Thanks, Paul Rose

2 3

Re: [boost] [Review] Quantitative units - compile time vs runtime
by Martin Schulz 03 Apr '07

03 Apr '07

Hello everybody, my background is in software development for scientific and engineering computing, facing complex applications in industry. Therefore, I may take the opposite stand here. For fairness, I must add that I am somewhat from the competion, as I have started my own little (not yet upgrown) project in this area. Practically speaking, when developing such a technically minded piece of software, approximately 30% of the development effort goes into the computation kernel whereas the remaining 70% of the effort goes to the overall infrastructure, business layer, presentation layer (batch, gui, api,..), interoperability, productizing etc. It is sad to say, but such is life. The proposed solution is only targeted towards the compuation kernels. As a matter of fact, you have to ensure that the right things get in, and the right things get out there. What happens inside however is a completely different story. Once you know for sure what you got, you'll take a pencil and a piece of paper and you write down what you're going to implement. Once you are sure what you are doing, you go and implment it (using plain dimensionless floating point arithmetic). That worked well for over 50 years now. While a template-based solution might seem appealing and might even be applicable in some cases, there are many others where it is not: Consider for example solving an ordinary differential equation: A mechanical system described by locations and velocities, the excitation given by some forces depending on various factors. As long as you restrict yourself to explicit time integration, you may get around with type-encoded units. For implicit schemes, however, you will have to solve linear or nonlinear systems of equations, with various unknowns of different physical quantities (aka types) in a single vector (locations and velocities in the above case). This is not possible in C++ and thus the point where the approach by this library does no more hold. You can apply some fancy transforms beforehand to basically make all numbers dimensionless, but then you dont need a unit library anyway. Similar situations occur in all kind of fluid dynamics, finite difference, finite element codes, dynamic simulation codes and the like. I feel a far stronger need for a physical unit library in two other parts: Namely the business locgic and the presentation layer. A) The business logic is about intermediate storage of compuation results for the use by other parts of the software, probably written by other people, at other times, in other locations. Here you have to ensure that the units _really_ match in every possible case. And there are lots of cases possible. If they do not match, a conversion is usually acceptable, as it does not happen over and over again. We also talk about serialisation aspects here. Language dependend output (as suggested for future development in the documentation) to files is an absolute no-go: Otherwise the file saved by one engineer will not be able to get read by his collegue, only because they do not have the same language setting. Furthermore, many times, you do not know wile writing the software, what kind of quantity you actually handle. This is not so true for compuation kernels but more for backend storage that abstractly handles results of one computation over to some other computation, some postprocessing tools or the like. Nevertheless correct unit handling is indispensable. B) The presentation layer consists of everthing that is visible to the user, namely the GUI or the like. People in academics can hardly imagine what expectations engineers might have towards the units of their data. (Before entering industry, I was no exception to that rule :-) ) This is partly due to historical reasons; the choice of units in the presentation layer may vary by corporate guidelines, personal preference, professional background of the user or geographical location. If you want to get around with a single piece of code then, you cannot live with a fixed units for the quantities in your program. (The presentation layer, that is -- computation kernels are another story.) As another example, consider simply a nifty small graph plotting widget. Clearly enough, this widget must handle whatever unit may arrive. Furthermore, users may decide to add or multiply some channels or combine them by some other means. Therefore the arithmetic operations for units are necessary at the runtime of the program. All together, the library does not fit my need or those of my present or previous coworkers. As mentioned, there are severe obstacles for the application where it could be deployed and it does not help where the real problems are. In my opinion, it simply does not go far enough. Template-based solutions are known for many, many years by now (the book of Barton&Nackman is the oldest I personally know of) but have not been widely adopted until now. In my opinion, this is not so much due to the lack of compiler support but because the template-based approach can only be applied to some small portion to the issue, and thus can only be a minor (though not so unimportant) building block of a solution. I like the notion of a unitsystem as a mean of choice for the internal represenation of the quantities (and have already taken that idea to my own project). On the other hand: the length of my desk is a physical quantity that exists independently of the unit it is expressed in. The numerical value of that quantity is only fixed for a given unitsystem but this is an implementation detail, not a principal thought or definition. Thus I find the definition "A quantity is defined as a value of an arbitrary value type that is associated with a specific unit." somewhat irritating. Some more details: ------------------ The author mentiones the problem to distinguish the units for energy and torque. Both quantities result as a product of a length and a force but have completly different physical meanings. When reading the documentation, I got the impression that these two should be distinguishable somehow, but the author does not tell us of what type the product (2*meter)*(5*Newton) should actually be and how a compiler should tell the difference. I got the impression that the intent of the following code is not so obvious: quantity<force> F(2.0*newton); std::cout << "F = " << F << std::endl; The author states that the intent is obviously F = 2 m kg s^(-2); In contrast to the author, I personally would naturally expect something like: F = 2.0[N] This issue is not half as superficial as it might seem at first glance. In fact that is what the whole presentation layer stuff is all about. I have yet to see any stringend need for rational exponents. They rather obscure the physical meaning of certain terms, imho. To define all possible conversions of n unitsystems, you'll need about O(n*n) helper structs to be defined. I may be overlooking some more elaborated automatism, though. However, we are likely to face a larger number of unitsystems as already the conversion of "cm" in "m" requires different systems. The handling of temperatures (affine units in general) is correct but not very practical. The executive summary: ---------------------- * What is your evaluation of the design? I am strongly missing concepts that help to create additional functionality instead of "only" error avoidance. To me the semantics of quantities or units is not clear, and does not conform well with the one of the NIST (National Institute of Science and Technology: http://physics.nist.gov/cuu/Units/introduction.html) * What is your evaluation of the implementation? >From the technical aspects, this library looks probably good. My objections focus on the semantic level. * What is your evaluation of the documentation? The documentation looks very good, though the "quick start" and the following pages is too much about the internal implementation and not helpfull enough for those people that simply want to use the library. * What is your evaluation of the potential usefulness of the library? In the current form, it is no of direct use for me. I am sorry to say that. Basically it is what is was originally written for: "An example of generic programming for dimensional analysis for the Boost mailing list". It was not designed with focus on the problems of realistic large scale scientific and engineering C++-programming. Nevertheless I already took ideas from it. * Did you try to use the library? With what compiler? Did you have any problems? I briefly compiled some examples and tried to extend them. I had no technical difficulties using VC8. Rather had to struggle to find syntactically how I should do the things I wanted to. But that would be only a minor documentation issue. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I thouroughly read the documentation, thought deeply about it, and briefly played around with the implementation. * Are you knowledgeable about the problem domain? Yes, definitely. I am working on that topic for about 2 years now, analyzed our existing solutions, held meetings with different coworkers about the strengths and weaknesses of their existing solutions, evaluated some other existing libraries. Because all were unsatisfactory, I finally started to go for my own solution few months ago. * Do you think the library should be accepted as a Boost library? No, I dont think this library should be accepted as it is. I am sorry. I apologize as well for the lengthy mail, but I hope my requirements get clearer that way. Yours, Martin Schulz. -- Dr. Martin Schulz (schulz(a)synopsys.com) Software Engineer Sigma-C Software AG / Synopsys GmbH, Thomas-Dehler-Str.9, D-81737 Munich, Germany Phone: +49 (89) 630257-79, Fax: -49 http://www.synopsys.com

5 23

[Sorting] Is there any interest in sorting algorithms for the Boost Graph Library
by Sam Schetterer 03 Apr '07

03 Apr '07

If there is interest, I will gladly write sorting algorithms specialized for the Boost Graph Library. These algorithms will include: sort by property values sort by vertex values sort by matrix values sort by adjacent vertex values sort by edge values sort by location along a path and probably more

1 0

[Boost-bugs] [ boost-Patches-1685351 ] [mpl] Detect nested template members with has_template_xxx
by SourceForge.net 03 Apr '07

03 Apr '07

Patches item #1685351, was opened at 2007-03-21 12:38 Message generated for change (Comment added) made by daniel_walker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1685351&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Walker (daniel_walker) Assigned to: Aleksey Gurtovoy (agurtovoy) >Summary: [mpl] Detect nested template members with has_template_xxx Initial Comment: This patch is for Boost.MPL. Apply with 'patch -p0 < djw_has_template.patch' from the boost root directory. See discussion at http://tinyurl.com/35x5z5. ---------------------------------------------------------------------- >Comment By: Daniel Walker (daniel_walker) Date: 2007-04-02 19:54 Message: Logged In: YES user_id=1226757 Originator: YES I uploaded a revision of the previous patch with documentation, tests, and support for multiple compilers. Apply with 'patch -p0 < djw_has_xxx_template.patch' from the boost root directory. See the discussion on the thread at http://tinyurl.com/35x5z5 for information about changes from the previous patch. File Added: djw_has_xxx_template.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1685351&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Graph] User supplied allocators with Boost.Graph?
by Ford, Rich 02 Apr '07

02 Apr '07

Hi, I'm sending this to you as the authors of the Boost Graph library. We have some applications of Boost.Graph where it would be desirable for us to be able to supply our own memory allocator that Boost.Graph would use when it needs to allocate memory for vertices, edges, or whatever. For example, we might want to allocate the graph in an arena and when we are done just deallocate the whole arena. Has there been any request from others for this? I would not think it would be too hard to add (e.g. for adjacency_list, add another template parameter for the allocator and use it whenever allocation is needed). I would be interested in hearing your feedback on this proposal. Thanks for your help. Richard L. Ford, Ph. D. Principal Member of Technical Staff Software Strategy and Solutions T 978-795-8584 F 978-795-2525

3 3

units: review
by Lewis Hyatt 02 Apr '07

02 Apr '07

-What is your evaluation of the design? It makes sense to me to have a rigid compile-time system for this, the design is simple and very intuitive. I was able to use the basic unit conversions without even reading the docs, and everything shows up just where you expect it. The library does require a lot of typing, but this is going to automatically go away once the auto keyword becomes standard. I do disagree with previous comments on the evilness of the mutating value() method. In particular, if the unit base is a user-defined type, then there is no other way for the user to access the contained object's member functions, so I don't see how you can get away without having value(). (As a reasonable example, you might want to use units with a boost::rational<int> data type, but without a mutating value(), you can't call boost::rational<int>::assign() anymore). I think this deficiency would cause people either to not use units, or to use a quantity<Q, boost::reference_wrapper<T> > instead, which is annoying and suffers from the same dangers anyway. Also, quantity<> should pass through operator++ and operator-- in addition to the other arithmetic operators. I was surprised to find that the prefixes kilo, mega, etc, are in namespace SI. They are equally useful for CGS and for user defined systems; perhaps they should be in a new namespace boost::units::prefix, since they are just static constants? Also, I was surprised that units/systems/si/prefixes.hpp was not included by units/systems/si.hpp, since I thought that was going to be a "catch-all" header. -What is your evaluation of the implementation? I didn't look in a lot of detail, enough to tell that there is good re-use of Boost metaprogramming libraries, etc, and the code seems easy to follow. It compiles in a reasonable amount of time. One thing I noticed is that the code does not use BOOST_STATIC_CONSTANT. Is this under the assumption that compilers which need BOOST_STATIC_CONSTANT won't compile the code anyway? That's probably correct I guess. I was surprised by the following behavior: #include <iostream> #include <boost/units/io.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/systems/cgs.hpp> #include <boost/units/systems/si/prefixes.hpp> using namespace boost::units; int main() { quantity<CGS::force> F0 = 20 * CGS::dyne; quantity<SI::force> F1 = quantity_cast<SI::force>(F0); quantity<SI::force> F2 = quantity_cast<SI::force>(20 * CGS::dyne); quantity<SI::force> F3(F0); //quantity<SI::force> F4 = F0; //quantity<SI::force> F5(20 * CGS::dyne); //quantity<SI::force> F6 = 20 * CGS::dyne; std::cout << F1 << '\n' << F2 << '\n' << F3 << '\n'; } Firstly, I would have expected all 6 initializations of F1-F6 to do exactly the same thing. The last three do not compile at all, though. I think it is particularly surprising that there is a difference between F3 and F4. Most users are used to these two syntaxes being absolutely identical in meaning. I haven't looked at the implementation in detail, I'm just pointing out that this is a surprising feature. Also problematic is F2, which does compile, albeit with a warning, but then does the wrong thing at run time. The output of this program is: 1e-05 m kg s^(-2) 0 m kg s^(-2) 1e-05 m kg s^(-2) This appears to be related to the fact that in the initialization of F0, there is an implicit conversion from the int (20) to double. If I change the int to a double (20.) , then the code compiles without warnings and does the right thing. Similarly, changing the int to a double allows F5 to compile, but again, the equivalent-looking F6 does not. BTW, the warning issued by gcc is: ../../../boost/units/conversion.hpp: In static member function `static boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S2> >, Y> boost::units::conversion_helper<boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S> >, Y>, boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S2> >, Y> >::convert(const boost::units::quantity<boost::units::unit<Dim1, boost::units::homogeneous_system<S> >, Y>&) [with S1 = boost::units::CGS::system_tag, S2 = boost::units::SI::system_tag, Dim1 = boost::units::force_type, Y = int]': ../../../boost/units/quantity.hpp:91: instantiated from `boost::units::quantity<Unit, Y>::quantity(const boost::units::quantity<boost::units::unit<Dim2, System2>, YY>&, typename boost::disable_if<typename boost::units::is_implicitly_convertible<boost::units::unit<Dim2, System2>, boost::units::unit<typename boost::units::get_dimension<T>::type, typename boost::units::get_system<T>::type> >::type, void>::type*) [with System2 = boost::units::CGS::system, Dim2 = boost::units::force_type, YY = int, Unit = boost::units::unit<boost::units::force_type, boost::units::SI::system>, Y = int]' ../../../boost/units/quantity.hpp:360: instantiated from `boost::units::quantity<boost::units::unit<Dim, System>, X> boost::units::quantity_cast_helper<boost::units::unit<Dim, System>, boost::units::quantity<Unit2, X> >::operator()(const boost::units::quantity<Unit2, X>&) [with X = int, System = boost::units::SI::system, Dim = boost::units::force_type, Unit2 = boost::units::unit<boost::units::force_type, boost::units::CGS::system>]' ../../../boost/units/quantity.hpp:378: instantiated from `typename boost::units::quantity_cast_helper<X, Y>::type boost::units::quantity_cast(const Y&) [with X = boost::units::SI::force, Y = boost::units::quantity<boost::units::unit<boost::units::force_type, boost::units::CGS::system>, int>]' t.cpp:14: instantiated from here ../../../boost/units/conversion.hpp:52: warning: passing `double' for converting 1 of `static boost::units::quantity<Unit, Y> boost::units::quantity<Unit, Y>::from_value(const Y&) [with Unit = boost::units::unit<boost::units::force_type, boost::units::SI::system>, Y = int]' -What is your evaluation of the documentation? The large number of examples is excellent. The documentation needs a lot more substance to it, particularly explaining surprising features of implicit conversions. -What is your evaluation of the potential usefulness of the library? I can see it being very useful. I myself am considering using it in the near future. One concern I have, is that I use a lot of C++ wrappers over legacy C libraries such as CLAPACK and ATLAS. I would still be able to use boost::units, provided I could count on sizeof(quantity<Q,T>) == sizeof(T), so that an array of quantitity<Q,T> would look the same in memory as an array of T. I doubt you would find any compiler where this is not the case, but it would be nice if the library could offer some sort of guarantee, since the standard doesn't, or at least comment on this issue in the docs. Another convenient option would be to put a static assert in the definition of quantity<> that the user could turn on via a #define if they want to be sure of this. -Did you try to use the library? With what compiler? Did you have any problems? The compile of cmath fails on gcc 3.4.4 on cygwin/MinGW and on gcc 3.4.6 on Linux because of undefined symbol __builtin_signbit in detail/cmath_gnu_impl.hpp line 195. This prohibits eg compilation of unit_example_11.cpp There are also a few source files missing terminating newlines, which produces a warning on some compilers. The library does not compile on earlier gcc versions as I mentioned in an earlier email, but this is not surprising. Other than cmath, the library compiled fine on gcc 3.4.{4,6} and 4.0.2. gcc 3.4.{4,6} was not able to optimize the runtime overhead entirely away. Without optimizations, the supplied timing example was about 10 times slower compared to the non-unit version. With optimization, it was only about 20% slower. On gcc 4.0.2, with optimization it was the same speed. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Played around with it for a couple hours, didn't put in a lot of time reading the actual implementation. -Are you knowledgeable about the problem domain? Yes, I am knowledgeable about units/dimensional analysis. - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, I think this library is a good and useful example of compile-time programming, and it should be accepted. I do have some concerns about the implicit conversions and initialization issues, but I think they probably just stem from my lack of understanding of some implementation issues, which means that improved docs would probably suffice to take care of them. I do think the one issue I mentioned above (the combination of quantity_cast and a conversion from int to double producing incorrect runtime behavior) qualifies as a bug, perhaps compiler-specific? -Lewis

12 56

Intrusive library review results: library accepted
by "JOAQUIN LOPEZ MU?Z" 02 Apr '07

02 Apr '07

I'm pleased to announce that Ion Gaztañaga's Intrusive library has been accepted into Boost. Prior to its inclusion in Boost, the author is encouraged to address several issues raised during the review, a summary of which is given below. A total of 14 full reviews were received, all of them positive. Additionally, other members did not submit full reviews but expressed their support for the library. One Boost member raised some concerns about the usefulness of the library; I hope these concerns have been satisfactorily addressed by those review participants who explained their current and potential usage scenarios for Boost.Intrusive. This has shown that more movitational material need to be provided in the documentation introduction and in the form of full-fledged examples. Thank you to Ion Gaztañaga for all the hard work involved in creating a Boost library, to Olaf Krzikalla, who wrote the first versions of this piece of work, and to all the participants in the review. The list of issues to be addressed follows. Feel free to comment if you detect some error or omission from my part. List of issues to be addressed prior to inclusion of the Intrusive library into Boost: * Documentation - Provide a motivating introduction about usefulness of Boost.Intrusive. - Add some hello world motivating examples. - Class names linked to their section in the reference (except in code due to Quickbook limitations). - Document iterator and const_iterator as part of the container interfaces. - Add overview of iterator validity rules. - Document usage before concepts. - Improve concepts part. - Provide container concepts à la STL. - Add performance section. - Add quick guide to docs. - Make the tests more comprehensive. - Add examples section. - State clearly the purpose of the lib in the introduction. - Add more examples using the different hooks. - State in docs the possibility that tags be incomplete types. - State in docs the fact that Boost.Intrusive does not support shared_ptr's. - Document the fact that member hooks rely on non-standard implementation techniques. * Naming - Change Destroyer to a more suitable name (e.g. Sink or Disposer), rename member functions accordingly. - Rename current() as iterator_to(). - Rename [s]list_algorithms as circular_[s]list_algorithms. - Drop the 'i' prefix from the names of containers. - Rename linked() as is_linked(). - Rename assign_and_destroy() as destroy_and_assign(). * Interface improvements - Study ways to simplify the usage syntax of hooks. - Add a default value to Tag. - Member hooks shouldn't be parameterized on the host class type. - Make hooks assignment operator a no-op. - bucket_size() y bucket() should be const. - Provide cbegin(), cend() etc. - Add *_fwd.hpp headers. - Fuse autolink and regular/safe hooks into one class whose second parameter is a category class. * Implementation improvements - Iterators to be implemented with iterator_facade. - Use Boost.Concept for concept checking if compilation times are not severely affected. - Extend bucket primes table to 64 bits. - Use template trick to avoid direct use std::size_t in template parms of containers, thus pulling the std namespace in via ADL. - Use Watanabe's version of swap_nodes() for ilist. - Use insert_after() in clone_from(). - Reimplement clone_from() to not delete partially constructed data on exception. - Investigate bug with member hooks and virtual inheritance. * Extensions and issues to be considered in the future - Order-statistics tree. - Study other libraries for ideas: DOL, PTL, jjLib. - Study feasibility of implementing a "destroy multihooked element when completely unlinked" mode. - Investigate use of two-way pointers with Boost.Intrusive. - Consider a shift() member function for lists and slists. - Additional slist-like container with a pointer-to-last member to make swapping constant time. The Review Manager, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Boost inspection notification (2007-04-02/RC_1_34_0) *LC*
by Rene Rivera 02 Apr '07

02 Apr '07

Boost Inspection Report Run Date: 16:07:50 UTC, Monday 02 April 2007 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11449 files scanned 908 directories scanned (including root) 1051 problems reported Problem counts: 653 files missing Boost license info or having wrong reference text 398 files missing copyright notice Summary: any (1) archive (1) build (68) concept_check (22) conversion (5) doc (1) filesystem (2) function (1) graph (1) inspect (1) integer (9) lambda (10) libs (6) logic (2) math (1) more (13) mpl (417) multi_array (13) numeric (188) optional (1) people (4) program_options (35) property_map (15) ptr_container (8) python (6) rational (5) regex (4) regression (118) release (2) serialization (16) signals (2) smart_ptr (8) test (3) timer (1) tr1 (2) tuple (5) utility (12) variant (42) Details: *L* missing Boost license info, or wrong reference text *C* missing copyright notice |any| libs/any/doc/ any.xml: *L* |archive| boost/archive/detail/ utf8_codecvt_facet.hpp: *L* |build| tools/build/v2/build/ build-request.jam: *L* modifiers.jam: *L* tools/build/v2/doc/ Jamfile.v2: *C* *L* tools/build/v2/doc/src/ advanced.xml: *C* *L* architecture.xml: *C* *L* catalog.xml: *C* *L* extending.xml: *C* *L* faq.xml: *C* *L* fragments.xml: *C* *L* howto.xml: *C* *L* install.xml: *C* *L* recipes.xml: *C* *L* reference.xml: *C* *L* standalone.xml: *C* *L* tutorial.xml: *C* *L* userman.xml: *C* *L* tools/build/v2/example/generate/ REAME.txt: *C* *L* a.cpp: *C* *L* tools/build/v2/example/generator/ README.txt: *C* *L* soap.jam: *C* *L* tools/build/v2/example/python_modules/ python_helpers.jam: *C* *L* python_helpers.py: *C* *L* tools/build/v2/test/ abs_workdir.py: *C* *L* dependency_property.py: *L* dependency_test.py: *C* *L* direct_request_test.py: *C* *L* dll_path.py: *L* double_loading.py: *L* duplicate.py: *L* echo_args.jam: *C* *L* empty.jam: *C* *L* expansion.py: *L* explicit.py: *L* gcc_runtime.py: *L* tools/build/v2/test/project-test3/lib3/ Jamfile: *C* *L* tools/build/v2/test/ readme.txt: *C* *L* svn_tree.py: *L* tag.py: *L* test_system.html: *L* tools/build/v2/tools/ sun.jam: *L* xsltproc.jam: *L* |concept_check| libs/concept_check/ bibliography.htm: *L* concept_check.htm: *L* concept_covering.htm: *L* creating_concepts.htm: *L* libs/concept_check/doc/ Jamfile.v2: *C* *L* libs/concept_check/doc/reference/ Assignable.xml: *L* BidirectionalIterator.xml: *L* CopyConstructible.xml: *L* DefaultConstructible.xml: *L* EqualityComparable.xml: *L* ForwardIterator.xml: *L* InputIterator.xml: *L* LessThanComparable.xml: *L* OutputIterator.xml: *L* RandomAccessIterator.xml: *L* SignedInteger.xml: *L* concepts.xml: *L* libs/concept_check/ implementation.htm: *L* prog_with_concepts.htm: *L* reference.htm: *L* using_concept_check.htm: *L* |conversion| libs/conversion/ cast.htm: *L* index.html: *C* *L* lexical_cast.htm: *L* libs/conversion/test/ Jamfile.v2: *L* |doc| doc/html/ docutils.css: *L* |filesystem| libs/filesystem/doc/ tr2_proposal.html: *L* libs/filesystem/src/ utf8_codecvt_facet.hpp: *L* |function| boost/function/detail/ gen_maybe_include.pl: *L* |graph| libs/graph/doc/ lengauer_tarjan_dominator.htm: *L* |inspect| tools/inspect/build/ Jamfile.v2: *L* |integer| libs/integer/ cstdint.htm: *C* *L* libs/integer/doc/ integer_mask.html: *L* static_min_max.html: *L* libs/integer/ index.html: *C* *L* integer.htm: *L* integer_traits.html: *C* *L* |lambda| libs/lambda/doc/ Jamfile.v2: *C* *L* libs/lambda/doc/detail/ README: *C* *L* lambda_doc.xsl: *C* *L* lambda_doc_chunks.xsl: *C* *L* libs/lambda/test/ Makefile: *C* *L* |libs| libs/ expected_results.xml: *C* *L* maintainers.txt: *C* *L* platform_maintainers.txt: *C* *L* |logic| libs/logic/doc/ Jamfile.v2: *C* *L* |math| boost/math/ common_factor_rt.hpp: *L* |more| more/ error_handling.html: *L* generic_exception_safety.html: *C* *L* generic_programming.html: *L* getting_started.rst: *C* *L* moderators.html: *C* regression.html: *C* *L* report-apr-2006.html: *C* *L* report-jan-2006.html: *C* *L* |mpl| libs/mpl/doc/src/refmanual/ ASSERT.rst: *C* *L* ASSERT_MSG.rst: *C* *L* ASSERT_NOT.rst: *C* *L* ASSERT_RELATION.rst: *C* *L* AUX_LAMBDA_SUPPORT.rst: *C* *L* Acknowledgements.rst: *C* *L* Algorithms-Iteration.rst: *C* *L* Algorithms-Querying.rst: *C* *L* Algorithms-Runtime.rst: *C* *L* Algorithms-Transformation.rst: *C* *L* Algorithms.rst: *C* *L* AssociativeSequence.rst: *C* *L* BackExtensibleSequence.rst: *C* *L* BidirectionalIterator.rst: *C* *L* BidirectionalSequence.rst: *C* *L* CFG_NO_HAS_XXX.rst: *C* *L* CFG_NO_PREPROCESSED.rst: *C* *L* Categorized.rst: *C* *L* Data.rst: *C* *L* ExtensibleAssociativeSeq.rst: *C* *L* ExtensibleSequence.rst: *C* *L* ForwardIterator.rst: *C* *L* ForwardSequence.rst: *C* *L* FrontExtensibleSequence.rst: *C* *L* HAS_XXX_TRAIT_DEF.rst: *C* *L* HAS_XXX_TRAIT_NAMED_DEF.rst: *C* *L* Inserter.rst: *C* *L* IntegralConstant.rst: *C* *L* IntegralSequenceWrapper.rst: *C* *L* Iterators-Concepts.rst: *C* *L* Iterators-Metafunctions.rst: *C* *L* Iterators.rst: *C* *L* LIMIT_LIST_SIZE.rst: *C* *L* LIMIT_MAP_SIZE.rst: *C* *L* LIMIT_METAFUNCTION_ARITY.rst: *C* *L* LIMIT_SET_SIZE.rst: *C* *L* LIMIT_UNROLLING.rst: *C* *L* LIMIT_VECTOR_SIZE.rst: *C* *L* LambdaExpression.rst: *C* *L* Macros-Asserts.rst: *C* *L* Macros-Configuration.rst: *C* *L* Macros.rst: *C* *L* Metafunction.rst: *C* *L* MetafunctionClass.rst: *C* *L* Metafunctions-Arithmetic.rst: *C* *L* Metafunctions-Bitwise.rst: *C* *L* Metafunctions-Comparisons.rst: *C* *L* Metafunctions-Composition.rst: *C* *L* Metafunctions-Conditional.rst: *C* *L* Metafunctions-Invocation.rst: *C* *L* Metafunctions-Logical.rst: *C* *L* Metafunctions-Trivial.rst: *C* *L* Metafunctions-Type.rst: *C* *L* Metafunctions.rst: *C* *L* NumericMetafunction.rst: *C* *L* PlaceholderExpression.rst: *C* *L* Placeholders.rst: *C* *L* RandomAccessIterator.rst: *C* *L* RandomAccessSequence.rst: *C* *L* ReversibleAlgorithm.rst: *C* *L* Sequences-Classes.rst: *C* *L* Sequences-Concepts.rst: *C* *L* Sequences-Intrinsic.rst: *C* *L* Sequences-Views.rst: *C* *L* Sequences.rst: *C* *L* TagDispatchedMetafunction.rst: *C* *L* TrivialMetafunction.rst: *C* *L* VariadicSequence.rst: *C* *L* accumulate.rst: *C* *L* advance.rst: *C* *L* always.rst: *C* *L* and_.rst: *C* *L* apply.rst: *C* *L* apply_wrap.rst: *C* *L* arg.rst: *C* *L* at.rst: *C* *L* at_c.rst: *C* *L* back.rst: *C* *L* back_inserter.rst: *C* *L* begin.rst: *C* *L* bind.rst: *C* *L* bitand_.rst: *C* *L* bitor_.rst: *C* *L* bitxor_.rst: *C* *L* bool_.rst: *C* *L* clear.rst: *C* *L* contains.rst: *C* *L* copy.rst: *C* *L* copy_if.rst: *C* *L* count.rst: *C* *L* count_if.rst: *C* *L* deque.rst: *C* *L* deref.rst: *C* *L* distance.rst: *C* *L* divides.rst: *C* *L* empty.rst: *C* *L* empty_base.rst: *C* *L* empty_sequence.rst: *C* *L* end.rst: *C* *L* equal.rst: *C* *L* equal_to.rst: *C* *L* erase.rst: *C* *L* erase_key.rst: *C* *L* eval_if.rst: *C* *L* eval_if_c.rst: *C* *L* filter_view.rst: *C* *L* find.rst: *C* *L* find_if.rst: *C* *L* fold.rst: *C* *L* for_each.rst: *C* *L* front.rst: *C* *L* front_inserter.rst: *C* *L* greater.rst: *C* *L* greater_equal.rst: *C* *L* has_key.rst: *C* *L* identity.rst: *C* *L* if_.rst: *C* *L* if_c.rst: *C* *L* inherit.rst: *C* *L* inherit_linearly.rst: *C* *L* insert.rst: *C* *L* insert_range.rst: *C* *L* inserter_.rst: *C* *L* int_.rst: *C* *L* integral_c.rst: *C* *L* is_sequence.rst: *C* *L* iter_fold.rst: *C* *L* iter_fold_if.rst: *C* *L* iterator_category.rst: *C* *L* iterator_range.rst: *C* *L* joint_view.rst: *C* *L* key_type.rst: *C* *L* lambda.rst: *C* *L* less.rst: *C* *L* less_equal.rst: *C* *L* list.rst: *C* *L* list_c.rst: *C* *L* long_.rst: *C* *L* lower_bound.rst: *C* *L* map.rst: *C* *L* max.rst: *C* *L* max_element.rst: *C* *L* min.rst: *C* *L* min_element.rst: *C* *L* minus.rst: *C* *L* modulus.rst: *C* *L* multiplies.rst: *C* *L* negate.rst: *C* *L* next.rst: *C* *L* not_.rst: *C* *L* not_equal_to.rst: *C* *L* numeric_cast.rst: *C* *L* or_.rst: *C* *L* order.rst: *C* *L* pair.rst: *C* *L* partition.rst: *C* *L* plus.rst: *C* *L* pop_back.rst: *C* *L* pop_front.rst: *C* *L* preface.rst: *C* *L* prior.rst: *C* *L* protect.rst: *C* *L* push_back.rst: *C* *L* push_front.rst: *C* *L* quote.rst: *C* *L* range_c.rst: *C* *L* remove.rst: *C* *L* remove_if.rst: *C* *L* replace.rst: *C* *L* replace_if.rst: *C* *L* reverse.rst: *C* *L* reverse_copy.rst: *C* *L* reverse_copy_if.rst: *C* *L* reverse_fold.rst: *C* *L* reverse_iter_fold.rst: *C* *L* reverse_partition.rst: *C* *L* reverse_remove.rst: *C* *L* reverse_remove_if.rst: *C* *L* reverse_replace.rst: *C* *L* reverse_replace_if.rst: *C* *L* reverse_stable_partition.rst: *C* *L* reverse_transform.rst: *C* *L* reverse_unique.rst: *C* *L* sequence_tag.rst: *C* *L* set.rst: *C* *L* set_c.rst: *C* *L* shift_left.rst: *C* *L* shift_right.rst: *C* *L* single_view.rst: *C* *L* size.rst: *C* *L* size_t.rst: *C* *L* sizeof_.rst: *C* *L* sort.rst: *C* *L* stable_partition.rst: *C* *L* terminology.rst: *C* *L* times.rst: *C* *L* transform.rst: *C* *L* transform_view.rst: *C* *L* unique.rst: *C* *L* unpack_args.rst: *C* *L* upper_bound.rst: *C* *L* value_type.rst: *C* *L* vector.rst: *C* *L* vector_c.rst: *C* *L* void_.rst: *C* *L* zip_view.rst: *C* *L* libs/mpl/doc/ style.css: *L* libs/mpl/example/fsm/ README.txt: *C* *L* libs/mpl/test/ Jamfile.v2: *C* *L* |multi_array| libs/multi_array/doc/ iterator_categories.html: *C* *L* reference.html: *L* libs/multi_array/doc/xml/ MultiArray.xml: *C* *L* const_multi_array_ref.xml: *C* *L* multi_array.xml: *C* *L* multi_array_ref.xml: *C* *L* reference.xml: *L* libs/multi_array/test/ Jamfile.v2: *L* |numeric| boost/numeric/ublas/ banded.hpp: *L* blas.hpp: *L* boost/numeric/ublas/detail/ concepts.hpp: *L* config.hpp: *L* definitions.hpp: *L* documentation.hpp: *L* duff.hpp: *L* iterator.hpp: *L* matrix_assign.hpp: *L* raw.hpp: *L* temporary.hpp: *L* vector_assign.hpp: *L* boost/numeric/ublas/ exception.hpp: *L* expression_types.hpp: *L* functional.hpp: *L* fwd.hpp: *L* hermitian.hpp: *L* io.hpp: *L* lu.hpp: *L* matrix.hpp: *L* matrix_expression.hpp: *L* matrix_proxy.hpp: *L* matrix_sparse.hpp: *L* operation.hpp: *L* operation_blocked.hpp: *L* operation_sparse.hpp: *L* storage.hpp: *L* storage_sparse.hpp: *L* symmetric.hpp: *L* traits.hpp: *L* triangular.hpp: *L* vector.hpp: *L* vector_expression.hpp: *L* vector_of_vector.hpp: *L* vector_proxy.hpp: *L* vector_sparse.hpp: *L* libs/numeric/conversion/test/ Jamfile.v2: *C* *L* test_helpers.cpp: *C* test_helpers2.cpp: *C* test_helpers3.cpp: *C* traits_test.cpp: *C* udt_example_0.cpp: *C* udt_support_test.cpp: *C* libs/numeric/ublas/bench1/ bench1.cpp: *L* bench1.hpp: *L* bench11.cpp: *L* bench12.cpp: *L* bench13.cpp: *L* libs/numeric/ublas/bench2/ bench2.cpp: *L* bench2.hpp: *L* bench21.cpp: *L* bench22.cpp: *L* bench23.cpp: *L* libs/numeric/ublas/bench3/ bench3.cpp: *L* bench3.hpp: *L* bench31.cpp: *L* bench32.cpp: *L* bench33.cpp: *L* libs/numeric/ublas/bench4/ bench4.cpp: *L* bench41.cpp: *L* bench42.cpp: *L* bench43.cpp: *L* libs/numeric/ublas/doc/ Release_notes.txt: *C* *L* array_adaptor.htm: *C* *L* banded.htm: *L* blas.htm: *L* bounded_array.htm: *C* *L* container_concept.htm: *L* doxygen.css: *C* *L* expression_concept.htm: *L* hermitian.htm: *L* index.htm: *L* iterator_concept.htm: *L* matrix.htm: *L* matrix_expression.htm: *L* matrix_proxy.htm: *L* matrix_sparse.htm: *L* operations_overview.htm: *L* overview.htm: *L* products.htm: *L* range.htm: *C* *L* libs/numeric/ublas/doc/samples/ banded_adaptor.cpp: *L* banded_matrix.cpp: *L* bounded_array.cpp: *L* compressed_matrix.cpp: *L* compressed_vector.cpp: *L* coordinate_matrix.cpp: *L* coordinate_vector.cpp: *L* hermitian_adaptor.cpp: *L* hermitian_matrix.cpp: *L* identity_matrix.cpp: *L* map_array.cpp: *L* mapped_matrix.cpp: *L* mapped_vector.cpp: *L* matrix.cpp: *L* matrix_binary.cpp: *L* matrix_binary_scalar.cpp: *L* matrix_column.cpp: *L* matrix_column_project.cpp: *L* matrix_matrix_binary.cpp: *L* matrix_matrix_solve.cpp: *L* matrix_range.cpp: *L* matrix_range_project.cpp: *L* matrix_row.cpp: *L* matrix_row_project.cpp: *L* matrix_slice.cpp: *L* matrix_slice_project.cpp: *L* matrix_unary.cpp: *L* matrix_vector_binary.cpp: *L* matrix_vector_range.cpp: *L* matrix_vector_slice.cpp: *L* matrix_vector_solve.cpp: *L* range.cpp: *L* slice.cpp: *L* symmetric_adaptor.cpp: *L* symmetric_matrix.cpp: *L* triangular_adaptor.cpp: *L* triangular_matrix.cpp: *L* unbounded_array.cpp: *L* unit_vector.cpp: *L* vector.cpp: *L* vector_binary.cpp: *L* vector_binary_outer.cpp: *L* vector_binary_redux.cpp: *L* vector_binary_scalar.cpp: *L* vector_range.cpp: *L* vector_range_project.cpp: *L* vector_slice.cpp: *L* vector_slice_project.cpp: *L* vector_unary.cpp: *L* vector_unary_redux.cpp: *L* zero_matrix.cpp: *L* zero_vector.cpp: *L* libs/numeric/ublas/doc/ storage_concept.htm: *C* *L* storage_sparse.htm: *L* symmetric.htm: *L* triangular.htm: *L* types_overview.htm: *L* ublas.css: *C* *L* unbounded_array.htm: *C* *L* vector.htm: *L* vector_expression.htm: *L* vector_proxy.htm: *L* vector_sparse.htm: *L* libs/numeric/ublas/test/ README: *C* *L* concepts.cpp: *L* test1.cpp: *L* test1.hpp: *L* test11.cpp: *L* test12.cpp: *L* test13.cpp: *L* test2.cpp: *L* test2.hpp: *L* test21.cpp: *L* test22.cpp: *L* test23.cpp: *L* test3.cpp: *L* test3.hpp: *L* test31.cpp: *L* test32.cpp: *L* test33.cpp: *L* test4.cpp: *L* test4.hpp: *L* test42.cpp: *L* test43.cpp: *L* test5.cpp: *L* test5.hpp: *L* test52.cpp: *L* test53.cpp: *L* test6.cpp: *L* test6.hpp: *L* test62.cpp: *L* test63.cpp: *L* test7.cpp: *L* test7.hpp: *L* test71.cpp: *L* test72.cpp: *L* test73.cpp: *L* |optional| libs/optional/test/ Jamfile.v2: *L* |people| people/ paul_moore.htm: *C* *L* vesa_karvonen.htm: *C* *L* |program_options| boost/program_options/detail/ utf8_codecvt_facet.hpp: *L* libs/program_options/build/ Jamfile.v2: *C* *L* libs/program_options/doc/ Jamfile.v2: *C* *L* acknowledgements.xml: *C* *L* changes.xml: *C* *L* design.xml: *C* *L* glossary.xml: *C* *L* howto.xml: *C* *L* overview.xml: *C* *L* post_review_plan.txt: *C* *L* todo.txt: *C* *L* tutorial.xml: *C* *L* libs/program_options/example/ Jamfile.v2: *C* *L* libs/program_options/test/ Jamfile.v2: *C* *L* program_options_size_test.py: *C* *L* ucs2.txt: *C* *L* utf8.txt: *C* *L* winmain.py: *C* *L* |property_map| libs/property_map/ LvaluePropertyMap.html: *L* ReadWritePropertyMap.html: *L* ReadablePropertyMap.html: *L* WritablePropertyMap.html: *L* associative_property_map.html: *L* const_assoc_property_map.html: *L* libs/property_map/doc/ dynamic_property_map.html: *C* *L* dynamic_property_map.rst: *C* *L* libs/property_map/ example2.cpp: *L* identity_property_map.html: *L* iterator_property_map.html: *L* property_map.html: *L* vector_property_map.html: *L* |ptr_container| libs/ptr_container/doc/ default.css: *L* intro.xml: *C* *L* ptr_container.xml: *L* libs/ptr_container/test/ Jamfile.v2: *C* *L* sequence_point.cpp: *C* *L* |python| libs/python/doc/ internals.html: *L* internals.rst: *L* libs/python/test/ operators_wrapper.cpp: *C* *L* operators_wrapper.py: *C* *L* |rational| boost/ rational.hpp: *L* libs/rational/ index.html: *L* rational.html: *L* rational_example.cpp: *L* rational_test.cpp: *L* |regex| libs/regex/build/ gcc-shared.mak: *C* *L* libs/regex/example/timer/ input_script.txt: *C* *L* |regression| tools/regression/build/ Jamfile.v2: *C* *L* tools/regression/detail/ tiny_xml_test.txt: *C* *L* tools/regression/ index.htm: *C* *L* run_tests.sh: *C* *L* tools/regression/test/test-cases/general/expected/ results.xml: *C* *L* tools/regression/test/test-cases/incremental/expected/ results.xml: *C* *L* tools/regression/test/ test.bat: *C* *L* tools/regression/xsl_reports/ boostbook_report.py: *C* *L* tools/regression/xsl_reports/db/ load.py: *C* *L* test-runs.xsd: *C* *L* tools/regression/xsl_reports/ empty_expected_results.xml: *C* *L* tools/regression/xsl_reports/runner/ __init__.py: *C* *L* default.css: *L* instructions.html: *L* instructions.rst: *C* *L* tools/regression/xsl_reports/test/ common.py: *C* *L* expected_results.xml: *C* *L* generate_test_results.py: *C* *L* generate_test_results_v1.py: *C* *L* restrict_to_library.xsl: *C* *L* run_notes_regression.py: *C* *L* run_v1.py: *C* *L* tools/regression/xsl_reports/test/test-components/ test.py: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/ compile-fail.xml: *C* *L* completed.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/ compile-fail.xml: *C* *L* completed.xml: *C* *L* lib.xml: *C* *L* misfire.xml: *C* *L* no-run.xml: *C* *L* run_pyd.xml: *C* *L* test-case.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/ lib.xml: *L* misfire.xml: *C* *L* no-run.xml: *C* *L* run_pyd.xml: *C* *L* test-case.xml: *L* test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/test-components/test_re_match/expected/ test_re_match.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/expected/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/ test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/expected/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/ test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/ test.py: *C* *L* test_boost_wide_report.py: *C* *L* tools/regression/xsl_reports/ test_results.xsd: *C* *L* tools/regression/xsl_reports/utils/ __init__.py: *C* *L* accept_args.py: *C* *L* char_translation_table.py: *C* *L* check_existance.py: *C* *L* checked_system.py: *C* *L* libxslt.py: *C* *L* log.py: *C* *L* makedirs.py: *C* *L* send_mail.py: *C* *L* sourceforge.py: *C* *L* tar.py: *C* *L* zip.py: *C* *L* tools/regression/xsl_reports/xsl/v2/ expected_to_1_33_format.xsl: *C* *L* |release| tools/release/ utils.py: *C* *L* |serialization| libs/serialization/doc/ style.css: *C* *L* libs/serialization/example/ demo_output.txt: *C* *L* demo_save.xml: *C* *L* demofile.txt: *C* *L* libs/serialization/test/ run_archive_test.bat: *C* *L* runtest.bat: *C* *L* runtest.sh: *C* *L* libs/serialization/vc7ide/ readme.txt: *C* *L* |signals| libs/signals/doc/ tutorial.xml: *C* *L* |smart_ptr| libs/smart_ptr/ compatibility.htm: *L* scoped_array.htm: *L* scoped_ptr.htm: *L* shared_array.htm: *L* shared_ptr.htm: *L* smart_ptr.htm: *L* smarttests.htm: *L* weak_ptr.htm: *L* |test| boost/test/utils/runtime/cla/detail/ argument_value_usage.hpp: *L* libs/test/test/auto-link-test/ run_bjam.bat: *C* *L* |timer| libs/timer/ timer.htm: *L* |tr1| boost/tr1/ tuple.hpp: *C* *L* |tuple| libs/tuple/doc/ design_decisions_rationale.html: *L* tuple_advanced_interface.html: *L* tuple_users_guide.html: *L* libs/tuple/test/ README: *C* *L* |utility| boost/ shared_container_iterator.hpp: *L* libs/utility/ OptionalPointee.html: *L* call_traits.htm: *L* compressed_pair.htm: *L* enable_if.html: *L* libs/utility/test/ Jamfile.v2: *L* libs/utility/ utility.htm: *L* value_init.htm: *L* value_init_test.cpp: *C* value_init_test_fail1.cpp: *C* value_init_test_fail2.cpp: *C* value_init_test_fail3.cpp: *C* |variant| libs/variant/doc/ Jamfile.v2: *C* *L* biblio.xml: *C* *L* design.xml: *C* *L* introduction.xml: *C* *L* misc.xml: *C* *L* libs/variant/doc/reference/ apply_visitor.xml: *C* *L* bad_visit.xml: *C* *L* concepts.xml: *C* *L* get.xml: *C* *L* recursive_variant.xml: *C* *L* recursive_wrapper.xml: *C* *L* reference.xml: *C* *L* static_visitor.xml: *C* *L* variant.xml: *C* *L* variant_fwd.xml: *C* *L* visitor_ptr.xml: *C* *L* libs/variant/doc/tutorial/ advanced.xml: *C* *L* basic.xml: *C* *L* tutorial.xml: *C* *L* libs/variant/doc/ variant.xml: *L* libs/variant/ index.html: *C* *L* libs/variant/test/ Jamfile.v2: *L*

1 0