- Boost - lists.boost.org

howto make test2 not run unless test1 succeeds
by Larry Evans 06 Sep '04

06 Sep '04

The following is my Jamfile.v2: <----------- project dependent_test ; run test1.cpp : #args : #input-files : #requirements : test1_test #target-name : #default-build ; run test1_test test2.cpp : : : : test2_test : ; >----------- What I want is for test2_test to run only if test1_test passes. I know the above rule invocations look suspicious because the target is normally the 1st token after the rule name; however, the run rule (in testing.jam) is: rule run ( sources + : args * : input-files * : requirements * : target-name ? : default-build * ) So, I thought putting test1_test in the 2nd run (for target test2_test ) would cause test1_test to always be run first, and only if that passed, then would test2_test be tried. However, this is not what happened. test2_test was ALWAYS run. What should I do to make test2_test's run only after test1_test successfully ran?

1 1

RE: [boost] Is there any interest in a simple template for streamingin/out primitives and STL Containers of them?
by Reece Dunn 06 Sep '04

06 Sep '04

Boris Kats wrote: >I am using it for some time and hope that other will >benefite from it. >One file streamline.h will help user to stream out/in >an arbitrary item of primitives or STL containers of >them. >It is very simple to use; just type like this: > >#include "streamline.h" >using namespace hekate; >....... >typedef std::pair<std::string, std::vector<int> > >element; >element one,other; >And stream it out as: streamline(cout,one); >or stream it in as: streamline(cin,other); . > >User will find a lot of examples in the streamtest.cpp >file >at streamline.tar in "Files section". >The streaming templates were tested with gcc version >3.3.2, msvc7 and >ibm89 c++ compiler. >Boris Kats. Hi Boris, As Jonathan has pointed out, my library is aimed at solving this type of problem. Your example would become: #include <sstream> #include <boost/outfmt/stl/vector.hpp> #include <boost/outfmt/stl/pair.hpp> int main() { typedef std::pair< std::string, std::vector< int > > element; element one, other; one.first = "Meine \"Grosse\" Welt!"; one.second.push_back( 3 ); one.second.push_back( 6 ); one.second.push_back( 9 ); std::stringstream ss; ss << one; std::cout << "written: " << ss.str() << '\n'; ss >> other; std::cout << "read: " << other << '\n'; return( 0 ); } Providing a much simpler syntax and stream integration. The output for this is: written: ( "Meine \"Grosse\" Welt!", [ 3, 6, 9 ] ) read: ( "Meine \"Grosse\" Welt!", [ 3, 6, 9 ] ) It is possible to control how the pair and vector types are rendered using a custom formatter. Refer to the examples and documentation for more information. Regards, Reece _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

2 1

outfmt formal review - postponed
by John Torjo 06 Sep '04

06 Sep '04

Dear boosters, Due to the feedback I've received, I chose to postpone the formal review of Output Formatters library until 12th of Sept. Best, John -- John Torjo Freelancer -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)

1 0

New design proposal for boost::filesystem
by Martin 06 Sep '04

06 Sep '04

Just a thought on the filesystem implementation. Why not separate the path from the filesystem? Let the path be a container for all kind of paths that follow the generic syntax explained in the boost::filesystem documentation. Then use implementation classes that handles root name and conversion to native strings etc. The benefits would be: 1. The path can be used for other things than filesystems (XPath, Win32 registry) 2. Operations can be implemented selectivly for different types (No need for the current messy #ifdefs) bool exists( const path_base<posixfs<std::string> >& aPath); bool exists( const path_base<win32fs<std::wstring> >& aPath); bool exists( const path_base<win32reg<boost::fixed_string<100> > >& aPath); 3. Easy to expand the functionality for specific tasks without touching the boost headers. The implementation could look something like: template <class ImplT> class path_base : private ImplT { public: typedef ImplT::string_type string_type; path_base() : ImplT() {} // all path operations as in current implementation ... private: string_type m_path; }; // // implementation for win32 filesystem // template <class StringT> class win32fs { // root-name ::= root-drive | root-share | root-device // root-drive ::= char ":" // root-share ::= "//" name // root-device ::= name ":" protected: typedef StringT string_type; win32fs() { } string_type make_generic(const string_type::value_type* src); string_type native_file_string(const string_type& m_path) const { return algorithm::replace_all_copy(m_root + m_path, "/", "\\"); } ... private: string_type m_root }; // // implementation of posix filesystem // template <class StringT> class posixfs { win32fs() { } string_type make_generic(const string_type::value_type* src); string_type native_file_string(const string_type& m_path) const { return m_path; } ... } #ifdef BOOST_POSIX typedef path_base<posixfs<std::string>> path; #else ...

5 8

[serialization] request: low-level info about order of serialization
by Joaquín Mª López Muñoz 06 Sep '04

06 Sep '04

I'm slowly designing the addition of serialization support to Boost.MultiIndex, and come up with a need that, AFAIK, the current serialization library does not cover: The serialization of a multi_index_container should ensure that the order in which elements appear is preserved for all indices of the container. This implies serializing the elements and then recording the appropriate rearrangements in each index. I'm writing the code for serializing these rearrangements in an efficient manner as some sort of "diff" sequences, using an algorithm called "longest increasing subsequence" (LIS). The algorithm would greatly benefit for some low-level API by the serialization lib that, given an object reference, would return the order in which that object was serialized. I guess this information is already available internally, as the lib must keep track of previously saved objects. If this requirement is deemed too exotic to provide to the general user, well, I can write something myself without aid from the lib, but I thought I should ask at least :) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[request] Sun and IBM users...
by Paul Mensonides 06 Sep '04

06 Sep '04

Can someone test the following preprocessor code on the Sun and IBM preprocessors: #include <boost/preprocessor/detail/split.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #include <boost/preprocessor/punctuation/paren.hpp> #include <boost/preprocessor/tuple/eat.hpp> #define IS_NULLARY(x) \ BOOST_PP_SPLIT(1, IS_NULLARY_C x BOOST_PP_COMMA() 0) \ /**/ #define IS_NULLARY_C() \ ~, 1 BOOST_PP_RPAREN() \ BOOST_PP_TUPLE_EAT(2) BOOST_PP_LPAREN() ~ \ /**/ IS_NULLARY(()) // 1 IS_NULLARY(()abc) // 1 IS_NULLARY(+) // 0 IS_NULLARY(xyz) // 0 #define IS_UNARY(x) IS_NULLARY(IS_UNARY_C x) #define IS_UNARY_C(a) () IS_UNARY((a)) // 1 IS_UNARY((a)abc) // 1 IS_UNARY(+) // 0 IS_UNARY(xyz) // 0 Regards and thanks, Paul Mensonides

3 12

algorithm/string bug
by Llew Sion Goodstadt 06 Sep '04

06 Sep '04

There seems to be a bug somewhere in #include <boost/algorithm/string.hpp> If I am not mistaken, this is the central include file for all the string algorithms. But if, e.g. in replace_example.hpp, you replace the separate declarations of #include <boost/algorithm/string/replace.hpp> #include <boost/algorithm/string/erase.hpp> #include <boost/algorithm/string/case_conv.hpp> with //#include <boost/algorithm/string/replace.hpp> //#include <boost/algorithm/string/erase.hpp> //#include <boost/algorithm/string/case_conv.hpp> #include <boost/algorithm/string.hpp> the file no longer compiles. However, #include <boost/algorithm/string/replace.hpp> //#include <boost/algorithm/string/erase.hpp> //#include <boost/algorithm/string/case_conv.hpp> #include <boost/algorithm/string.hpp> does work. Is there an error in the order of header inclusion? Leo Goodstadt

2 1

Program options possible error?
by Llew Sion Goodstadt 06 Sep '04

06 Sep '04

In <boost/program_options/detail/config_file.hpp> why is BOOST_WORKAROUND used (line 19) before the inclusion of #include <boost/detail/workaround.hpp>? Thanks Leo

2 1

RE: [boost] Re: IOStreams formal review start
by Reece Dunn 06 Sep '04

06 Sep '04

Jonathan Turkanis wrote: >I'm starting to think it would be very useful to have a Flushable concept, >which >would allow components to advertise that they can send all buffered data >downstream at any time. I haven't given it much though yet, but I think it >would >allow OuputFilters to be inserted and removed in the middle of processing a >character sequence, as Dietmar suggested. This would make it possible to write a processor for a PDF file that contains several 'stream' objects, each with different filters (LZW compression, ASCII85 encoding, JPEG images, etc.). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

tru64cxx65 regression tests temporarily disabled
by Markus Schöpflin 06 Sep '04

06 Sep '04

The regular regression tests for Compaq C++ 6.5 on Tru64 V5.1 have been temporarily disabled. They will be reactivated as soon as possible. Markus

1 0