- Boost - lists.preview.boost.org

[tokenizer] fix for msvc-stlport
by Joaquín Mª López Muñoz 01 Oct '04

01 Oct '04

tokenizer currently fails with tests example (regression) and simple_example_3 and simple_example_4 (expected) under msvc-stlport: http://tinyurl.com/3mkvx http://tinyurl.com/44pbx http://tinyurl.com/5xd8z I've tracked down the failure to a problem of MSVC 6.0 with templatized memfuns of an imported class (thanks to Francois Dumont): http://www.stlport.com/dcforum/DCForumID6/1763.html The following workaround in boost/token_functions.hpp solves the problem for all tests. As the patch is strictly msvc-stlport-specific, I don't think it can have nasty side effects somewhere else. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 11a12,13 > // 30 Sep 2004 Joaquín M López Muñoz > // Workaround for a problem with string::assign in msvc-stlport 38a41 > #include <boost/detail/workaround.hpp> 210a214,224 > > #if BOOST_WORKAROUND(BOOST_MSVC, == 1200) &&\ > BOOST_WORKAROUND(__SGI_STL_PORT, < 0x500) &&\ > defined(_STLP_DEBUG) > // Problem with string::assign for msvc-stlport in debug mode: the > // linker is not able to import the templatized version of this memfun. > // See http://www.stlport.com/dcforum/DCForumID6/1763.html for details. > > t = Token(); > while(b != e) t += *b++; > #else 211a226,227 > #endif >

2 1

Call for Volunteers: the Synopsis project
by Stefan Seefeld 01 Oct '04

01 Oct '04

Hi there, The Synopsis project is looking for volunteers to enhance its C++ parser and source code introspection facilities. The Synopsis project (http://synopsis.fresco.org) started some years ago with the goal to provide a more robust and flexible alternative to code documentation tools such as doxygen and javadoc. As it evolved, it became clear that the infrastructure could serve in a much broader context, and so the current goal is to provide a framework for code introspection. Some obvious use cases include semi-automatic language-binding generation (such as done by boost.python's pyste) as well as reverse engineering and refactoring tools. Synopsis with its current code base is able to parse most of boost (as I posted earlier I have been working with David Abrahams to generate a reference manual for boost.python), though there are some C++ constructs it can not yet fully analyse. My goal is to provide a fully standard compliant C++ parser with C++ and python APIs to access the processing pipeline as well as the abstract syntax tree for maximum power and flexibility. You'll find the project mailing lists at http://synopsis.fresco.org/mailinglists.html Kind regards, Stefan

4 4

Boost.Strings
by Martin 01 Oct '04

01 Oct '04

The fixed_string is already in the review schedule and a proposal for immutable strings was published recently. Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library. That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.

5 6

Re: [boost] Re: MultiMethod/Visitor Interest
by Danil Shopyrin 01 Oct '04

01 Oct '04

David Abrahams writes: > Yeah. It's hard to imagine how "compile-time multimethods" would be > any different from what C++ already provides in terms of overload > resolution and partial ordering. The main difference is that they work when particular types of participants are unknown at compile time. It is just like trying to implement unary virtual method using overloading. Jesse Jones writes: > Can a static library do better type > checking? In particular can it figure out, at compile time, if there > are no applicable methods or no unambiguous method? Yes. The compile-time library detects ambiguity and absence of proper method. It is compile-time error. P.S. It is looks like this post was lost.

1 0

can emacs cc-mode be made to do boost-style preprocessor indents?
by Jonathan Graehl 01 Oct '04

01 Oct '04

The Boost style of nested indenting for preprocessor directives is nice. I'm using cc-mode for emacs (the sourceforge version), and it doesn't seem to directly support this: #if 1 # if 2 # define A 1 # else # endif #endif I found this cc-mode mailing list discussion that confirmed the lack of support: http://sourceforge.net/mailarchive/forum.php?thread_id=5382045&forum_id=6827 Anyone already got some working elisp for preprocessor autoindent?

2 1

Portable test_and_set, please...
by no_carrier 01 Oct '04

01 Oct '04

Hi all, I see some atomic operations in atomic_count.hpp (usable only by the atomic_count class unfortunately, and not directly) for incrementing and decrementing, but the most important atomic operation seems to be missing: the test_and_set. Without that one it's not possible to create lockfree algorithms in MT. Also, atomic incrementing, decrementing etc. can be performed having the test_and_set but not vice versa. Would anybody please make a wrapper for that? On Windows it's the InterlockedCompareExchange, on Gcc and Linux I think they are called __test_and_set and atomic_test_and_set respectively. I don't know if they would better go in the Boost.Threads or in the atomic_something header files... Thanks

1 0

[Signals] slot/trackable object disconnection question
by Dave Deakins 01 Oct '04

01 Oct '04

I have a question about the disconnection of slots in the signals library. I couldn't find any information about it in previous message threads, but if I missed one you guys can just direct me to the appropriate discussion. In my project I have a serial port communications queue that allows various other objects to transmit a command over the serial port and then have the response routed to a designated callback function. Each command request can specify a different response callback function and often the object posting the command will ask the queue to pass the response data back to one of its member functions for interpretation. I use the automated connection management feature of signals to insure that the response member function is not called if its target object is destroyed before the serial port response is received. This queue typically handles about 10-15 command/response transactions per second and I noticed that, after about 15-20 hours of continuous operation, the system began to run low on available memory. I spent a fair amount of time trying to track down the source of the excessive memory usage and it appeared that it was coming from the trackable object base class. Each time a command is added to the communications queue, a new queue entry is created and we connect the response handling function to the signal in this queue entry. If I understand correctly, signal's connect function will create a temporary slot object to adapt the boost::bind(&AClass::ResponseFunction, pAClass, _1, _2) object that is passed to it. When this temporary slot is created, it uses visit_each to enumerate the bound trackable objects and then uses trackable::signal_connected(...) to have each bound trackable object save a 'controlling' connection to the slot in its connected_signals list. So if any of the bound trackable objects are destroyed, the 'controlling' connection will deactivate the slot and tell all of the bound trackable objects used by the slot that they can erase their connections to this slot. So my question is this: When a slot object (not a signal object) is destroyed, what tells the trackable objects that are used by the slot that they can release their connection to this slot? Signal objects make the connections in their internal slot map 'controlling' so these connections would do the clean up when the signal is destroyed. As mentioned above, trackable objects also make the connections in their internal connected_signals list 'controlling' to enable deactivation and clean up of standalone slots or slots connected to signals when the trackable object is destroyed. But the watch_bound_objects connection in the slot object is not 'controlling' (as far as I can tell) and thus a slot does not seem to have any way to indicate to the bound objects that this connection needs to be cleaned up if the slot is destroyed. The following program roughly illustrates the behaviour I see in my application: #include "boost\bind.hpp" #include "boost\signals.hpp" class CommunicatingObject : public boost::signals::trackable { public: void ProcessResponse() {} }; int main(int argc, char* argv[]) { CommunicatingObject Obj; while (true) { boost::signal0<void> NewResponseData; NewResponseData.connect( boost::bind(&CommunicatingObject::ProcessResponse, &Obj) ); NewResponseData(); } return 0; } Obj would represent the object making a request on the queue and NewResponseData would represent the signal contained in the queue entry. When I run this test program on my system, the system runs out of memory in fairly short order. I have the same memory draining situation if the while(true) loop is changed to the simpler case of: while (true) { boost::signal0<void>::slot_type( boost::bind(&CommunicatingObject::ProcessResponse, &Obj) ); } Can someone please confirm if this behavior happens on other systems or if maybe there is some pecularity with my system/compiler? If this situation is not peculiar to my system, should there be a: watch_bound_objects.set_controlling(); statement at the very end of the slot_base::create_connection() procedure (after the safe_connection.release() statement) in slot.cpp? Thanks in advance for your help, -Dave

2 6

Re: [boost] [Random] GCC 2.95.3 regressions
by Michael Stevens 01 Oct '04

01 Oct '04

> Aleksey Gurtovoy writes: > > > > Given that the code compiles with the latests versions of the > > compiler, the following (from http://tinyurl.com/58lll) is most likely > > to be a compiler bug, but since the test used to pass some time ago, I > > was wondering if anyone is interested in making it work again or simply > > commenting on it before I mark it green: > > [snip errors] > > OK, seems like nobody is interested in these, marked up as expected. I took a quick look. It seems like gcc-2.95 has namespace problems when BOOST_USING_STD_MIN/MAX Since Random never worked on systems without min/max in std I have simplified and use std::min/max instead. This fixes gcc-2.95 and should not regress on any of the good compilers. If this looks good in the tests tomorrow I will remove the failure markup. Michael

2 1

use of strcpy, strcat, etc in Boost libraries
by Reece Dunn 01 Oct '04

01 Oct '04

Hi All, In my post on the "vc8.0 toolset (bjam)" thread, I commented that VC8 also warns when using the str[n]xxx APIs, because MS declares them deprecated. There are several issues here: [1] How does this impact Boost code that uses the <cstring> API? Especially since they deprecate the strn variations as well, which are safer, and considering that the "safe" versions are not yet a part of the standard. Would it be possible to put this in the Boost <cstring> header? I.e. using the safe versions for VC8 and using the C9x API for the other compilers/libraries. [2] Does this affect the Intel compiler using the Dinkumware libraries because Intel does not like how the library declares items deprecated. (This is already an issue using the <locale> header and <hash_xxx> extensions). [3] What are the wider security issues of using strcpy, etc in Boost code? The libraries should use the strnxxx variants for better protection against buffer overrun attacks, but I found several instances where strcpy was used (I haven't checked for strcat, strcmp and others) instead of strncpy: boost/regex/v4/regex_cstring.hpp (104): use of strcpy [via re_strcpy] libs/regex -- various files using strcpy libs/serialization/test/test_tools.hpp (69): use of strcpy [via STRCPY] libs/smart_ptr/test/smart_ptr_test.cpp (139/223): use of strcpy tools/build/jam_src -- execnt.c; regexp.c; variable.c [4] Doing this, I found that regex was using re_strcpy as a workaround for Borland using strxxx as macros when using intrinsics. Serialization uses STRCPY for a similar workaround, and my fixed_string library uses the following: # if defined(__BORLANDC__) && defined(strcpy) // replace Borland instrinsic string function # undef strcpy inline char * strcpy( char * dest, const char * src ) { return( __strcpy__( dest, src )); } # endif So: should the workarounds be placed in <cstring> and affected libraries use the Boost version. NOTE: I suggested telling Boost.Build to disable the deprecated API warning for the upcoming release and then address these issues for the next (1.33) release. Thoughts? Comments? Regards, Reece

4 6

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 30 Sep '04

30 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: <snip> > But now, by looking again at atomic_conditional_increment. I'm not a > threading expert, but it seems pretty costly as it is implemented > now. Could it not go multiple times (n>=2) thorughout the for? Yes. > Current implementation: > > inline long atomic_conditional_increment(long volatile & value) > { > for(;;) > { > long tmp = value; > if(tmp == 0) return 0; > if(InterlockedCompareExchange(&value, tmp + 1, tmp) == tmp) > return tmp + 1; > } > } > > > Couldn't it become: > > inline long atomic_conditional_increment(long volatile & value) > { > long tmp = value; Suppose we read the count as 2 here... > if(tmp == 0) return 0; ...and that another thread decrements the count to 1 around here... > long new_val = InterlockedCompareExchange(&value, tmp + 1, tmp); > if(new_val == tmp) return tmp + 1; ...so that InterlockedCompareExchange fails and returns 1, so this doesn't return; and suppose that another thread decrements the count to 0 around here... > else return InterlockedIncrement(&value); ...then this increments the count to 1, which is wrong. > } The increment has to be conditional on the count being non-zero, and neither the Win32 API nor the x86 processor (AFAIK) can perform that atomically. So the loop is unavoidable. There is room for a slight optimisation in that the value returned by InterlockedCompareExchange can be used the next time round: inline long atomic_conditional_increment(long volatile & value) { long old = value, older; do { if (old == 0) return 0; older = old; old = InterlockedCompareExchange(&value, old, old + 1); } while (old != older); return old + 1; }

2 1

Output formatters: different approaches
by Vladimir Prus 30 Sep '04

30 Sep '04

During the review of the output formatters library, there were suggested several alternative approaches. For example, Gennadiy thinks the library is too complicated, and Hartmut suggests creating a library dual to Spirit -- which would be extra powerfull. That's not all. Independently, I've talked with Vaclav Blazek, who's the author of the Teng text template engine (http://teng.sourceforge.net/) which is also a similiar domain -- it's too about formatting objects. It would be great if we had some common foundation, so that I could output ptr_vector<Function> using both a simple formatter, or a flexible one, or even some template engine. Such foundation can be pretty simple: 1. A fixed set of type "categories" (sequence, map, tuple, something else) and a mechanism to obtain the category for a specific type. The current library even has some mechanism, but I'm not sure if's as simple as possible and is extentable. 2. A mechanism to iterate over elements of composite type. After some though, I believe that the mechanism should be boost::serializaton. Take, for example, sequences. The reviewed version of the library contains the code to handle boost:array, vector, list, and pair. The amount of code devoted for this is significant. If serialization library were used (it provides 'save' and 'load' functions for those types), the implementation would be simpler: The basic formatter could look like: class formatter { template<class T> void write(T &t, is_primitive) { os << t; } template<class T, class Category> void write(T &t , Category { os << start_delimiter<Category>(); os << t; os << end_delimiter<Category>() } template<class T> formatter& operator&(const T& t) { write(t); } }; The idea of the library, as I see it, is to provide object serialization, but - without the overhead serialization library has - with extra layout tweaks I don't see why it's necessary to reinvent the object traversal code which is already in boost::serialization. For example, boost::serialization support scoped_ptr. It would not make sense to add separate support for scoped_ptr in outfmt. And, as I've already mentioned I'd like the 'serialize' approach even for class members. Even if serialization headers which provide support for vectors, lists and so on drag too many dependencies, I think this is fixable. On the top of this, it's easy to provide various output facilities. - A simple multi-line indenting formatter. No customization at all, no overhead - A more advanced solution which uses nested formatters (like the revieved version), and stores formatting information in iword/pword - An interface with template system: e.g. Template t(...); vector<Function> f; t["functions"] = f; would traverse 'f' creating a tree of values which can be used in template. Thoughs? - Volodya

3 2

RE: [boost] Re: Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 30 Sep '04

30 Sep '04

Peter Dimov <pdimov(a)gmail.com> wrote: > Ben Hutchings wrote: <snip> > > I feel the naming of functions may give a false sense of generality > > and encapsulation when they actually only work in the way they are > > being used currently. > > I'm not sure which functions do you have in mind here. I'm perhaps overstating the case, but still: Firstly, atomic_read. I think people generally expect atomicity and ordering to go hand-in-hand - though I realise they don't have to - and the other functions whose names begin with "atomic_" do prevent reordering of their memory accesses, so this name could be misleading. Secondly, use_count's return values can only be used in very specific ways (e.g. the comparison with 0 as an optimisation in weak_ptr<>::lock). I realise that the use_count functions in shared_ptr and weak_ptr are documented as "only for debugging and testing purposes", but I was kind of thinking the name ought to suggest that. (Also the documentation fails to point out that return values can immediately become incorrect in multithreading systems, and has postconditions based on use_count() that won't necessarily be true if tested in real code, though this perhaps ought to be obvious.) > http://66.102.9.104/search?q=cache:1ZQ1uXtFUEIJ:www.pdimov.com/cpp/ > shared_count_x86_exp2.hpp Thanks for that.

1 0

Re: [boost] Re: MultiMethod/Visitor Interest
by Danil Shopyrin 30 Sep '04

30 Sep '04

_____ From: Danil Shopyrin Sent: Monday, September 27, 2004 11:13 AM To: 'boost(a)lists.boost.org' Subject: RE: Re: [boost] Re: MultiMethod/Visitor Interest Hi! http://tinyurl.com/5qxky - it's a "preliminary" version of my solution. The [maybe] complete version can be found at http://www.codeproject.com/cpp/mmcppfcs.asp. And some of mentioned drawbacks are already eliminated. Background. My solution is an "idealized" solution. It is stands as an answer to question: "can multimethods be implemented in C++ using only 'good' programming techniques?" It is fully compile time and absolutely type safe. And there is no of RTTI. This is an academic result. Moreover, this is ready to practical use (I do it). There is a big resource of flexibility. By reducing the 'type safety sugar' this solution can be extended. Look on "Compilation in separate modules" section. And so on. I hope that the approach can be extended to met 'practical solution' requirements. But this is a hard job to one person to produce consistent set of these requirements. However, I think that "clear" solution is also practical in many cases. Further, about drawbacks: 1) Compile time. Yes, this solution is strongly compile time. But I think it is an advantage :-) 2) You are right. There is no "next_method". I was never think of them. 3) Intrusive. It is eliminated. 4) "distinguishes the first argument". It is eliminated. 5) Gnarly user code. Look at up-to-date "tiny use case" at http://sdanil.narod.ru/mm/m2vd3_v5.zip -- Danil

5 9

RE: [boost] Re: Call for Volunteers: the Synopsis project
by Stefan Seefeld 30 Sep '04

30 Sep '04

> From: Doug Gregor [mailto:dgregor@cs.indiana.edu] > Sent: September 30, 2004 10:30 > > I should mention that the design of the C++ parser allows > to manipulate > > the generated parse tree in-memory and write it out into a > file again > > in > > a non-lossy way, i.e. it could indeed be used as a source-to-source > > compiler. > > That's an excellent goal, and you have me interested. It's a > huge task, > requiring a great deal of expertise (collectively, we have that) and > will require a lot of time. I think it would be wise to attempt to > isolate some of the interesting-but-disjoint problems early, > so we can > put out a "request for libraries" of some sort. Things that come to > mind quickly: a unification algorithm (for template > instantiation/partial ordering), a tree > manipulation/rewriting library > (for AST transformations), and a flexible symbol table library. in what sense do you use the term 'library' here ? While I fully agree that is is very useful to approach this big task by splitting it into modules, I doubt it is feasible or even useful to use these entities as separate deployment units. However, I think we can come up with a high level design that respects the data flow requirements (the complex interactions between the parser and the symbol lookup table notably) yet is flexible enough to let the individual modules evolve in parallel. In fact, I have good hope that I could use the same framework to analyze C code (something I hope the Free Software community around GNOME / GNU will benefit from) by using some form of polymorphism in the lexer, the parser, and the symbol lookup. Regards, Stefan

2 1

[tokenizer and token_iterator] request for policy or redesign
by Thorsten Ottosen 30 Sep '04

30 Sep '04

Hi John, I vaguely recall that the standard committee rejected the tokenizer proposal because of performance problems. A thing that would boost performance a lot would be to allow the user to specify a "token match type". So I have some stupid questions: 1. Why is the three template paramters not defined as template < class TokenizerFunc = char_delimiters_separator<char>, class Type = std::string class Iterator = typename range_const_iterator<Type>::type > class tokenizer ?? 2. what is the requirement exactly on the Type parameter? 3. would it not be possible to allow typedef boost::tokenizer< fun, boost::sub_range<string> > tokenizer; ? I believe this would give a huge speedup. br Thorsten

6 23

[Serialization] Remaining failures markup
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Robert, Pending msvc-stlport issue aside, the serialization library reports show quite a few failures with other toolsets, in particular: cw-9.3 borland-5.6.4 cw-8.3 msvc vc7 I'm sure you've well aware of these; what I'd like to ask you is to comment on them in the "explicit-failures-markup.xml" in the similar way you commented on "*_warchive" tests, so that a) the library users are not scared away by all these yellow cells, and b) the release manager and everybody else besides the author have a simple way of telling whether the library is in the OK state or not. Thanks in advance, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[Random] GCC 2.95.3 regressions
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Given that the code compiles with the latests versions of the compiler, the following (from http://tinyurl.com/58lll) is most likely to be a compiler bug, but since the test used to pass some time ago, I was wondering if anyone is interested in making it work again or simply commenting on it before I mark it green: /boost/head-regression/boost/boost/random/xor_combine.hpp: In method `uint32_t boost::random::xor_combine<boost::random::linear_feedback_shift<unsigned int,32,31,13,12,0>,0,boost::random::linear_feedback_shift<unsigned int,32,29,2,4,0>,0,0>::min() const': /boost/head-regression/boost/boost/random/xor_combine.hpp:74: instantiated from `boost::random::xor_combine<boost::random::xor_combine<boost::random::linear_feedback_shift<unsigned int,32,31,13,12,0>,0,boost::random::linear_feedback_shift<unsigned int,32,29,2,4,0>,0,0>,0,boost::random::linear_feedback_shift<unsigned int,32,28,3,17,0>,0,0>::min() const' /boost/head-regression/boost/libs/random/random_test.cpp:251: instantiated from `instantiate_urng<boost::taus88, unsigned int>(const basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> > &, const boost::taus88 &, const unsigned int &)' /boost/head-regression/boost/libs/random/random_test.cpp:377: instantiated from here ... Date: 2004-09-26 06:35 set -e "/usr/local/gcc-2.95.3/bin/g++wrap" --limit-memory=600 --limit-cpu=1800 -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"../bin/boost/libs/random/test" -I "/boost/head-regression/boost" -o "../bin/boost/libs/random/test/random_test.test/gcc-2.95.3-linux/debug/random_test.o" "/boost/head-regression/boost/libs/random/random_test.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "../bin/boost/libs/random/test/random_test.test/gcc-2.95.3-linux/debug/random_test.o" Anyone? -- Aleksey Gurtovoy MetaCommunications Engineering

1 1

[Lambda] GCC 3.4.1 failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Jaakko, Could you please take a look/comment on the following failure in "bind_tests_simple_f_refs" (from http://tinyurl.com/52xlg) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"C:\MinGW\Bronek\boost\results\bin\boost\status" -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\status\bind_tests_simple_f_refs.test\mingw-3.4.1\debug\bind_tests_simple_f_refs.obj" "C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp" C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp: In function `int test_main(int, char**)': C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp:69: error: call of overloaded `bind(int (&)())' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:48: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<1, boost::lambda::function_action<1, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(), boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)()) [with Result = int] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:70: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<1, boost::lambda::function_action<1, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&) [with Arg1 = int ()()] C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp:70: error: call of overloaded `bind(int (&)(int), int)' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:188: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(Par1), const Arg2, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)(Par1), const Arg2&) [with Result = int, Par1 = int, Arg2 = int] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:210: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, const Arg2, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&, const Arg2&) [with Arg1 = int ()(int), Arg2 = int] [...] ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Test failure with STLPort
by Robert Ramey 30 Sep '04

30 Sep '04

I've noticed that you are testing the serialization library with the toolset msvc-stlport. I've tested that here and got most of to pass - at least as well as standard msvc. I had to make some changes though and I believe that you will have to make similar ones if you want the test to pass. I had to invoke the following before running the tests. export STLPORT_PATH="c:/" export STLPORT_VERSION=4.5.3 export STLPORT_INCLUDE_DIRECTORY="c:/program files/Microsoft Visual Studio/vc98/include/stlport" my stlport install process created a special set of stlport header files in the msvc include directory. This is and altered version of the original ones. The original ones compiler ok but they have some switches set so that some inline code is not included and this makes the test builds fail at link time. The above variables communicate information to the msvc-stlport toolset on where to look for the stlport headers. Note that the documentation on msvc-stlport jam is somewhat out of date so that confuses this issue as well. Note that failures of other STLPort toolsets that depended upon vc6 may be related to this issue as well. Robert Ramey

2 3

Python/GCC 3.4.1/Linux failures
by Gottfried.Ganssauge＠HAUFE.DE 30 Sep '04

30 Sep '04

David Abrahams wrote: > Martin Wille <mw8329(a)yahoo.com.au> writes: > > > David Abrahams wrote: > >> Martin Wille writes: > >> > >>>Trying: assert abs(rewrap_value_complex_float(4+.2j) - > (4+.2j)) < .000001 > >>>Expecting: nothing > >>>Segmentation fault > >> Wild guess: This is an ODR violation. The Boost.Python library and > >> the test shared library were compiled with a different > definition of > >> std::complex. > > > > How could that have happened? > > Weird INCLUDE picked up from the environment? Sorry, after that I'm > fresh out of wild guesses ;-) > > GDB should be able to show you what's going wrong, though. > > > Note, this is not the intel compiler, > > so flags like "-cxxlib-gcc" shouldn't be a problem here. Could the > > build system use so different flags that the resulting libraries > > wouldn't be interoperable? (I know this can happen rather easily > > on other systems. However, I haven't seen that with gcc on Linux > > as long as you stick to the same compiler version). > > > > Python was compiled using gcc 3.3.4. Could this cause the problem? > > (I don't think so.) It probably can if python was linked using the C++-Compiler. Gcc-3.3 uses libstdc++.so.5 for it's standard library whereas gcc-3.4 uses libstdc++.so.6. Probably both are dynamically linked to your extension (ldd will reveal if that's the case). Cheers, Gottfried

1 0

[Filesystem] Intel 7.1/Linux failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6) Compiler output []: /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(122): error: the global scope has no "readdir64" if ( (dp = ::readdir( handle )) == 0 ) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(313): error: incomplete type is not allowed struct stat path_stat; ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(314): error: the global scope has no "stat64" if(::stat( ph.string().c_str(), &path_stat ) != 0) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(339): error: incomplete type is not allowed struct stat lcl_stat; ^ [...] ? Should I mark the library as unusable in this configuration? -- Aleksey Gurtovoy MetaCommunications Engineering

3 8

Any Intel on Linux Gurus (help wanted with toolset for 8.1)?
by John Maddock 30 Sep '04

30 Sep '04

Apparently from Intel 8.1 onwards, we can no longer link C++ programs with icc as the current intel-linux toolset does: icc is now Intel's equivalent to gcc and performs a C only link, we need to use icpc to link C++ programs (and ideally to compile them as well, although icc currently still recognises C++ source and internally calls icpc). So here's the big question - does anyone have access to Intel 6 and/or 7 on Linux and do these also have icpc? If they do, then this is a no-brainer change to the toolset, but if not then we're going to have to get creative :-| Thanks, John.

2 2

ublas problem
by Matthias Troyer 30 Sep '04

30 Sep '04

Hi, I encounted a strange assertion failure in ublas: Assertion failed in file /Users/troyer/src/boost/boost/numeric/ublas/matrix_sparse.hpp at line 2603: !preserve internal logic Can anyone shed light on this? Matthias

1 0

[config] bcc configuration fix
by Tobias Schwinger 30 Sep '04

30 Sep '04

Just tripped over this (maybe still "sleeping") bug: Neither Builder 5 nor the free 5.5.1 tool chain do support member function specializations: 27a28 > # define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS

2 2

Re: [boost] Re: MultiMethod/Visitor Interest
by Danil Shopyrin 30 Sep '04

30 Sep '04

Hi! I think about multimethods as about generalized version of virtual method. There are compile time virtual methods in C++, and it's ok. Everyone practically use compile time virtual methods. And, by my opinion, the generalized version of them also should be compile time. Maybe we speak about different things? Maybe there should be at least two versions of multimethods: 1) as a generalization of traditional virtual methods; 2) as a generalization of "fully runtime polymorphism". >> Which file are you talking about? I talk about *.h/*.cpp files that aren't located in mm subfolder.

3 2

[Numeric/Interval] Mingw-3.4.1 failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Could somebody please take a look at these (from http://tinyurl.com/477vr) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\libs\numeric\interval\test\integer.test\mingw-3.4.1\debug\integer.obj" "C:\MinGW\Bronek\boost\boost\libs/numeric/interval/test/integer.cpp" In file included from C:/MinGW/Bronek/boost/boost/boost/numeric/interval.hpp:20, from C:\MinGW\Bronek\boost\boost\libs/numeric/interval/test/integer.cpp:11: C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::asinh_down(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:42: error: `::asinh' has not been declared C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::asinh_up(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:42: error: `::asinh' has not been declared C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::acosh_down(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:43: error: `::acosh' has not been declared [...] ? -- Aleksey Gurtovoy MetaCommunications Engineering

6 28

Why all prog-fail test are failing
by Gennadiy Rozental 30 Sep '04

30 Sep '04

I already asked this one. Did I miss an answer? Gennadiy.

3 3

RE: [boost] Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 30 Sep '04

30 Sep '04

Hi, Perhaps my fault - It wasn't that easy to just define YY_NO_UNISTD_H to make graph compile with vc7.1. The problem is that two non-ANSI C functions is called: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; A little documentation search on Win32 gives: <io.h> int _isatty(int); <stdio.h> int _fileno(FILE*); As for how to solve these non-portable stuff with perhaps some BOOST defines, I think you all know better than I do. Kindest Regards, Christian -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Wed 2004-09-29 17:45 To: boost(a)lists.boost.org Cc: Subject: Re: [boost] Re: Graph broken for vc7.1 after 1.31? On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote: >> Were you able to check it on VC 7.1? > > No. I'd appreciate if you could try there. I'll try to do so later. > >>>> We'll deprecate it in 1.32.0 (when, hopefully, we will >>>> have a new GraphViz parser that works well) and remove it >>>> afterwards. >>> >>> How the new parser will be implemented? >> >> Spirit. > > Is it written yet? Would be interesting to see. I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in. >> Granted, they've dropped support for older, broken compilers, >> so someone will still be getting hurt by this. > > Right. OTOH, I start to wonder if BGL should drop support for old > compilers > as well. (borland and vc6 are marked unusable already). There seem to > be a > lot of workaround inside BGL which means even reading the code hard. We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: MultiMethod/Visitor Interest
by Danil Shopyrin 30 Sep '04

30 Sep '04

David Abrahams writes: > Yeah. It's hard to imagine how "compile-time multimethods" would be > any different from what C++ already provides in terms of overload > resolution and partial ordering. The main difference is that they work when particular types of participants are unknown at compile time. It is just like trying to implement unary virtual method using overloading. Jesse Jones writes: > Can a static library do better type > checking? In particular can it figure out, at compile time, if there > are no applicable methods or no unambiguous method? Yes. The compile-time library detects ambiguity and absence of proper method. It is compile-time error.

1 0

Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 30 Sep '04

30 Sep '04

Hi, Sorry if I am missing something - I can't compile (with Visual C++ 7.1) the graph library in the cvs snapshots since a couple of months. The errors are in graphviz_graph_lex.cpp and graphviz_digraph_lex.cpp due to an include of a Unix specific file "unistd.h". Although there is a preprocessor condition YY_NO_UNISTD_H around it, I can't find anywhere this would be defined for non-unix systems. I start the build with this command: libs\graph\build>bjam "-sTOOLS=vc7.1" Will this be fixed to the final 1.32 release? I do remember the graph library worked in 1.31, but with some build tweaks regarding un-/directed graphs. Regards, Christian

4 7

[filesystem] possible bug in exists(path const &)
by Angus Leeming 30 Sep '04

30 Sep '04

Beman, I notice that the Windows implementation of exists() contains the line: if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) This contrasts with DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); in is_directory(). I wonder if there are any implications in using string() as opposed to native_file_string() here? It does appear that in most places you prefer to use the "native_" flavour when invoking system functions. Regards, Angus

2 1

[review] Formal review of the Smart Container library - one week left reminder
by Pavol Droba 29 Sep '04

29 Sep '04

Hi All, This the the reminder, that there is only one week left for the Smart Containers review. Please post your reviews if you find this library interesting. Best Regards, Pavol Droba Following is the copy of the invitation message: The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * 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. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

Re: [uBLAS] Linux regressions
by Michael Stevens 29 Sep '04

29 Sep '04

Martin, Thanks for your work on the Linux tests. Looks like all the staleness problems are fixed. The uBLAS tests now show the expected 100% passes. Michael

2 1

Formal review of "Output Formatters" library begins today
by John Torjo 29 Sep '04

29 Sep '04

Dear boosters, The FORMAL Review of "Output Formatter" library begins today, Sept 12, 2004. Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. 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. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

15 42

[tokenizer] Any expert in bjam?
by Joaquín Mª López Muñoz 29 Sep '04

29 Sep '04

tokenizer is regressing for msvc-stlport as shown in http://tinyurl.com/3mkvx The same kind of problem happens at the following cells wich are marked as expected failures: http://tinyurl.com/44pbx http://tinyurl.com/5xd8z I've built these tests locally for msvc-stlport locally (from my IDE) and they work just fine. No fundamental problem with this platform. So I guess the problem lies in the corresponding Jamfile entries (located directly in boost/status/Jamfile): test-suite tokenizer : [ run libs/tokenizer/examples.cpp <lib>../libs/test/build/boost_test_exec_monitor ] [ run libs/tokenizer/simple_example_1.cpp ] [ run libs/tokenizer/simple_example_2.cpp ] [ run libs/tokenizer/simple_example_3.cpp ] [ run libs/tokenizer/simple_example_4.cpp ] [ run libs/tokenizer/simple_example_5.cpp ] ; I'm pretty sure this is related to some messing up of stdlibs binaries (I vaguely recall that STLPort does not work with single-thread static runtime lib), but my skills of Jamfile are lousy. Could somebody please have a look at it? Another thing that left me wondering is that examples 1, 2 and 4 have the same structure as 3 and 5, and yet they do not fail. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

failures with intel-win32-7.1-vc6-stlport-4.5.3 Toolset?
by John Maddock 29 Sep '04

29 Sep '04

I've been trying to track down a couple of regex test failures that appear for this toolset, but can't build even build STLPort never mind the tests with Intel 7.1, I consistently get errors like: c:\download\open\stlport\STLport-4.5.3\stlport\cstdlib(42): error: namespace "st d" has no member "div_t" using _STLP_VENDOR_CSTD::div_t; ^ c:\download\open\stlport\STLport-4.5.3\stlport\cstdlib(43): error: namespace "st d" has no member "ldiv_t" using _STLP_VENDOR_CSTD::ldiv_t; ^ So is this test being run with a modified STLport version or something? Thanks, John.

2 1

Re:Re: [boost] serialization: buffers
by Robert Ramey 29 Sep '04

29 Sep '04

Darren Cook wrote: >> Or you might try the following (non-portable) idea >> >> ar & BOOST_SERIALIZATION_NVP( >> make_binary_object(str, (p - str)* sizeof(int)) >> ); >Thanks, that is closest to what I was after; I don't need a portable >version here. >> But really, I think you might be best off replacing the class above >> with >> >> class Example { >> std::slist<int> str; // or maybe std::vector<int> str } >It was done using a fixed size buffer to avoid dynamic memory allocation >(mainly for speed reasons). >However as I worked through the class some more I found it can output a >string representation, which uses fewer bytes. So in future I might add a >parser for input and then switch to using that (though I'll be back to >needing separate load/save functions then won't I, oh well :-). A couple final observations: a) the make_binary .. implementation is maximal speed on a binary archive. It just streams the bytes to the i/o buffer. b) If you're concerned about binary portability and file size, take a look at the demo binary portable. It implements saving/loading of integers as variable length binary bytes so that a lot of the zeros are eliminated. c) if you're concerned about file size. You might consider using the streams library - currently pending review - to compress/de-compress the i/o on the fly as the data is saved/loaded. Robert Ramey

1 0

date_time formatting
by Martin 29 Sep '04

29 Sep '04

I'm trying to understand the date_time formatting via iostreams but got problems with a few things. I tried to search the archive but didn't find answers to these questions. 1. Why doesn't date_time use the standard time facet (time_put.do_put etc) if the special greg_date_facet isn't available? 2. Why do I need to specify the names of all months and weekdays in the greg_date_facet just to use a different separator than '-' or another ordering? 3. How do I specify the format of a ptime (date-separator, time-separator and decimal separator)? -------------------------------------------- I also got some compile warnings on VC70 (latest CVS) 1: in the function "from_time_t" on this line return start + seconds(t); boost\date_time\posix_time\conversion.hpp(27) warning C4244: 'argument' : conversion from 'time_t' to 'long', possible loss of data 2: in the function "from_stream_type" ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown boost\date_time\date_parsing.hpp(211): warning C4244: 'argument' : conversion from 'wchar_t' to 'char', possible loss of data

2 3

New numeric cast
by Fernando Cacciola 29 Sep '04

29 Sep '04

Hi, According to the regression summary, the new numeric conversion library is in pretty good shape(thanks to Joaquín Muñoz for his latest fixes!) I want to test how far can the new "numeric_cast<>" replace the old one. For that, I want to put the exact same test that's currently used for the old numeric_cast in the new library. Right now, cast_test.cpp contains numeric_cast<> test with other conversions. I will factor it out, but I have a doubt: it is not using the Test framework at all, it's just printing the test result to std out. Does the regression scripts parse the output, or these test are just wrongly integrated? Should I update those test to use the Unit Test Framework? Fernando Cacciola SciSoft

3 6

[type_traits] fixes for GCC 2.95
by Joaquín Mª López Muñoz 29 Sep '04

29 Sep '04

The following regressions in gcc-2.95.3-linux http://tinyurl.com/638l6 http://tinyurl.com/3k6hu are IMHO due to the fact that bad_alloc is defined in <new>, and this header is not included by the corresponding test programs. I'd say it's only out of sheer luck (dependant inclusions) that these tests works for the rest of compilers, but I might be wrong. In any case, #including <new> solves the problem. If noone sees a problem with these patches, I'll commit them. Joaquín M Lópz Muñoz Telefónica, Investigación y Desarrollo 16d15 < #include <new> 22d21 < #include <new>

2 1

Boost.Test token_iterator_test failure
by Gennadiy Rozental 29 Sep '04

29 Sep '04

Hi, Looks like subject test fails at runtime on following line: std::list<char> l; // here I populate l; std::string s; s.assign( l.begin(), l.end() ); // <---------- HERE Funny things is that it start working if I change list to vector. Is this some kind of gcc STL bug? Gennadiy.

2 4

Suspicious warning message python/src/object/function.cpp
by Neal D. Becker 29 Sep '04

29 Sep '04

Current boost.cvs, gcc-3.4.2: /usr/local/src/boost.cvs/libs/python/build/../src/object/function.cpp:101: warning: right-handoperand of comma has no effect

6 7

most boost.python tests fail on Tru64
by Markus Schöpflin 29 Sep '04

29 Sep '04

After I finally got the regression tests running again on my machine, I would like to figure out, why most of the python tests are failing. For an example error message see http://tinyurl.com/46he3 . Has anybody any idea as to where I should start looking for this? Markus

2 3

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 29 Sep '04

29 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > Ben Hutchings wrote: <snip> > > expired() may read the count as still being 1 and so return false, > > but I believe the wnd_shared_ptr constructor will catch the fact > > that the pointer really has expired. Unfortunately I can't yet > > see the code to confirm this! > > By looking at the code, I would think not. But I may be wrong. > Anyway, I've posted the code in my other post. Thanks for that. Supposing that expired() wrongly returns false because use_count is really 0 but it gets an old non-zero value. Then lock() attempts to construct a shared_ptr: calls shared_ptr<T>::shared_ptr<T>(weak_ptr<T> const &) calls detail::shared_count::shared_count(weak_count const &) calls detail::sp_counted_base::add_ref_lock() calls detail::atomic_conditional_increment( long volatile &) either reads the count as 0 or calls _InterlockedCompareExchange fails and returns 0 then loops around and reads the count as 0 returns 0 throws bad_weak_ptr catches bad_weak_ptr returns 0 OK?

3 2

[Date-Time] Regressions/failures with Intel 7.1/Linux
by Aleksey Gurtovoy 29 Sep '04

29 Sep '04

What should we do about these three: http://tinyurl.com/4hbok http://tinyurl.com/4vv64 http://tinyurl.com/4a2xs ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Re:[boost] serialization: buffers
by Robert Ramey 29 Sep '04

29 Sep '04

>I've a class like this: >class Example{ >int str[BSize]; >int *p; >}; >Where p points to next available element (p==str+BSize is possible when it >is full). I.e. str is like begin() and p is like end(). I want to add a >serialize() function, something like this: >template<class Archive> void serialize(Archive &ar,const unsigned int){ >ar & BOOST_SERIALIZATION_NVP(buf,p); >} >but there seems to be no support for buffers like this? Of course the following would work: ar & BOOST_SERIALIZATION_NVP(buf,str); but it would copy too many elements. Or you might try the following (non-portable) idea ar & BOOST_SERIALIZATION_NVP(buf, make_binary_object((p - str)* sizeof(int), str) ); But really, I think you might be best off replacing the class above with class Example { std::slist<int> str; // or maybe std::vector<int> str } For which serialization is already implemented. Robert Ramey

2 1

Re: [boost] [serialization] documentation for xml archive usage
by Robert Ramey 28 Sep '04

28 Sep '04

>> Oh - no. Use the variable name for the tag not the name of the type. >> This is encouraged by usage of the idiom >> >> ar & BOOST_SERIALIZATION_NVP(my_variable); >Might I also suggest a similar interface which allows the caller to specify >the name to go with the value: >BOOST_SERIALIZATION_NAME_VALUE ("variable", m_variable); The following already exists. make_nvp("variable", m_variable); The above macro was only created to avoid retyping the variable name in the Most common case. Robert Ramey

1 0

[Thread] GCC 2.95/STLPort/Linux static lib failures
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

Is it the test environment that is at failt here (from http://tinyurl.com/5t5mf) /usr/bin/ld: cannot find -lstlport_gcc_stldebug_static collect2: ld returned 1 exit status set -e LD_LIBRARY_PATH=/usr/local/gcc-2.95.3/stlport-4.5.3/lib:/usr/local/gcc-2.95.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/usr/local/gcc-2.95.3/bin/g++" -static -g -pthread -pthread -o "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/test_barrier_lib" -L"../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi" -L"/usr/local/gcc-2.95.3/stlport-4.5.3/lib" -L"/usr/local/gcc-2.95.3/lib" "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/test_barrier.o" "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/tss_null.o" "../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_thread-gcc295-mt-sgdp-1_32.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" "../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_thread-gcc295-mt-sgdp-1_32.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" -lrt -lstlport_gcc_stldebug_static -lrt -Wl,-rpath-link,. ? -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

Re:[boost] [serialization] documentation for xml archive usage
by Robert Ramey 28 Sep '04

28 Sep '04

>However, this triggers a BOOST_STATIC_ASSERT in >basic_xml_oarchive<Archive>::save_override<T>(const T&, BOOST_PFTO int). >The implementation insists that all serialized types be wrapped in a >nvp<T>. That is the intent. >But I couldn't find an >explanation in the docs what special steps a user is supposed to take >if the data shall be serialized into an xml archive. (The only hint >that xml archives need special care that I found was the description >of the header file nvp.hpp libs/serialization/doc/headers.html: "To >associate a name tag with a serializable object. This is necessary to >properly render an xml archive which includes the object name." BTW, >this webpage claims nvp.hpp is in boost/archive, but in fact it is in >boost/serialization.) >Do I need to write > ar & nvp<MyMemberType>("my_member_tag", this->my_member); >in my serialization functions for every variable I want to > (de-)serialize? Can I choose an arbitrary tag for each variable or is >it supposed to be consistent for all variables of a specific type? Oh - no. Use the variable name for the tag not the name of the type. This is encouraged by usage of the idiom ar & BOOST_SERIALIZATION_NVP(my_variable); >Am I correct to assume that the code will still work if I serialize into >a "normal" text archive and the nvp will essentially be ignored? And all other archives as well - with no extra runtime overhead (assuming a decent optimizing compiler) There a section Reference:Class Serialization:Serialization Wrappers:Name-Value pairs where this is described. Perhaps this isn't obvious from contents. >May I suggest that a section explaining the issues with xml archives be >added to the docs before the 1.32 release? Yes you may.

4 3

The Smart Container library
by brangdon＠cix.compulink.co.uk 28 Sep '04

28 Sep '04

In-Reply-To: <1256163046.20040926162826(a)topmail.sk> I'm very dubious about using: vec.begin()->bar(); instead of: (*vec.begin())->bar(); It means that ptr_vector<T> is not syntactically a drop-in replacement for vector<T *> or vector<shared_ptr<T> >. Won't that make it unnecessarily difficult to "upgrade" existing classes, and harder to switch back again should the need arise? Doesn't it also obscure what is going on? It seems a fundamentally wrong notation to me. -- Dave Harris, Nottingham, UK

2 1

repost: [mpl] bad interaction with Boost.Bind
by Joaquín Mª López Muñoz 28 Sep '04

28 Sep '04

Alexsey, do you think something must/can be done to solve this? http://lists.boost.org/MailArchives/boost/msg72210.php I think I cannot commit the patch myself since the affected code is automatically generated by some tools of yours. Otherwise, please tell me so and I'll be happy to proceed. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: [review] Formal review of the Smart Container
by brangdon＠cix.compulink.co.uk 28 Sep '04

28 Sep '04

In-Reply-To: <cj6o3i$rgn$1(a)sea.gmane.org> pavel_vozenilek(a)hotmail.com (Pavel Vozenilek) wrote (abridged): > 0. Name of the library should be "Smart Containers" > (note the plural). Also I'm not keen on anything calling itself "smart". It's too vague - smart in what way? Wouldn't "Pointer Container(s)" be better? -- Dave Harris, Nottingham, UK

1 0

Fw: Boost License Permission
by John Maddock 28 Sep '04

28 Sep '04

Another permission received: ----- Original Message ----- From: <SCleary(a)jerviswebb.com> To: <boost-owner(a)lists.boost.org> Sent: Tuesday, September 28, 2004 12:53 PM Subject: Boost License Permission > I, Stephen Cleary, give permission for all my contributions to Boost to be > moved to the Boost Software License Version 1. > > -Steve > > P.S. Sorry for the late reply; I've been on sabbatical. >

1 0

[Optional] Borland failures
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

Could somebody who cares about Borland take a look/comment of these two: http://tinyurl.com/5uw9x http://tinyurl.com/6jse9 ? Judging from the errors, they seem like a low-hanging fruit. -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

regression problems
by Victor A. Wagner Jr. 28 Sep '04

28 Sep '04

I've had to remove mingw from my regression testing since it's creating .lib files which cause bjam to "except" when running the tests. I can see _what_ the problem is, but not _why_ it is. Here's the call stack (well what appears relevant... the top when the error occurs) bjam.exe!_chvalidator(int c=-128, int mask=8) Line 56 + 0x2a bytes C > bjam.exe!file_archscan(char * archive=0x02fd82c0, void (void *, char *, int, long)* func=0x00412400, void * closure=0x00500458) Line 266 + 0x36 bytes C bjam.exe!timestamp(char * target=0x02fd86e0, long * time=0x0097ab8c) Line 164 + 0x15 bytes C bjam.exe!search(char * target=0x00b3247c, long * time=0x0097ab8c, char * * another_target=0x00000000) Line 130 + 0xd bytes C bjam.exe!bind_explicitly_located_target(void * xtarget=0x0097ab64, void * data=0x00000000) Line 165 + 0x14 bytes C bjam.exe!hashenumerate(hash * hp=0x004ffd08, void (void *, void *)* f=0x0040f9d0, void * data=0x00000000) Line 251 + 0xe bytes C bjam.exe!bind_explicitly_located_targets() Line 176 + 0x12 bytes C bjam.exe!make(int n_targets=1, const char * * targets=0x0012f6bc, int anyhow=0) Line 128 C bjam.exe!main(int argc=0, char * * argv=0x003213c0, char * * arg_environ=0x00321470) Line 434 + 0x15 bytes C Here's a memory dump of the variable "name"...note the two \n\n near the end (just before the FD FD FD FD) and NO trailing '\0' to stop the strlen() 0x02FD9EA8 65 78 65 63 75 74 69 6f 6e 5f 6d 6f 6e 69 74 6f execution_monito 0x02FD9EB8 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 r.obj/.unit_test 0x02FD9EC8 5f 70 61 72 61 6d 65 74 65 72 73 2e 6f 62 6a 2f _parameters.obj/ 0x02FD9ED8 0a 75 6e 69 74 5f 74 65 73 74 5f 6c 6f 67 2e 6f .unit_test_log.o 0x02FD9EE8 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 5f 6d 6f bj/.unit_test_mo 0x02FD9EF8 6e 69 74 6f 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f nitor.obj/.unit_ 0x02FD9F08 74 65 73 74 5f 72 65 73 75 6c 74 2e 6f 62 6a 2f test_result.obj/ 0x02FD9F18 0a 75 6e 69 74 5f 74 65 73 74 5f 73 75 69 74 65 .unit_test_suite 0x02FD9F28 2e 6f 62 6a 2f 0a 73 75 70 70 6c 69 65 64 5f 6c .obj/.supplied_l 0x02FD9F38 6f 67 5f 66 6f 72 6d 61 74 74 65 72 73 2e 6f 62 og_formatters.ob 0x02FD9F48 6a 2f 0a 0a fd fd fd fd 80 00 1a 00 dd 00 dd 06 j/..ýýýý...Ý.Ý. 0x02FD9F58 d8 f6 fd 02 78 01 32 00 dd dd dd dd dd dd dd dd Øöý.x.2.ÝÝÝÝÝÝÝÝ Further debug information available upon request. It would be nice to get the mingw tests back in my testing...this system has a fair chunk of free time right now. Oh, as for the white space in the report? I have NO idea were to even start looking. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 6

GUI Windowing Framework in C++
by Reece Dunn 28 Sep '04

28 Sep '04

A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework: [1] Support constructor-based window creation, e.g.: frame.add( new gui::button( "Boost!" )); The justification for this is that I find using an OnCreate + Create style for creating windows (MFC and WTL) or similar is too complex: the above method for creating a component is 1 line compared to many lines in other frameworks. For the record, I have a basic version of the above implemented in Windows where the add function changes the parent of the child component. This would make it easy to implement advanced GUI like docking controls. [2] Support for lightweight components: components that do not use native window handles. This will allow for advanced facilities like layout managers. The infrastructure should be such that using native and lightweight components is transparent. Component positioning should be allowed to be set explicitly (absolute position - using the units library?) or set using layout managers. There should be wrapping, clipping and stretching position schemes for the various layout managers. [3] The event manager should be platform independent, flexible and extensible. That is to say, if you are using Windows, you should be able to register a handler for a Windows-specific message. In general, the library should match system messages to an independent version wherever possible. It should also support message reflection where a message for a component is handled by a different window or object (e.g. responding to a close message on an application object). When an event is handled, the handler should inform the manager how to process the event: (1) the event has been handled (e.g. focus events); (2) the event was not handled - try the next handler; (3) the event was handled, but processing should continue (e.g. draw events) There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects? If so, this would increase the size of each component. Also, what if you want a "handle all events" handler. (2) if generic events are defined in an 'event' object, and a handler function has the form: event_handled_type eventfn( const event & e ); what if you want to support: event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke ); Regards, Reece

6 13

Re: [boost] [uBLAS] Linux regressions
by Michael Stevens 28 Sep '04

28 Sep '04

On Monday 27 September 2004 15:25, Martin Wille wrote: > Possibly stale results. I'll remove all ublas results > before the next run. Martin thanks for responding to this. I have been watching the results for a while. I just looked at todays results and there are still errors. Last week I intentionally add some blank lines into some source files to change the line numbers in runtime asserts. Todays results are still showing the old line numbers. Since you removed old ublas results before the test I suspect there must be some problem with your CVS updates. I have double checked and Boost CVS has the new file versions. For example boost/numeric/ublas/vector_assign.hpp should be labeled: Revision 1.25 Fri Sep 24 06:31:48 2004 UTC (4 days, 1 hour ago) by mistevens Thanks and good luck, Michael

2 2

[uBLAS] Linux regressions
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

uBLAS "test2" currently fails with most of Linux toolsets, and it used to pass in the previous release -- http://tinyurl.com/3vmlv. Does anybody has any idea what's up here? -- Aleksey Gurtovoy MetaCommunications Engineering

2 3

serialization: buffers
by Darren Cook 28 Sep '04

28 Sep '04

I've a class like this: class Example{ int str[BSize]; int *p; }; Where p points to next available element (p==str+BSize is possible when it is full). I.e. str is like begin() and p is like end(). I want to add a serialize() function, something like this: template<class Archive> void serialize(Archive &ar,const unsigned int){ ar & BOOST_SERIALIZATION_NVP(buf,p); } but there seems to be no support for buffers like this? For the moment I've implemented using separate load/save functions, where save writes the buffer size and load starts by reading it. While much simpler than the load/save code I'm replacing, the above 1-liner is even more appealing. Darren

1 0

RE: [boost] lexical_cast.hpp:102: error: `wstring' is not a member of `std' ?
by DY, JERRY U (SBCSI) 28 Sep '04

28 Sep '04

Could be related to the following g++ problem. Scheduled to be fixed in gcc 3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005 -Jerry -----Original Message----- From: Rob [mailto:spamrefuse@yahoo.com] Sent: Sunday, September 26, 2004 9:17 PM To: boost(a)lists.boost.org Subject: [boost] lexical_cast.hpp:102: error: `wstring' is not a member of `std' ? Hello, I'm not a boost expert, but I'm using LyX, which has boost (version 1.31.0) included in its source code. I have FreeBSD (4.10) and use gcc 3.4.2. When I compile LyX, I get an error from boost: [...] ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:103: error: template argument 1 is invalid ../../boost/boost/lexical_cast.hpp:103: error: explicit specialization of non-template `<type error>' ../../boost/boost/lexical_cast.hpp:162: error: declaration of `operator>>' as non-function ../../boost/boost/lexical_cast.hpp:162: error: expected `;' before '(' token ../../boost/boost/lexical_cast.hpp:168: error: expected `;' before "private" When I reported this to the LyX list, I was told to forward the problem to the boost list. There may be a problem here with FreeBSD, gcc 3.4.2 and boost. Any idea what is going on here? Thanks, Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

regression results? (where's the beef??)
by Victor A. Wagner Jr. 28 Sep '04

28 Sep '04

Is it just me, or have the regression results not been picked up by metacomm in the past 24 hours? Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 2

Re: immutable string
by Igor Kholodov 28 Sep '04

28 Sep '04

>> Agree, but which name should we used - >> "reverse_const_iterator" >> or "const_reverse_iterator"? >> I thought it was the latter. > >Now I see :) Will fix it. Great, after the fix I will run the same tests with VC 7.1. It is amazing how many strings are const_string-compatible objects! Thanks, Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

[boostbook] link to an enum
by Angus Leeming 27 Sep '04

27 Sep '04

I can define a link to a class with: <classname alt="boost::glob_predicate">glob_predicate</classname> How do I define a link to an enum? It seems that a shorthand notation is missing. Is there a longhand way? Regards, Angus

3 3

[boostbook] mangling of names of generated docs
by Angus Leeming 27 Sep '04

27 Sep '04

I find that if I have a header file "foo_bar.hpp" containing the declaration of a function "foo_bar" (there may be other functions in there too of course), then the generated html docs are: Writing foo_bar.html for refentry(foo_bar) Writing id2767798.html for section(id2767798) foo_bar.html contains the docs for the function whilst id2767798.html contains Header <foo_bar.hpp> namespace boost { namespace child { void foo_bar(std::string const &); } } I can see why this is done, but why not modify the mangling so that id2767798 becomes foo_bar_hpp and id2767798.html becomes foo_bar_hpp.html? Especially since each regeneration of the docs results in a different ID. Regards, Angus

1 0

Re:Re: [boost] Re: FORMAL review of "Output Formatters" - votes needed
by Robert Ramey 27 Sep '04

27 Sep '04

Reece wrote: >Roland Richter wrote: > John Torjo wrote: > >> The dilemma I see is that the outfmt library is somewhere between >> serialization (boost::serialization) and pretty-printing >> (boost::format). IMO, outfmt provides *both* at a basic level in that >> it simply adds streaming operators << and >> to STL containers, >> which, for some reason, are currently missing. What advantages does using the output formatters for output/input have over using the serialization library to do the same thing? Robert Ramey

1 0

[thread] test_read_write_mutex* failures
by Stefan Slapeta 27 Sep '04

27 Sep '04

Hi all, there are some failures at runtime for this testcase which look like this: [...] timed test, sp=0 ../../../libs/thread/test/test_read_write_mutex.cpp(293): error in "test_read_write_mutex": test w1.m_value == 10 failed ../../../libs/thread/test/test_read_write_mutex.cpp(294): error in "test_read_write_mutex": test r1.m_value == -1 failed ../../../libs/thread/test/test_read_write_mutex.cpp(295): error in "test_read_write_mutex": test r2.m_value == 10 failed I didn't investigate too much so far, but something is very strange with this: (1) If I compile this test with bjam using the Intel toolset, it fails (exactly like in the regression results). (2) If I compile this test with bjam using the vc 7.1 toolset, it passes (exactly like in the regression results). Now here comes the interesting part: (3) If I compile this test in the VS IDE using Intel Compiler, it fails, but has a slightly different output from bjam. (4) If I compile this test in the VS IDE using VC, it fails, too (!!), with the same output as above. I've already checked the compiler and linker options that are passed by bjam, there is nothing suspicious. I'll continue my investigations tomorrow, in between any ideas about where these differences could come from are _very_ appreciated! Stefan

3 3

[shared_ptr] Interlocked* - possible bug?
by John Torjo 27 Sep '04

27 Sep '04

Hi Peter, I think there is a bug in your Interlocked* implementation of shared_ptr (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) In atomic_read you have: inline long atomic_read(long volatile const & value) { return value; } I don't believe this is thread-safe. In order to make sure you're receiving the latest value, I assume you could do something like: inline long atomic_read(long volatile & value) { const int IMPOSSIBLE_VALUE = -100; return InterlockedCompareExchange(&value, IMPOSSIBLE_VALUE, IMPOSSIBLE_VALUE); } Am I missing something? Best, John -- John Torjo -- 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.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

4 13

RE: [boost] Python/GCC 3.4.1/Linux failures
by Stefan Seefeld 27 Sep '04

27 Sep '04

> From: Jonathan Brandmeyer [mailto:jbrandmeyer@earthlink.net] > Sent: September 27, 2004 15:55 > > > Just an observation, g++ 3.4.2 (Debian 3.4.2-2) passes > all of the tests. > > > > The tests fail for gcc 3.4.2 here. > > > > Which Python version do you use? > > 2.3.4 (Debian package 2.3.4-12) unfortunately debian has the bad habit to assign its own version numbers, so it could well be that what it refers to as 'gcc 3.4.2' is actually only a prerelease or something. I'v always found this very confusing... FWIW, Stefan

1 0

Unit Test Framework documentation/usage...
by Boost Rookie 27 Sep '04

27 Sep '04

Hello, I've just started to play around with Boost and I thought that I could use the Unit Test Framework, hence I opened up the documentation page at: http://www.boost.org/libs/test/doc/components/unit_test_framework/index.html I found the section I was looking for: Usage. In that part I expected to find information what files are needed to be included and what libraries I have to link against - but not so. What do I have to do to *use* the Unit Test Framework? Thanks in advance!

3 4

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 27 Sep '04

27 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > Alexander Terekhov wrote: > > > John Torjo wrote: > > [...] > > > >>Whenever a thread (other than main) wants to access this window, it > >>will query the weak_pointer. The weak_pointer needs to know the > >>LATEST reference count in order to know if the weak pointer is still > >>valid. Thus, atomic_read that simply returns the value is not > >>enough. However, the weak_ptr doesn't just use atomic_read. If atomic_read returns 0 that means the use count has dropped to 0 [*] and can never increase again, so it must be the latest version. Otherwise weak_ptr makes a second test that is properly protected. So it can never use an old value. [*] I think this is right but I'm not certain that it can't return a 0 that the processor read during creation of an object that uses enable_shared_from_this. Having said all that, I feel the naming of functions may give a false sense of generality and encapsulation when they actually only work in the way they are being used currently. <snip> > Here's my scenario: > (remember - we're talking about: > http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) This is still unaccessible. why don't you mail the code to Alexander and me (or to the list, in case anyone else is interested)? > class test { ... }; > > [thread1] > shared_ptr<test> p1( new test); // refcount = 1 > > ---------------- thread switch Switches between threads running on a single processor can't cause problems here, because the use of "volatile" ensures that the compiler won't reoder access to the use count and the processor will only reorder memory access in a way that is invisible to the code it's running. There might conceivably be problems that occur when multiple threads run concurrently on multiple processors, in which case reordering by one processor can affect another. So I'll ignore the "thread switches". > [thread2] > shared_ptr<test> p2(p1); // refcount = 2 > weak_ptr<test> weak(p2); > p2 = shared_ptr<test>(); // refcount = 1 > > ------------------thread switch > [thread1] > p1 = shared_ptr<test>(); // refcount = 0 - object gets destroyed > ---------------- thread switch > [thread2] > > // here - you need InterlockedCompareExchange > // to realize that refcount is 0 (zero) > shared_ptr<test> p3 = weak.lock(); expired() may read the count as still being 1 and so return false, but I believe the wnd_shared_ptr constructor will catch the fact that the pointer really has expired. Unfortunately I can't yet see the code to confirm this! > Also, see my other post to Peter Dimov. Seen it. Ben.

4 4

[boostbook] doxygen docs for enums
by Angus Leeming 27 Sep '04

27 Sep '04

Next question ;-) I find that boostbook can handle doxygen docs for classes and for functions but it ignores enums totally. That's both enums nested in classes and global enums. Any chance of getting it to add glob_flags.html to the list below? Regards, Angus Writing globbing.user_guide.html for section(globbing.user_guide) Writing bad_glob.html for refentry(bad_glob) Writing glob_iterator.html for refentry(glob_iterator) Writing glob_predicate.html for refentry(glob_predicate) Writing glob_traits.html for refentry(glob_traits) Writing glob.html for refentry(glob) Writing globbing.reference.html for section(globbing.reference) Writing globbing.history_and_acknowledgements.html for section(globbing.history_and_acknowledgements) Writing index.html for chapter(globbing) Writing HTML.manifest namespace boost { /** @brief The boost::glob function accepts a @c glob_flags * argument made up of a bitwise OR of zero or more of the * following symbolic constants. */ enum glob_flags { /** The vanilla, POSIX glob behaviour. */ glob_basic = 0, /** Do not sort the returned pathnames. */ glob_nosort = (1 << 0), /** If no pattern matches, return the original pattern. */ glob_nocheck = (1 << 1), /** Characters (including meta chars) cannot be quoted by backslashes. */ glob_noescape = (1 << 2), /** csh-style brace expressions {foo,bar} are expanded. * The glob will match either alternative. */ glob_brace = (1 << 3), /** Only directories are matched. */ glob_onlydir = (1 << 4) }; } // namespace boost

2 3

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>reverse_iterator and reverse_const_iterator actually >refer the same type: > > typedef char_type const* iterator; > typedef char_type const* const_iterator; > typedef std::reverse_iterator<iterator> >reverse_iterator; > typedef std::reverse_iterator<const_iterator> >reverse_const_iterator; Agree, but which name should we used - "reverse_const_iterator" or "const_reverse_iterator"? I thought it was the latter. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

Re:[boost] Re:[serialization] scoped_ptr.hpp broken
by Robert Ramey 27 Sep '04

27 Sep '04

Vladimir wrote: >I think the docs are a bit unclear: Well, I guess that's no surprise as the whole question is still not totally clear to me. >What's the meaning of 'dependent' type? Do you mean 'dependent in context >of 'serialize'? Then, if I write: > template<class Archive> > inline void serialize( > Archive & ar, > my_class & t, > const unsigned long int file_version) {} >then the type to be serialized is never dependent type. Or do you refer to >a case where 'serialize' is templated on saved type? I'd suggest that you >write that explicitly, as "dependent type" is a bit vague. >From Vandervoorde and Josuttis book "C++ Templates - A Complete Guide" page 119 I quote: "A name is a dependent name if it depends in some way on a template parameter. For example, std::vector<T>::iterator is a dependent name if T is a template parameter but it is a nondependent name if T is a known typedef (for example, of int)." That is the definition I'm using for "dependant type" >> Before this change, there is a problem with compilers which implement >> two-phase lookup. Overrides for templates have to be defined before their >> usage in another template. >It would be great if you could put the explanation to the docs. I'll try to expand on this a little. >BTW, I start >to wonder if two-phase lookup does any good, for all additional portability >problems that it has. I've "wondered" about that as well. I brought this up before and the rationale was explained to me but I was left unsatisfied. I have to say this is the kind of thing that raises doubts in my mind about the applicability of C++ for programming jobs assigned to people who can't justify the rigorous parsing of the standard and extremely subtle compiler variations. That is - the rest of us. >> This conflicted with the implementation of >> BOOST_CLASS_EXPORT. To support these compilers, I had to either put >> non-intrusive serialization functions in the same namespace as the type >> being serialized or re-organize export. The latter is non-trivial and >> couldn't be guaranteed to be ready in time for release (at least at the >> time the issue came up). >Is the issue really with BOOST_CLASS_EXPORT? It seems that on compilers >with two-phase lookup, if 'save' overloads are in boost::serialization, >they must be seen before any code which uses 'save'. And this requirement >is not specific to BOOST_CLASS_EXPORT. And also, btw, the table says >boost::serialization is suitable for 'save' overload if compiler supports >ADL, two-phase lookup and type is dependent. Why is it so? Damn - now I have to figure it out all over again. I honestly don't remember. I believe I concluded that the problem could be addressed by requiring all the serialization headers be specified before all the archive headers, but that THAT conflicted with the implementation of export which required the opposite. It turned out invoking serialization without namespace qualification delayed lookup until instantiation and that resolved the solution. My current thinking is that I should re-implement export so that all serializations can be required to be before inclusion of all archive headers. Then serializations could be in any of the following namespace (on conforming compilers: Boost::serialization The namespace of T The namespace of Archive And that section of the manual could be eliminated. Robert Ramey

1 0

FORMAL review of "Output Formatters" - votes needed
by John Torjo 27 Sep '04

27 Sep '04

Dear boosters, There's been quite a hot debate about "Output Formatters" library. Reece has provided some input facilies in this library as well. This has drawn people to either sides: some don't want these input facilities, while others do. To conclude, I would like to ask you to vote: - "Yes" - in favor of Input facilities - "No" - don't want Input facilities. My personal vote is "No". Please share your own. Best, John Review Manager -- John Torjo -- 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.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

8 12

cvs wedged?
by Neal D. Becker 27 Sep '04

27 Sep '04

Been saying this for a while now: cvs update: [15:53:19] waiting for david_abrahams's lock in /cvsroot/boost/boost/libs/numeric/ublas/test4

2 1

Re: [Test] Current failures
by Gennadiy Rozental 27 Sep '04

27 Sep '04

"Jonathan Wakely" <cow(a)compsoc.man.ac.uk> wrote in message news:20040923120115.GA88617@compsoc.man.ac.uk... > On Thu, Sep 23, 2004 at 06:22:58AM -0500, Aleksey Gurtovoy wrote: > > > Gennadiy, > > > > Could you please take a look at/comment on the current Boost.Test > > failures as per http://tinyurl.com/5wojs? > > Attached patch fixes the failures. > > jon Thanx, Jonathan. I forgot about this one. Will fix today. Regards, Gennadiy.

2 2

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 27 Sep '04

27 Sep '04

Hi again Volodya, after thinking this over I'm not so sure the mpl::deref thing has anything to do with your problem --still, it'd be good to know whether it has some impact, if you can do the test locally. I'm afraid we're in Alexsey's hands to solve this out. BTW, boost/bind/arg.hpp is deceivingly simple I can't figure out how its inclusion can make a difference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Sábado, Septiembre 25, 2004 3:56 pm Asunto: Re: [boost] [multi_index + mpl + bind] Regression? > Vladimir, I don't have my compiler handy right > now, but I think this is due to an overlook when > doing the adaptation to the new MPL. In particular, > the line 50 in boost/multi_index/detail/node_type.hpp: > > typedef typename IndexSpecifierIterator::type index_specifier; > > should be changed to > > typedef typename mpl::deref<IndexSpecifierIterator>::type > index_specifier; > > (also, the corresponginf #include <boost/mp/defer.hpp> > must be inserted) > Could you please try this locally and report the results? > If the problem is solved, I'll commit something along this > line next Monday. > > I don't know the rationale for having to use deref, since > I thought these two expressions are equivalent, but there > must be some difference, for Alexsey changed some of the > code in multi_index to do that when mergien the new MPL. > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo > > > ----- Mensaje original ----- > De: Vladimir Prus <ghost(a)cs.msu.su> > Fecha: Sábado, Septiembre 25, 2004 2:41 pm > Asunto: [boost] [multi_index + mpl + bind] Regression? > > > > > The attached code, which use the multi_index library, produces > > screens of > > errors from mpl. The STLfilted log is attached too. > > > > Commenting out #include <boost/bind/arg.hpp> makes the error go > > away, as well > > as including it after multi_index. > > > > This happens with: > > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > > > The code used to work some time ago, but I can't give the exact > date.> > > I've tried too look at the problem, but got lost in MPL internals. > > > > - Volodya > > > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 8

[Test or Build?] How to add dummy files and dirs to a test?
by Angus Leeming 27 Sep '04

27 Sep '04

Dear all, I'm putting the finishing touches to a Posix-conformant boost::glob function that I'd like to submit to Boost (assuming there's some interest). However, before I do so, I'd like to get the regression tests running smoothly. Currently my 'test' directory contains: $ ls .oo* foo* foo1bar foo bar foo!bar foo]bar foo*bar foocbar foo.hpp fooabar foo-bar foo?bar foo{bar foo\bar foo.cpp .oobar foo^bar foo,bar foo[bar foo}bar foobbar foo.cxx All 20 of these files have zero size; the idea is to test boost::glob's ability to find matches. However, I'd rather not have them as part of the library. How do I get the test framework to create them for me before running a test? Regards, Angus

4 7

[serialization] documentation for xml archive usage
by Christoph Ludwig 27 Sep '04

27 Sep '04

Hi, I am using the Boost Serialization library with the text archive implementation in my project and it works quite well. Robert did a very good job - thanks! For some reason I am considering switching to the xml archive implementation. However, this triggers a BOOST_STATIC_ASSERT in basic_xml_oarchive<Archive>::save_override<T>(const T&, BOOST_PFTO int). The implementation insists that all serialized types be wrapped in a nvp<T>. I think I understand more or less why this is necessary - the xml archive implementation generates the xml name tags from the information stored in the nvp wrapper. But I couldn't find an explanation in the docs what special steps a user is supposed to take if the data shall be serialized into an xml archive. (The only hint that xml archives need special care that I found was the description of the header file nvp.hpp libs/serialization/doc/headers.html: "To associate a name tag with a serializable object. This is necessary to properly render an xml archive which includes the object name." BTW, this webpage claims nvp.hpp is in boost/archive, but in fact it is in boost/serialization.) Do I need to write ar & nvp<MyMemberType>("my_member_tag", this->my_member); in my serialization functions for every variable I want to (de-)serialize? Can I choose an arbitrary tag for each variable or is it supposed to be consistent for all variables of a specific type? Am I correct to assume that the code will still work if I serialize into a "normal" text archive and the nvp will essentially be ignored? I guess I could find my answers by some trial and error and digging through the test cases. But since I probably won't be the only user looking for this information may I suggest that a section explaining the issues with xml archives be added to the docs before the 1.32 release? Thanks Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

[program_options] cw9.3 failures
by Vladimir Prus 27 Sep '04

27 Sep '04

The current regression test results show two similar failures of program_options on cw9.3 http://tinyurl.com/6ay5m The situation is the following: parsers.hpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&); parsers.cpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>& is, const options_description& desc) { ........ } template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc); And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker. Can anybody sched the light on this? Thanks, Volodya

2 4

Any interest in a boost::glob() function?
by Angus Leeming 27 Sep '04

27 Sep '04

Dear all, I've taken Richard Johnson's glob_iterator that he posted to the list back in January and re-written it completely, using Boost.Spirit to transform the input 'glob' into an equivalent regex. The result is a 'boost::glob' function that I believe is fully POSIX-conformant. Example usage: fs::path const starting_directory("."); std::list<fs::path> const matches = boost::glob("../te?t/foo*bar", starting_directory); The docs can be browsed online at http://www.devel.lyx.org/~leeming/globbing/index.html The library can be found at http://www.devel.lyx.org/~leeming/globbing.zip It should unzip to give: boost/glob.hpp boost/detail/glob.hpp libs/glob + ensuing sub directories and files. The code has been tested on Linux (g++ 3.3.2) and on Windows using MinGW/MinSys. There are still some "issues" that I don't know how to resolve. Any pointers would be most welcome: REGEX ===== A single test "foo[[:alpha:]]bar" is failing under Windows. It succeeds under Linux. Is there anything about Boost.Regex with MinGW/MinSys that I should be aware of? DOCS ==== * It would be nice to insert a table inside an itemized list item, but quickbook doesn't like doing that. Instead I must add the table in a separate paragraph which messes up the look a little. * boostbook/doxygen fails to document the glob_flags enum. * I generate a BOOST_LIB_NAME.html page and would like to supress it. * The bottom of the first page has this "Last revised: September 13, 2004 at 04:56:20 GMT" I don't know where it comes from, but it's just not true ;-) BUILD ===== I have a couple of targets, lib/glob/example/real_glob.cpp and lib/glob/test/test_real_glob.cpp that I'd like to build only on POSIX machines. (They're wrappers for the system glob function.) Any pointers on how to instruct bjam to do that? Regards, Angus

1 0

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>> Any plans in the future >> to add reverse iterator support to const_string? >> I wrote some code to work around the absence >> of const_reverse_iterator, rbegin(), and rend(), >> all of which would be nice to have available. > >They are there. Sorry, I meant to say that existing versions of rbegin() and rend() inside const_string template class return reverse_iterator, not const_reverse_iterator. There is a typedef for "reverse_const_iterator", but it is not used by any member functions. At the same time, std::basic_string<> provides const_reverse_iterator, just like all other sequence containers. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

RE: [boost] Name checking in filesystem
by Ben Hutchings 27 Sep '04

27 Sep '04

Walter Landry <wlandry(a)ucsd.edu> wrote: > I have come across an annoying problem with the filesystem library. I > have wrapped filesystem with Swig so that I can call it from python. <snip> Er... why? Aside from the name portability checking, I think everything in Boost.Filesystem is already available in the Python standard library. Ben.

2 1

[mpl] bad interaction with Boost.Bind
by Joaquín Mª López Muñoz 27 Sep '04

27 Sep '04

This is a distilled form of the problem Vladimir found in http://tinyurl.com/3zsha The attached snippet fails with the latest CVS image in GCC 3.2 (see err.out). If I comment the first line #include <boost/bind/arg.hpp> // comment to get it working the snippet works OK. Also, the code works fine for Boost 1.31, (by previously replacing reverse_iter_fold with iter_fold_backward, of course) regardless of wether I comment or not the first line. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo foo.cpp: In instantiation of `f1::apply<mpl_::_2, mpl_::_1>': /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp:205: instantiated from `boost::mpl::apply_wrap2<f1, mpl_::_2, mpl_::_1>' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp:205: instantiated from `boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>::apply<int, boost::mpl::v_iter<f3, 3>, mpl_::na, mpl_::na, mpl_::na>' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply_wrap2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >' /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: instantiated from `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >' foo.cpp:23: instantiated from here foo.cpp:11: no type named `type' in `struct mpl_::_2' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp: In instantiation of `boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>::apply<int, boost::mpl::v_iter<f3, 3>, mpl_::na, mpl_::na, mpl_::na>': /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply_wrap2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >' /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: instantiated from `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >' foo.cpp:23: instantiated from here /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp:205: no type named `type' in `struct boost::mpl::apply_wrap2<f1, mpl_::_2, mpl_::_1> ' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp: In instantiation of `boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >': /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: instantiated from `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >' foo.cpp:23: instantiated from here /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:141: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:142: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:143: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:146: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp: In instantiation of `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >': foo.cpp:23: instantiated from here /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: no type named ` state' in `struct boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >' foo.cpp:23: syntax error before `;' token foo.cpp: In function `int main()': foo.cpp:27: `f4' undeclared (first use this function) foo.cpp:27: (Each undeclared identifier is reported only once for each function it appears in.) foo.cpp:27: parse error before `;' token

2 2

RE: [boost] Re: Re: Constrained genericity at last? (anyinterestinanoperator traits/concept traits library?)
by Ben Hutchings 27 Sep '04

27 Sep '04

Matt Hurd <matt.hurd(a)gmail.com> wrote: > Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: > > I don't see the safety issue and what you showed is incorrect; > > a + (b-a) / 2 is at least correct, but b-a overflows just as readily > > as a+b > > oops, for sure, b-a rather. > > I'm missing some understanding, given that b >= a, why is b-a just as > ready to overflow as a+b? I guess you are saying b - a > 2GB > (typical ptrdiff_t) is just as likely as an overflow from a + b, if > it was legal, on a common 32 bit platform for example, or have I > misunderstood? For any two pointers a, b into the same array, b - a is well-defined, so a + (b - a) / 2 is as well. (So if ptrdiff_t has n value bits, arrays must have fewer than 2^(n-1) elements.) If a and b don't point into the same array, b - a is undefined. I don't see any basis for Victor's statement that "b-a overflows". Given the way pointers are commonly represented, adding them is likely to result in overflow very often unless one uses extra bits in the representation of pointer sums. This is not a problem if one sticks to modulo arithmetic, but it is if one wants to do division. Ben.

1 0

Boost License Permission
by Samuel Krempp 27 Sep '04

27 Sep '04

I Samuel Krempp, give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. I thus add my name to more/blanket_permission.txt. -- Samuel Krempp

2 1

[build] doxygen and predefined macros
by Angus Leeming 27 Sep '04

27 Sep '04

My header file defines two macros, BOOST_LIB_NAME and BOOST_GLOB_DECL. I don't want either to be documented, but find that I can pass only one PREDEFINED variable to doxygen through Jamfile.v2. Multiple PREDEFINED lines don't work. Is ther a way to pass more than one variable on a single line? Regards, Angus import toolset ; toolset.using doxygen ; doxygen autodoc : ../../../boost/glob.hpp : <doxygen:param>EXTRACT_ALL=YES <doxygen:param>EXTRACT_PRIVATE=NO <doxygen:param>HIDE_UNDOC_MEMBERS=YES <doxygen:param>ENABLE_PREPROCESSING=YES <doxygen:param>MACRO_EXPANSION=YES <doxygen:param>EXPAND_ONLY_PREDEF=YES <doxygen:param>PREDEFINED=BOOST_GLOB_DECL <doxygen:param>SEARCH_INCLUDES=YES ; boostbook glob : glob.qbk.xml : <xsl:param>boost.root=../../../.. <xsl:param>toc.max.depth=3 <xsl:param>toc.section.depth=3 <xsl:param>chunk.section.depth=3 ;

1 0

Where are they now? (needed license permissions)
by John Maddock 27 Sep '04

27 Sep '04

Here are the people we still need to contact, in order to move the rest of Boost over to the BSL, if anyone has a more up to date email address for these folks than the ones shown here, please let me know, as at present they're not responding :-( Cadenza New Zealand Ltd mark.rodgers(a)cadenza.co.nz David Moore dmoore(a)viefinancial.com François Faure francois(a)cg.tuwien.ac.at Gennadiy Rozental ?? Guillaume Melquiond guillaume.melquiond(a)ens-lyon.fr Jaap Suter j.suter(a)student.utwente.nl Joerg Walter jhr.walter(a)t-online.de Mathias Koch ?? Joaquín M López Muñoz joaquin(a)tid.es Paul Moore ?? Ronald Garcia garcia(a)cs.indiana.edu Samuel Krempp krempp(a)crans.ens-cachan.fr Stephen Cleary scleary(a)jerviswebb.com Stephen Silver ?? Terje Slettebø tslettebo(a)chello.no Thomas Becker tmbecker1(a)yahoo.com William E Kempf ?? iMAGIS-GRAVIR UJF co François Faure francois(a)cg.tuwien.ac.at Francois.Faure(a)imag.fr uBLAS developers ?? Thanks! John.

2 1

explicit-failures-markup.xml invalid
by Stefan Slapeta 27 Sep '04

27 Sep '04

Currently all expected failures are not considered in the summary because explicit-failures-markup.xml was invalid. I've fixed the file now (...and hope there will soon be a fixed table, too :) ). Stefan

2 1

mingw-3.4.2 release candidate and regression tests
by Bronek Kozicki 27 Sep '04

27 Sep '04

Hello I'm going to upgrade testing environment from mingw-3.4.1 to mingw-3.4.2 release candidate (I will keep running tests on mingw-3.3.1 with toolset mingw, as it is now). I'm also going to upgrade mingw-runtime to version 3.5 and w32api to version 3.1. This might of course change results of regression tests I'm running, but I believe that these results will be closer to release version of mingw 3.4.2, when it's finally released. Any objections, opinions or advices about this move? B.

2 3

lexical_cast.hpp:102: error: `wstring' is not a member of `std' ?
by Rob 27 Sep '04

27 Sep '04

Hello, I'm not a boost expert, but I'm using LyX, which has boost (version 1.31.0) included in its source code. I have FreeBSD (4.10) and use gcc 3.4.2. When I compile LyX, I get an error from boost: [...] ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:103: error: template argument 1 is invalid ../../boost/boost/lexical_cast.hpp:103: error: explicit specialization of non-template `<type error>' ../../boost/boost/lexical_cast.hpp:162: error: declaration of `operator>>' as non-function ../../boost/boost/lexical_cast.hpp:162: error: expected `;' before '(' token ../../boost/boost/lexical_cast.hpp:168: error: expected `;' before "private" When I reported this to the LyX list, I was told to forward the problem to the boost list. There may be a problem here with FreeBSD, gcc 3.4.2 and boost. Any idea what is going on here? Thanks, Rob.

2 1

dynamic_bitset taking a buffer...
by Boost Rookie 27 Sep '04

27 Sep '04

Hi, I've just started playing around with Boost. I have a specific need which I hope dynamic_bitset can fulfill. I'd like to have a dynamically sized bitbuffer which is initialized with a data stream of bits (this should be quite efficient). Then I'd like to extract the bits from that bitbuffer as specified in a protocol, e.g. bit 0-3 : version bit 4-5 : whatever bit 6 : ack bit 7-9 : whatever and so on... So something like this is what I think should be possible to do: // Note: Original code simplified to examplify... // Read DATALEN bytes from socket char buffer[DATALEN]; int read_bytes = read(socket,buffer,DATALEN); // Init a bit buffer (efficiently) boost::dynamic_bitset<unsigned char> bitbuf(buffer,read_bytes); // Extract different data, as specified by the communication protocol int version = bitbuf.get(0,4); // Extract 4 bits starting at position 0 int whatever = bitbuf.get(4,2); // Extract 2 bits starting at position 4 bool ack = bitbuf.get(6,1) // Extract 1 bit at the 6th position and so on... Reading docs at http://www.boost.org/libs/dynamic_bitset/dynamic_bitset.html shows that my shot at using dynamic_bitset is totally wrong! I cannot construct the bitbuf in that way. Instead, I should specify something called Block/BlockInputIterator as a template parameter? I do not know what that is. Looking at the examples at that page doesn't help either. Only different intergers are stored in the dynamic_bitset... It seems that a string of 1's and 0's can be stored but I really do not want to convert my original data buffer into a std::string and then convert that into a bitbuffer. After construction I do not see how to extract the bits!? Is it only possible to extract one bit at a time?!?!? Is dynamic_bitset designed to handle problems like this or am I trying to do something that is not possible? If dynamic_bitset can't help, is there something else in boost or elsewhere that is designed to solve problems like this? Thanks in advance!

1 1

true64 and Irix tests out of date?
by John Maddock 27 Sep '04

27 Sep '04

I committed a bunch of fixes for issues such as http://tinyurl.com/6s2go and http://tinyurl.com/3smk3 on Monday, but the latest regression test runs (dated Wednesday), are still showing the same errors - in fact they are showing errors for code that no longer exists, so I know that there's something up with the test runs :-) Anyone any idea what's going on, we haven't branched for release yet have we? Thanks, John.

3 3

[BGL] bfs and boost::ref
by Vladimir Prus 27 Sep '04

27 Sep '04

At the moment, it's not possible to pass the object returned by boost::ref as visitor to the breadth_first_search function. So, if visitor has state, I need to hold that state by pointer, which is inconvenient. Any opinions on the attached patch? Unless there are any objections, I'll commit it after we branch for release. - Volodya

2 2

Re:[boost] [serialization] scoped_ptr.hpp broken
by Robert Ramey 27 Sep '04

27 Sep '04

Vladimir wrote: > ......./boost/boost/serialization/scoped_ptr.hpp:36: error: `make_nvp' > undeclared (first use this function) >The attached patch fixes the problem. >BTW, Robert, this problem was introduce when you moved the content of the >header from boost::serialization to just boost::. What was the rationale? >The log only says: > fixes for cw/comeau implement ADL This was changed in order to function with compilers that implement two-phase lookup. This is described (somewhat) in them manual under the section:Reference/Class Serialization/Free Functions/Namespaces for Free Function Overrides Before this change, there is a problem with compilers which implement two-phase lookup. Overrides for templates have to be defined before their usage in another template. This conflicted with the implementation of BOOST_CLASS_EXPORT. To support these compilers, I had to either put non-intrusive serialization functions in the same namespace as the type being serialized or re-organize export. The latter is non-trivial and couldn't be guaranteed to be ready in time for release (at least at the time the issue came up). Perhaps, export may someday get re-organized so that BOOST_CLASS_EXPORT can appear before the archive classes which would resolve the problem in a simpler way. But for now - that's the way it is. Robert Ramey

2 1

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>>> Igor Kholodov <C.JUMP(a)prodigy.net> wrote: >>> >>>> I am testing immutable string outside boost, using >> it >>>> as string type with common text transformation >> library >>>> (http://cttl.sourceforge.net/) It works quite well, >>>> about 18% speed is gained while parsing large XML >>>> documents (>1MB) when using const_string. >>> >>> Could you please specify the compiler and STL >> implementation you use? >>> >> >> Tested with GCC 3.4.1 (mingw) and GCC 3.2.3 on linux. > >Then, I think, the results are very good because GNU ISO >C++ implementation of std::basic_string<> uses representation sharing with >reference counting, which is the same thing that const_string<> does. The >only difference between the std::basic_string<> and const_string<> is that >the latter one uses small string optimization, and, I think, this is what >makes it look better. > Glad if this helps. Any plans in the future to add reverse iterator support to const_string? I wrote some code to work around the absence of const_reverse_iterator, rbegin(), and rend(), all of which would be nice to have available. Regards, Igor Kholodov http://cttl.sourceforge.net/

2 1

program_options - required (or min/max) number of occurences declaratively?
by Jonathan Graehl 27 Sep '04

27 Sep '04

I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options. I know it's possible to do variables_map::count("option-name") or if I have an impossible default value bound to an option, I could check for that (default would = option absence), but it might be nice to have "requiredness" be a declared option trait, that could show up in the option description. value<int>(&myoption)->required() or something like that - obviously min/max wouldn't make sense for scalars (I have no use for min/max personally). -Jonathan p.s. I know there is a concept in the command line parser of "value required or not" - I'm talking about an *option* being required.

4 4

Re: immutable string
by Igor Kholodov 26 Sep '04

26 Sep '04

>Igor Kholodov <C.JUMP(a)prodigy.net> wrote: > >> I am testing immutable string outside boost, using it >> as string type with common text transformation library >> (http://cttl.sourceforge.net/) It works quite well, >> about 18% speed is gained while parsing large XML >> documents (>1MB) when using const_string. > >Could you please specify the compiler and STL implementation you use? > Tested with GCC 3.4.1 (mingw) and GCC 3.2.3 on linux. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/ Igor Kholodov http://cttl.sourceforge.net/

2 1

RSI/cw-8.3 results
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Rene, Since you are testing with a quite different configuration than ours, could you please adjust the name of your toolset somehow so that we have the ability to mark up the failures specific to your setup? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

CW 9.3 results (or lack thereof) - current state
by Stefan Slapeta 26 Sep '04

26 Sep '04

After one day and one night of investigation, I think (!) I've finally managed to make bjam report correct results for my regressions. As it seems, the solution is not calling cv_env.bat before running the test. This batch file is also called again before each test case and it seems that the environment gets somewhat confused then: during the execution of the cmd file the errorlevel is still set to 0 after the test case has been executed although the test case definitely reported something different. What I know for sure is that this problem occurs independent of the OS and the machine (see the temporary 'slapeta_experimental' results) and whether the test is started by regression.py or not. The results for CW-9.3 seem to be correct now and thus there should be some more failing test cases for this toolset now. As for my Intel 8.0 results, I hope there are no similar interferences because they don't run without calling iclvars.bat once. I must manually make a testcase fail to verify this (before I fixed the tss cleanup, Intel failed, too, but this wasn't reported, either). That's where I am at the moment. Cheers, Stefan

4 5

Re: [boost] immutable string
by Igor Kholodov 26 Sep '04

26 Sep '04

I am testing immutable string outside boost, using it as string type with common text transformation library (http://cttl.sourceforge.net/) It works quite well, about 18% speed is gained while parsing large XML documents (>1MB) when using const_string. I would like to point out a couple of issues: First, there seems to be a typo in implementation of const_string& append(char_t c, size_t n). It should use a comma instead of dot when calling corresponding constructor of const_string. See const_string.hpp, line 444. Second, a lack of length() member function. Thanks, Igor Kholodov cttl(a)users.sourceforge.net --- Original Message --- From: "Maxim Yegorushkin" <e-maxim(a)yandex.ru> To: boost(a)lists.boost.org Subject: [boost] immutable string >Hello all, > >I've been working on a small library - an immutable C++ string. Now it is >in usable state and has been put in use in a couple of real projects. >Although it needs further polishing, I would like to know is there any >interest in such a library? > >Here is the link: http://conststring.sourceforge.net/ > >-- >Maxim Yegorushkin > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Igor Kholodov http://cttl.sourceforge.net/

2 2

Re: [boost] [Pointer Containers] [Indexed Set]
by JOAQUIN LOPEZ MU?Z 26 Sep '04

26 Sep '04

Hi Bruno, ----- Mensaje original ----- De: Bruno Martínez Aguerre <br1(a)internet.com.uy> Fecha: Viernes, Septiembre 24, 2004 10:44 pm Asunto: [boost] [Pointer Containers] [Indexed Set] > Hi. > > I was wondering if these two libs work together. That is, can > Indexed > Sets take ownership of my pointers? (First of all, the lib was renamed to Boost.MultiIndex.) Indexed containers are no different to STL containers in this respect: you can control ownership issues with some smart pointer, for instance boost::shared_ptr, so that objects pointed to get deleted along with the container. Apart from this, no special provision has been made to work with pointers. Ownership management aside, I'd say one of the key features of Thorsten's pointer containers is that their interface automatically dereference the pointers held so as to create the illusion that it is the actual elements that are being stored in the container. This feature is not supported by Boost.MultiIndex, and I don't think both libs can be used together to implement this artifact. To get something close to that, you can put a "view" on top of a multi_index_container of pointers and get dereferencing access. There are some view libraries out there. > > Also, I couldn't find the docs for neither of the two libs. I > looked here > http://www.boost.org/regression-logs/cs- > win32_metacomm/doc/html/libraries.html > for Indexed Set, The lib was renamed to Boost.MultiIndex, and will ship with Boost 1.32. In the meantime you can consult the docs at www.boost-consulting.com/boost/libs/multi_index > and here > http://boost-consulting.com/boost/more/formal_review_schedule.html > for > Pointer Containers. This Thorsten already anwered. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

** releasing **
by David Abrahams 26 Sep '04

26 Sep '04

Hi Everyone, This is just a reminder that we are trying very hard to get to a release point. Aleksey has been making an incredible effort in managing this release, so please do everything in your power to be responsive to his requests. Being proactive is even better, so if you can, see if there are any regressions you can fix. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 3

BOOST_STATIC_ASSERT and gcc 3.3
by Mark Purtill 26 Sep '04

26 Sep '04

BOOST_STATIC_ASSERT doesn't produce a useful error message with gcc 3.3. E.g.: #include <boost/static_assert.hpp> BOOST_STATIC_ASSERT(0); produces % g++ -c -o bsa.o bsa.cpp bsa.cpp:3: error: invalid application of `sizeof' to an incomplete type According to <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15337>, this is fixed, but some of use will still be using gcc 3.3 for a while. It turns out the version of BOOST_STATIC_ASSERT used when BOOST_INTEL_CXX_VERSION is defined works for the offending versions of gcc, too: #include <boost/static_assert.hpp> # define BOOST_STATIC_ASSERT_1( B ) \ typedef char BOOST_JOIN(boost_static_assert_typedef_, __LINE__) \ [ ::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >::value ] BOOST_STATIC_ASSERT_1(0); produces % g++ -c -o bsa.o bsa.cpp bsa.cpp:6: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' Could that version be used for gcc 3.3 and 3.4.0 in the upcoming boost 1.32? FYI: % gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions--enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib --enable-__cxa_atexit --enable-clocale=generic Thread model: posix gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) -- ^.-.^ Mark Purtill (("))

2 1

mpl::equal_to changes
by Ian McCulloch 26 Sep '04

26 Sep '04

Hi, Is the following program supposed to compile with the new MPL? It works fine with boost 1.31, but apparantly fails in CVS. But, maybe I was mis-using equal_to ? #include <boost/mpl/equal_to.hpp> #include <boost/mpl/bool.hpp> int main() { boost::mpl::equal_to<boost::mpl::bool_<true>, boost::mpl::bool_<true> > dummy; } Error message from CVS is: (thanks to Matthias Troyer for testing it) ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp: In instantiation of `boost::mpl::equal_to_tag<mpl_::bool_< true> >': ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:72: instantiated from `boost::mpl::equal_to<mpl_::bool_< true>, mpl_::bool_< true> >' test.C:11: instantiated from here ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:60: error: no type named `tag' in `struct mpl_::bool_< true>' ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp: In instantiation of `boost::mpl::equal_to<mpl_::bool_< true>, mpl_::bool_< true> >': test.C:11: instantiated from here ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:72: error: no type named `type' in `struct boost::mpl::equal_to_tag<mpl_::bool_< true> >' Cheers, Ian

4 4

[numeric/conversion] fixes for intel-win32-7.1-vc6
by Joaquín Mª López Muñoz 26 Sep '04

26 Sep '04

These are trivial fixes taking care of BOOST_NO_STDC_NAMESPACE. With them, converter_test and udt_support_test (the latter is currently marked as known fail) work for Intel 7.1. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 33a34 > #if !defined(BOOST_NO_STDC_NAMESPACE) 35a37,38 > #endif > 52a56 > #if !defined(BOOST_NO_STDC_NAMESPACE) 55c59 < --- > #endif 81a86 > #if !defined(BOOST_NO_STDC_NAMESPACE) 82a88,89 > #endif > 97a105 > #if !defined(BOOST_NO_STDC_NAMESPACE) 98a107,108 > #endif > 496a497,498 > > #if !defined(BOOST_NO_STDC_NAMESPACE) 497a500,501 > #endif >

3 5

[Signals] Regressions/crashes on Linux and CodeWarrior
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs) Run output []: /boost/head-regression/boost/boost/test/minimal.hpp(127): exception "signal: memory access violation" caught in function: 'int main(int, char **)' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 Same for CodeWarrior 8.3 on Windows. Could somebody with access to the environment take a look at it, please? -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

[random] intel-win32-8.0 failures
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Could somebody take a look/comment on this one (from http://tinyurl.com/4k3f2) "C:\Programme\Intel\CPP\Compiler80\Ia32\bin\icl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope /Zc:wchar_t /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qansi_alias -D_NATIVE_WCHAR_T_DEFINED /Qvc7.1 -I"C:\boost_regression\results\bin\boost\libs\random\test" -I"C:\Programme\Microsoft Visual Studio .NET 2003\VC7\include" -I"C:\boost_regression\boost" -Fo"C:\boost_regression\results\bin\boost\libs\random\test\random_demo.test\intel-win32-8.0\debug\threading-multi\random_demo.obj" -Tp"C:\boost_regression\boost\libs/random/random_demo.cpp" random_demo.cpp C:\boost_regression\boost\libs/random/random_demo.cpp(122): error: no operator "<<" matches these operands operand types are: std::ofstream << base_generator_type file << generator; ^ compilation aborted for C:\boost_regression\boost\libs/random/random_demo.cpp (code 2) ? It seems like Intel 8.0 for Windows is the only compiler that has this problem (the one for Linux is OK). -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Python again
by Stefan Slapeta 26 Sep '04

26 Sep '04

Anybody an idea what is the reason for the "new" white cells (Intel-win32, cw, vc*)? I can find nothing about these tests in bjam.log but a single line in the list at the beginning boost-test(COMPILE) "python/select_arg_to_python_test" : "libs\python\test\select_arg_to_python_test.cpp" ...so it very much looks like they are not compiled at all! Stefan

3 3

Please, comment design decision of simple FSM
by Alexander Nasonov 25 Sep '04

25 Sep '04

After playing with my overloads library and trying to apply it to FSM I realized that some metaprogramming can be replaced with natural overload resolution rules. After realizing it, I come to conclusion that simple FSM can be implemented as a set of call operators and a list of states. Each call operator represents a transition and follows this pattern: NewState operator()(State,Event) const; Transition functions are generated in process_event function on first call (in a constructor of static variable, for example). Each function extracts current state from StatesAsVariant (boost::variant of all states): template<class StatesAsVariant, class State, class Event> void transition(FSM& fsm, StatesAsVariant states, Event event) { states = fsm( get<State>(states), event); // select best transition // according to overload // resolution rules } The only metaprogramming algorithm is for_each<States> to initialize transition table for the event. Comments? -- Alexander Nasonov

3 13

Re: CW 9.3 results (or lack thereof) - uBLAS fails
by Michael Stevens 25 Sep '04

25 Sep '04

Stefan Slapeta wrote: > I've noticed that once again all ublas test cases threw a gpf in the > last run or CW 9.3. I think I used the latest sources, but at the moment > I've switched back to non-incremental builds and thus we can be sure > tomorrow. I suspect we have some real problem. The failure conditions are interesting. In all cased the first test set which is instantiated with double is successful. Then when instantiated with std::complex<double> the same test fails. Generally this failure is in a swap operation. test4 is however interesting. The first test only constructs two vectors and then destructs them on function return. It also fails with std::complex<double>. So I am suspecting some memory management problem related to complex<double>. If anyone has the time I would to see a call trace at the point of failure. Thanks, Michael

2 1

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 25 Sep '04

25 Sep '04

Vladimir, I don't have my compiler handy right now, but I think this is due to an overlook when doing the adaptation to the new MPL. In particular, the line 50 in boost/multi_index/detail/node_type.hpp: typedef typename IndexSpecifierIterator::type index_specifier; should be changed to typedef typename mpl::deref<IndexSpecifierIterator>::type index_specifier; (also, the corresponginf #include <boost/mp/defer.hpp> must be inserted) Could you please try this locally and report the results? If the problem is solved, I'll commit something along this line next Monday. I don't know the rationale for having to use deref, since I thought these two expressions are equivalent, but there must be some difference, for Alexsey changed some of the code in multi_index to do that when mergien the new MPL. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Vladimir Prus <ghost(a)cs.msu.su> Fecha: Sábado, Septiembre 25, 2004 2:41 pm Asunto: [boost] [multi_index + mpl + bind] Regression? > > The attached code, which use the multi_index library, produces > screens of > errors from mpl. The STLfilted log is attached too. > > Commenting out #include <boost/bind/arg.hpp> makes the error go > away, as well > as including it after multi_index. > > This happens with: > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > The code used to work some time ago, but I can't give the exact date. > > I've tried too look at the problem, but got lost in MPL internals. > > - Volodya > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[multi_index + mpl + bind] Regression?
by Vladimir Prus 25 Sep '04

25 Sep '04

The attached code, which use the multi_index library, produces screens of errors from mpl. The STLfilted log is attached too. Commenting out #include <boost/bind/arg.hpp> makes the error go away, as well as including it after multi_index. This happens with: gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) gcc version 3.4.1 (Debian 3.4.1-4sarge1) The code used to work some time ago, but I can't give the exact date. I've tried too look at the problem, but got lost in MPL internals. - Volodya

1 0

[serialization] scoped_ptr.hpp broken
by Vladimir Prus 25 Sep '04

25 Sep '04

Hello, I'm getting this error: ......./boost/boost/serialization/scoped_ptr.hpp:36: error: `make_nvp' undeclared (first use this function) The attached patch fixes the problem. BTW, Robert, this problem was introduce when you moved the content of the header from boost::serialization to just boost::. What was the rationale? The log only says: fixes for cw/comeau implement ADL - Volodya

1 0

RE: [boost] Re: GUI Windowing Framework in C++
by Brian Braatz 25 Sep '04

25 Sep '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Thomas Witt > Sent: Friday, September 24, 2004 7:21 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI Windowing Framework in C++ > > David Abrahams wrote: > > Reece Dunn <msclrhd(a)hotmail.com> writes: > > > >>[1] Support constructor-based window creation, e.g.: > >> > >> frame.add( new gui::button( "Boost!" )); > > > > > > Get rid of the new operator, though. IMO there's no excuse for a GUI > > framework to expose users to unmanaged resources. > > Hmm, do you know of a C++ GUI framework that gets this right? > > Just curious [Brian Braatz] The problem is handling the "dual lifetimes" of "system" GUI objects and C++ objects. BeOS is the only system I know that does not have this issue, because they extended C++ in such a way so that when you "create" a C++ window object- you now have a window. In frameworks like MFC, they have to internally track a windows resources "object" that the system understands as the gui object. You will always need a dynamic nature to things, but one could take a Rogue Wave approach here and hide all those new's behind accessor type objects which pass around by value and internally hold something like a boost::shared_ptr<> (my 2 cents) Brian

2 1

RE: [boost] C++ GUI - another view
by Reece Dunn 25 Sep '04

25 Sep '04

Andy Little wrote: >Recent discussions on boost have talked about GUI's in quite technical >terms, windowing etc. Another part of the abstraction is simply that of >providing an area for drawing on. The code below is a simple example of >what >I mean. The "drawFunction" is meant to be like a graphics version of a >main() function .( Note that there should ideally be no DeviceHandle >visible >to the "drawFunction". The DeviceHandle should be wrapped in the GX object, >passed to the function so some of the impl is poking through here in form >of >the gx.line_to etc functions 'hdc' argument. Its early days.) Your code looks good, but here are a few comments: [1] The general impression from users of a GUI library is that they are against using a template-based library. [2] The DeviceHandle should be hidden via an interface and have an implementation for *nix, mac, Windows and others. [3] I strongly recommend that the graphical side (devices, pens, brushes, images, fonts, etc.) be separate from the GUI (windows/widgets, events, etc.). The GUI framework will make use of the graphics framework for drawing to a window's client area. [4] I like how you specify independant coordinates. Is this customizable (i.e. can you change between pixels, cm, inches, etc.) and can you convert between coordinate systems (e.g. when implementing a web browser, CSS units can be percentages, cm, pc, pt, etc.)? [5] Can you get the width and height of the drawing rectangle? Is it possible to create a scrolling view of a larger drawing area? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

11 28

Addition for shared_ptr
by Michael Rutman 25 Sep '04

25 Sep '04

I'd like to propose adding a template function to shared_ptr to allow the automatic testing of a shared_ptr to its raw ptr. The template is as simple as template <class T> bool operator==(boost::shared_ptr<T> const & a, T * const & b) { return a.get() == b; } Here is the case where I need it. I have a vector<Foo> myFoo. In a method of Foo I need to see if this instance is in the vector. I want to do this vector<Foo>::iterator iter = find( myFoo.begin(), myFoo.end(), this );

4 9

[Pointer Containers] [Indexed Set]
by Bruno Martínez Aguerre 24 Sep '04

24 Sep '04

Hi. I was wondering if these two libs work together. That is, can Indexed Sets take ownership of my pointers? Also, I couldn't find the docs for neither of the two libs. I looked here http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… for Indexed Set, and here http://boost-consulting.com/boost/more/formal_review_schedule.html for Pointer Containers. I think these two are the best places for it. Bruno Martinez

2 1

Re: CW 9.3 results (or lack thereof) - current state
by Michael Stevens 24 Sep '04

24 Sep '04

Stefan, > After one day and one night of investigation, I think (!) I've finally > managed to make bjam report correct results for my regressions. Your perseverance is much appreciated. > The results for CW-9.3 seem to be correct now and thus there should be > some more failing test cases for this toolset now. I have fixed the compilation problem with uBLAS you reported. So I was looking forward to seeing the results. Now I see the runtime errors so there is still work to be done! Thanks, Michael

2 1

RE: [boost] Re: GUI Windowing Framework in C++
by Ben Hutchings 24 Sep '04

24 Sep '04

Brian Braatz <brianb(a)rmtg.com> wrote: [Thomas Witt wrote:] > > David Abrahams wrote: > > > Reece Dunn <msclrhd(a)hotmail.com> writes: > > > > > >>[1] Support constructor-based window creation, e.g.: > > >> > > >> frame.add( new gui::button( "Boost!" )); > > > > > > > > > Get rid of the new operator, though. IMO there's no excuse for a > > > GUI framework to expose users to unmanaged resources. > > > > Hmm, do you know of a C++ GUI framework that gets this right? > > > > Just curious > [Brian Braatz] > The problem is handling the "dual lifetimes" of "system" GUI objects > and C++ objects. > > BeOS is the only system I know that does not have this issue, because > they extended C++ in such a way so that when you "create" a C++ window > object- you now have a window. Be didn't extend C++; they just decided to use C++ for most of the system APIs rather than providing C APIs and C++ wrappers for them. (A problem with this approach is that it's difficult to preserve binary compatibility in C++ interfaces while extending them; also, language changes have forced ABI changes in some compilers over the past few years.) > In frameworks like MFC, they have to internally track a windows > resources "object" that the system understands as the gui object. Even in BeOS there is some kind of handle underneath, because windows are managed by a separate process called the application server. It seems to me that the annoyance of mismatched lifetimes in MFC is due to its design as a thin wrapper over the Windows API at a time when the language (or at least the MS implementation) did not have exceptions. This resulted in the evils of two-phase construction. Qt seems to have managed to avoid this, despite not using exceptions, by being a more heavyweight wrapper. > You will always need a dynamic nature to things, but one could take a > Rogue Wave approach here and hide all those new's behind accessor type > objects which pass around by value and internally hold > something like a > boost::shared_ptr<> That may well be a good approach.

2 1

Re:Re: [boost] [program_options] cw9.3 failures
by Robert Ramey 24 Sep '04

24 Sep '04

Howard Hinnant wrote: >How are clients (who can view only parsers.hpp) to know that: >template<> > basic_parsed_options<char> > parse_config_file(std::basic_istream<char>& is, > const options_description& desc); >is a function to be imported from a DLL? Does adding to parsers.hpp >something like: >template<> __declspec(dllimport) > basic_parsed_options<char> > parse_config_file(std::basic_istream<char>& is, > const options_description& desc); >help? I believe that most of the failures of the serialization library with toolset are due to similar problems. There we have Template<class T> Struct A : public Abase { A(const char * name){ //register this instance in a global table Register(this, name); } // static instance to be created at pre-runtime Static A instance; do_something(); }; Template<class T> Static A A::instance("T"); So that later when // lookup T Abase *ab = std::find("T") Ab->do_something(); It seems that the compiler optimizes away the code since its never explicitly called. An attempt to find the class through its name fails, the code isn't found, and the test fails. I've attempted to force instantiation of the code through various means such as dllexport and others. This solved the problem for other compilers but I've been unable to get it to work for Metrowerks. Alas my, 15 trial license expired so it will have to remain as it is until someone with an interest in this compiler decides they want to spend some time on this. Robert Ramey

1 0

FORMAL Review of "Output Formatter" library - 2 days left
by John Torjo 24 Sep '04

24 Sep '04

Dear boosters, For the FORMAL Review of "Output Formatter" - there are 2 days left. (it will end on this sunday) Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. 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. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

1 0

RE: [boost] Re: GUI Windowing Framework in C++
by Stefan Seefeld 24 Sep '04

24 Sep '04

> From: Reece Dunn [mailto:msclrhd@hotmail.com] > Sent: September 24, 2004 11:05 > There is also the issue of dynamically creating the GUI. If > you create a > docking/floating toolbar for example, which object stores the > toolbar? > The docked frame or the floating frame? > > Also, what if you have a large number of GUI components? > Storing them in > the frame class would just increase the size of the object to > the point > where it is unusable. > > Also, doing: > > frame.add( gui::button( "Boost!" )); > frame.add( gui::textbox( "Hello", 25, true )); > > would incur copy penalties. What if you want to share the same object > across multiple objects (e.g. the docking/floating frame) instead of > making a separate copy of it. Indeed. This question is much more than a simple matter of convenience. Some toolkits use a 'scene graph' - like approach, where 'outer' widgets wrap ('decorate') inner ones. Following this path further, widgets could be shared by multiple parents, i.e. they could be rendered at multiple positions on the screen (or multiple screens) at the same time. I'v been working on the fresco project (http://www.fresco.org) and there we push it even further: widgets are owned by the 'display server' which applications talk to remotely (fresco is, much as X, network transparent). So the object the application holds is just a proxy that will forward all requests to the display server. Regards, Stefan

1 0

[signals]: Making copies of a slot
by Jody Hagins 24 Sep '04

24 Sep '04

AFICT, the rationale for copying a slot is missing, hence the following questions... boost::signal<void (int)> some_signal; Some_Slot slot1; some_signal.connect(slot1); Some_Slot slot2(slot1); some_signal(42); The above code will only signal slot1. If slot2 is a copy of slot1, should it also get the signal? I know it does not work that way, but I was wondering why that decision was made. Also, if I *do* want the copy to receive the same signals, how can I do so? Thanks!

2 3

RE: [boost] [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 24 Sep '04

24 Sep '04

John Torjo <john.lists(a)torjo.com> wrote; > Hi Peter, > > I think there is a bug in your Interlocked* implementation of > shared_ptr > (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) > > In atomic_read you have: > inline long atomic_read(long volatile const & value) > { > return value; > } > > I don't believe this is thread-safe. > In order to make sure you're receiving the latest value, I don't believe that's actually important. What's important is that shared memory accesses are not reordered. The "volatile" should prevent the compiler from reordering the read with respect to other volatile access, but that leaves the question of whether the processor may reorder the read with respect to other shared memory access. I think the answer is that it cannot change the order of an atomic_read and an atomic update, assuming that the latter uses an Interlocked* operations which includes a full memory barrier, but unfortunately it would be able to change the order of two atomic_reads. (Unfortunately www.pdimov.com does not want to talk to me so I haven't been able to read the rest of the code.) > I assume you could do something like: > > inline long atomic_read(long volatile & value) > { > const int IMPOSSIBLE_VALUE = -100; > return InterlockedCompareExchange(&value, IMPOSSIBLE_VALUE, > IMPOSSIBLE_VALUE); > } > > Am I missing something? That looks reasonable, yet I feel that there should be a better way to do this! Note that InterlockedCompareExchange is not available in early Win32 implementations (NT 3.x and Win95).

2 2

tuples::for_each
by Maxim Yegorushkin 24 Sep '04

24 Sep '04

I was working on some code where I got some parameters as pairs of strings [name, value]. In my code I needed to convert those values to int's, doubles, etc (i.e. deserialize). And I wanted to convert them in bunch. I thought it was a great job for lexical_cast and tuple::tie. The only thing I missed was something like for_each for tuples. Is there going to be such a mechanism? Here is an example: template<class T, class F> inline void for_each(boost::tuples::cons<T, boost::tuples::null_type> const& tuple, F f) { f(tuple.get_head()); } template<class T, class U, class F> inline void for_each(boost::tuples::cons<T, U> const& tuple, F f) { f(tuple.get_head()); for_each(tuple.get_tail(), f); } struct printer { template<class T> void operator()(T& t) const { cout << typeid(t).name() << " (" << t << ")\n"; } }; typedef std::map<std::string, std::string> parameters; struct lexical_caster { parameters const* p; char const* name; template<class T> void operator()(T& t) { parameters::key_type const k(name); parameters::const_iterator i(p->find(k)); if(p->end() == i) throw std::runtime_error("a parameter is not found"); t = boost::lexical_cast<T>(i->second); name += 1 + k.size(); } }; int main() { bool b(1); char c('a'); int i(12345); double d(3.1428); for_each(boost::tie(b, c, i, d), printer()); parameters p; p["bool"] = "0"; p["char"] = "b"; p["int"] = "67890"; p["double"] = "1.6"; lexical_caster l = { &p, "bool\0char\0int\0double\0" }; for_each(boost::tie(b, c, i, d), l); for_each(boost::tie(b, c, i, d), printer()); } -- Maxim Yegorushkin

3 3

test - please ignore
by Peter Dimov 24 Sep '04

24 Sep '04

My mail server is down, and gmane posts I made didn't seem to appear, now trying with the alternate address. Apologies for the wasted bandwidth. -- Peter Dimov http://www.pdimov.com

1 0

[boost.config] mipspro
by Thorsten Ottosen 24 Sep '04

24 Sep '04

Hi, In the range regression I get errors like cc-1282 CC: ERROR File = /txusr/rwgrosse/boost_regression/boost/boost/range/empty.hpp, Line = 38 More than one instance of overloaded function "boost::begin" matches the argument list. Function symbol function template "boost::begin(T &)" is ambiguous by inheritance. Function symbol function template "boost::begin(const T &)" is ambiguous by inheritance. The argument types are: (const std::pair<std::vector<int, std::allocator<int>>::iterator, std::vector<int, std::allocator<int>>::iterator>). return boost::begin( c ) == boost::end( c ); I don't know this compiler, but could it be that it does not configures BOOST_NO_FUNCTION_TEMPLATE_ORDERING properly? (I assume by the error above mipspro should define the macro to 1) If so, can somebody fix it? Thanks Thorsten

3 8

[Thread] TSS + static linking status
by Aleksey Gurtovoy 24 Sep '04

24 Sep '04

What's the status of TSS cleanup issue in static library configuration for the following compilers: CodeWarrior 8.3 MinGW GCC 3.x Borland 5.6.4 Intel C++ 7.1 (for Windows) ? Should the corresponding test's failures (e.g. http://tinyurl.com/6v6sd) be marked as expected? -- Aleksey Gurtovoy MetaCommunications Engineering

4 13

[Thread] Read-write mutex failures with CodeWarrior/Intel 7.1
by Aleksey Gurtovoy 24 Sep '04

24 Sep '04

"test_read_write_mutex" fails with a similar output at run time on CodeWarrior 8.3 and Intel 7.1 (both Windows and Linux): http://tinyurl.com/62dwn, http://tinyurl.com/46dsp http://tinyurl.com/5h66a http://tinyurl.com/7287k Are these expected failures? -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] OutFmt library implementation questions
by Rozental, Gennadiy 24 Sep '04

24 Sep '04

> > > Use the ex< DelimiterType > variant on the innermost construct. > > > >This is unacceptable and does not follow standard practice. > > The new version templates that are templatized on character > type are also templatized on the format object that they use (to render > their elements). You keep repeating that you have some completely reworked version. Well let's see it next time. Then I will be able to comment on it. > > > >7. What deducer is supposed to deduce? I couldn't get > >IMO all that you needed is function overloading. I don't see a place > >for > >all > >these deduce/trats staff. > > Consider the pair format object (pair renderer): how do you > render each pair > type. Using function overloading, you would have: > > class basic_pair > { > public: > OutStream & write( OutStream & os, const std::pair< > T1, T2 > & p ){ > ... } > OutStream & write( OutStream & os, const > boost::compact_pair< T1, > T2 > & p ){ ... } > OutStream & write( OutStream & os, const > std::complex< T > & p ){ > ... } > OutStream & write( OutStream & os, const > boost::math::interval< T > > & p ){ ... } > }; > > But this would add dependencies on those libraries. Also, it is not > extensible: how do you add support for boost::rational< T >, > for instance? I am not sure I understand what you writing here. What I meant is something trivial like this: Template<typename C> ContanerFormatter<C> Foo( C const& ); // this together with ContanerFormatter is defined in pair general header Template<...> PairFormatter<..> Foo( pair<...> const& ); // this together with PairFormatter is defined in pair specific header Template<...> RationalFormatter<..> Foo( pair<...> const& ); // this together with RationalFormatter is defined in boost:: specific header And so on. Why wouldn't it work? > Using the deduction mechanism, I implement the output using > boost::io::detail::getval< n >( pair_type ). Input is more > complex because > you need to distinguish between types that you can get the elements > separately (e.g. std::pair) and types that you need to set > both values > together (e.g. boost::math::rational): the former uses > refval< n >( type ) > and the latter uses assignval( type, first, second ). > > How would function overloading solve this? (Note, function > overloading is > used for getval, refval and assignval). > > For containers, you need to use a different function/function > arguments to > insert an element depending on whether the container is sequential, > associative or a set. If you need to handle input then in addition you would add Template<typename T> VectorFormatter<T> Foo( std::vector<T> const& ); // this together with VectorFormatter is defined in vector specific header > My library provides a description of the types that it can > render (e.g. > separable pairs, 4-ary types, associative containers) without > saying what > these types are. The stl and boost directories in my library > then tell my > library that a std::vector is a sequential container. My > library then knows > how to handle a std::vector. Doing this, I can separate the > dependencies on > external libraries and allow it to be extended to support > other sequential > containers, pairs, etc. I don't see ANY need for all this complex staff when simple overloading/partial ordering will do the trick. > formatob_t::format returns *this because the FormatObject > (Renderer) that it > inherits returns a value of type FormatObject. Thus, if you > didn't have > these overloads, then: > > std::cout << formatob( vec ).format( " + " ); > > would not work, since it will try to output a containerfmt() type. Your code : inline formatob_t & format( format_type s) { FormatObject::format( s ); return( *this ); } formatob( vec ).format( " + " ) has the same type as formatob( vec ) What are you talking about? Why would you bother what FormatObject::format is returning? > Regards, > Reece Gennadiy.

4 5

RE: [boost] Re: Re: C++ GUI - another view
by Brian Braatz 24 Sep '04

24 Sep '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Noah Stein [Brian Braatz] (Snip)_ > > Yes..As I have touched in in a previous post this should be accessible > at > > the 'device layer'. OTOH Another way to look at a pixel is as a > > rectangular > > box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25 > mm > > high or whatever, the next layer up. > > What does "accessible at the device layer" mean in this context? A pixel > is > a fundamental unit in any graphics context. I don't think that an > application programmer should be forced to jump through hoops to get at > it. > [Brian Braatz] I have been watching this one for a bit now and it is time for me to weigh in. I have 2 perspectives to share: ** Encapsulation of common functionality in UI frameworks*** I am working on a framework that sits on top of boost for the purpose of making Thick Client DB apps. One of the things that I am going to be needing is a *light* layer over the various windowing libraries out there. What I need is about 20% of the common functionality between MFC\ Winforms\ Qt\ WxWindows in standard wrapper classes. This will allow me to write "most" of my applications to that interface and select the underlying platform\ framework as a build target. I mention my problem domain, because I believe it to be a rather common one. I also agree with the notion that it takes *alot* of effort to fully encapsulate a GUI. What I would LIKE would be a simple windowing system that I can use, maybe it is not the most robust, but it is "boost standard". This would then allow me to write portable Gui applications. In so far as paradigm, this would mean choosing between the common model features of the above libraries. I will be developing this, and may eventually submit it to boost, but if someone does before me, all the better. I just eventually want something that is "standard" in some way that gives me platform \framework isolation. *** Simple windowing layer needed for Boost ** I would like to also develop some GUI tools that do things like allow one to: * "step through" bjam files interactively \ debug * Show a "report" of my command line configuration outlining what appears to be set correctly (i.e. doxygen will not work in your config because variable XX is not set to a valid path) (maybe even a little cartoon dog that wags his tail if your vars are set properly) (<< JUST KIDDING) I believe simple gui tools along those lines would help the usage and spread of boost in general, and would help those who use boost on a day to day basis. To support that concept- I suggest something along the lines of the TinyXML library buried somewhere in boost. It is a bare bones lib that gets the job done. If we were to have: * Ability to create dialogs * make buttons and respond to them * make edit controls and read and write to them * make list boxes and manipulate them * make a tree control and manipulate it As a *very* simple and light library, this would allow me to make simple GUI apps that were "boost standard". The above functionality should be simple enough to do with Raw API calls on the various platforms. I would ask that those considering GUI libs take my perspective seriously, as the greatest value that can be had is "having something simple that is standard", more than it is in making something do everything. This would also provide a small incremental step to address many of the interesting ideas that have been put forth on this thread. :) (my 2 cents) Brian Braatz

2 1

getting started with boostbook
by Neal D. Becker 23 Sep '04

23 Sep '04

I'm trying to learn boostbook. I want to use this without bjam. Any hints what's wrong here: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN" "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd"> <library name="Any" dirname="any" xmlns:xi="http://www.w3.org/2001/XInclude" id="any" last-revision="$Date: 2004/01/15 16:08:59 $"> <libraryinfo> <author> <firstname>Kevlin</firstname> <surname>Henney</surname> </author> <librarypurpose> Safe, generic container for single values of different value types </librarypurpose> <librarycategory name="category:data-structures"/> </libraryinfo> </library> xsltproc /usr/local/src/boost.cvs/tools/boostbook/xsl/html-single.xsl \ test.xml > stuff No template for "/library" (or any of its leaves) exists in the context named "title" in the "en" localization. No template matches library. No template matches libraryinfo in library. No template matches librarypurpose in libraryinfo. No template matches librarycategory in libraryinfo.

2 1

Thread-safety in Boost.Signals
by Aaron W. LaFramboise 23 Sep '04

23 Sep '04

I see that the FAQ mentions that a future version of Boost.Signals will be thread-safe. Are there any plans for this to happen any time soon? Right now, is there even a weak thread-safety guarantee? Specifically, may two separate signal objects be manipulated by two separate threads at the same time? Aaron W. LaFramboise

2 1

outputformatters - using just one decorator string
by John Torjo 23 Sep '04

23 Sep '04

Hi Reece, This just popped into my head. A lot of confusion seems to come from how you pass decorators. What I'm trying to say is that it can be very difficult to get the decorator strings right (especially for more complex things like XML) from the first time. I would suggest every formatter takes only one string which parses and finds all decorators itself. Each formatter will have one or more escape sequences which it uses to find the decorators. Something like: // in this case, '%' is used for identifying an element // '*' is to mean "leave default" (don't change) std::vector<int> v; // equivalent to your "[ ", ", ", " ]" std::cout << formatob(v, "[ %, % ]"); // eq. to "<< ", " | ", " >>" std::cout << formatob(v, "<< % | % >>"); // set only open/close decorators std::cout << formatob(v, "<< %*% >>"); // sets only the separator std::cout << formatob(v, "*% | %*"); // for pair - you have "%1" and "%2" std::vector< std::pair<int,long> > vp; // write XML std::cout << formatob(vp, containerfmt("<elem> % </elem><elem> % </elem>", pairfrt("<int>%1</int><long>%2</long>"))); How's that? Best, John -- John Torjo -- 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.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

6 10

[graph] fix for intel-win32-7.1-vc6
by Joaquín Mª López Muñoz 23 Sep '04

23 Sep '04

This trivial fix takes care of issues having to do with BOOST_NO_STDC_NAMESPACE, which impact the test layout_test on intel-win32-7.1-vc6. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 106a107 > #ifndef BOOST_NO_STDC_NAMESPACE 107a109 > #endif // BOOST_NO_STDC_NAMESPACE 126a129 > #ifndef BOOST_NO_STDC_NAMESPACE 127a131 > #endif // BOOST_NO_STDC_NAMESPACE 145a150 > #ifndef BOOST_NO_STDC_NAMESPACE 146a152 > #endif // BOOST_NO_STDC_NAMESPACE

3 2

[graph] A patch for an invalid html link in the docs.
by Jurko Gospodneti� 23 Sep '04

23 Sep '04

Hi all. I attaching a patch for file 'libs/graph/doc/using_adjacency_list.html' that fixes one invalid link in a '<A HREF>' tag. Would someone please apply it. Hope this helps, Jurko begin 666 diff.txt M1DE,12!#3TU005))4T].#0I0<F]D=6-E9#H@,3 N.2XR,# T(#$U.C W.C0Y M#0H-"BHJ*B!U<VEN9U]A9&IA8V5N8WE?;&ES="YH=&UL(#(P,#0M,#8M,C @ M,#4Z,S<Z,3 N,# P,# P,# P("LM,#(P, T*+2TM('5S:6YG7V%D:F%C96YC M>5]L:7-T+FAT;6P@,C P-"TP.2TQ," Q-3HP-3HR,RXP,# P,# P,# @*RTP M,C P#0HJ*BHJ*BHJ*BHJ*BHJ*BH-"BHJ*B T,S,L-#8P("HJ*BH-"B @/%!2 M13X-"B @("!T>7!E9&5F('!R;W!E<G1Y)FQT.W9E<G1E>%]D:7-T86YC95]T M+"!F;&]A="P-"B @(" @(" @(" @(" @<')O<&5R='DF;'0[=F5R=&5X7VYA M;65?="P@<W1D.CIS=')I;F<F9W0[("9G=#L@5F5R=&5X4')O<&5R='D[#0H@ M(" @='EP961E9B!P<F]P97)T>29L=#ME9&=E7W=E:6=H=%]T+"!F;&]A="9G M=#L@161G95!R;W!E<G1Y.PT*#0H@(" @='EP961E9B!A9&IA8V5N8WE?;&ES M="9L=#MM87!3+"!V96-3+"!U;F1I<F5C=&5D4RP-"B @(" @(" @(" @(" @ M(" @(" @(" @(" @(%9E<G1E>%!R;W!E<G1Y+"!%9&=E4')O<&5R='DF9W0[ M($=R87!H.PT*#0H@(" @1W)A<&@@9RAN=6U?=F5R=&EC97,I.R O+R!C;VYS M=')U8W0@82!G<F%P:"!O8FIE8W0-"B @/"]04D4^#0H-"B @/% ^#0H@(%1H M92!P<F]P97)T>2!V86QU97,@87)E('1H96X@<F5A9"!F<F]M(&%N9"!W<FET M=&5N('1O('5S:6YG('!R;W!E<G1Y#0HA(&UA<',N(%-E92!396-T:6]N(#Q! M($A2148](B-S96,Z:6YT97)I;W(M<')O<&5R=&EE<R(^26YT97)I;W(-"B$@ M4')O<&5R=&EE<SPO03X@9F]R(&$@9&5S8W)I<'1I;VX@;V8@:&]W('1O(&]B M=&%I;B!P<F]P97)T>2!M87!S#0HA(&9R;VT@82!G<F%P:"P@86YD(')E860@ M4V5C=&EO;B \00T*(2!(4D5&/2(N+W5S:6YG7W!R;W!E<G1Y7VUA<',N:'1M M;"(^4')O<&5R='D@36%P<SPO03X@9F]R(&AO=PT*(2!T;R!U<V4@<')O<&5R M='D@;6%P<RX-"@T*(" \4#X-"@T*(" \2#,^/$$@3D%-13TB<V5C.F-U<W1O M;2UE9&=E+7!R;W!E<G1I97,B/CPO03X-"B @0W5S=&]M($5D9V4@4')O<&5R M=&EE<PT*(" \+T@S/@T*#0H@(#Q0/@T*("!#<F5A=&EN9R!A('EO=7(@;W=N M('!R;W!E<G1Y('1Y<&5S(&%N9"!P<F]P97)T:65S(&ES(&5A<WD[(&IU<W0@ M9&5F:6YE#0H@(&$@=&%G(&-L87-S(&9O<B!Y;W5R(&YE=R!P<F]P97)T>2X@ M5&AE('!R;W!E<G1Y('1A9R!C;&%S<R!W:6QL(&YE960@=&\-"BTM+2 T,S,L M-#4Y("TM+2T-"B @/%!213X-"B @("!T>7!E9&5F('!R;W!E<G1Y)FQT.W9E M<G1E>%]D:7-T86YC95]T+"!F;&]A="P-"B @(" @(" @(" @(" @<')O<&5R M='DF;'0[=F5R=&5X7VYA;65?="P@<W1D.CIS=')I;F<F9W0[("9G=#L@5F5R M=&5X4')O<&5R='D[#0H@(" @='EP961E9B!P<F]P97)T>29L=#ME9&=E7W=E M:6=H=%]T+"!F;&]A="9G=#L@161G95!R;W!E<G1Y.PT*#0H@(" @='EP961E M9B!A9&IA8V5N8WE?;&ES="9L=#MM87!3+"!V96-3+"!U;F1I<F5C=&5D4RP- M"B @(" @(" @(" @(" @(" @(" @(" @(" @(%9E<G1E>%!R;W!E<G1Y+"!% M9&=E4')O<&5R='DF9W0[($=R87!H.PT*#0H@(" @1W)A<&@@9RAN=6U?=F5R M=&EC97,I.R O+R!C;VYS=')U8W0@82!G<F%P:"!O8FIE8W0-"B @/"]04D4^ M#0H-"B @/% ^#0H@(%1H92!P<F]P97)T>2!V86QU97,@87)E('1H96X@<F5A M9"!F<F]M(&%N9"!W<FET=&5N('1O('5S:6YG('!R;W!E<G1Y#0HA(&UA<',N M(%-E92!396-T:6]N(#Q!($A2148](G5S:6YG7W!R;W!E<G1Y7VUA<',N:'1M M;"-S96,Z:6YT97)I;W(M<')O<&5R=&EE<R(^#0HA($EN=&5R:6]R(%!R;W!E M<G1I97,\+T$^(&9O<B!A(&1E<V-R:7!T:6]N(&]F(&AO=R!T;R!O8G1A:6X@ M<')O<&5R='D@;6%P<PT*(2!F<F]M(&$@9W)A<&@L(&%N9"!R96%D(%-E8W1I M;VX@/$$@2%)%1CTB=7-I;F=?<')O<&5R='E?;6%P<RYH=&UL(CX-"B$@4')O M<&5R='D@36%P<SPO03X@9F]R(&AO=R!T;R!U<V4@<')O<&5R='D@;6%P<RX- M"@T*(" \4#X-"@T*(" \2#,^/$$@3D%-13TB<V5C.F-U<W1O;2UE9&=E+7!R M;W!E<G1I97,B/CPO03X-"B @0W5S=&]M($5D9V4@4')O<&5R=&EE<PT*(" \ M+T@S/@T*#0H@(#Q0/@T*("!#<F5A=&EN9R!A('EO=7(@;W=N('!R;W!E<G1Y M('1Y<&5S(&%N9"!P<F]P97)T:65S(&ES(&5A<WD[(&IU<W0@9&5F:6YE#0H@ M(&$@=&%G(&-L87-S(&9O<B!Y;W5R(&YE=R!P<F]P97)T>2X@5&AE('!R;W!E <<G1Y('1A9R!C;&%S<R!W:6QL(&YE960@=&\-"@`` ` end

2 1

Workaround macro for intel-7.1-vc6-*
by Jonathan Brandmeyer 23 Sep '04

23 Sep '04

What is the correct BOOST_WORKAROUND macro for this platform? I'm currently using #ifdef ((BOOST_WORKAROUND( BOOST_INTEL_CXX_VERSION, == 710)) && defined(_WIN32)) which does not seem to be enough. Thanks, -Jonathan

3 3

[Optional] Inplace test is broken
by Aleksey Gurtovoy 23 Sep '04

23 Sep '04

"optional_test_inplace" fails on many compilers with the following diagnostics (from http://tinyurl.com/5nnh8) In file included from ../libs/optional/test/optional_test_inplace.cpp:22: /boost/head-regression/boost/boost/utility/typed_in_place_factory.hpp:15:52: boost/detail/in_place_factory_prefix.hpp: No such file or directory /boost/head-regression/boost/boost/utility/typed_in_place_factory.hpp:54:52: boost/detail/in_place_factory_suffix.hpp: No such file or directory Date: 2004-09-23 04:40 Looks like a result of incomplete/inconsistent checkin. Fernando? -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] Re: C++ GUI - another view
by Reece Dunn 23 Sep '04

23 Sep '04

Matt S Trentini wrote: >John Torjo wrote: > >>Could you elaborate a bit? What do you think is the window handle limit >>under win32? > >I think that perhaps Mathew is talking about the GDI object limit. At >least under Windows 2000 and earlier versions (I'm not sure about XP) there >is a firm limit of 16K handles that can be allocated system wide - >regardless of your particular specs (ie adding memory does not help). When >this limit is reached weird stuff [1] happens which can only be fixed by a >reboot. > >Any object that allocates a handle under Windows (pens, brushes, dc's, etc) >consume those resources and if you've got a graphically intense GUI using a >greedy GUI library (ie one that holds it's handles for a long duration) >that limit isn't too hard to break. Wouldn't you process the pen objects, etc. when handling the drawing event. Instead of storing a pen handle for each line (which IMHO is overkill), you would do something like: namespace gdi = boost::gdi; namespace colors = boost::gdi::colors; namespace units = boost::units; void draw( gdi::canvas & c ) { gdi::pen mypen( colors::lightskyblue ); gdi::font myfont( "Times New Roman", units::picas( 12 )); c.set_units( units::picas ); c.attach( mypen ); c.attach( myfont ); c.set_color( colors::red ); c.draw_string( 1, 1, "Hello World!" ); // uses myfont + colors::red c.line( 10, 10, 10, 15 ); // uses mypen c.line( 10, 15, 15, 15 ); // uses mypen c.line( 10, 10, 15, 15 ); // uses mypen c.attach( gdi::default_pen( colors::red )); // ... } Likewise, with the component framework (windows, widgets), it should be possible to implement windowless components that do not have a handle attached to them. This would be useful when implementing the layout managers. Handling an event should not be bound to the component that generates them. For example, MFC provides handling the exit message on the application object and not the main window object. This would then allow you to bind events to a graphical object without using a window handle. IMHO, line information should be separate from its colour, thickness, etc. Otherwise, you would need to do something like: class line_object { private: unit x1, y1, x2, y2; gdi::pen * pen; public: void draw( gdi::canvas & c ) { c.attach( *p ); c.draw_line( x1, y1, x2, y2 ); } }; which wastes a call to attach the pen each time. This is especially bad if you have 1000s of lines (e.g. drawing a hilbert curve or serpinski's triangle fractal with a fractal depth of 4 or more). Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Bugs-1033370 ] atomic_count_gcc.hpp does not compile on cygwin gcc 3.3.3
by SourceForge.net 23 Sep '04

23 Sep '04

Bugs item #1033370, was opened at 2004-09-23 16:31 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=1033370&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Latoshek (forester22) Assigned to: Nobody/Anonymous (nobody) Summary: atomic_count_gcc.hpp does not compile on cygwin gcc 3.3.3 Initial Comment: this operator long() const { return __exchange_and_add(&value_, 0); } causes error because on cygwin __exchange_and_add() is declared as: static inline _Atomic_word __attribute__ ((__unused__)) __exchange_and_add (volatile _Atomic_word *__mem, int __val); value_ must be made mutable or cast must be added in operator long() const. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1033370&group_… ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Minor mistake in getting_started.html
by Michael Stevens 23 Sep '04

23 Sep '04

The example in section 2.2 reads bjam "-sGCC_ROOT=/usr/local/gcc-3.3.2" this should be bjam "-sGCC_ROOT_DIRECTORY=/usr/local/gcc-3.3.2" I will commit this change if look correct to everyone -- Michael

2 1

Re: [boost] [Test] Current failures
by Jonathan Wakely 23 Sep '04

23 Sep '04

On Thu, Sep 23, 2004 at 01:01:15PM +0100, Jonathan Wakely wrote: > On Thu, Sep 23, 2004 at 06:22:58AM -0500, Aleksey Gurtovoy wrote: > > > Gennadiy, > > > > Could you please take a look at/comment on the current Boost.Test > > failures as per http://tinyurl.com/5wojs? > > Attached patch fixes the failures. ^ test - token_iterator_test / gcc-3.4.x sorry - failed to paste in the string that identified what i was talking about! > > jon -- I would like to suggest that you not use speed, and here's why: it is going to mess up your heart, mess up your liver, your kidneys, rot out your mind. In general this drug will make you just like your mother and father. - Frank Zappa

1 0

[serialization] white cells (continued)
by Stefan Slapeta 23 Sep '04

23 Sep '04

I don't know if that's the same as in boost.python but the serialization library now shows up white cells, too: http://tinyurl.com/3pvzv It's remarkable that all these are results of compile or compile-fail tests and the tests would succeed if they are reported correctly. I attach an excerpt of my bjam.log: please have a look at it, it seems to me that everything is correct except the interpretation of the results. Stefan ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************

2 1

[assign] fixes for msvc, msvc-stlport and vc7
by Joaquín Mª López Muñoz 23 Sep '04

23 Sep '04

The attached fix makes all tests compile for msvc (not all run, though) and hopefully also for the other two toolsets (can't try myself.) Two changes applied, both in list_insert.hpp: 1. MSVC++ 6.0/7.0, in the presence of a templated memfuns, interprets additional overloads as if they were specializations of the former (which is not legal C++, AFAIK). This introduces problems with the copy ctors of list_insert, which can be workarounded by a) making the template copy ctor accept const references b) declaring and defining the plain default copy ctor of list_insert *after* the templated copy ctor. 2. list_insert::operator()(T t) has been changed to accept a const reference instead. With these changes, all tests build, though three of them crash at run-time (list_inserter, list_of and multi_index_container) I've checked the changes with a compiler other than MSVC (GCC 3.2), seems like nothing ain't broken. I've got two questions: 1. Could somebody (the author, I guess) validate these changes for commit? 2. list_inserter follows a strange convention (IMHO) of not forcing template params to be const references in its various copy ctors and assignment operators, for instance: list_inserter( Function fun ); template< class T > list_inserter& operator=( T r ); Any reason for this approach? I don't know if this can pose problems, but to me having these qualified with const & seems like the usual way. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 164c164 < --- > 168,170d167 < list_inserter( const list_inserter& r ) : insert_( r.insert_ ) < {} < 172c169 < list_inserter( list_inserter<Function2,Arg> r ) --- > list_inserter( const list_inserter<Function2,Arg>& r ) 175a173,175 > list_inserter( const list_inserter& r ) : insert_( r.insert_ ) > {} > 239c239 < list_inserter& operator()( T t ) --- > list_inserter& operator()( const T& t )

4 7

[utility] fixes for assert_test and current_function_test
by Joaquín Mª López Muñoz 23 Sep '04

23 Sep '04

Again, BOOST_NO_STDC_NAMESPACE-related trivial fixes, which make the two tests pass for intel-win32-7.1-vc6, msvc and msvc-stlport (for the two latter, current_function_test passes but produces no useful result, as there's no __func__ macro or similar available for these platforms. Anyone sees a problem with these fixes? Thanks PS: I could just go commit these trivialities without consulting, but I'd rather leave a trace at the mailing list just in case some problem arises. Sorry for the noise caused. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 53a54 > #include <boost/config.hpp> 60c61,65 < std::printf("Expression: %s\nFunction: %s\nFile: %s\nLine: %ld\n\n", expr, function, file, line); --- > #if !defined(BOOST_NO_STDC_NAMESPACE) > using std::printf; > #endif > > printf("Expression: %s\nFunction: %s\nFile: %s\nLine: %ld\n\n", expr, function, file, line); 20a21 > #include <boost/config.hpp> 25c26,30 < std::printf("%s(%ld): %s in function '%s'\n", file, line, msg, func); --- > #if !defined(BOOST_NO_STDC_NAMESPACE) > using std::printf; > #endif > > printf("%s(%ld): %s in function '%s'\n", file, line, msg, func);

2 1

Re:[boost] Re: Re:[serialization] one MSVC build fix
by Robert Ramey 23 Sep '04

23 Sep '04

Tony Juricic wrote >I know. But, in the end, to do the real work, debugging and testing in any >particular environment, we have to stick with the particular compiler and >particular platform. No cross-platform build tool is going to help in that >case. That's why I consider generic build tool fantasies a major waste of >developer's time and resources. Sorry, got to disagree here. I use VC 7.1 compiler and IDE as my main compiler and environment. In general it very good, integrated help, simple editor, powerful debugger. On the other hand it hangs up from time to time and this drives me crazy - still I've tried a lot different ones and I like this the best. However, sticking to one compiler is a big mistake if you want to make good code. All compilers have problems. One problem is that all pass some invalid code as valid. It fools you into thinking there's no bugs or worse, hides your bugs so you can't find them. Also C++ is so complex now (too complex?) that I can't understand the error message half the time. Then when I do I'm left wondering if it's a compiler bug or is it that I don't understand what's going on. So, I've added a number of compilers to my external tools list so I can compile (can't link) write from the IDE with borland, Commeau, G++, and (until it expired) Metrowerks. So when I think some thing is correct or I know its not but can't figure out why, applying several compilers to the code module is indispensable. In this day in age, it's the only practical way to make correct portable C++ code. Honestly, I think that C++ is just to complex to make a correct compiler for. (I know someone is going to take exception to that - Sorry in advance - no offense intended). So here we are. For final build and test I use bjam. Bjam also drives me crazy. I've managed to work with it and I believe that it (or something equivalent) is indispensable for a truly portable project and I haven't found anything better - but still it drives crazy. I understand efforts to improve it are in the works and I look forward to seeing them. However, the main problem is that it seems to take a huge amount of time to understand and learn how to use. I don't know if that's going to change. Robert Ramey

5 5

What happened to the Command Line & Config library by Vladimir Prus?
by Hendrik Schober 23 Sep '04

23 Sep '04

Hi, I found this http://article.gmane.org/gmane.comp.lib.boost.announce/24 but couldn't find the lib at http://www.boost.org/libs/libraries.htm What happened to it? TIA, Schobi -- SpamTrap(a)gmx.de is never read I'm Schobi at suespammers dot org "Sometimes compilers are so much more reasonable than people." Scott Meyers

2 2

RE: [boost] Re: Formal review of "Output Formatters" library begi nstoday
by Rozental, Gennadiy 23 Sep '04

23 Sep '04

> Rozental, Gennadiy wrote: > >Here some more details: > > > > > 1. What is your evaluation of the design? > > > >Library trying to solve in fact trivial problem. Would it be > presented > >as trivial function > > > >Template<typename C> > >Foo( C const& c, std::string open, std::string close, > std::string sep > >); > > > >I may understand it. > > This would mean that you would duplicate code for rendreing > container types. What code? I have only one function. Could you please be more specific. In worse case I will have as many function as many different UDT I want to support. But this is also the case for you. > Also, you are missing special formatting, e.g. wrapping > open/close values > around elements, e.g.: Yeah, maybe. My solution is 5 lines. You solution is 170K of code. I could afford to repeat my function twice would I need to add extra grist. > std::cout << formatob( vec, containerfmt( > wrappedfmt().format( "<e>", > "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> And again, why would I do this? This code is looking for trouble. How long will it be until I mistype open/close brackets differently? > > the indentation functionality that Volodya has expressed an > interest in, and > position-based output, e.g.: > > [0] John, [1] James, [2] Marina I wonder how your interface would look like. Anyway it's not a part of submitted library. Once you presented it we may discuss it. > Also, the library should be usable on a standard stream. This > is one of the > key design aims. Can you do: > > std::cout << Foo( vec, "< ", " >", " :: " ); > > ? This requires returning an object that has << implemented. > The mechanism > for this is outlined in the standard by using *manipulators*. > Thus, you > would need that class to defer processing to the Foo function > if you want to > use your approach. *If* I want usual ostream interface, I do need to add one function object (note that it does not matter how many UDT I want to support). > > > 2. What is your evaluation of the implementation? > > > >In most part I either don't understand or don't like it. IMO simple > >task library trying to solve shouldn't require that much > code. Simple > >overloading base solution should've done the trick. > > This does not allow for flexibility to add indenting, wrapped > data, etc. I do not think it's true statement. See my other post. > > > 4. What is your evaluation of the potential usefulness of the > > > library? > > > >Now to the most important: why would I ever want to use library like > >this? > > > >We have already: > >std::ostream > >boost::format > >boost::serailization > > > >In what scenario I would use this library? > > But you can't do: > > std::vector< int > vec; > std::cout << vec; // oops! no operator << defined for vectors. Then I will write one. The thing is: I believe what library need to bring more value than just a substitution for 5 lines of custom code (especially since it not that flexible, and any step to the side causing you to write more code that custom solution would require you to). > >I most definitely wouldn't want to repeat all this formatting every > >time I need to output my vector. > > If you want [ a, b, c, d ] style output, you don't. The extra > machinery is > used to customize this. What if I want { a, b, c, d } for all my vectors? I could write global operator << using your library, using custom loop or using my trivial Foo above. I do it once. So where is the win for your solution? > Also, you can save a format object, e.g.: > // old style > containerfmt_t< char, pairfmt_t< char > > > myformat = containerfmt( pairfmt().format( " = " )).format( "<< ", " > >>" ); > > std::cout << formatob( vec, myformat ); // << ( a = 5 ), ( > b = 7 ), ... > >> > std::cout << formatob( lst, myformat ); // << ( i = 2.132 ), ( j = > 3.14159 ), ... >> > std::cin >> formatob( vec, myformat ); And now I need to write std::cout << formatob( lst, myformat ); every time I print list? No, thank you. > >If I write output operation rarely - I would use explicit loop -it's > >more flexible anyway. > > Depends what you are outputting. If the type contains nested > containers, it > can be more complex. Maybe. But compare user base for container over scalar types with multilevel containers. > >I wouldn't use this library for XML printing - why would I want to > >mention tag name twice? > > You can use a wrapper format object: > > std::cout << formatob( vec, containerfmt( > wrappedfmt().format( "<e>", > "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> I can. But I won't. And wouldn't recommend. See above. > Regards, > Reece Gennadiy.

2 1

RE: [boost] Proper threading (Was: Formal review of "Output Formatters"library beginstoday )
by Reece Dunn 23 Sep '04

23 Sep '04

Vladimir Prus wrote: >Rozental, Gennadiy wrote: > > Hi, > > > > I would like to start with resolution. I vote NOT to accept this > > submission. > >Gentlemen, may I ask that you use mailers which preserve correct threading? >In >particular, in review of the outfmt library, each message from Reece, >Robert >and Gennadiy is completely unrelated to the thread, missing the >"References" >and "In-reply-to" headers. > >This makes follow the thread a nightmare. Even web-based mailers nowdays >support proper threading. What do you do to break it? I am using the free version of Hotmail. I have filters to move the files from my inbox into a designated folder and hit "Reply" to reply to the messages. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 4

[Range] Current status?
by Aleksey Gurtovoy 23 Sep '04

23 Sep '04

Is the library really in a releasable state? The current test failures (http://tinyurl.com/5ch8u) don't look that good to me. In particular, half of the tests legitimately fail with CodeWarrior 8.3/9.3, and some failures on STLPort configurations (this one, for instance -- http://tinyurl.com/4lvkw) appear to be legitimate as well. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 23 Sep '04

23 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > I just took your implementation > (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) for shared_ptr > and use it now in win32gui (upcoming v1.4.2). Using Interlocked* for > win32 totally rocks! > > From my tests - Interlocked* are very fast. They're about twice as > slow as a raw increment (or my tests are wrong;)). > > From what I see - I think you can certainly merge them into > boost::shared_ptr. > Maybe users can select the old version or this Interlocked* version > with a certain macro - like BOOST_SHARED_PTR_USE_INTERLOCKED. > > Also, why not including windows.h directly, like this: > #define WIN32_LEAN_AND_MEAN > #include <windows.h> <snip> "Lean" is a bit of a joke. A rather smaller set of Windows definitions can be included by defining an architecture-identifying macro (e.g. _X86_ for i386) followed by: #define NOMINMAX // inhibits definition of min and max macros in // <windef.h> #include <windef.h> #undef NOMINMAX #include <stdarg.h> // <winbase.h> requires definition of va_arg #include <winbase.h> Unfortunately this still defines quite a few macros. The MSDN Library documentation of Win32 functions will tell you about any additional headers that need to be included, even though it recommends you include <windows.h> instead.

2 1

Re:[boost] Re: Standard/classic iostreams mess
by Robert Ramey 23 Sep '04

23 Sep '04

> My vote is for BOOST_CLASSIC_IOSTREAMS, BOOST_STANDARD_IOSTREAMS. How about just BOOST_NO_STANDARD_IOSTREAMS This would be inline with other boost feature macros Robert Ramey

1 0

RE: [boost] Re: Proper threading (Was: Formal review of "Output F ormatters" library beginstoday )
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> > I use Outlook. In some cases it preserve "threading". In some not. > > Do you mean Outlook Express? > > Are you receiving emails or do you use the gmane news server? > > Jeff I mean Outlook. And it's the only client allowed in our company. Gennadiy.

4 6

Standard/classic iostreams mess (was Re: Linux regressions)
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> > I added #include <ios>, which is apparently missing. > > > > Is there flag that separate standard/classic iostream (If I guess > > correctly - it should be enough) > > #ifndef BOOST_NO_STD_LOCALE > #include <ios> > #endif > > John. > (I also need to make the same fix!). It's quite obscure variable name for something very simple : switch classic/standard io. If you search through boost source you will see: 1. Check like "#if defined(__GNUC__) && (__GNUC__ < 3)" in boost/shared_ptr.hpp, boost/intrusive_ptr.hpp, boost/math/octonion.hpp boost/math/quaternion.hpp (which is incorrect BTW IMO since gcc2.95 could be using STLPort) 2. #ifndef BOOST_NO_TEMPLATE_STD_STREAM in boost/format/free_funcs.hpp and others Look also in boost/format/detail/workarounds_gcc-2.95.hpp that contains detailed workaround for gcc2.95 without STLPort 3. #if __GNUC__ < 3 in graph/detail/edge.hpp (the same comment applies as in 1.) 4. #ifdef BOOST_NO_TEMPLATED_STREAMS in boost/lambda/detail/operators.hpp and others, and Boost.Tuple headers 5. #ifdef BOOST_UBLAS_USE_BASIC_STREAM and #ifdef BOOST_UBLAS_USE_STREAM in ublas code 6. #ifndef BOOST_NO_STD_LOCALE in boost.random/detail/... several headers, Boost.Regex, 7. #if BOOST_WORKAROUND(__GNUC__, < 3) && !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) In Boost.Test headers 8. Boost.Variant present workarounds based on #if !defined(BOOST_NO_STD_LOCALE) in boost/detail/templated_streams.hpp 9. #ifdef BOOST_OLD_IOSTREAMS in boost/dynamic_bitset/dynamic_bitset.hpp 10. # if !defined(BOOST_IOFM_NO_BASIC_STREAM) in output formatters library currently under review. Also you could see that std::basic_ostream is used outside #ifndef BOOST_NO_STD_LOCALE and many other places where standard iostreams are used without any checks. I believe we need to put stop to this mess and force everybody use the same practice/variable(s). My vote is for BOOST_CLASSIC_IOSTREAMS, BOOST_STANDARD_IOSTREAMS. Regards, Gennadiy.

2 1

numeric_cast/MPL/vc6 conflict
by David Abrahams 22 Sep '04

22 Sep '04

The introduction of mpl::numeric_cast has caused a regression in libs\python\test\vector_indexing_suite.cpp for vc6. How shall we resolve this problem? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 4

python/detail/config.hpp bug?
by Aleksey Gurtovoy 22 Sep '04

22 Sep '04

Boost.Python fails to build with MSVC 6.x/STLPort (see http://tinyurl.com/4nl7l) due to the following (incorrect) configuration logic in "boost/python/detail/config.hpp": // The STLport puts all of the standard 'C' library names in std (as far as the // user is concerned), but without it you need a fix if you're using MSVC or // Intel C++ # if defined(BOOST_MSVC_STD_ITERATOR) # define BOOST_CSTD_ # else # define BOOST_CSTD_ std # endif The issue, as explained in "boost/config/stdlib/stlport.hpp" is that: // STLport does a good job of importing names into namespace std::, // but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since our // workaround does not conflict with STLports: Is there a reason why we are not using BOOST_NO_STDC_NAMESPACE here? -- Aleksey Gurtovoy MetaCommunications Engineering

2 5

CW 9.3: uBlas is in a very bad state
by Stefan Slapeta 22 Sep '04

22 Sep '04

The ublas tests 1-3 are currently not compiling with cw 9.3. Tests 4 and 6 compile but do not execute (they throw a GPF), which is, because of what seems to be a defect in the build system, not reflected in the results (a general cw 9.3 problem, see http://tinyurl.com/5mlxs) Shall we mark the library unusable for this compiler (as for cw 8.3)? Stefan

2 1

Re: CW 9.3: uBlas is in a very bad state
by Michael Stevens 22 Sep '04

22 Sep '04

Stefan, > The ublas tests 1-3 are currently not compiling with cw 9.3. Interesting. This is due to a commit last night which add these swap functions to some closures. cw 9.3 seems to have multiple problems with this. The swap function should never be instantiated in test1-3. Also the instantiation is for a const type which is odd. Sadly the error message that produced do not give sufficient context to indicate where the template was instantiated like this. > Tests 4 and 6 compile but do not execute (they throw a GPF), which is, > because of what seems to be a defect in the build system, not reflected > in the results (a general cw 9.3 problem, see http://tinyurl.com/5mlxs) OH. I wondered why cw 9.3 results were so good! > Shall we mark the library unusable for this compiler (as for cw 8.3)? I will wait and gather a bit more information. Thanks. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 22 Sep '04

22 Sep '04

Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > > It means that it's hard to write portable lock-free algorithms. > > Not necessarily. > Presumably you are thinking of not allowing lock-free algorithms to > compile if the primitives used are not available on the > target platform? Yes. If a lock-free algorithm depends on an atomic operation which the processor does not support natively, that operation can presumably only be implemented using a hidden global (possibly per-type) mutex - or, even worse, an "unimplemented instruction" processor exception and fix-up in the kernel. This could make the lock-free algorithm far slower than a locking algorithm that uses a very specific mutex and locks and unlocks it only once. > Presumably we could use template traits to indicate whether or not a > particular atomic operation is available on a given platform, and > then use if<>s to decide whether or not to use a lock in shared_ptr. > > Speaking of which, are there any plans to include lock-free algos in > boost? That would be something I would be very interested in... There are plans afoot to include atomic operations in the standard. I dare say Boost may be the testing ground for them, but I don't know. <snip> > > Perhaps I could put #define BOOST_STDLIB_LIBSTDCPP3 in > > <boost/config/stdlib/libstdcpp3.hpp> and then guard any use of > > <bits/atomicity.h> with #ifdef BOOST_STDLIB_LIBSTDCPP3. > > I think it would be preferable to distinguish between HW/OS > combinations as opposed to C++ lib implementations. I'm talking about using atomic operations that are included in libstdc++. I only mentioned Linux because most C++ programs built for Linux will use libstdc++ and so could take advantage of a lock- free shared_ptr implementation that depends on libstdc++. It would be less significant for other operating systems on which most people are using other libraries. > > Making shared_ptr lock-free wherever possible is indeed a great idea > > and will hopefully become a great reality! > > Yes. What release are we looking at here? I believe only bug fixes can now be committed to 1.32 so improvements to shared_ptr will have to wait for 1.33.

1 0

RE: [boost] Re: Re: immutable string
by Ben Hutchings 22 Sep '04

22 Sep '04

Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: > Ben Hutchings <ben.hutchings(a)businesswebsoftware.com> wrote: > > [] > > >> But I think there might be another solution. The standard states in > >> 5.3.4.10 that arrays of char's allocated with new expression are > >> always properly aligned for types whose size is no greater than the > >> size of the array. Does allocator<char>::allocate() have the same > >> requirement? I could not find it in my copy of the standard. <snip> > > However, the requirements for > > allocators in general (table 32 in subclause 20.1.5) say only that > > "[m]emory is allocated for n objects of type T" by the allocate() > > function. > > So, that means that there is no requirement and thus it is not > guarantied that any custom_allocator<char> returns a pointer > properly aligned for any type, right? Right.

1 0

program_options: configuring array-like objects
by Maurizio Vitale 22 Sep '04

22 Sep '04

Hi all, I'm trying to somewhat abuse the boost program_options library for configuring large simulations of digital systems. One feature that I need is the initialization of arrays (and any object supporting an operator []). For instance for a block containing a register file I'd like to be able to say things like: [block] regs[10] = 0 even nicer if the index was not contrained to be an integer. For instance [block] regs[0..5] = 1 would be an handy way for initializing a range of locations. Now, as far as I can tell, both these uses are not supported by the library. Having to modify the library itself, a quick (and obviously dirty) change would be to check for [] when parsing the option name and stuffing it as prefix to the value so that user defined parsers can take care of it. Just for clarity, what I mean is to turn: [block] regs[0..5] = 1 into: [block] regs = [0..5]1 With an appropriate type declaration for regs we can cause the appropriate user defined parser for doing the validation. So I guess I have three questions: - would be an extension to program_options to take care of the initialization of array-like object considered of general enough interest to deserve a place in the library? - if not, does the quick-and-dirty approach outlines seem viable to people familiar with the program_options library? - any other suggestions for a cleaner/more general implementation? Thanks a lot for any suggestions. Best regards, Maurizio

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 22 Sep '04

22 Sep '04

Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > Ben, > > > Atomic operations are highly platform-dependent, with > > different platforms having different capabilities and many > > requiring use of assembly language rather than providing an > > API for atomic operations. > > Would that be a problem? It means that it's hard to write portable lock-free algorithms. However I don't think this is a problem for shared_ptr because it already has a portable mutex-based implementation of the counter operations which can be used as a fallback where a lock-free implementation is impracticable. <snip> > > Second, shared_ptr has two counters and updating them safely > > without using a lock requires some subtlety. > > On ia32, ia64 and amd64 you can always use DCAS. That isn't available on all IA32; it was introduced with the Pentium. Worse, on a 386SX even 32-bit atomic operations are unavailable. (This is why Windows 95 requires a 386DX and why there have been some binary compatibility problems with glibc and libstdc++ built for 386+ vs 486+.) > On Ultrasparc you could restrict the counter to 32-bits and use CAS > (64-bit). > You can add other platforms as the implementation becomes available, > but use a lock by default. Right. > > It's something > > I meant to implement but hadn't quite got round to. Perhaps > > I could make it work on g++ (and hence most Linux > > configurations) by using libstdc++'s atomic primitives? I > > No. This is not portable enough. > The problem is that libstdc++'s atomic ops come with libstdc++ which > precludes you from using other standard library implementations. Perhaps I could put #define BOOST_STDLIB_LIBSTDCPP3 in <boost/config/stdlib/libstdcpp3.hpp> and then guard any use of <bits/atomicity.h> with #ifdef BOOST_STDLIB_LIBSTDCPP3. <snip> > > don't think they are really public though, so this might be a > > bad idea. > > I think this would be a great idea, and it would make shared_ptr a lot > more acceptable at our company. I meant that using libstdc++'s atomic operations might be a bad idea. Making shared_ptr lock-free wherever possible is indeed a great idea and will hopefully become a great reality!

3 2

platform specific structures
by Matt Hurd 22 Sep '04

22 Sep '04

I'm interested in getting something like "needs_lock" below into the normal traits, perhaps as part of boost thread. It informs you whether of not an operation on such a contiguous block needs a lock to be atomic. For example, on ia32 32 bit aligned ops are atomic, on ia64 it is 64 bit. doubles on ia32 need locking to be atomic, on ia64 they don't. sizeof(void*) works generically for these two platforms as is included in the code below. A default, safety first implementation might return true always for needs lock, or perhaps, true for all sizeof's greater than a byte. "Ifdef" hell for platforms can read to readability problems and big config.hpp equivalents. An alternative is to redirect headers to generic, where possible, or platform specific headers, where necessary, but this may lead to a bit of a maintenance nightmare due to supporting similar code for different platforms even though the code is typically much more readable. Another often intertwined approach is to include a platform independent api/function layer that is then used by the library, e.g. ACE's os.h. Any suggestions on best practice for this? Regards, Matt Hurd matthurd(a)acm.org www.hurd.com.au /*_____________________________________________________________________ created: 2004-6-7 16:20 filename: needs_lock.hpp author: Matt Hurd _______________________________________________________________________*/ #ifndef NEEDS_LOCK_HPP_200467 #define NEEDS_LOCK_HPP_200467 #include <boost/type_traits.hpp> #include "boost/type_traits/is_integral.hpp" #include "boost/type_traits/is_float.hpp" #include "boost/type_traits/detail/ice_or.hpp" #include "boost/config.hpp" // should be the last #include #include "boost/type_traits/detail/bool_trait_def.hpp" namespace boost { namespace detail { template< typename T > struct needs_lock_impl { BOOST_STATIC_CONSTANT(bool, value = (sizeof(T) > sizeof( void *)) ); }; } // namespace detail BOOST_TT_AUX_BOOL_TRAIT_DEF1(needs_lock,T,::boost::detail::needs_lock_impl<T>::value) } // namespace boost #include "boost/type_traits/detail/bool_trait_undef.hpp" #endif

5 17

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 22 Sep '04

22 Sep '04

Ben, > Atomic operations are highly platform-dependent, with > different platforms having different capabilities and many > requiring use of assembly language rather than providing an > API for atomic operations. Would that be a problem? I have implemented this for our internal managed pointer class, and our code needs to run on a few different platforms (At the moment I am discussing the posibility of contributing to boost with our legal dept - note that it wasn't until recently that I was allowed to even post to an external mail group. Before that I used to follow boost quite closely) > Second, shared_ptr has two counters and updating them safely > without using a lock requires some subtlety. On ia32, ia64 and amd64 you can always use DCAS. On Ultrasparc you could restrict the counter to 32-bits and use CAS (64-bit). You can add other platforms as the implementation becomes available, but use a lock by default. > It's something > I meant to implement but hadn't quite got round to. Perhaps > I could make it work on g++ (and hence most Linux > configurations) by using libstdc++'s atomic primitives? I No. This is not portable enough. The problem is that libstdc++'s atomic ops come with libstdc++ which precludes you from using other standard library implementations. The ones that come with Linux in sys/atomic.h tend to be quite inconsistent, not to mention that many are implemented in such a way that they don't return the new/old value. On Solaris, sys/atomic.h ops are not available in user space anyway, not to mention that they are declared as extern - so they can't be inlined. > don't think they are really public though, so this might be a > bad idea. I think this would be a great idea, and it would make shared_ptr a lot more acceptable at our company. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

RE: [boost] Re: immutable string
by Ben Hutchings 22 Sep '04

22 Sep '04

Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: > Ben Hutchings <ben.hutchings(a)businesswebsoftware.com> wrote: > > [] > > > There's one possible problem I noticed, which is that an allocated > > buffer will be aligned properly for boost::detail::atomic_count but > > perhaps might not be aligned properly for char_t (or to whatever > > buffer_storage_alignment specifies). Let me apply the James Kanze > > test [*]: is it safe to create a const_string<double> on a SPARC? > > > > [*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you > > don't know what I'm talking about. > > I fixed it using the union trick. > > But I think there might be another solution. The standard states in > 5.3.4.10 that arrays of char's allocated with new expression are > always properly aligned for types whose size is no greater than the > size of the array. Does allocator<char>::allocate() have the same > requirement? I could not find it in my copy of the standard. The default allocator's allocate() member function uses ::operator new(std::size_t) so any specialisation could be used to allocate memory aligned for any type. However, the requirements for allocators in general (table 32 in subclause 20.1.5) say only that "[m]emory is allocated for n objects of type T" by the allocate() function.

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 22 Sep '04

22 Sep '04

Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > > Also, why not including windows.h directly, like this: > > #define WIN32_LEAN_AND_MEAN > > #include <windows.h> > > I believe WIN32_EXTRA_LEAN may be even better. > > > <side-note> > > From my tests it seems your version as is now fails to link > > for gcc (unresolved external > > _InterlockedIncrement/_InterlockedDecrement). > > However, if #including <windows.h> and use > > InterlockedIncrement/Decrement - they work. > > </side-note> > > That is not suprising - Interlocked* are parts of the Win32 API. > > In fact, it has been a complete mistery to me as to why boost doesn't > use atomic operations for its ref counting. The mutex on the counter > was one of the big reasons why people here decided not to use > shared_ptr. Atomic operations are highly platform-dependent, with different platforms having different capabilities and many requiring use of assembly language rather than providing an API for atomic operations. Second, shared_ptr has two counters and updating them safely without using a lock requires some subtlety. It's something I meant to implement but hadn't quite got round to. Perhaps I could make it work on g++ (and hence most Linux configurations) by using libstdc++'s atomic primitives? I don't think they are really public though, so this might be a bad idea.

1 0

Multimethods Design
by Jesse Jones 22 Sep '04

22 Sep '04

There seems to be some interest in my multimethod library so I thought I'd post a message describing the design in more detail. In this message I'll focus on the API and ignore the implementation except when it affects the API. I may post another message later focusing on the implementation. The vault is still full, so if you want to look at the code go to <https://sourceforge.net/projects/multimethods/>. The draft proposal to add multimethods as a core feature is also interesting: <http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1529.html#1.1.1>. Also <http://www.op59.net/accu-2003-multimethods.html> has some info on why multimethods are a Good Thing. The design is actually quite simple. Function objects (aka methods) may be added to a generic function object. Then the generic function can be called with a set of actual arguments. It will then dispatch to the most specialized method using the dynamic type of the actual arguments. One way to think of this is as a form of runtime overloading. The API for generic functions looks like this (using an arity 2 function as an example): template <typename Result, typename Formal1, typename Formal2> class generic_function2 : public detail::base_generic_function< Result > { When this is instantiated it creates a function object. Currently the arity is encoded in the class name, but presumably boost::preprocessor could be used to allow users to instantiate the classes in the way that boost:;function does. base_generic_function is a helper class that does all of the heavy lifting. Method formal arguments and actual argument types must be compatible with Formal1 and Formal2 (this is checked at compile time). The formal argument types may also be any_type which means that the formal argument in the methods for that position may be of any type. The API is as follows. First there are some standard typedefs: typedef Result result_type; typedef typename Formal1 first_argument_type; typedef typename Formal2 second_argument_type; A default ctor (and compiler provided copy ctor/assignment op): generic_function2(); Members to add methods: template <typename R, typename T1, typename T2> generic_function2& operator<<(R (*method)(T1, T2)); template <typename Functor> generic_function2& operator<<(Functor method); If the method has the same arguments as an existing method a std::runtime_error exception is thrown. If the Functor version is used the functor must have result_type, first_argument_type, and second_argument_type typedefs. A member used to invoke the generic function: template <typename T1, typename T2> RESULT operator()(const T1& arg1, const T2& arg2) const; This works by building a list of the applicable methods and then sorting this list from most to least specific using the dynamic type of the actual arguments. A method A is more specific than another method B if, for a given set of actual argument, for each argument, A has a better match for the actual argument than B in at least one slot and the other arguments are no worse than B's (this is similar to the rule used for overloaded functions). Argument matching follows the usual C++ rules so derived types are better matches than base types and promotions are better matches than conversions. If no applicable methods or a most specific method cannot be found a runtime_error exception is thrown. When a method is called it may call the next most specific method using one of the following methods: RESULT next_method(); template <typename T1, typename T2> RESULT next_method(const T1& arg1, const T2& arg2); The second overload calls the next method using a new set of actual arguments, but the types of those arguments don't affect which method is called. The first overload calls the next method with the last set of actual arguments that were used. If there are no more methods or the next method is ambiguous a runtime_error exception is thrown. The only missing piece is that clients of the library must register polymorphic types if they want them to be treated polymorphically. This is done with a macro that looks like this: #define DECLARE_SUBTYPE(type, base) This seems like a simple yet flexible API, but there's probably room for improvement. For example: 0) The names "generic function" and "method" seem potentially confusing in a C++ context (they're from Dylan and (I think) CLOS). 1) There's no support for removing methods. This seems like a good idea, but it's not possible to compare arbitrary function objects so we'd probably have to add an add_method member which returned a cookie that a remove_method member would take to determine which method to remove (similar to the way boost::signal works). 2) Policy decisions like type compatibility and ordering are hardwired into the code. It might make sense to refactor these into policy classes although I'm not sure what they'd be used for. Maybe special casing smart pointers. 3) The library allows lossy conversions like floats to chars. This was done so that it world work as much like normal C++ code as possible, but it's a pretty evil thing. Maybe an option could be added that would reject such conversions. 4) boost::bind is a bit annoying because it doesn't provide the typedefs that the library requires. This is a known issue with bind and, as far as I know, isn't fixable. The workaround is to assign the result of boost:;bind to a boost:;function and add that to the generic function. 5) Method formal arguments can't be non-const reference types. The problem here is that typeid(const T&) == typeid(T&) == typeid(T). It might be possible to work around this, but the type code is already full of hacks working around typeid and type_info limitations... 6) It might be a good idea to add a member that will return a function pointer or boost:;function to the most specific method for a given set of types. This would allow users to skip the overhead of dispatching when using multimethods inside loops in some cases. -- Jesse

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 22 Sep '04

22 Sep '04

Rozental, Gennadiy wrote: >Here some more details: > > > 1. What is your evaluation of the design? > >Library trying to solve in fact trivial problem. Would it be presented as >trivial function > >Template<typename C> >Foo( C const& c, std::string open, std::string close, std::string sep ); > >I may understand it. This would mean that you would duplicate code for rendreing container types. Also, you are missing special formatting, e.g. wrapping open/close values around elements, e.g.: std::cout << formatob( vec, containerfmt( wrappedfmt().format( "<e>", "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> the indentation functionality that Volodya has expressed an interest in, and position-based output, e.g.: [0] John, [1] James, [2] Marina Also, the library should be usable on a standard stream. This is one of the key design aims. Can you do: std::cout << Foo( vec, "< ", " >", " :: " ); ? This requires returning an object that has << implemented. The mechanism for this is outlined in the standard by using *manipulators*. Thus, you would need that class to defer processing to the Foo function if you want to use your approach. >As to presented design - I see it as unnecessary complicated. And in many >cases simply incorrect. >Library does not follow standard practice as to wide char support. I am addressing these issues. See my other discussions for details. >Interfaces seem confusing and error prone. >Decoration model seems too simple to warrant so much trouble as reusable >library. Maybe more powerful/flexible solution should be considered. I have been reshaping the decoration model and have commented on it elsewhere. > > 2. What is your evaluation of the implementation? > >In most part I either don't understand or don't like it. IMO simple task >library trying to solve shouldn't require that much code. Simple >overloading >base solution should've done the trick. This does not allow for flexibility to add indenting, wrapped data, etc. > > 4. What is your evaluation of the potential usefulness of the library? > >Now to the most important: why would I ever want to use library like this? > >We have already: >std::ostream >boost::format >boost::serailization > >In what scenario I would use this library? But you can't do: std::vector< int > vec; std::cout << vec; // oops! no operator << defined for vectors. >I most definitely wouldn't want to repeat all this formatting every time I >need to output my vector. If you want [ a, b, c, d ] style output, you don't. The extra machinery is used to customize this. Also, you can save a format object, e.g.: // old style containerfmt_t< char, pairfmt_t< char > > myformat = containerfmt( pairfmt().format( " = " )).format( "<< ", " >>" ); std::cout << formatob( vec, myformat ); // << ( a = 5 ), ( b = 7 ), ... >> std::cout << formatob( lst, myformat ); // << ( i = 2.132 ), ( j = 3.14159 ), ... >> std::cin >> formatob( vec, myformat ); >If I write output operation rarely - I would use explicit loop -it's more >flexible anyway. Depends what you are outputting. If the type contains nested containers, it can be more complex. >I wouldn't use this library for filtering - we will have iostreams library >for that (If I am not mistaken). This library does not provide filtering capabilities. What I was saying is that if you want to pretty print the data, it might be worth using Jonathan's library. >I wouldn't use this library for XML printing - why would I want to mention >tag name twice? You can use a wrapper format object: std::cout << formatob( vec, containerfmt( wrappedfmt().format( "<e>", "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] OutFmt library implementation questions
by Reece Dunn 22 Sep '04

22 Sep '04

Rozental, Gennadiy wrote: > > >4. How does this all machinery will work with wchar_t? > > > > std::wcout << formatob( vec, containerfmtex< wchar_t * > > >()).format( L" - > > " ); > > > > Use the ex< DelimiterType > variant on the innermost construct. > >This is inacceptable and does not follow standard practice. The new version templates that are templatized on character type are also templatized on the format object that they use (to render their elements). This means that in order to provide c/w-style interface, you need: template< typename CharT, class ElementRenderer = basic_default< CharT > > class basic_container{ ... }; basic_container< char > ccontainer(){ return( basic_container< char >()); } basic_container< char, ElementRenderer > ccontainer( const ElementRenderer & er ){ return( basic_container< char >( er )); } basic_container< wchar_t > wcontainer(){ return( basic_container< wchar_t >()); } basic_container< wchar_t, ElementRenderer > wcontainer( const ElementRenderer & er ){ return( basic_container< wchar_t >( er )); } // what about custom character type (e.g. unicode?) basic_container< char > my_format = ccontainer().decorate( " : " ); std::cout << io::object( vec, my_format ); std::cout << io::object( vec, ccontainer().decorate( "< ", " >" )); > > This is a VC 6.x workaround. > >But you don't list this compiler amoung supported. At the moment there are a few problems with it. I am looking to resolve these if possible. > > >6. Why the same entity you sometime call format_type and sometime > > >DelimeterType? > > > > format_type is the typedefed version (should be delimiter_type) and > > DelimiterType is the template parameter. > >So is it delimeter type or forat type - it can't be both. delimiter type. In the new version it is char_type since the decorators (formatters in the review implementation) now take a CharT parameter instead of the storage type. > > >7. What deducer is supposed to deduce? I couldn't get > > through all the > > >details, but couldn't the same be achieved using partial > > specialization > > >and/or partial ordering. Cause it look way too complex and > > unnecessary. > > > > The deduction mechanism is used to evaluate what type T is > > (e.g. std::pair< > > char, int >), what format object is needed to render it > > (including nested > > format objects) and to construct the appropriate format object. > > > > It could be possible to use partial specialization, but the > > type traits are > > used elsewhere to redirect formatting behaviour (e.g. when > > reading in a > > container do diffreent things if it is a sequential, > > associative or set > > container). > >IMO all that you needed is function overloading. I don't see a place for >all >these deduce/trats staff. Consider the pair format object (pair renderer): how do you render each pair type. Using function overloading, you would have: class basic_pair { public: OutStream & write( OutStream & os, const std::pair< T1, T2 > & p ){ ... } OutStream & write( OutStream & os, const boost::compact_pair< T1, T2 > & p ){ ... } OutStream & write( OutStream & os, const std::complex< T > & p ){ ... } OutStream & write( OutStream & os, const boost::math::interval< T > & p ){ ... } }; But this would add dependencies on those libraries. Also, it is not extensible: how do you add support for boost::rational< T >, for instance? Using the deduction mechanism, I implement the output using boost::io::detail::getval< n >( pair_type ). Input is more complex because you need to distinguish between types that you can get the elements separately (e.g. std::pair) and types that you need to set both values together (e.g. boost::math::rational): the former uses refval< n >( type ) and the latter uses assignval( type, first, second ). How would function overloading solve this? (Note, function overloading is used for getval, refval and assignval). For containers, you need to use a different function/function arguments to insert an element depending on whether the container is sequential, associative or a set. My library provides a description of the types that it can render (e.g. separable pairs, 4-ary types, associative containers) without saying what these types are. The stl and boost directories in my library then tell my library that a std::vector is a sequential container. My library then knows how to handle a std::vector. Doing this, I can separate the dependencies on external libraries and allow it to be extended to support other sequential containers, pairs, etc. > > >11. Need for all this hierarchies: > > >Formatter->formater_t->openclose_formatter_t > > > > This is to ensure that the return type of 'format' in Formatter > > [FormatObject] is Formatter and not openclose_formatter_t. Thus: > > formatob( vec, containerfmt().format( " / " )); > > will work as intended without overriding 'format' in > > containerfmt_t (created > > by containerfmt()) to return the correct type. > > > > >openclose_formatter->openclose_formatter_t > > > > > >are completely unclear. Explanations presented in docs does not help > > >since format methods seems to be returning *this anyway. > > > > They return: > > *static_cast< ReturnType * >( this ) > > to allow 'format' to return the correct type when inherited > > in the format > > objects. > >Formatob_t::format return *this. You did not answer my question. I still >believe it's all unnecessary. formatob_t::format returns *this because the FormatObject (Renderer) that it inherits returns a value of type FormatObject. Thus, if you didn't have these overloads, then: std::cout << formatob( vec ).format( " + " ); would not work, since it will try to output a containerfmt() type. > > >Why couldn't we just use something trivial like > > > > > >template<char Ch> > > >struct formatter > > >{ > > > std::basic_string<Ch> m_open; > > > std::basic_string<Ch> m_close; > > > std::basic_string<Ch> m_sep; > > >}; > > > > > >Is beyond me. If any member is empty it means it missing. > > > > This is the direction I am going in the development version. The only > > difference is that I am using io::decoration< CharT, int id > > > instead of > > std::basic_string< CharT >. The decoration class uses > > std::basic_string to > > store the values, while providing support for looking up the > > default value > > on a stream and an external function for checking for a match > > on an input > > stream. > >You presented library call *Output* formatter. Why do we talk about input >at >all. The *output* designation is a "legacy" from before the library supported input facilities. People expressed an interest in inputting as well, so I added it; output stuck. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

1 0

Spirit on Intel 8.0/Linux
by Aleksey Gurtovoy 22 Sep '04

22 Sep '04

Folks, Is this a known problem that somebody can comment on (from http://tinyurl.com/5hhne) icc: error: Fatal error in /opt/intel_cc_80/bin/mcpcom, terminated by segmentation violation compilation aborted for ../libs/spirit/test/./ast_calc_tests.cpp (code 1) . /opt/intel_cc_80/bin/iccvars.sh icc -c -w1 -g -O0 -I"../bin/boost/libs/spirit/test" -I"../libs/spirit" -I".." -I"/usr/include" -I"/boost/head-regression/boost" -o "../bin/boost/libs/spirit/test/ast_calc_tests.test/intel-8.0-linux/debug/ast_calc_tests.o" "../libs/spirit/test/./ast_calc_tests.cpp" ? This obviously looks like a compiler issue, but before I mark it up as such I'd like to hear if anybody has to say anything on it. There are more Spirit tests failing in a similar manner on this configuration -- see http://tinyurl.com/5dtbz. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RE: [boost] outputformatters - using just one decorator string
by Reece Dunn 22 Sep '04

22 Sep '04

John Torjo wrote: >Hi Reece, > >This just popped into my head. A lot of confusion seems to come from how >you pass decorators. What I'm trying to say is that it can be very >difficult to get the decorator strings right (especially for more complex >things like XML) from the first time. > >I would suggest every formatter takes only one string which parses and >finds all decorators itself. >Each formatter will have one or more escape sequences which it uses to find >the decorators. > >Something like: > >// in this case, '%' is used for identifying an element >// '*' is to mean "leave default" (don't change) > >std::vector<int> v; >// equivalent to your "[ ", ", ", " ]" >std::cout << formatob(v, "[ %, % ]"); This looks good :) On the implementation side it would require splitting the string into the 2/3 components and constructing the decorators accordingly. Maybe defining an "extract_decorators" function internally, so wrapper_decorators and sequence_decorators can process this internally. How about: std::cout << io::object( v )( "[ %, % ]" ); I am sure this would be feasible. >// eq. to "<< ", " | ", " >>" >std::cout << formatob(v, "<< % | % >>"); > >// set only open/close decorators >std::cout << formatob(v, "<< %*% >>"); Here, you would need special handling of string == "*". This should also be implementable. >// sets only the separator >std::cout << formatob(v, "*% | %*"); > >// for pair - you have "%1" and "%2" >std::vector< std::pair<int,long> > vp; >// write XML >std::cout << formatob(vp, > containerfmt("<elem> % </elem><elem> % </elem>", > pairfrt("<int>%1</int><long>%2</long>"))); Here, you don't need %1 and %2. You just do: "<int>%</int><long>%</long>". >How's that? In terms of implementability, I don't see a problem. The two issues I have are: [1] What are the performance penalties for this? [2] What if you want '%' or '*' in your format string, e.g. "[ a * b * c ]"? You would thus need to implement some sort of escaping capability. NOTE: This could sit along side using the 'decorate' function and Volodya's idea for expressions, e.g.: io::object( v, "<<" + fmt::container( fmt::pair()( "<a>%</a>%" )) + " >>" ).decorate( " : " ); // output: << <a>2.75</a>1 : <a>3.14159</a>7 >> Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Support Requests-1032391 ] bug in boost using STLport?
by SourceForge.net 22 Sep '04

22 Sep '04

Support Requests item #1032391, was opened at 2004-09-22 07:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1032391&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andi (andreasfuchs) Assigned to: Nobody/Anonymous (nobody) Summary: bug in boost using STLport? Initial Comment: Hi, I want to run a project under Visual .Net 2003 using boost1.31.0 and STLport. Compilation and linking runs perfect. But if I start the excecutable the debugger terminates with an "Access violation" error at at line 97 in _construct.h of STLport. I posted this message to the STLport forum. They told me that this could also be a bug in the boost library because before this error occurs some boost functions are called. So are there any known bugs using boost together with STLport und Visual .Net? Any help would be appreciated. Thanks a lot Andi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1032391&group_… ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] OutFrmt lib design questions
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> >Here some question I've got while reading submitted library. > > > >1. What is an advantage if using this library for scalar types (vs. > >defining > >operator<<) > > Do you mean for things like int, Person, etc. If that is the > case, the > default behaviour of the library is to delegate output of > these types to > operator<<, so it doesn't do much. However, with support for a > fmt::serialize formatter that calls 'serialize' instead of > <<, you can > register a particular class as being serializable so my type > deduction > system knows to associate instances of that type with > fmt::serialize, so you > can then do: > > // new design > std::cout << io::object( my_serializable_object ) << '\n'; > std::cout << io::object( vec_of_serializable_objects ) << > '\n'; // [ ..., > ..., ... ] I don't really interested in another serialization library. We already have one. > The advantage of using this for things like std::complex or > boost::math::quaternion that already supply << and >> > operators is if you > want to have control over how a type is rendered, e.g.: > > // new design > std::cout << io::object( complex_val ).decorate( "", "", " + i" ) > << " = " << io::object( complex_val ).decorate( "( ", " > )" ) << '\n'; And you believe that I will keep repeating this code every time I need to print my complex value? > >2. If primary target is collection formatting wouldn't it be > better to > >name library "collection formats something"? > > This is a good idea. The name is from when the library just > had output > support, thus the "outfmt" directory in the sandbox. I am > thinking about > moving to a "formatter" directory. What do other people think? > > >3. If there is a way to assign format to collection/type combination > >permanently (through global operator <<), why would I want > to do it in > >every instance of output operation? > > Do you mean: > std::vector< int > vec; > std::cout << "vector = " << vec << '\n'; // [1] > std::cout << "vector = " << io::formatob( vec ) << '\n'; // [2] > > using [1] vs using [2]? If so, these are the same, but the > second allows you > to customize the decoration around the sequence, for example: > std::cout << io::formatob( vec ).format( " : " ); // [ 1 : > 2 : 3 : 4 ] No my question was Is there a way to assign custom (meaning different from one you selected) decoration permanently. > >4. What is an advantage of using this library to assign format to > >collection/type combination permanently vs. explicit implementation > >(using FOREACH construct for example) > > Using a foreach construct you would need to hand-code the surrounding > decoration, e.g.: > > // output: { a + b + c } > std::cout << "{ "; > foreach( char ch : vec ) > { > std::cout << ch; > if( !atend ) std::cout << " + "; > } > std::cout << " }"; > > vs: > > std::cout << io::formatob( vec ).format( "{ ", " }", " + " ); // output: > { a + b + c } > > If you have a nested construct, such as int tictactoe[ 3 ][ 3 > ], std::list< > std::list< float > > or math::matrix4x4< float > then > outputting/inputting > it manually would be more complex, whereas my library has all > the machinery > to handle this simply. Yeah. But I do it only once. And using foreach is way more flexible. I don't believe your library bring any advantage in this scenario. > >5. Why do we need boost::io::range? Couldn't we use boost::range > >instead? > > I suppose it would be possible to use > boost::range::make_iterator_range > instead. The only thing I have against this is its length. Consider: > > // new design > using boost::range::make_iterator_range; > namespace range = boost::range; > namespace io = boost::io; > > std::cout << io::object( range::make_iterator_range( i, i > + 7 )); // [1] > std::cout << io::object( make_iterator_range( i, i + 7 )); // [2] > std::cout << io::object( io::range( i, i + 7 )); // [3] > > If only you could alias functions, e.g.: > namespace io{ alias range = boost::range::make_iterator_range; } IMO you shouldn't introduce yet another range notion. > >6. In a formatter usage how would I guess what is what? > > boost::io::formatter< char * > fmt( "\ ", " /", " | " ); > > boost::io::formatob( vec, > boost::io::containerfmt()).format( fmt ); > > I have revised the names, so that is now: > namespace fmt = boost::io::format; > > io::sequence_decorators< char > seq( "\\ ", " /", " | " ); > io::object( vec, fmt::container()).decorate( seq ); IMO it's really bad idea to introduce interfaces that change meaning depend on number of arguments of the same type. Moreover it easy to confuse one with another. Your interface: ( str1, str2, str3 ) - open, close, separator ( str1, str2 ) - open, close ( str1 ) - separator Now If I do not use your library on everyday basis, And look on invocation of first function - how would I now what is what. There should be something that tell explicitly - here is open/close brackets, here is separator. > >7. Who come format calls order dependent? > > boost::io::formatob( vec, boost::io::containerfmt()).format( fmt > >).format( > >" : " ); > > format( fmt ) is called first, then format( " : " ). Thus, > you will have "\ > a : b : c /" as the formatting. You did not answer the question. I believe that interface is incorrect if it order dependent > >9. Let say I print vector<char>. Is there way to print it > like this: { > >'a', 'b', 0x01, ' ' } Actually I did not want '' around hex value - intent was to print array in c++ format. > Yes. You need to provide a wrappedfmt() format object. For example: > > formatob( vec, containerfmt( wrappedfmt().format( "'", "'" > ))).format( "{ > ", " }" ); > // output: { 'a', 'b', 'c' } So this wouldn't wark for me since I do not want '' around some of the values. > With the 0x01 character, special treatment needs to be > applied. You will > need to supply a custom format object to see if the character > is printable, > e.g.: > [your 20 lines solution skipped] IMO In this scenario your library doesn't stand a comparison with handcrafted solution. > > Regards, > Reece Gennadiy.

2 2

Patch for program_options<mingw>
by Janusz Piwowarski 22 Sep '04

22 Sep '04

Hello I'm attaching patch for program_options which fixes known problem with wstring in mingw. Regards, Janusz

2 2

RE: [boost] immutable string
by Ben Hutchings 22 Sep '04

22 Sep '04

Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: > I've been working on a small library - an immutable C++ string. Now > it is in usable state and has been put in use in a couple of real > projects. > Although it needs further polishing, I would like to know is there > any interest in such a library? Great stuff. I certainly think it would be useful to have a light- weight string. > Here is the link: http://conststring.sourceforge.net/ There's one possible problem I noticed, which is that an allocated buffer will be aligned properly for boost::detail::atomic_count but perhaps might not be aligned properly for char_t (or to whatever buffer_storage_alignment specifies). Let me apply the James Kanze test [*]: is it safe to create a const_string<double> on a SPARC? [*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you don't know what I'm talking about. Ben.

3 4

RE: [boost] RE: Re: Formal review of "Output Formatters" librarybeginstoday
by Reece Dunn 22 Sep '04

22 Sep '04

Vladimir Prus wrote: >Reece Dunn wrote: > > > You can explicitally state where/how new lines and indentation are going > > to be within my library by adding them to the open/close/separator > > formatting (see output-3D.cpp for an example). > >Yes, but I'd rather write > > os << v > >and have the right formatting, even if 'v' is a vector of something, which >has vector members, and the vector element type has another vector member, >and so on... This would further complicate the implementation of the library. To do what you want would require something similar to the Cascading Style Sheet proposal to maintain the default values for each format object type. This would be more complex for it to handle std::vector and std::list separately, but it may be possible to use the ID returned by type traits (differentiating sequential, associative and set containers). >The wrapping is indeed a separate issue. What I was asking is support of >indenting in your library. For example, the output such as >[snip] >Yes, except that I'd want "multiline" to act recursively, so if I print >vector of maps, the result will look like: >[ > { > a: 1 > b: 2 > } > { > c: 3 > } >] > >or using a different syntax. It would be possible to make use of a state object: a state object is an object that is rendered before or after an element is rendered. The implementation of this using the review version would be complex, but possible. I was considering adding pre+post support for a state object. Another idea is to implement an "event object" that gets called at the various stages of output. e.g.: Event::handler( before_decorator( io::open_decorator_id )); os << open; Event::handler( after_decorator( io::open_decorator_id )); // ... I'll need to think about this. >I'd suggest that you at least try to make top-level functions non-inline. >That would reduce the code size for application which use your library -- >I've had this experience both with program_options and function. For a >single library, it's probably not a huge difference, but if all libraries >use inline less liberaly, the code size of C++ apps would be lower. ok. noted. > >>I might be missing something, but the mechanism for getting the type of > >>formatter from a type to be output seems too complex. First, the > >>type_deducer.hpp file is used, and 'select' computes a 'category'. Then > >>format_deducer.hpp takes the category, and again uses 'select' to obtain > >>the real type of formatter. Why the type_deducer.hpp is needed? > >... > > > template<> struct deduce_type< io::seq_container_type > > > { > > template< typename CharT, typename T > > > struct type_from > > { > > typedef typename T::value_type value_type; > > typedef typename get_deducer< CharT, value_type >::type > > value_deducer; > > > > typedef container_t > > < CharT, typename value_deducer::format_object > format_object; > > > > static format_object deduce( const T & ) > > { > > return( format_object( value_deducer::deduce( >value_type()))); > >Does this expects the T::value_type is DefaultConstructible? IIRC, >containers only require that objects be CopyConstructible and Assignable. Don't std::list implementations work like: struct list_node { T value; list_node * prev, next; }; typedef list_node list_node_block[ 100 ]; // ... so T needs to be DefaultConstructible. I'll need to consult C++98 to be sure. > > } > >Still, I don't understand the need for integer type category. Can't you >have > > 'deduce_sequence_type' > 'deduce_pair_type' > >and so on, and use 'select' to map a type directly into those classes, not >into integer? Then I would need to do: select < is_std_vector< T >, deduce_sequence_type, is_std_list< T >, deduce_sequence_type, ... > This would not allow you to add a new container type into the mechanism without obtrusively altering the code. Also, there is a limit to the number of template parameters on select. The present system simplifies this by mapping to a category. (This also allows you to write more generic code, for example fmt::pair is implemented using these categories to work out how the pair type is constructed and fmt::container uses it to provide different behaviour for sequential, associative and set-based containers). In the new type deduction system, I map type --> type to extract a format object type, e.g. assoc_container_type to seq_container_type. This allows you to only provide one template overload. This system is more extensible than the review version (using select). > >> "providing an extensible framework that sits" > >> > >>How it's extensible? I see only one section about extending and it's >just > >>one paragraph long > > > > I really need to add more documentation regarding this. The idea is that > > you can: > > > > * add your own decorators (delimiters in the review docs) to support >more > > complex types (e.g. trees and graphs). > >That's interesting. Can you explain? You can write a class similar to [openclose_]formatter to add your own decorator type, e.g.: // new style template< typename CharT > struct binary_tree_decorators { decoration< CharT, 3 > left; decoration< CharT, 4 > right; // ... }; where 3 and 4 are the decorator IDs for the left and right decorations. You can then make use of this in a tree format object, e.g.: os << tree.left << left << tree.value << right << tree.right; resulting in something like: 1 <-- 2 --> 3 combining this with fmt::wrapper: [[1] <-- 2 --> [3] ] <-- 4 --> [[] <-- 5 --> [[6] <-- 7 --> []]] This is just an example. Consideration would need to be given to how the data is nested and how it interacts with the rest of the library. > > Underlying type is: typeid(ob).name(). > >Sorry, that's the name of type ;-) Maybe you just mean "according to its >type?" (also note "its", not "it's"). The "underlying" implies there's some >another type, besides 'T'. yes! >Maybe, you can use something like: > > "The 'object' function can only output a container, so to output a range > of iterators you need to make a container from it using io::range". "output a container": the argument is not necessarily a container (e.g. std::pair). How about: "The 'object' function can only output an object of type T (it cannot output ranges declared using two arguments), so to output a range of iterators you need to make a container-like object from it using io::range". >The original sentence sounds like the format is something external to >openclose_formatter, and the class is just a proxy which allows to set it. It is a holder for several decorations (e.g. open/close or open/close/separator), allowing you to set more than one of these and - in the discussion of using expressions - dealing with the evaluation of one of these expressions, e.g.: fmt::container() / " + " > >>The code block before > >>this comment defines two classes openclose_formatter_t and > >>openclose_formatter. Is this a typo, or you really have two classes? > > > > This is not a typo. The _t variants take a template parameter that > > contains the return value of the 'format' ('decorate') functions. This >is > > so that: > > std::cout << io::object( vec, fmt::container().decorate( " | " )); > > works properly. > >Why don't 'decorate' return the same type as 'fmt::container()'? Because they are implemented in wrapper_decorators_t [review version: openclose_formatter_t] and sequence_decorators_t [formatter_t]. To return the same type as fmt::container() would require implementing the 'decorate' function in the fmt::basic_container class (i.e. implementing 5 or 6 functions). You would need to do this for all the other format objects, including the ones that the user writes, so why do this? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: Formal review of "Output Formatters" library beginstoday
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

Hi, I would like to start with resolution. I vote NOT to accept this submission. Here some more details: > 1. What is your evaluation of the design? Library trying to solve in fact trivial problem. Would it be presented as trivial function Template<typename C> Foo( C const& c, std::string open, std::string close, std::string sep ); I may understand it. As to presented design - I see it as unnecessary complicated. And in many cases simply incorrect. Library does not follow standard practice as to wide char support. Interfaces seem confusing and error prone. Decoration model seems too simple to warrant so much trouble as reusable library. Maybe more powerful/flexible solution should be considered. > 2. What is your evaluation of the implementation? In most part I either don't understand or don't like it. IMO simple task library trying to solve shouldn't require that much code. Simple overloading base solution should've done the trick. > 3. What is your evaluation of the documentation? Did not get to this stage. > 4. What is your evaluation of the potential usefulness of the library? Now to the most important: why would I ever want to use library like this? We have already: std::ostream boost::format boost::serailization In what scenario I would use this library? I most definitely wouldn't want to repeat all this formatting every time I need to output my vector. If I write output operation rarely - I would use explicit loop -it's more flexible anyway. If I write output operation frequently - I would separate in function and here again would use explicit loop for the same reasons. If I write many output functions like above - I would write wrapper function like in 1. And it will work for most collections. I wouldn't use this library for filtering - we will have iostreams library for that (If I am not mistaken). I wouldn't use this library for XML printing - why would I want to mention tag name twice? Anybody? > 5. Did you try to use the library? Did not get to this stage. > 6. How much effort did you put into your evaluation? A quick In-depth study. > 7. Are you knowledgeable about the problem domain? That's the main issue - I do not see problem domain. Regards, Gennadiy.

2 1

Re:RE: [boost] Re: FORMAL Review of "Output Formatter" library -
by Reece Dunn 22 Sep '04

22 Sep '04

Robert Ramey wrote: > > Although my library is still under review, I am re-architecturing it > >based on the feedback thus far. This post is the code associated with >what > > was the delimiters/formatters part of the library. They are now given >the > > better name of "decorators". > >If your making changes in the library already, maybe you might want to >consider withdrawing it from the formal review and re-submitting it after >you've made all the changes you want to make. It might be easier (for you >as well as for reviewers) than going through the whole process more than >once. IIUC, the serialization library went through several reviews before being accepted. This is the best place to get decent feedback on a library from the most people. If I withdraw the library, there may be a comment that I miss (because the reviewer has not posted it since the library is withdrawn) that makes an important point. I have had lots of feedback regarding the names of the various components. The changes I have made are an attempt to pre-emptively address these issues and to say that I am taking all the comments into consideration. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

6 11

Re: [boost] RE: OutFrmt lib design questions
by Reece Dunn 22 Sep '04

22 Sep '04

John Torjo wrote: >>>>2. If primary target is collection formatting wouldn't it be better to >>>>name library "collection formats something"? >>> >>>This is a good idea. The name is from when the library just had output >>>support, thus the "outfmt" directory in the sandbox. I am thinking about >>>moving to a "formatter" directory. What do other people think? >> >> >>I'm -1. Having "format" and "formatter" is confusing. The name should >>somehow mention that you format data structures. > >I second that - 'formatter' is just confusing. >However, something like 'coll_format' or 'sequence_format' - I'm ok with >them. 'coll_format' has got my vote :) Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 2

Regression: avoid cleanup of binaries
by Stefan Slapeta 21 Sep '04

21 Sep '04

After the regression tests there seems to be a total cleanup of the binaries. Is it possible to avoid this in some way? (maybe specifying --incremental is the solution, but I would rather guess letting away this option should clean up the binaries _before_ the test run, shouldn't it?!?) Stefan

3 4

[shared_ptr] InterlockedIncrement rocks!
by John Torjo 21 Sep '04

21 Sep '04

Hi Peter, I just took your implementation (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) for shared_ptr and use it now in win32gui (upcoming v1.4.2). Using Interlocked* for win32 totally rocks! From my tests - Interlocked* are very fast. They're about twice as slow as a raw increment (or my tests are wrong;)). From what I see - I think you can certainly merge them into boost::shared_ptr. Maybe users can select the old version or this Interlocked* version with a certain macro - like BOOST_SHARED_PTR_USE_INTERLOCKED. Also, why not including windows.h directly, like this: #define WIN32_LEAN_AND_MEAN #include <windows.h> <side-note> From my tests it seems your version as is now fails to link for gcc (unresolved external _InterlockedIncrement/_InterlockedDecrement). However, if #including <windows.h> and use InterlockedIncrement/Decrement - they work. </side-note> Best, John -- John Torjo -- 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.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 21 Sep '04

21 Sep '04

> >>Also, why not including windows.h directly, like this: > >>#define WIN32_LEAN_AND_MEAN > >>#include <windows.h> > > > > > > I believe WIN32_EXTRA_LEAN may be even better. > > Just a thought - there is no WIN32_EXTRA_LEAN on vc7.1 Yes you are correct. I misremembered VC_EXTRALEAN, which is a similar macro, but for MFC only. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

Re: [boost] Re: [assign] fixes for msvc, msvc-stlport and vc7
by JOAQUIN LOPEZ MU?Z 21 Sep '04

21 Sep '04

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Martes, Septiembre 21, 2004 9:03 pm Asunto: [boost] Re: [assign] fixes for msvc, msvc-stlport and vc7 > Hi Joaquin, > [...] > > | 2. list_insert::operator()(T t) has been changed to accept > | a const reference instead. > > I have made this change as > > #if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) > > template< class T > > list_inserter& operator()( const T& t ) > #else > template< class T > > list_inserter& operator()( T t ) > #endif As you wrote it, the workaround applies only to MSVC 6.0. Let's wait for the next test cycle to see if it has to be extended to MSVC 7.0 as well. > > | With these changes, all tests build, though three of them > | crash at run-time (list_inserter, list_of and multi_index_container) > > ok, this is much better than before! some of the test a big and > fat and do > some tricky conversions...but just having the > basic stuff working is great! > > |I've got two questions: > | > |1. Could somebody (the author, I guess) validate these changes > |for commit? > > I have comitted them. > > |2. list_inserter follows a strange convention (IMHO) of not > |forcing template params to be const references in its various > |copy ctors and assignment operators, for instance: > | > |list_inserter( Function fun ); > |template< class T > > |list_inserter& operator=( T r ); > | > |Any reason for this approach? I don't know if this can pose > |problems, but to me having these qualified with const & seems > |like the usual way. > > yes, the bitches are char[N] and wchar_t[N] which does not convert > to char* > and wchar_t* otherwise. this comes up in simple stuff like > > vector<string> = list_of( "foo" )( "goobar" ); Ummm, I see. The fact is that here lies, I think, the reason for the three remaining crashes, all on calls to multi-argument versions of list_inserter::operator(). Maybe I'll give this some thinking over if I have some spare time tomorrow. > > of course, the Function arg could be const Function&, but is there any > difference in inline code? I think this can involve an extra copy under some circumstances, ans some compilers might not optimize this away. But in general I agree with you little is gained by having const Function &. > > Muchos gracias for the patch! Velbekomme :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: static_cast and const
by Ben Hutchings 21 Sep '04

21 Sep '04

Jonathan Turkanis <technews(a)kangaroologic.com> wrote: > "David Abrahams" <dave(a)boost-consulting.com> wrote in message > news:umzzl3pvk.fsf@boost-consulting.com... > > Richard Hadsell <hadsell(a)blueskystudios.com> writes: > > > > > Jonathan Turkanis wrote: > > > > > >>When I was writing it I initially typed 'const_cast', but then > > >>thought to myself: why use my big guns if I don't have to? ;-) > > >> > > > For clarity -- to tell the reader that you intended to modify the > > > const-ness. > > > > static_cast is a bigger gun than const_cast. At least const_cast > > cant violate data layout, and unless there is actually a constant > > object, won't result in undefined behavior. > > Good point. I guess part of the reason I avoid const_cast whenever > possible is that people look upon it suspiciously, even if it's only > adding cv-qualification. Maybe people should be more suspicious of > static_cast. If you want to make an implicit conversion explicit, use boost::implicit_cast.

3 3

dynamic scoping emulation - was Re: Lexical cast suggestion
by Jonathan Graehl 21 Sep '04

21 Sep '04

> > >Nope, there's only one global locale, it's not per-thread. If it's >per-thread, you can do > > std::locale::tss_global(std::locale("koi8-r")); > // do some work with program_options > std::locale::tss_global(std::locale("")); > I do this all the time (but using a scope guard), for globals I've declared thread-local. This essentially simulates dynamic scoping (which I'd prefer to see supported directly by the language, as an alternative to lexical scoping). Perhaps a Boost library for dynamically scoped properties would be nice? -Jonathan

1 0

RE: [boost] Avoiding warning on the do{...}while(0) macroimplementation trick
by Ben Hutchings 21 Sep '04

21 Sep '04

Ivan Vecerina wrote: > I've noticed discussions about this a couple of years ago. > For assert-style macros that include multiple statements, > a common idiom is to enclose the statements in a do{...}while(0) > dummy loop. This makes the macro behave like a single statement. > > A problem with some compilers (notably VC7.x) is that this > triggers a warning (C4127: conditional expression is constant). > > The workaround adopted by boost is to automatically disable > this warning -- which however can be legitimate and useful > in user code. > > I think I have found a better 'always-false' condition which > does not trigger a warning, and works at least in VC7.1: > do{ }while(__LINE__==-1) > > Do you see a problem with this approach? <snip> It works in VC++ 7.1 if you enable "edit and continue", because this results in non-standard expansion of the __LINE__ macro to an expression that isn't a compile-time constant. In general it doesn't work.

3 2

[assign] MSVC support?
by Aleksey Gurtovoy 21 Sep '04

21 Sep '04

Is assign library unusable on MSVC < 7.1? If so, could the maintainer please mark it up as such in "boost/status/explicit-failures-markup.xml"? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 21 Sep '04

21 Sep '04

> Also, why not including windows.h directly, like this: > #define WIN32_LEAN_AND_MEAN > #include <windows.h> I believe WIN32_EXTRA_LEAN may be even better. > <side-note> > From my tests it seems your version as is now fails to link > for gcc (unresolved external > _InterlockedIncrement/_InterlockedDecrement). > However, if #including <windows.h> and use > InterlockedIncrement/Decrement - they work. > </side-note> That is not suprising - Interlocked* are parts of the Win32 API. In fact, it has been a complete mistery to me as to why boost doesn't use atomic operations for its ref counting. The mutex on the counter was one of the big reasons why people here decided not to use shared_ptr. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

RE: [boost] OutFmt library implementation questions
by Rozental, Gennadiy 21 Sep '04

21 Sep '04

> >2. Why doesn't insert_iterator is implemented using iterator_facade? > > [1] I am not that familiar with using iterator_facade > [2] Is it worth the abstraction penalties? Compring to output operations? > >4. How does this all machinery will work with wchar_t? > > std::wcout << formatob( vec, containerfmtex< wchar_t * > >()).format( L" - > " ); > > Use the ex< DelimiterType > variant on the innermost construct. This is inacceptable and does not follow standard practice. > >5. Why do you need static_cast< const base_type * > to cast > to the base > >type > >in container.hpp? > > This is a VC 6.x workaround. But you don't list this compiler amoung supported. > >6. Why the same entity you sometime call format_type and sometime > >DelimeterType? > > format_type is the typedefed version (should be delimiter_type) and > DelimiterType is the template parameter. So is it delimeter type or forat type - it can't be both. > >7. What deducer is supposed to deduce? I couldn't get > through all the > >details, but couldn't the same be achieved using partial > specialization > >and/or partial ordering. Cause it look way too complex and > unnecessary. > > The deduction mechanism is used to evaluate what type T is > (e.g. std::pair< > char, int >), what format object is needed to render it > (including nested > format objects) and to construct the appropriate format object. > > It could be possible to use partial specialization, but the > type traits are > used elsewhere to redirect formatting behaviour (e.g. when > reading in a > container do diffreent things if it is a sequential, > associative or set > container). IMO all that you needed is function overloading. I don't see a place for all these deduce/trats staff. > >9. What is RT2 stands for? > > ReturnType2. Do not abbreviate. > >11. Need for all this hierarchies: > >Formatter->formater_t->openclose_formatter_t > > This is to ensure that the return type of 'format' in Formatter > [FormatObject] is Formatter and not openclose_formatter_t. Thus: > formatob( vec, containerfmt().format( " / " )); > will work as intended without overriding 'format' in > containerfmt_t (created > by containerfmt()) to return the correct type. > > >openclose_formatter->openclose_formatter_t > > > >are completely unclear. Explanations presented in docs does not help > >since format methods seems to be returning *this anyway. > > They return: > *static_cast< ReturnType * >( this ) > to allow 'format' to return the correct type when inherited > in the format > objects. Formatob_t::format return *this. You did not answer my question. I still believe it's all unnecessary. > >Why couldn't we just use something trivial like > > > >template<char Ch> > >struct formatter > >{ > > std::basic_string<Ch> m_open; > > std::basic_string<Ch> m_close; > > std::basic_string<Ch> m_sep; > >}; > > > >Is beyond me. If any member is empty it means it missing. > > This is the direction I am going in the development version. The only > difference is that I am using io::decoration< CharT, int id > > instead of > std::basic_string< CharT >. The decoration class uses > std::basic_string to > store the values, while providing support for looking up the > default value > on a stream and an external function for checking for a match > on an input > stream. You presented library call *Output* formatter. Why do we talk about input at all. > >14. list_object -> formatter_t inheritance look wrong. > Where is IS A > >relationship? > > list_object *isa* formatter_t *isa* openclose_formatter_t > > using the new design: > > list_object *isa* sequence_decorators_t *isa* > wrapper_decorators_t *hasa* > decoration List_object IS A formatter ???? Something really worng with naming here. > Regards, > Reece Gennadiy.

1 0

immutable string
by Maxim Yegorushkin 21 Sep '04

21 Sep '04

Hello all, I've been working on a small library - an immutable C++ string. Now it is in usable state and has been put in use in a couple of real projects. Although it needs further polishing, I would like to know is there any interest in such a library? Here is the link: http://conststring.sourceforge.net/ -- Maxim Yegorushkin

10 21

RE: [boost] OutFrmt lib design questions
by Reece Dunn 21 Sep '04

21 Sep '04

Rozental, Gennadiy wrote: >Here some question I've got while reading submitted library. > >1. What is an advantage if using this library for scalar types (vs. >defining >operator<<) Do you mean for things like int, Person, etc. If that is the case, the default behaviour of the library is to delegate output of these types to operator<<, so it doesn't do much. However, with support for a fmt::serialize formatter that calls 'serialize' instead of <<, you can register a particular class as being serializable so my type deduction system knows to associate instances of that type with fmt::serialize, so you can then do: // new design std::cout << io::object( my_serializable_object ) << '\n'; std::cout << io::object( vec_of_serializable_objects ) << '\n'; // [ ..., ..., ... ] The advantage of using this for things like std::complex or boost::math::quaternion that already supply << and >> operators is if you want to have control over how a type is rendered, e.g.: // new design std::cout << io::object( complex_val ).decorate( "", "", " + i" ) << " = " << io::object( complex_val ).decorate( "( ", " )" ) << '\n'; >2. If primary target is collection formatting wouldn't it be better to name >library "collection formats something"? This is a good idea. The name is from when the library just had output support, thus the "outfmt" directory in the sandbox. I am thinking about moving to a "formatter" directory. What do other people think? >3. If there is a way to assign format to collection/type combination >permanently (through global operator <<), why would I want to do it in >every >instance of output operation? Do you mean: std::vector< int > vec; std::cout << "vector = " << vec << '\n'; // [1] std::cout << "vector = " << io::formatob( vec ) << '\n'; // [2] using [1] vs using [2]? If so, these are the same, but the second allows you to customize the decoration around the sequence, for example: std::cout << io::formatob( vec ).format( " : " ); // [ 1 : 2 : 3 : 4 ] >4. What is an advantage of using this library to assign format to >collection/type combination permanently vs. explicit implementation (using >FOREACH construct for example) Using a foreach construct you would need to hand-code the surrounding decoration, e.g.: // output: { a + b + c } std::cout << "{ "; foreach( char ch : vec ) { std::cout << ch; if( !atend ) std::cout << " + "; } std::cout << " }"; vs: std::cout << io::formatob( vec ).format( "{ ", " }", " + " ); // output: { a + b + c } If you have a nested construct, such as int tictactoe[ 3 ][ 3 ], std::list< std::list< float > > or math::matrix4x4< float > then outputting/inputting it manually would be more complex, whereas my library has all the machinery to handle this simply. >5. Why do we need boost::io::range? Couldn't we use boost::range instead? I suppose it would be possible to use boost::range::make_iterator_range instead. The only thing I have against this is its length. Consider: // new design using boost::range::make_iterator_range; namespace range = boost::range; namespace io = boost::io; std::cout << io::object( range::make_iterator_range( i, i + 7 )); // [1] std::cout << io::object( make_iterator_range( i, i + 7 )); // [2] std::cout << io::object( io::range( i, i + 7 )); // [3] If only you could alias functions, e.g.: namespace io{ alias range = boost::range::make_iterator_range; } >6. In a formatter usage how would I guess what is what? > boost::io::formatter< char * > fmt( "\ ", " /", " | " ); > boost::io::formatob( vec, boost::io::containerfmt()).format( fmt ); I have revised the names, so that is now: namespace fmt = boost::io::format; io::sequence_decorators< char > seq( "\\ ", " /", " | " ); io::object( vec, fmt::container()).decorate( seq ); >7. Who come format calls order dependent? > boost::io::formatob( vec, boost::io::containerfmt()).format( fmt >).format( >" : " ); format( fmt ) is called first, then format( " : " ). Thus, you will have "\ a : b : c /" as the formatting. >8. If I got vector<vector<int> >. How do I supply separators for both >internal and external vectors? You apply the 'format' function to containerfmt(). For example: boost::io::formatob( vec, containerfmt( containerfmt().format( " : " )).format( " + " )); // output: [ [ a : b : c ] + [ x : y : z ] + ... ] >9. Let say I print vector<char>. Is there way to print it like this: { 'a', >'b', '0x01', ' ' } Yes. You need to provide a wrappedfmt() format object. For example: formatob( vec, containerfmt( wrappedfmt().format( "'", "'" ))).format( "{ ", " }" ); // output: { 'a', 'b', 'c' } With the 0x01 character, special treatment needs to be applied. You will need to supply a custom format object to see if the character is printable, e.g.: class char_escape { public: typedef void traits_type; typedef const char * format_type; typedef boost::io::seq_type< -1 > formatter_type; public: template< typename CharT, typename TraitsT > static std::basic_ostream< CharT, TraitsT > & write( std::basic_ostream< CharT, TraitsT > & os, CharT value ) const { if( isprintable( value )) return( os << value ); return( os << "0x" << int( value )); } }; formatob( vec, containerfmt( wrappedfmt( char_escape()).format( "'", "'" ))).format( "{ ", " }" ); // output: { 'a', 'b', 'c' } Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

Outdated GCC versions checks with BOOST_TESTED_AT()
by Jonathan Wakely 21 Sep '04

21 Sep '04

There's an out-of-date workaround in dynamic_bitset/config.hpp, which tests the compiler version to see if a GCC bug is still present. The bug is still present in GCC 3.4, so BOOST_TESTED_AT should test 30400. Also, boost/variant/detail/move.hpp contains this: #if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP) \ || BOOST_WORKAROUND(__GNUC__, BOOST_TESTED_AT(2)) Should that be changed? IIUC that means that GCC 3.x uses the workaround for non-ADL compilers. Since GCC 3.x has pretty good (not perfect) ADL, and since the BOOST_TESTED_AT is outdated, that test should be changed. Finally, boost/iterator/detail/config_def.hpp tests # if BOOST_WORKAROUND(__GNUC__, == 2) && BOOST_WORKAROUND(__GNUC_MINOR__, BOOST_TESTED_AT(95)) \ This looks outdated - there will be no more GCC 2.x releases and I would be surprised if vendor-specific releases such as RedHat's GCC 2.96 fixed that issue, but GCC 3 probably did. I can check this assumption if someone can provide a testcase but I would expect the test can be changed to simply: # if BOOST_WORKAROUND(__GNUC__, == 2) \ since it applies to all known version of GCC 2.x, and there will not be any more 2.x releases. The attached patches make the first two changes. I have left the third, since it doesn't affect GCC 3.x so is doing no harm, and because I'm not sure the bug has been fixed. jon -- I listen a lot and talk less. You can't learn anything when you're talking. - Bing Crosby

1 0

Boost.Python/vc6 regressions
by David Abrahams 21 Sep '04

21 Sep '04

Due to what appears to be an MPL problem, neither libs/python/test/polymorphism.cpp nor libs/python/test/polymorphism2.cpp are compiling on vc6. This fact is reflected only strangely by the posted regression log, as white cells. Here is the error output: ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** ***************************************************************************** -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] OutFmt library implementation questions
by Reece Dunn 21 Sep '04

21 Sep '04

Rozental, Gennadiy wrote: >Here some implementation questions I've got: > >1. Why does the library brake const correctness. FWIV I could write: > > const vector<int>& v = ...; > > std::cin >> io::formatob( v ); > > and it would compile without questions. I'll try to resolve this issue. >2. Why doesn't insert_iterator is implemented using iterator_facade? [1] I am not that familiar with using iterator_facade [2] Is it worth the abstraction penalties? >3. Why do you need 2 different functions containerfmtex and containerfmt? This was so that older compilers (e.g. VC 7.0) could resolve the arguments correctly. The new implementation just uses the single function name. >4. How does this all machinery will work with wchar_t? std::wcout << formatob( vec, containerfmtex< wchar_t * >()).format( L" - " ); Use the ex< DelimiterType > variant on the innermost construct. >5. Why do you need static_cast< const base_type * > to cast to the base >type >in container.hpp? This is a VC 6.x workaround. >6. Why the same entity you sometime call format_type and sometime >DelimeterType? format_type is the typedefed version (should be delimiter_type) and DelimiterType is the template parameter. >7. What deducer is supposed to deduce? I couldn't get through all the >details, but couldn't the same be achieved using partial specialization >and/or partial ordering. Cause it look way too complex and unnecessary. The deduction mechanism is used to evaluate what type T is (e.g. std::pair< char, int >), what format object is needed to render it (including nested format objects) and to construct the appropriate format object. It could be possible to use partial specialization, but the type traits are used elsewhere to redirect formatting behaviour (e.g. when reading in a container do diffreent things if it is a sequential, associative or set container). >8. Why class formatter, formatter_t is defined in namespace io, while it >reside among details headers? It is included in the <boost/outfmt/formatter.hpp> header. In the new version, these are in an "impl" directory, i.e. are part of the implementation and should not be included directly. >9. What is RT2 stands for? ReturnType2. >10. detail/formatter.hpp refer to openclose_formatter_t, but does not >include no headers. See question [8]. >11. Need for all this hierarchies: >Formatter->formater_t->openclose_formatter_t This is to ensure that the return type of 'format' in Formatter [FormatObject] is Formatter and not openclose_formatter_t. Thus: formatob( vec, containerfmt().format( " / " )); will work as intended without overriding 'format' in containerfmt_t (created by containerfmt()) to return the correct type. >openclose_formatter->openclose_formatter_t > >are completely unclear. Explanations presented in docs does not help since >format methods seems to be returning *this anyway. They return: *static_cast< ReturnType * >( this ) to allow 'format' to return the correct type when inherited in the format objects. >Why couldn't we just use something trivial like > >template<char Ch> >struct formatter >{ > std::basic_string<Ch> m_open; > std::basic_string<Ch> m_close; > std::basic_string<Ch> m_sep; >}; > >Is beyond me. If any member is empty it means it missing. This is the direction I am going in the development version. The only difference is that I am using io::decoration< CharT, int id > instead of std::basic_string< CharT >. The decoration class uses std::basic_string to store the values, while providing support for looking up the default value on a stream and an external function for checking for a match on an input stream. >12. select and switch templates seems useful. Why doesn't MPL provide >these? I don't know. Dave? >13. Doesn't MPL provide eq_int, lt_int? I think so. I am not an MPL expert. I should really fix this. >13. struct selector needs to be PP generated Again, I am not a PP expert. I will look into this. >14. list_object -> formatter_t inheritance look wrong. Where is IS A >relationship? list_object *isa* formatter_t *isa* openclose_formatter_t using the new design: list_object *isa* sequence_decorators_t *isa* wrapper_decorators_t *hasa* decoration >15. You couldn't do this: typename InputStream::char_type ch = '\0'; Since the new version takes template< typename CharT > across the board, this is now: CharT ch = CharT(); So I have fixed the problem. Regards, Reece _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

1 0

Re: Lexical cast suggestion
by Martin Adrian 21 Sep '04

21 Sep '04

Sorry for not keeping the thread. Got some strange errors from when using followup in gmane >I think that it's not such a big problem. If you want to use locales, then >your application should start with: > > std::locale::global(std::locale("")); > >after that, I think lexical_cast will use the default user's locale. Or you >can replace "" above with something else that your application wants. The >only problem is that it's not possible to use several locales in one >application. For program_options, it's not very important. > >Why do you need to specify locales for call to 'lexical_cast'? There are two different cases here. The first one is when you are communicating with the user (e.g. via a GUI). You will then ofcourse use the system locale to format output and parse input. Since c++ defaults to the "C" locale you need to add the line you mention above to get streams, sorting etc to work properly. But, it is also common to do things in an application that doesn't follow the system globale like parsing and writing xml or csv files, generating SQL statements etc. (program options might fall into theis category as well) For the two cases above you need to use different locales. Since lexical_cast doesn't allow you to specify which locale to use it can only be used for one of the cases above. The current implementation uses the global locale which basicly means that it should only be used for communication with the user. Since there seem to be a strong opinion against specifiying locale for lexical_cast I'm hoping that the documentation is updated to warn about lexical_cast for other things than communicating with the user. I learned it myself the hard way. When it comes to program options the author has decided to use lexical_cast and the global locale to verify input. It might be a good choice but it means that you can't move configuration files between computers with different locales. Better documentation might be sufficient here as well but there might also be other problems (like space as thousand separators on integers).

4 6

RE: [boost] Re: platform specific structures
by Ben Hutchings 21 Sep '04

21 Sep '04

Matt Hurd <matt.hurd(a)gmail.com> wrote: > Alexander Terekhov <terekhov(a)web.de> wrote: > > > > Matt Hurd wrote: > > [...] > > > > >> But why is a concurrent-aware setter useful if its effects > > > > >> aren't visible to the other threads? > > > > > > > > > > In what way do you mean they not visible? > > > > > > > > > > Such aligned memory operations are guaranteed to be atomic on > > > > > ia32 at a system wide level AFAIK. > > > > > > > > On IA32, sure, but not on other architectures. > > > > > > Yup. Which gets back to the subject line... > > > > On IA32, > > > > - stores have release semantics (sink-load/store mbar for > > preceding loads/stores in the program order); > > > > - loads have acquire semantics (hoist-load/store mbar for > > subsequent loads/stores in the program order); > > > > - lock instructions have compound release and acquire semantics > > (fully fenced). > > > > See Plan9 story for an illustration of lockless stuff that > > needs store-load fence (compound sink-store and hoist-load mbar) > > on IA32. > > > > http://groups.google.com/groups?selm=414E9E40.A66D4F48%40web.de > > (Subject: std::msync) > > > > regards, > > alexander. > > Always insightful, thanks Alexander. However, I'm not talking about > guarantees of ordering or timing, just "eventual" visibility. If a change to a variable is not followed by what the compiler sees as a release then the change could perhaps be moved into a following critical section, resulting in deadlock. See the last paragraph of <http://groups.google.com/groups?selm=409A193B.7DD71861%40xemaps.com> (further up the thread Alexander pointed at). Note also that the compiler could also hoist the test of the control variable out of the loop if it can tell that nothing in that loop will modify the control variable. This seems to me to be a more likely problem. It is possible that "volatile" may help you to ensure visibility, but the semantics of volatile are implementation-dependent and not well specified. <snip> > By the way, when you say ia32 which architectures are you referring > to, as they have varied quite a bit on their capabilities from 386 to > P4 & Xeon? <snip> The ordering guarantees remain much the same though the atomicity guarantees have become stronger as the bus width increased from 16 bits (386SX) to 32 and 64 bits. Ben.

2 1

Re: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 21 Sep '04

21 Sep '04

John Torjo wrote: >>>My real observation is that I see this as orthogonal to serialization and >>>that it should remain that way. I don't seen any real overlap now except >>>that there might be a couple of instances where either one might do. I >>>think even these would be rare cases. I would resist any idea to >>>intertwine these concepts. >> >>I'm lost. What are "these concepts"? What I propose is that the >>"serialize" >>method be usable by the outfmt library to generate more usable output. No >>other link between the two libraries is suggested. >> >I assume you suggest something like: >- if an object can be serialized, use that for output Is there a way to test if a class can be serialized. If that is the case, maybe it would be beneficial to add it into fmt::basic using MPL wizardry. I.e. can you do: mpl::if_< is_serializable< T >, ..., ... > ? >- if not, use default (operator<<) > >This seems ok to me. Reece? I was thinking of having a separate format object (fmt::serialize?) instead of complicating fmt::basic. You can then do: BOOST_IO_CLASSIFY( SerializableType, boost::io::serializable_type ) to add it into the type deduction mechanism, unless there is an is_serializable< T > trait. Alternatively, you would be able to explicitly designate to use 'serialize': io::object( people, fmt::container( fmt::serialize())); Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 21 Sep '04

21 Sep '04

Vladimir Prus wrote: >John Torjo wrote: > > > The FORMAL Review of "Output Formatter" library begins today, > > Sept 12, 2004. > >The primary case is debugging. I want to either output small vectors to >some >log/dump file (in which case the output will be small one-line), or output >some huge structures (vector<Function>, where Function has a lot of data). >In the latter case, the output should be multiline, with nice indentation, >or I won't understand anything. You can explicitally state where/how new lines and indentation are going to be within my library by adding them to the open/close/separator formatting (see output-3D.cpp for an example). As for more intelligent indentation, it is hard to know in advance if an object you are writing to the stream should be wrapped or not. This is where feeding it through Jonathan's library (via an indentation filter) would be useful. >A particularly interesting question is how the proposed library overlaps >with serialization. When outputting vector<Function> I'd prefer the content >of 'Function' to be outputted too, preferably by describing the members >with the 'serialize' method. The default behaviour for an unrecognised type is to output it directly to the stream so it will use the << operator associated with that type. If you want to use a particular method, such as 'serialize', then you will need to write your own format object that calls that function. > > 1. What is your evaluation of the design? > >There are some things I don't like. First, as many mentioned, the naming is >not optimal. For example: > > boost::io::formatob(v).format(" | "); The naming scheme for the various elements has undergone an overhaul. See my other posts for comments. From here on in, I will use the new naming, with: namespace io = boost::io; namespace fmt = boost::io::format; >or maybe even > > ("[" + io(v)/"," + "]") Cool! I shall look into trying to implement something like this. >It's desirable that the library support some multiline output style out of >the box, so that I could write: > > os << io::multiline(v) << ... Do you mean something like: std::cout << io::object( v ).decorate( "[\n ", "\n]", ",\n " ); resulting in: [ 1, 2, 3 ] > > 2. What is your evaluation of the implementation? > >There should be the <boost/outfmt.hpp> header, including everything else of >the library. ok >Some of the lines are longer than 80 characters (e.g. template header of >formatob_t has 111 characters). ok >Methods defined in the body of the class are implicitly inline, there's no >need to put the "inline" in front of them, as it's just one more word to >read. ok >I don't think defining methods in the class is a good idea -- this makes >the >class interface less obvious. I agree. I prefer to keep interface and implementation seperate, but MS VC (prior to 7.1) will choke on nested templates declared out of line, e.g.: template< typename T > struct foo { template< typename U > void bar(); template< typename U > void ok(){} }; template< typename T > template< typename U > // VC<=7.0 ==> error void foo< T >::bar(){} I also try to be consistent where possible, so don't tend to mix the two. >Why is the formatob_t necessary? It seems to work by delegating everything >to the underlying formatter. Can't the 'formatob' just return the >appropriate formatter? It's necessary because the format objects don't define << and it is necessary to keep a refererence to the object passed to it for formatting so that it can be accessed when inside the implementation of the << operator. >I might be missing something, but the mechanism for getting the type of >formatter from a type to be output seems too complex. First, the >type_deducer.hpp file is used, and 'select' computes a 'category'. Then >format_deducer.hpp takes the category, and again uses 'select' to obtain >the real type of formatter. Why the type_deducer.hpp is needed? I have been working on improving this. There are 3 parts to the type deduction: [1] identifying the type and mapping it to its generic type (e.g. container, array, etc.) This is done by type_traits.hpp. [2] working out the formatter type that is needed to render this to the stream. In the review implementation this is done by format_deducer.hpp, using the information gathered by type_deducer.hpp to compute the nested structure (e.g. std::vector< std::pair< char, std::list< int > > >). [3] creating an instance of the format object. This is also done by format_deducer.hpp in the review version. In the version I am working on at the moment, I have a deduce_type< int > template that is used to simulate partial specialization (for compilers that don't support it). The int parameter is the format object category and is taken from type_traits.hpp (or your own value if you add a custom type and format object). The decude_type template contains template< typename CharT, typename T > struct type_from{ ... }; that has a format_object typedef and the method: static format_object deduce( const T & ); for constructing an instance of that format object. For example: template<> struct deduce_type< io::seq_container_type > { template< typename CharT, typename T > struct type_from { typedef typename T::value_type value_type; typedef typename get_deducer< CharT, value_type >::type value_deducer; typedef container_t < CharT, typename value_deducer::format_object > format_object; static format_object deduce( const T & ) { return( format_object( value_deducer::deduce( value_type()))); } }; }; > > 3. What is your evaluation of the documentation? > >The documentation leaves much to be desired. I'll walk though some of the >aspects (indented text is quote from the docs) I will attempt to address the issues you have raised. > "providing an extensible framework that sits" > >How it's extensible? I see only one section about extending and it's just >one paragraph long I really need to add more documentation regarding this. The idea is that you can: * add your own decorators (delimiters in the review docs) to support more complex types (e.g. trees and graphs). * add your own format objects to control the way the data is rendered, for example adding a format object to call the 'serialize' method on a class. * create state objects used by fmt::state to perform custom formatting (e.g. in the john-torjo.cpp example, a state object is used to render the position: { [0] Vladimir, [1] Terje, [2] John, [3] Dave, [4] Rene } ) * register a type with the type deduction system so it can be implicitly deduced, e.g.: BOOST_IO_CLASSIFY_TYPE( 2, boost::array, io::seq_container_type ); // ... boost::array< int, 5 > a; std::cout << io::object( a ); // output: [ 1, 2, 3, 4, 5 ] > boost::io::formatobex< DelimeterType >( const T & ob ); > > This will format ob according to it's underlying type. > >How is this different from using the 'formatob' function. What's >"underlying >type". Underlying type is: typeid(ob).name(). That is std::vector< int > will be formatted differently to std::pair< char, std::list< std::complex< float > >. >I'd also suggest >for formatobex use the "basic" prefix to indicate it's templated on the >character type. E.g. stlio and basic_stlio, or something like that. That is a good idea. Especially considering the revisions I am in the process of making. > If you need to specify a range or sub-range, boost::io::formatob will >not > recongnise it unless it is a container. > > boost::io::range( ForwardIterator first, ForwardIterator last ); > >This is more of a language problem. Range, by definition, is a pair (but >not >std::pair) of iterators. It's never a container. What I meant is that: std::cout << io::object( vec ); // [1] ok - know how to process containers std::cout << io::object( a, a + 5 ); // [2] oops! don't know how to handle ranges std::cout << io::object( io::range( a, a + 5 )); // [3] ok - range is now explicit The reason I don't allow variant 2 is because that would mess up argument resolution. >For a reference, the code examples are not necessary. For tutorial, >you don't need to list every overload, just mention that there are others. noted. > boost::io::openclose_formatter is a class that allows the user to >change > and access the format used for open and close delimeters > >Here we're definitely in the reference docs already, while I did not get an >overall picture yet. Then, what's "change and access the format". If the >format can be changed, it is stored somewhere. Where? It is stored inside the [openclose_]formatter object (wrapper_decorators and sequence_decorators in the new version). You can set the delimiters (decorators in the new version) using the various 'format' functions ('decorate') and get their values via open(), close() and separator() (used when implementing your own format objects). >The code block before >this comment defines two classes openclose_formatter_t and >openclose_formatter. Is this a typo, or you really have two classes? This is not a typo. The _t variants take a template parameter that contains the return value of the 'format' ('decorate') functions. This is so that: std::cout << io::object( vec, fmt::container().decorate( " | " )); works properly. >Do you mean that every FormatObject class should have this signature? Then, >the phrase about "FormatObject::write(os, fo.ob)" is not necessary. ok. Regards, Reece _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

2 1

RE: [boost] RE: Re: Formal review of "Output Formatters" librarybeginstoday
by Reece Dunn 21 Sep '04

21 Sep '04

Vladimir Prus wrote: >Reece Dunn wrote: > > > Vladimir Prus wrote: > >>There are some things I don't like. First, as many mentioned, the naming > >>is not optimal. > >>[snip] > >>or maybe even > >> > >> ("[" + io(v)/"," + "]") > >> > >>for nested formats, something like > >> > >> ("[" > >> + io::format( > >> "(" + io::format()/":" + ")" > >> )/"," > >> + > >> "]" > >> ) > >> > >>These are just ideas, though. > > > > In my development version, I now have this working! That is, you can do: > > > > std::cout << io::object > > ( > > std::make_pair( 'a', 5 ), > > "{ " + fmt::pair()/" == " + " }" > > ) << '\n'; // output: { a == 5 } > >Great. I wonder what others think? Personally, I really like the / >operator. >Probably that's because I've borrowed the idea from one parser generator >which allows to write: > > (literal / "," ) > >to mean a list of literals separated by ",". Sure. Another alternative would be: fmt::pair()[ " = " ] but this may be confusing WRT the standard behaviour of the [] operator. >The opening and closing braces look less clear for me now. Maybe, we can >use > > fmt::pair("{", "}")/" == " The problem with this is deducing that the parameters passed to fmt::pair or others are format objects (for formatting first and second data members) or delimiter strings or other arguments (e.g. DelimiterType or array length). This could possibly be done using MPL, but would further complicate the implementation. >or > > fmt::braces("{", "}") + fmt::pair()/" == " > >But I'm really really not sure. Suggestions are always welcome. fmt::braces is openclose_formatter in the review implementation (wrapper_decorators in the version I am currently working on). The problem with defining operator + for <open_close> + <open_close_separator> value holders is: how do you inherit values, for example: fmt::braces( "<< ", " >>" ) + fmt::pair( "{ ", " }" )/" == " is this: << a == b >> or: { a == b } This would be "<< a == b >>" in this instance, because fmt::pair will set the values and fmt::brace will cause them to be overrided. This is similar to this situation: "<< " + fmt::pair().decorate( "{ ", " }" )/" == " + " >>" Also, MW CodeWarrior 9.2 is complaining about the above: typedef boost::io::sequence_decorators<char> decorators; ### mwcc Compiler: # 122: = "<< " + decorators() / " :: "; # Error: ^ # illegal operands 'boost::io::sequence_decorators<char>' / 'const char *' I will need to investigate this further. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1