- Boost - lists.boost.org

A few more filesystem documentation corrections
by Edward Diener 06 Dec '04

06 Dec '04

Here are a few more grammatical corrections to the excellent filesystem documentation. Default Name Check mechanism Dangers second sentence: "Since global variables are considered harmful [Wulf-Shaw-73], class path allows the default name check function can be set only once, and only before the first use." should be: "Since global variables are considered harmful [Wulf-Shaw-73], class path allows that the default name check function can be set only once, and only before the first use." or "Since global variables are considered harmful [Wulf-Shaw-73], class path allows the default name check function to be set only once, and only before the first use." Rationale Const vs non-const returns last sentence: "A requirement that path::iterator not be a non-class type was added to eliminate errors non-const iterator errors." should be: "A requirement that path::iterator not be a non-class type was added to eliminate non-const iterator errors." or better: "A requirement that path::iterator be a class type was added to eliminate non-const iterator errors." Finally, in operations.hpp, links on "class directory_iterator" and "other functions" to their explanations further down the page do not work using IE, Netscape, or Opera, so I imagine some HTML error.

2 1

Filesystem documentation error
by Edward Diener 06 Dec '04

06 Dec '04

The documentation to filesystem is outstanding. Congratulation Mr. Dawes ! I did find an error, however. In the class documentation to path.hpp there are two default_name_check member functions. In the specific documentation for default_name_check, there is only a single default_name_check mentioned and the return value in the declaration of the specific documentation has 'void' even while the "Returns:" says otherwise and correctly matches the return value given for either one of the default_name_checks given in the class documentation.

2 1

BOOST_FOREACH questions
by Vladimir Prus 05 Dec '04

05 Dec '04

Eric, I've some questions about BOOST_FOREACH (which is pretty cool, BTW). 1. Is it possible to use typeof on gcc, to avoid any possible overhead? While you've posted some results which show that gcc generally can optimise it very well, I'd like to be 100% sure). Something like: #define FOR_EACH(var, container) \ for(typeof(container.begin()) _for_each_i = container.begin(),\ _for_each_e = container.end();\ _for_each_i != _for_each_e; ++_for_each_i)\ if(bool _for_each_continue = false) {}\ else\ for(var = *_for_each_i; !_for_each_continue; _for_each_continue=true) which works perfectly for me. 2. Any chance that BOOST_FOREACH((pair<int, int> p), container) will work? I don't know how to make it work without require paranthethis in all cases, but maybe there's a smart trick. 3. Is it possible that you place this to sandbox, for easier access? - Volodya

7 31

[Boost-bugs] [ boost-Bugs-1079444 ] type_traits headers use #include ""
by SourceForge.net 05 Dec '04

05 Dec '04

Bugs item #1079444, was opened at 2004-12-05 08:59 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=1079444&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: type_traits headers use #include "" Initial Comment: The various type_traits headers (as of boost 1.32.0) use #include "" directives while the rest of boost headers uses #include <>. For example the use of #include "" in boost/type_traits/ add_reference.hpp compared to the use of #include <> in boost/ mpl/bool.hpp . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1079444&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Deserialization issue
by Jared McIntyre 05 Dec '04

05 Dec '04

I have a class that I am serializing using the non-intrusive method. It serializes just fine, but when I code the input stream, the compiler complains that the class doesn't implement the serialize function (which is, of course, true since I'm am doing the non-intrusive method on this class). Any idea what could be going wrong? The class I'm wrapping is being serialized as part of another class (if that helps at all). Visual Studio 7.1 Boost 1.32.0 tar ball Wide character XML output Jared McIntyre

2 7

Front page redesign...
by Rene Rivera 05 Dec '04

05 Dec '04

Fellow Boosters, Well I must say I've been smiling all day :-) Thanks for the encouraging feedback. And I've been putting finishing touches on my design hopefully coming up with something everyone can enjoy. I have two different sample for you to gander at. The first is the simple clean version... http://redshift-software.com/~grafik/boost/index.htm The second adds some background flair to the page... http://redshift-software.com/~grafik/boost/index_code.htm And for those with CSS switching browser, there's an alternate CSS on each of those which displays the page without any CSS. Just to show that everything is done in thee CSS ;-) Enjoy. Have a good weekend, and all that. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

17 64

[1.32] SunPRO build failures
by Caleb Epstein 04 Dec '04

04 Dec '04

% CC -V CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-20 2004/03/19 Sorry, I should have been testing this toolset earlier in the release process, but now that the official 1.32.0 is out and I've tried building it with the crufty old Sun CC, I've encountered a handful of errors and perhaps two valid warnings. The first is in date_time. It appears that Rogue Wave's std::locale::facet has an undocumented abstract virtual method __get_id. Attached is a patch which adds this method when building with SUNPRO_CC and RWSTD. This may be better done with some BOOST_* config macros, I'm not sure. There are several other errors in filesystem, program_options, serialization, and signals which manifest themselves as errors resolving overloads of iterator_traits. I'm attaching the output from my build as I'm unsure how to address these issues. Also, in archive/impl/basic_xml_grammar.hpp, the compiler warns that the StringType typedef is not accessible from the public interface of basic_xml_grammar (e.g. in the return_values struct). Making this one typedef public fixes this issue. Finally, the compiler warns about the "static" being anachronistic in boost_1_32_0/boost/smart_cast.hpp, lines 264 and 292 (the free functions smart_cast and smart_cast_reference). I think the compiler may actually be correct - what purpose does "static" serve here? I know this is a crufty toolset, but this code (at least date_time and filesystem) used to build with 1.31.0. -- Caleb Epstein caleb dot epstein at gmail dot com

8 28

"Expect" exactness from your input
by Daryle Walker 04 Dec '04

04 Dec '04

I added a file "iomanip_expect.hpp" to the Sandbox CVS. It provides manipulators to read an exact string from an input stream. This gives functionality from std::scanf that C++ I/O never had. Changed files "iomanip.hpp", "iomanip.html", and "iomanip_test.cpp" give additional tips. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Questions re Jamfile for testing
by Robert Ramey 04 Dec '04

04 Dec '04

I've been making adjustments to the serialization library to permit it to be used as a DLL and I have a couple of questions. As an example, I looked at the Jamfile for testing the filesystem. It contains: test-suite "filesystem" : [ run libs/filesystem/test/path_test.cpp <lib>../../../libs/filesystem/build/boost_filesystem : : : <define>BOOST_ALL_NO_LIB=1 ] ... a) I presume the BOOST_ALL_NO_LIB is to suppress autolinking name generation of the libraries. Is this correct? b) the requirements included <lib> ... but not <dll>. Does this test Jamfile EVER test the dll version of the filesystem library? Now suppose the test is built with runtime-link/dll . I believe that would indicate that the msvc dll version of the C++ libraries will be used and the compiler will compile code accordingly. On the other hand the <lib> above suggests that this test should be built with static linking. This raises a couple of questions: a) b) would it not make more sense for the filesystem test use the dll version of the library when the dll version of the c++ library is being used? By the same token I would expect that if the static version of the c++ library is being used, then the static version of the filesystem library would be used. Of course this isn't a requirement, but just a presumption that the most likely scenario is that a user that wants to use C++ libraries in dll from would likely want the same for other libraries. c) ideally, if we had nothing but time I would like to be able to test all combinations debug/release <runtime-link>static/dynamic, <filesystem library>static/dynamic. What would be the most convenient way to do this. Robert Ramey

3 6

Intel toolset / library names
by Stefan Slapeta 04 Dec '04

04 Dec '04

I've just found out that there is still something wrong with the intel configurations (also in 1.32). The libraries (I build them using bjam stage) have the name "....iw81...lib" but the names referred to by auto link are "...iw...lib". One has to rename them manually. I got the feeling that the Intel toolsets should undergo a substantial review anyway; I hope I've enough time to do that one day (any other volunteers?? :) ) Stefan

4 11