Re: [boost] Re: variant questions
On Friday 29 August 2003 10:53 pm, Eric Friedman wrote: P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? (This of course does not solve the problem of offline access though...) There has been no progress, though it is much more likely now that I'm back at home base. Perhaps I can get something up and running at Sourceforge (if we have enough space!). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: variant questions
On Saturday 30 August 2003 08:00 am, David Abrahams wrote: Misha Bergal [EMAIL PROTECTED] writes: Eric Friedman wrote: P.S. Has there been any progress in handling BoostBook documentation in CVS? Perhaps Greg or MetaComm can run nightly builds? We can do that. Is there any info on how to use Boost.Build v2 to build BoostBook? I missed Misha's reply somehow. There is information on using BBv2 and BoostBook here: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it g. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] adaptable_any vs any_with
On Monday 01 September 2003 07:53 am, Alexander Nasonov wrote: I'm asking for voting for the new name of dynamic_any. Please, give you preference. Here is my discussion about the name with Kevlin Henney ( and empty prefix - Kevlin, - me) Between the two: adaptable_any is better, I think. Because I like throwing wrenches: have you considered a very different name such as polymorphic or just poly. The idea is that we read: polyless_than_comparable, equality_comparable as a type that is polymorphic over all less_than_comparable equality_comparable types. And because I'm feeling silly and reading a book on lattice theory... it could also be named models_meet, as in a type that models the meet of the following concepts in the concept lattice. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: variant questions
On Tuesday 02 September 2003 04:58 pm, Misha Bergal wrote: Douglas Gregor [EMAIL PROTECTED] writes: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You can build local copies of the documentation with BBv2 once you've read it Thanks. It worked. We will be publishing HTML docs starting with this night's run. That's great, thank you! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: optional/type_with_alignment.hpp vs. metrowerks 8.3PPC CFM
On Tuesday 02 September 2003 05:01 pm, David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
Maybe adding struct { double x; } would be enough?
I think it would be safer to add struct { double T; } for each T in
the list of types, just in case.
I agree. I've checked in the following patch, which implementations (a
corrected version of) the above. The preprocessor library rocks.
Mat, does this fix the problem for you?
Doug
Index: type_with_alignment.hpp
===
RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v
retrieving revision 1.12
diff -u -r1.12 type_with_alignment.hpp
--- type_with_alignment.hpp 9 Jun 2003 22:16:19 - 1.12
+++ type_with_alignment.hpp 2 Sep 2003 22:39:51 -
@@ -12,6 +12,8 @@
#include boost/preprocessor/list/for_each_i.hpp
#include boost/preprocessor/tuple/to_list.hpp
#include boost/preprocessor/cat.hpp
+#include boost/preprocessor/list/transform.hpp
+#include boost/preprocessor/list/append.hpp
#include boost/type_traits/alignment_of.hpp
#include boost/type_traits/is_pod.hpp
#include boost/static_assert.hpp
@@ -38,11 +40,22 @@
typedef int (alignment_dummy::*member_ptr);
typedef int (alignment_dummy::*member_function_ptr)();
-#define BOOST_TT_ALIGNMENT_TYPES BOOST_PP_TUPLE_TO_LIST( \
+#define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \
11, ( \
char, short, int, long, float, double, long double \
, void*, function_ptr, member_ptr, member_function_ptr))
+#define BOOST_TT_HAS_ONE_T(D,Data,T) boost::detail::has_one_TT
+
+#define BOOST_TT_ALIGNMENT_STRUCT_TYPES \
+BOOST_PP_LIST_TRANSFORM(BOOST_TT_HAS_ONE_T, \
+X, \
+BOOST_TT_ALIGNMENT_BASE_TYPES)
+
+#define BOOST_TT_ALIGNMENT_TYPES\
+BOOST_PP_LIST_APPEND(BOOST_TT_ALIGNMENT_BASE_TYPES, \
+ BOOST_TT_ALIGNMENT_STRUCT_TYPES)
+
#define BOOST_TT_CHOOSE_MIN_ALIGNMENT(R,P,I,T)
\
typename mpl::if_c
\
(alignment_ofT::value == target !BOOST_PP_CAT(found,I)),
\
@@ -52,6 +65,12 @@
#define BOOST_TT_CHOOSE_T(R,P,I,T) T BOOST_PP_CAT(t,I);
+template typename T
+struct has_one_T
+{
+ T data;
+};
+
template std::size_t target
union lower_alignment
{
@@ -73,6 +92,9 @@
)
};
+#undef BOOST_TT_ALIGNMENT_BASE_TYPES
+#undef BOOST_TT_HAS_ONE_T
+#undef BOOST_TT_ALIGNMENT_STRUCT_TYPES
#undef BOOST_TT_ALIGNMENT_TYPES
#undef BOOST_TT_CHOOSE_MIN_ALIGNMENT
#undef BOOST_TT_CHOOSE_T
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
On Thursday 28 August 2003 06:26 pm, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Perhaps because you work with the authors of the documentation to
make it sure it says what needs saying?
Are the documentation authors monitoring this mailing list?
The developers generally write the documentation, or at the very least have
authority over what it says.
How about
template typename T, typename Counter = int
shared_ptr
{
typedef Counter counter; //counter type should be public
template typename DataAlloc = std::allocatorT, typename
CounterAlloc=std::allocatorcounter
shared_ptr( const DataAlloc da = DataAlloc(), const IntAlloc ia =
CountAlloc() ); };
I suggest that you:
(1) flesh out the interface you want,
(2) decide what the specific semantics of the interface are, and
(3) put together at least a toy implementation (at least try to compile the
interface specification; the above isn't valid C++, for instance); then
(4) start a new thread to discuss the semantics you need and the syntax you
want.
Actually this is probably what the whole thread is about
to get people to try to find the best practicle solution
for memory management in the modern C++ age.
I am not sure that STL style allocators is the best
possible solution.
Nor is anyone else. But the point is that grand visions cannot go anywhere
without specific examples. Remember: Boost policies are implemented bottom-up
not top-down.
You have suggested a way to fix your problem for shared_ptr, and I suggest you
follow my recommendation above to come up with a proposal that does what you
need (but do note the comments Peter has already made regarding interfaces
similar to the one you suggest above).
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bitset question
On Thursday 28 August 2003 09:35 am, Neal D. Becker wrote: I have looked at std::bitset, std::vectorbool, and boost:dyn_bitset, but none seems to supply a feature I need. I'd like to be able to assign to a contiguous field of bits in one operation. For example: bitset12 n; n.subset (1, 10) = 0x2; Is there any good c++ lib that can do this? Not that I know of... Would this be a good addition to boost? I'm sure it would be a good addition to boost::dyn_bitset at least. It depends on whether you need std::bitset, std::vectorbool, or boost::dyn_bitset semantics for the rest of your code as to which one you would benefit most from modifying. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deprecation/removal of libraries
On Thursday 28 August 2003 08:20 am, Daniel Frey wrote: Douglas Gregor wrote: I'd like to deprecate or remove two libraries: - min_rand has been the only entry in our list of Obsolete Libraries for quite some time. Random is quite mature, so let's just eliminate min_rand now. - compose has been surpassed by bind to the point where we dissuade users from using compose if they ask, and tell them to use bind instead. Let's deprecate this in 1.31.0 and remove it in 1.32.0. utility/tie was moved to tuple, so should we remove the obsolete docs/references in utility now? Please do. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [BGL] Recent patch to depth_first_visitor.hpp breaks depth_first_search
Vladimir,
The patch you recently checked in:
revision 1.36
date: 2003/08/28 11:48:59; author: vladimir_prus; state: Exp; lines: +53
-18
Implement depth_first_visit variant which allows to stop the search at
certain vertices.
breaks depth_first_search by aborting before it starts unless a different
TerminatorFunc is specified. I've checked in the patch below to fix this.
Doug
Index: depth_first_search.hpp
===
RCS file: /cvsroot/boost/boost/boost/graph/depth_first_search.hpp,v
retrieving revision 1.36
diff -u -r1.36 depth_first_search.hpp
--- depth_first_search.hpp 28 Aug 2003 11:48:59 - 1.36
+++ depth_first_search.hpp 28 Aug 2003 16:31:14 -
@@ -76,9 +76,9 @@
namespace detail {
-struct truth2 {
+struct nontruth2 {
templateclass T, class T2
- bool operator()(const T, const T2) const { return true; }
+ bool operator()(const T, const T2) const { return false; }
};
@@ -127,7 +127,7 @@
put(color, u, Color::gray());
vis.discover_vertex(u, g);
tie(ei, ei_end) = out_edges(u, g);
- if (static_castTF(func)(u, g)) {
+ if (static_castTF(func)(u, g)) {
// If this vertex terminates the search, we push empty range
stack.push_back(std::make_pair(u, std::make_pair(ei_end, ei_end)));
} else {
@@ -166,7 +166,7 @@
}
#else // BOOST_RECURSIVE_DFS is defined
-
+
template class IncidenceGraph, class DFSVisitor, class ColorMap,
class TerminatorFunc
void depth_first_visit_impl
@@ -219,14 +219,14 @@
}
if (start_vertex != *vertices(g).first){ vis.start_vertex(start_vertex,
g);
- detail::depth_first_visit_impl(g, start_vertex, vis, color,
- detail::truth2());
+ detail::depth_first_visit_impl(g, start_vertex, vis, color,
+ detail::nontruth2());
}
for (tie(ui, ui_end) = vertices(g); ui != ui_end; ++ui) {
ColorValue u_color = get(color, *ui);
if (u_color == Color::white()) { vis.start_vertex(*ui, g);
-detail::depth_first_visit_impl(g, *ui, vis, color, detail::truth2());
+detail::depth_first_visit_impl(g, *ui, vis, color,
detail::nontruth2());
}
}
}
@@ -360,14 +360,14 @@
DFSVisitor vis, ColorMap color)
{
vis.start_vertex(u, g);
-detail::depth_first_visit_impl(g, u, vis, color, detail::truth2());
+detail::depth_first_visit_impl(g, u, vis, color, detail::nontruth2());
}
template class IncidenceGraph, class DFSVisitor, class ColorMap,
class TerminatorFunc
void depth_first_visit
(const IncidenceGraph g,
- typename graph_traitsIncidenceGraph::vertex_descriptor u,
+ typename graph_traitsIncidenceGraph::vertex_descriptor u,
DFSVisitor vis, ColorMap color, TerminatorFunc func = TerminatorFunc())
{
vis.start_vertex(u, g);
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/detail/iterator.hpp update
On Thursday 28 August 2003 01:23 pm, David Abrahams wrote: The other possible option would have been to simply not give the user a readable error message. I'm open to opinions that I chose the wrong balance. So we're breaking code in order to produce a better error message? This seems like the wrong trade-off to make, especially because it means it breaks code when users upgrade from VC6 to VC7; but we want them to upgrade! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
On Thursday 28 August 2003 04:40 pm, Gregory Colvin wrote: I also have no objection, and much sympathy, for having a clear memory management policy for Boost libraries. But again, it is a matter of people who care about and understand the issue doing the necessary work, just like everything else here at Boost. Moreover, it's not a matter of convincing certain people that a clear memory management policy should be adopted by Boost and handed down for developers to do the work. Boost doesn't work that way. Policies always come from the bottom up: someone has a problem, so they fix it in the libraries that matter most to them. With that knowledge of _how_ to fix the problem correctly, they can approach other developers and say hey, I think we should fix this problem in library X; here's how we did it in library Y. Eventually, most of the libraries will support it, and _then_ we can approve it as a Boost policy so that future libraries will follow it. The most productive thing we could do right now would be to end this policy discussion. Start with smart_ptr and address *specific* documentation and *specific* implementation problems in this library, with resolutions specific to that library. Is there a library that does it well? Reference that library and state why it does it well, so that others may follow. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
On Tuesday 26 August 2003 01:23 pm, Peter Dimov wrote: Leaving aside the issue of whether specializing std::allocatorMyClass is a good idea: shared_ptr MyClass, MyAllocator s; note that you now wouldn't be able to pass s to a function that expects shared_ptrMyClass since the type is not the same. There's no reason shared_ptr couldn't support a constructor that takes an allocator as an argument. Then sp_counted_base_impl would also take an Allocator parameter (heh, the allocator it was in fact allocated with) and would know how to deallocate itself via a (copy of) this allocator. We'd get allocator support without putting the allocator into the type of shared_ptr (just like we have deleter support). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Deprecation/removal of libraries
I'd like to deprecate or remove two libraries: - min_rand has been the only entry in our list of Obsolete Libraries for quite some time. Random is quite mature, so let's just eliminate min_rand now. - compose has been surpassed by bind to the point where we dissuade users from using compose if they ask, and tell them to use bind instead. Let's deprecate this in 1.31.0 and remove it in 1.32.0. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] garbled boostboc output in online docs
On Monday 18 August 2003 11:42 pm, Jeremy Siek wrote: Hi Doug, Hmm, I just viewed it with a different browser (Apple's Safari instead of and old version of Netscape on a Sun) and now I see lots of newlines (there were none before). Is this a case of non-portability of a html tag, or a bug in Netscape? Cheers, Jeremy It's just a preformatted block, but I think the answer is both :). The formatting that the pre tag does is essentially non-portable, but nearly every browser does it the same way, so it looks like a bug. I don't know of a suitable replacement tag. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] garbled boostboc output in online docs
On Monday 18 August 2003 06:04 pm, Jeremy Siek wrote: The Header section in the following pages is garbled. Looks like a bunch of missing newlines. http://www.boost.org/doc/html/any.reference.html http://www.boost.org/doc/html/function.reference.html -Jeremy Where would you like to see the newlines? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: Re: [boost] GUI/GDI template library
- Original Message - From: Brock Peabody [EMAIL PROTECTED] Do you think we will be OK restricting this library to the more conformant compilers? That should be fine. Compiler workarounds can often be added later, and you shouldn't need to worry about these from the start. In fact, we do NOT want compilar workarounds to affect the interface, so it's sometimes best to push them out of your mind when putting together an interface. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.30.1 released
- Original Message - From: Fredrik Blomqvist [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 4:40 PM Subject: [boost] Re: Boost 1.30.1 released Shouldn't the documentation for function and signals be added when your're making an official release also? Yep, we should add that to the release manager's TODO list. We can just pull in the 1.30.0 docs, because nothing has changed in either library for 1.30.1. What's the status regarding the new doc-system btw? (too lazy/tired to dig through the archives right now ;-) It's there, and it's not half bad, although development has been a little slow over the summer. Doxygen extraction has been improved a bit in recent times. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] what happened to allocators in boost?
- Original Message -
From: E. Gladyshev [EMAIL PROTECTED]
I am wondering what happened to the allocator idiom in
boost. Was it left out intentially?
I can control all memory allocation details in STL
(orthogonally to data types) but not in boost.
It seems like a step backward comparing to STL.
How can I use allocators with shared_ptr? Is there any
way to write something like this.
f()
{
shared_ptr int, std::allocatorint myptr;
myptr.allocate();
*myptr = 123;
}
shared_ptrint myptr(new int(123));
?
The allocator design focused on the benefits one could get from specialized
allocators for containers, e.g., data structures that may allocate large
chunks of memory that are expected to be used together. They don't really
give us much for components like shared_ptr that allocate one thing (and
note that shared_ptr does not allocate the pointer it stores, although it
does allocate a reference count). boost::function supports an allocator
argument, but the C++ committee is considering removing this allocator from
the library TR version of function for precisely this reason.
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
- Original Message - From: E. Gladyshev [EMAIL PROTECTED] IMHO, boost needs to get rid of any possibility of this to happen. Why does boost::signal() need a DLL/LIB in the first place? Would not be just the .h file enough? It could be put in a .h, but there is a lot of code in the library and it makes sense to have it built as a .lib. I think that it doesn't make sense if we have all these problems that you are talking about below. If the user wants to speed the compile-time up, he/she can always create a simple wrapper around the standard signal.h. It's not just compile time, it's also the size of the generated code. std::multimap instances tend to be huge on many platforms, and a typical program that uses signals/slots tends to have many instantiations of boost::signal... in it Sure, it would be possible to put everything into header files, but now we're paying the cost of instantiating them in every single translation unit. I am really worried about the road the boost comunity has choosen just to reduce the compile time. Compile time is a huge problem for many programs. Sure, it doesn't matter much with a 100 or 1000-line sample program, but get past 10k lines of application code (not including the tens of thousands of lines brought in by including Boost/C++ standard library headers) and your edit-compile-debug turnaround time becomes unbearable. This is a real problem on real, industrial code bases, and we have to deal with this problem. Please let the user to reduce the compile time (making his custom wrappers) any way he/she likes it. I want to be able to just include a .h file w/o having to verify that my program won't break from time to time because of some .lib/.h conflicts enforced on me by boost developers. As I see it, it's a simple matter of economics. Say we can shave 15 minutes off the required build time for project X by moving some Boost code into a . lib. How many compiles will it take before the effort of creating/using that .lib pays off? Two or three, perhaps, assuming it doesn't take more than 45 minutes to read the Boost.Build documentation to build the library for the system? Sure, we could make it easier to build/link the libraries, e.g., on Windows, and we're working on that, but even with the current less-than-perfect state of affairs it is worth the effort. Custom wrappers are fine, but again they cost time to create and maintain. This cost is per-instantiation vs. the per-library cost of using a .lib. On the side note: this boost road already lead to the fact that the boost::thread library is not up-to-date anymore. Win32 supports two threading models that can be used in one application at the same time. boost::thread doesn't allow it. The Boost.Threads library defines its own threading model and implements it on several platforms. If two distinct threading models are useful with the Boost.Threads model, then it can be extended to support that model. Windows' two threading models aren't the only threading models out there, and one thing that Boost.Threads brings to the table is a threading model that is consistent across all platforms. How portable would a program that relies on two coexisting Win32 threading models be? I think if we continue down this road, boost will be in a big trouble becoming a true industry standard (at least for some of its components). Businesses are run by economics, and experience shows that refactoring code into compiled libraries saves time. IMHO boost::signals should be in a .h file completely. I can always reduce the compile time myself if I need to. Eugene I'm not opposed to providing an option to include all code into headers (e.g., a BOOST_SIGNALS_NO_LIB macro akin to the RegEx macro), and clearly where there are cases with problems stemming from the DLL/user code split (e.g., pointers allocated in the DLL and freed in user code) I'll fix the library, but I don't expect to see Boost moving toward putting more code into headers in the future. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Infinite number of parameters?
- Original Message - From: Philippe A. Bouchard [EMAIL PROTECTED] Joe Gottman wrote: They are considering a language solution. See this link: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1483.pdf Wow, that is good. I like the new syntax... 0,01$: But maybe they could add some template specifier before its declaration; this could help typename / non-type arguments / template templates arguments: [snip example] fooint, long, double(1, 2, 3); foo1, 2, 3, 4, 5(); foomap, list, vector(); You can always write a forwarding 'foo' that checks the argument types, but I understand the reason you'd like this feature. My only question is whether it is worth the additional machinery that it would take, e.g., would this help a large amount of code? Perhaps you have a particular real world use in mind? I can't think of one, and there's a bit of code in the paper that uses the template varargs stuff but didn't need it. 0,01$: And they should rename 'the-return-type' to something else... something like 'nameless' or 'holotype'. That's just a placeholder, because there was still quite a bit of discussion of whether to call the expression-type grabber 'typeof' or 'decltype'. Any revisions will skip the the-return-type placeholder and use decltype directly. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] switch-based runtime type selection (for variant)
- Original Message - From: Brian Simpson [EMAIL PROTECTED] The general case devolves into an else-if-then: Let us assume that we have specializations up to a certain number, 'max_specialization_count'. Then we know that we can get switch-based runtime type selection (rtts) on any mpl::Sequence whose size is not greater than 'max_specialization_count'. To provide rtts for Sequences whose size is greater than 'max_specialization_count', we provide a more general template definition. Its invoke function sets up a switch-based selection among the first 'max_specialization_count' types, and then sets up a (recursive) selection among the remaining types. Of course, you can do slightly better than this by switching in chunks of size max_specialization_count, so there there are only a few if statements (to determine which chunk we're in). Granted, the effort would be large and the return potentially small, so it may not be of interest. (My assumption is that most people do not use variants with huge numbers of possibilities, so that few variants require the if statements). Questions or comments? I haven't reviewed the code itself, but the idea is good and I believe this would be a boon to the variant library. Itay and/or Eric will need to look this over if it is to be included. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
- Original Message - From: Bohdan [EMAIL PROTECTED] E. Gladyshev [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Have you built the signals library multi-threaded or single threaded and Whatever the default build is. are you building an application of the same sort? The application is set to use multi-thread run-time libraries and MFC.DLL. Check boost::signal library compile/link options as well. It looks like commons source of problems. Would it be difficult to add automatic library selection for boost::signal ? I mean library suffixes and comment pragmas as in boost::regex. Honestly ... i'd like to see such build system in all boost non-template libs :) IMHO, it is very convenient. regards, bohdan The Boost.Build folks are working on a solution for this. I don't know quite when it will happen, but a future Boost release will fix all of these compile/link option problems with a common scheme. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
- Original Message - From: Lars Gullik Bjønnes [EMAIL PROTECTED] David Abrahams [EMAIL PROTECTED] writes: | I have put a diff of the changes between Version_1_30_0 and RC_1_30_0 | at http://www.boost-consulting.com/diffs-1-30-1.txt. These are the changes we (LyX Developers) have made to boost 1.30.0 to make it compile with gcc 3.3 without warnings, as well as using a different string class than std::string¹. If appropriate, please include these changes in 1.30.1. I think we should apply these changes for 1.30.1. They aren't going to break anything, and GCC 3.3 is an important compiler. At the very least, we need the config changes. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
From: E. Gladyshev [EMAIL PROTECTED] [snip] template typename IT, typename PhysicalGuiLayer class ListControl [snip] I'm coming in a bit late into this discussion, but I too am interested in the outcome of this project. I strongly dislike the PhysicalGuiLayer template parameter, for several reasons: 1) It buys us very little: generally template parameters are useful when more than one instantiation will be used within any particular program. It is highly unlikely that a program will support two physical GUI layers simultaneously, and I would claim that any such program would be such a usability nightmare as to be excluded from consideration. 2) It hurts us a lot: compile times will skyrocket because every widget, layout engine, etc. will have to have full source code included in every translation unit. We cannot do this to users, especially with a GUI library, because GUIs are often tweaked (requiring many builds). 3) There is an alternative solution: Boost.Threads presents a single, non-template interface to the user and hides all of the platform-specific details using the pImpl idiom. The same approach can be applied here, and I think we'll find that it has all of the same advantages. Here is a more general comment regarding the compile-time vs. run-time discussions: Genericity can be accomplished at run-time or at compile-time, but neither approach excludes the other. I believe that one bit that falls out of the above agrees 100% with the poster that suggested the following: class list_control; // implemented by the library. Uses some sort of generic list element type templatetypename Element class typed_list_control; // thin wrapper over list_control. Element is the type of the data in the list As noted earlier, this design has a huge number of benefits: 1) list_control is not a template, so we can use the simplified cross-platform model used in Boost.Threads, and of course this gives us the ability to create a much more dynamic system (e.g., loaded from a resource file) if we choose to. 2) typed_list_control gives us all of the great static-checking features we would want, but in a lightweight veneer. I've used this model extensively before (e.g., Boost.Signals uses it to shrink the size of boost::signal template instantiations), and it has worked very well. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Signals and multi_array? [was: Problem compilingboost.filesystem]
Douglas Paul Gregor [EMAIL PROTECTED] writes: Doesn't look like there has been any activity on signals and multi_array. Are the developers aware of the need for action? I'll try to work on Signals tonight. Hint: turn the body of your policies class into the body of your iterator. 'tis done, and it was _very_ easy, and the result is as clean as is conceivable. Nice job! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
- Original Message - From: Aleksey Gurtovoy [EMAIL PROTECTED] Beman Dawes wrote: What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. The way we do it in the new reports is to extract the failures from the original regression run and pass them as expected failures to the input of the scripts producing the today's reports. The scripts merge these into extended results XML, and then produce the HTML reports basing on that. Works perfectly. All XML processing is done through XSLT, but it's very worth it - the stlysheets which do the extracting and merging are barely 100 lines long. Aleksey I don't have the time now, but if it's feasible for you I would absolutely _love_ if we could integrate this with BoostBook in the future. If I had my way, everything would run through the documentation system so that everything would be documented (see, e.g., the testsuite documentation and generation for Function) and in sync. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Missing functional files in CVS?
- Original Message - From: Daryle Walker [EMAIL PROTECTED] To: Boost [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 3:10 PM Subject: [boost] Missing functional files in CVS? In my copy of the main CVS, looking at ROOT/boost/libs/libraries.htm, the links to function and signals, both by Doug Gregor, don't work. Hopefully this is temporary?... Less temporary than I'd hoped, because we still don't have a good solution for the generated documentation... anyway, the documentation is all available here: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html From that page, you can grab the HTML documentation tarball and extract it in $BOOST_ROOT to get the documentation you seek. You can also grab the PDF file or some Unix man pages, if you prefer those :) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Documenting/testing boost::incomplete?
- Original Message - From: Eric Friedman [EMAIL PROTECTED] Other components, however, are more general purpose -- namely, boost::empty and boost::incomplete. Since boost::empty is almost trivial, I plan to document and test it as part of the utility library. But boost::incomplete is generally quite useful (for example, in implementing the pimpl idiom), and I think Boosters may employ it often without boost::variant. My question then: should boost::incomplete be given its own libs/incomplete directory and an announcement on the main html page? Any input welcome. I think both boost::empty and boost::incomplete should go into the utility library, because they are both of general utility and are relatively small. But they should be mentioned on the main HTML page in any case, because they can be useful for users. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Signals] BCB patchlet
This removes a possible use of 'tag' before definition warning with BCB. I didn't use this actual patch (I'd rather avoid pragmas when there's a reasonable in-language workaround), but the code I checked in should get rid of the warning on BCB (not that Signals compiles at the moment!). Sorry for the delay. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] rw_lock / next thread version
Ok, enough of the review. Assuming that rw_lock is destined for
release, I propose that whether you want to lock for reading, or for
writing, is usually a decision made at compile time, and that this fact
can be made to slightly simplify the scoped_lock interface, and make it
slightly more efficient. So as a minor twist to the interface, I
propose:
class rw_mutex
{
public:
typedef detail::read_lockrw_mutex read_lock;
typedef detail::write_lockrw_mutex write_lock;
...
};
I too would prefer this interface, because I feel it is much cleaner. I
*hate* enums and constants, btw :)
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::signal patch
MSVC 7.1 complains: warning C4099: 'boost::signals::detail::real_get_signal_impl0,T1,T2,T3,T4,T5' : type name first seen using 'struct' now seen using 'class' at several later points in the same file. These can all be removed by changing struct to class in the declaration quoted above. Thanks, it's done now. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor nitpick: why signal.hpp instead of signals.hpp?(notext)
Subject: [boost] minor nitpick: why signal.hpp instead of signals.hpp? (notext) Probably a mistake. signal.hpp made sense when the library was not in the namespace boost::signals, but signals.hpp makes more sense now. This should probably change. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Graph] Improved creation of visitors fromfunctionobjects
- Original Message - From: Vladimir Prus [EMAIL PROTECTED] Douglas Gregor wrote: Creating new visitors in the BGL can be a pain, because it may require a lot of extra typing for simple cases. I'd like to add the ability to attach function objects to visitor events like this: dfs_visitor() .do_on_back_edge(var(has_cycle) = true) .do_on_tree_edge(bind(vectoredge::push_back, ref(tree_edges), _1)); I'd really prefer on_XXX instead of do_on_XXX, but GCC trips over the former syntax. Anyway, the code is ready to check in if there are no objections. The patch isn't very large, but is bigger than I would like to post here. Hi Doug, did you commit that patch already? I can't find anything named do_on in current CVS. I've now committed it. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Mac OS 10 type_traits/type_with_alignment.hpp
- Original Message - From: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Sent: Saturday, June 07, 2003 5:50 AM Subject: Re: [boost] Mac OS 10 type_traits/type_with_alignment.hpp --- Douglas Gregor [EMAIL PROTECTED] wrote: /var/tmp/mac/boost/boost/type_traits/type_with_alignment.hpp:120: error: no type named `type' in `boost::maybe_print_alignfalse, 8, 4' So you have a type that is 8-byte aligned, but we don't have any types in the list of possible types that have an alignment of 8 on that architecture, so it fails. We'll just have to find a type that has 8-byte alignment and add it to the list. I'll see if I can dig one up tomorrow. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Mac OS 10 type_traits/type_with_alignment.hpp
My apologies for the very late reply. I was away for a while and am still
sorting through my inbox...
Platform:
Mac OS 10.2
gcc 3.3 compiled from sources
boost cvs from last Friday
When porting the Boost.Python bindings for some custom libraries I ran
into a problem with static asserts in type_with_alignment.hpp:
[snip patch]
This patch allows me to compile and link, and our regression test
runs fine.
Reducing my code to a minimal test is most likely a time-consuming
project that I'd like to avoid if possible (compilation is quite slow
to make things worse). Do the authors of the code above have any ideas
what could be going wrong? Are there things that I could try first
before chopping my code into pieces?
If you could figure out what alignment value you're trying to get a type for
it would help greatly. One way you could do it would be to replace the
static assertion lines with something that will halt the compile and give
back the Align value in an error message, e.g.,
// somewhere
templatebool DontPrintIt, std::size_t Align struct maybe_print_align {
typedef void type; }
templatestd::size_t Align struct maybe_print_alignfalse, Align {};
// instead of the static asserts:
typedef typename maybe_print_align(found = Align), Align::type foobar;
Note that when those static asserts fail, it means that you aren't getting
back a type with the right alignment.
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for the Function library
Guillaume and Giovanni, As Beman mentioned, I've been away for a bit. Let's see if I can answer some of the lingering what-was-the-maintainer-thinking questions: Giovanni said: Instead, I think this is ill-formed because it's throwing an exception which is not derived from std::bad_alloc(). This is an error. I'll use std::bad_alloc instead. Giovanni also said: What is this code supposed to do? If the goal is disabling new() for stateless_integer_add, why simply you don't add a protected operator new as member of the class? The goal is for the regression test to fail at run time when operator new () is being used. The failure needs to be at run time (not compile time, as the above solution proposes) because the feature we're testing is an optimization: compilers that can't do it should still compile the code (it just has slightly different semantics). Guillaume said: The best solution would be to track down compilers that complains if the return statement is missing and conditionaly add it for them. But only the maintainer can tell us for which compiler the dummy return statement was needed. Or maybe we could just remove it and see which compilers suddenly complains in the regression tests :-). Ha! If only the maintainer knew which compiler that was :). If CVS doesn't tell us, let's just remove the return statement, replace std::runtime_error with std::bad_alloc, and see who whines about it. I'll commit the patch as soon as I can, but someone else is welcome to do so if they get there first. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Patch for nonrecursive DFS to fix stack overflow
- Original Message - From: B B [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 30, 2003 9:52 AM Subject: [boost] [BGL] Patch for nonrecursive DFS to fix stack overflow Here's a patch to depth_first_search.hpp in BGL in version 1.30.0 of boost that implements nonrecursive depth first search. This reduces or eliminates the problem of stack overflow that occurs with DFS in large graphs. There also may be a performance gain in some cases. This is good. Unless there are any objections, I think we should apply this. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] interest in dominator tree?
- Original Message - From: Jeffrey Hsu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 30, 2003 2:41 AM Subject: [boost] interest in dominator tree? Is there any interest in a generic implementation of the Lengauer-Tarjan algorithm to compute the immediate dominator tree of a flow graph in almost-linear time? I'm interested, having recently implemented it myself for the BGL. My only concern is that the algorithm is very specific to a narrow domain, and might not belong in Boost. Granted, the thought of a good, _generic_ static analysis library makes me giggle with glee :) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost Library Guidelines
On Wednesday 30 April 2003 06:30 am, Pavol Droba wrote: Most of the new warnings can be easily removed with a static_cast. I don't understand, why any boost lib have to generate such a warnings. enters grumpy old developer mode I agree that it would be great from the user's point of view if all of Boost compiled without warnings, but I'm afraid a no-warnings policy will make the whack-a-mole game all that much worse. As it stands, some Boost code is brittle on certain compilers: tweak in one place, and it breaks a compiler; fix for that compiler and you've broken another compiler. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and mutexes : assign_to error
On Wednesday 30 April 2003 08:44 am, Jacques Kerner wrote:
Hi,
I get the following error :
error C2664: 'void boost::function0R,Allocator::assign_to(Functor)' :
unable to convert parameter 1 from 'const CTaskManager' to 'CTaskManager'
when doing this :
class CTaskManager
{
public:
CTaskManager();
~CTaskManager();
void operator()() {}
private:
boost::mutex m_mutex;
}
and
CTaskManager taskManager;
boost::thread_group mainThreadGroup;
mainThreadGroup.create_thread(taskManager);
mainThreadGroup.join_all();
The error dissapears when I remove the mutex from the definition of
CTaskManager ... (?!!)
So what is the right way to use mutex and threads together? Do I have to
declare the mutex outside of the
functor? Why?
Mutexes are not copyable, and when you pass taskManager to create_thread it
tries to make a local copy of the function object . If you would prefer to
pass a reference to taskManager to create_thread, do this:
mainThreadGroup.create_thread(boost::ref(taskManager));
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost implementation of the Library TR?
On Wednesday 30 April 2003 08:25 am, Beman Dawes wrote: * What namespace should the Boost version go in? (tr1 is t, r, followed by numeral one, and is the committee's tentative choice for a sub-namespace.) std::tr1 // well, this IS an implementation of the standard TR boost::tr1 // users can pick and choose, also more traditional Putting everything into boost::tr1 feels like gratuitous code movement. Then our users' migration path is from ::boost to ::boost::tr1 to ::std::tr1. Why bother with the intermediate step? * What header naming convention? Note that users can pick and choose an implementation by header choice, even if we use namespace std::tr1. I'd prefer to use the standard's naming convention for headers, to make it a real implementation of TR1. There is one problem with this that I don't know how to completely solve: some of the new libraries are extensions to old headers, e.g., function, reference_wrapper, and bind all go into functional. Can we rely on something like GNU's #include_next to allow us to have our own functional that falls back to the standard library's functional? * Should we continue to maintain the pre-TR Boost versions of the libraries? Decide this on a library by library basis Long term, probably don't want to continue as we don't want to compete against the standard itself. We should maintain the pre-TR versions at least until the TR gets its rubber stamp, because until then the TR versions may still change whereas the pre-TR versions are generally quite stable. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Graph] Improved creation of visitors from functionobjects
On Thursday 17 April 2003 03:50 am, Vladimir Prus wrote: IOW, now specifying behaviour for event requires creating a new class, with event_filter typedef and operator(). You propose to pass lambda, immediately on dfs_visitor creation. I think this is indeed convenient. I've some concerns about efficiency, but why don't try? It's a little worse than just creating the new class with event_filter: you need to build up a cons-list out of std::pairs containing your visitor types. I generally just subclass dfs_visitor, but that's a typing-heavy hoop to jump through for a simple visitor. The efficiency won't be any worse than using a bind object elsewhere in a program. The do_on_XXX functions merely augment the visitor list of dfs_visitor and return a new dfs_visitor object. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Graph] Improved creation of visitors from functionobjects
On Thursday 17 April 2003 10:04 am, Vladimir Prus wrote: Douglas Gregor wrote: The efficiency won't be any worse than using a bind object elsewhere in a program. The do_on_XXX functions merely augment the visitor list of dfs_visitor and return a new dfs_visitor object. This precisely what worries me -- bind might not be very efficient. I may be a overly concerned about efficiency at the moment --- recently wrote a graph algorithm in BGL which turned out to be 100 times slower that a simply-coded one :-( Not sure if this is BGL's fault or the problem with the algorithm, though. Not to blame the victim, but in my experience the abstraction penalty doesn't go above, say, 20x in the worst case, so it sounds like an algorithmic problem to me. Granted, figuring out the actual complexity of a particular instance of any BGL algorithm can be a nontrivial task: one property map with non-constant access time can sink the whole thing. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression logs
On Saturday 29 March 2003 09:46 am, David Abrahams wrote: I just returned from PyConDC 2003, where a system was described which will watch a CVS repository for checkins, launch new remote tests on any number of platforms, collect the results, and notify people of failures (e.g. via mail or even IRC chat). It can be set up to bother the person at fault first, and then bother a different group, for example. http://buildbot.sourceforge.net/. It looks like it could be really useful for us. Brian Warner expressed interest in helping us get that BuildBot up for Boost if we want to use it. Thoughts? This sounds great, but do we have access to enough hardware to make this feasible? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regressions in type_traits and lexical_cast (was: Re: [Boost-Users]Question about boost::function)
John, This regression in Function is coming from your recently change to is_class.hpp. Would you mind taking a look? On Saturday 15 March 2003 01:31 pm, Bernhard Glueck wrote: Hi ! I was using boost:function for a while now with success on Visual C 7.0 ( MSVC 1300 ) . I was always using the most actual boost 1.30.0 version from the CVS. Today i updated the CVS again ( after two days of not doing so ) and suddenly my code which relied on boost::function does not compile anymore. boost::function hasn't changed in the last few weeks, but some of the libraries it depends on have changed. I think there have some changes been made, so i need to change my code, but since there is no boost::function documentation in the CVS yet can someone please enlighten me what has changed .. ? FYI, updated documentation for Boost.Function is here: http://www.cs.rpi.edu/~gregod/boost/doc/html/function.html Also, it's on the RC_1_30_0 branch in CVS (that will be 1.30.0; mainline CVS is for 1.31.0 and later). Here is the relevant code: ( I have marked the line where compilation fails and provided the exact error details below ) ( This code compiled perfectly two days ago ) [snip code] /// /// VISUAL C ERROR OUTPUT: /// /// D:\Sdk\boost\boost\type_traits\is_class.hpp(78) : error C2510: 'value' : left of '::' must be a class/struct/union D:\Sdk\boost\boost\type_traits\is_class.hpp(94) : see reference to class template instantiation 'boost::detail::is_class_implT' being compiled with [ T=boost::any (__cdecl *)(const boost::any ) ] Looks like a type_traits problem. I suspect this patch: Index: is_class.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.5 retrieving revision 1.6 diff -r1.5 -r1.6 84a85 ::boost::type_traits::ice_not ::boost::is_functionT::value ::value John? // SECOND Problem As you may note all conversions from data types to std::string are commented out ! This is because boost::lexical_cast fails to compile in DEBUG mode ( it compiles fine in RELEASE Mode and also works like a charm in RELEASE mode ) The implementation of lexical_cast w.r.t. strings is in a state of flux. I'm too far out of the loop to be helpful on this one. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regressions in type_traits and lexical_cast (was: Re:Questionabout boost::function)
On Saturday 15 March 2003 06:03 pm, Andreas Huber wrote: [ ... ] Index: is_class.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.5 retrieving revision 1.6 diff -r1.5 -r1.6 84a85 ::boost::type_traits::ice_not ::boost::is_functionT::value :: ::value John? This is due to the missing comma I reported in http://lists.boost.org/MailArchives/boost/msg45211.php Regards, Andreas Ah, yes it is. I've applied the patch (actually, Daniel Frey's version: no need to duplicate code) on mainline and the RC_1_30_0 branch. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: C++ Standards Committee upcoming meeting
On Wednesday 12 March 2003 08:05 am, Beman Dawes wrote: At 11:19 PM 3/11/2003, Douglas Gregor wrote: As it stands, the system itself is in good shape, and the documentation for libraries I've redocumented in BoostBook is quite reasonably. I still think a BoostBook overview/tutorial at Oxford would be beneficial. Let's plan on it. Would Sunday evening be OK? --Beman Okay. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: C++ Standards Committee upcoming meeting
On Tuesday 11 March 2003 09:20 pm, Beman Dawes wrote: Doug Gregor is tentatively planning to host a session on the Boost documentation system he has been working on. No date or time yet.c Doug, how are your plans shaping up? --Beman I'm mainly working on usability issues now, most importantly moving the tools into their final places in the Boost CVS repository (unless there are any objections?), teaching BBv2 to handle BoostBook documents (need... help... from... experts...), and getting some good reference documentation together. As it stands, the system itself is in good shape, and the documentation for libraries I've redocumented in BoostBook is quite reasonably. I still think a BoostBook overview/tutorial at Oxford would be beneficial. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] HTML documentation imported into 1.30.0
I've imported the BoostBook-generated HTML documentation into the RC_1_30_0 branch under doc/html. The affected libraries are: Any, Function, Ref, and Signals. Other than the new directory there should be no effect Should we include PDF and/or man pages for these libraries? - The PDFs are about 270k uncompressed, 127k compressed - Man pages are about 90k uncompressed, 8k compressed Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HTML documentation imported into 1.30.0
On Wednesday 05 March 2003 03:53 pm, Beman Dawes wrote: I thought we agreed to make pdf, man, and all formats other than HTML available on some separate site. Okay. PDF and man pages are available at: http://boost.sourceforge.net/release/ and there are links from libs/libraries.htm. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::bind - cannot convert resulting function objectto function pointer
On Tuesday 04 March 2003 10:02 am, Marc Jacobs wrote: I'm trying to use a member function as a callback to a C-style library. I've got the bind working by itself, but the resulting function object does not convert to the type required by the library. Clearly a boost::bind object is not a simple function pointer and the type is being checked by the compiler. Is there any way to coerce the types and still use boost::bind? I have no control over the declaration or definition of the C-style library. Here's a sample: [snip code] Unfortunately, this isn't generally possible. boost::bind objects can carry state with them but function pointers cannot. However, if you have some way to associate arbitrary data with each callback (even if its just a void pointer), such as: typedef void (*callback_type)( int i, void* user_data ); Then you can use a combination of bind and function to create a thunk routine mapping the void* to a boost::function object. The technique is described here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Generalizing_C-Style_Callbacks Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.signal with gcc 3.3 or gcc 3.4
On Monday 03 March 2003 11:42 am, Lars Gullik Bjønnes wrote: I have been trying, but gcc failes with an ICE. Of course gcc should not segfault, but I am trying to find out if it is an segfault on valid code or if it is an segfault on illegal code. I have not been successful on finding a small testcase so far... I believe it is valid code. The EDG front end accepts it on its strictest mode, if that means anything. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::bind - simple test case does not work...
On Monday 03 March 2003 05:03 pm, Marc Jacobs wrote: bind( X::f, x, _1 )( 6 ); // error! You can't pass rvalues to boost::bind function objects, because of the forwarding problem in C++. If you use this it should work: int i = 6; bind( X::f, x, _1 )( i ); There's a good description of the forwarding problem here: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Encapsulate boost::bind in a template method
On Wednesday 19 February 2003 09:37 am, Peter Dimov wrote:
You'll soon find that this is not _that_ easier to use compared to
setEventHandler(bind(CButton::OnPaint, this));
and the latter is much more flexible:
setEventHandler(bind(CButton::OnMessage, this, WM_PAINT));
but that's another story. :-)
... and if you decide to go down that road, you'll likely want to write
setEventHandler like this:
void setEventHandler(const boost::function0long handler)
{
// add event handler to std::map
}
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
On Monday 17 February 2003 11:21 am, Beman Dawes wrote: Ouch! That means the current HTML docs for these libraries aren't available to Boosters who depend on CVS to keep up-to-date, They're always available here, regenerated nightly in HTML, DocBook, FO, PDF, and man pages: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html or to the inspect program, or any other operations that depends on the CVS tree including an exact representation of what a release would look like. I just ran inspect without any doc/ subdirectory. You'll see broken links from the forwarding HTML to $(BOOST_ROOT)/doc/html. Extract http://www.cs.rpi.edu/~gregod/boost/doc/boost-doc-html.tar.gz into $(BOOST_ROOT) and you'll have a full release. I think you need to develop a procedure so that a documentation change is reflected in the CVS doc/html files right away. We don't want to stick all of the generated HTML into CVS (too big). Documentation changes will show up the next morning at the aforementioned site. I'd like to add a link to this generated documentation on the main page (so it is obvious that both the current release documentation and the current CVS documentation are available on-line). Then the top-level site would look like this: http://www.cs.rpi.edu/~gregod/boost/index.htm Another effect of that change was to break all links to these docs from other Boost libraries. We won't even mention links from other web sites. They will only break if the links try to link inside the documentation files, e.g., to a specific anchor. Links that go directly to the library's entry point (index.html) will find the meta-refresh index.html that redirects to the generated documentation. I've checked with inspect: nothing broke. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
On Monday 17 February 2003 04:49 pm, Beman Dawes wrote: At 02:00 PM 2/17/2003, Douglas Gregor wrote: They're always available here, regenerated nightly in HTML, DocBook, FO, PDF, and man pages: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html That really isn't very satisfactory. In the last hour for example, pages on that web site have only been available sporadically. One minute access is OK, the next minute the site or page can't be found. No problems with other popular web sites. You probably caught me messing with the scripts (and therefore regenerating the documentation in-place). Having the docs locally on my own machine is just a lot more satisfactory. Cheaper, too (my Internet access is metered service.) Well, you'll have the doc source on your machine, and can generate whatever format you want. We don't want to stick all of the generated HTML into CVS (too big). If it is too big for the regular CVS, isn't it too big for the distribution too? How big is big? The documentation isn't big (~650k, much smaller compressed). However, generated documentation tends to change a lot even with minor changes to the input, so unless someone has a good way to tell CVS don't track any history for this file then the CVS repository will get huge with the histories of these generated files. Documentation changes will show up the next morning at the aforementioned site. I'd like to add a link to this generated documentation on the main page (so it is obvious that both the current release documentation and the current CVS documentation are available on-line). Seems like a step backward. We have a simple model now. Click on CVS update (or equivalent in your favorite client) and you get the latest version of all files. CVS is the only tool needed. Sure, but we also have documentation that's inconsistent across libraries, not indexable, and unavailable in any format other than HTML. Our current simple model is simple for simple uses, but doesn't extend to any more advanced cases. It really isn't practical for many Boost developers to download a whole tarball and unpack it every time they want to be sure their Boost tree is up to date. Unpacking doesn't do things like getting rid of obsolete files either. Need a way to just download the changed files - and that sounds like CVS to me. It's my hope that developers will adopt BoostBook for their own documentation. Then any time they want to be sure their local copy of the documentation is up-to-date they just regenerate the format they want locally. It's really not much different from rebuilding, e.g., libboost_regex with Boost Jam. So I think we need to figure out a way for generated docs to work in the context of CVS. Or am I just being too picky? If I can stabilize the filenames a bit, it _might_ be plausible to use CVS along with the cvs admin -o command, which can erase completely certain revisions of a file. It would be possible for a little grim reaper script to come by and erase all but the most recent version of each file on a nightly basis, after checking in the new version. Sounds tenuous to me... They will only break if the links try to link inside the documentation files, e.g., to a specific anchor. Links that go directly to the library's entry point (index.html) will find the meta-refresh index.html that redirects to the generated documentation. I've checked with inspect: nothing broke. Well, but that's because there are only three libraries being generated now. Some lib's docs do a lot more linking to other boost docs. --Beman It's easy to link out of the generated documentation to static documentation (of course), and it's much easier to link amongst entities in BoostBook than in HTML. For instance, librarynameTuple/libraryname will link to the Tuple library, regardless of where the HTML is (even if it isn't generated); functionnameboost::ref/functionname will link to the function boost::ref, regardless of where it is. Broken link detection is built into the BoostBook XSL, because it emits a warning whenever name lookup fails (and won't generate a link). What we do now is much more involved: find the HTML file and anchor documenting the entity we want to link, put in an explicit link a href=..., and checking the links will have to be run manually prior to a release. Using generated documentation has some up-front costs: you'll need to get an XSLT processor, and maybe some stylesheets (if you don't want them downloaded on demand), and probably run a simple configuration command (now a shell script; will be in Jam eventually). The time savings from the generated documentation will come in little pieces: you won't need to keep the synopsis in sync with the detailed description, you won't need to keep a table of contents in sync, keep example code in a separate test file in sync with the HTML version in the documentation, or look up
Re: [boost] Regression progress; Win32
On Saturday 15 February 2003 10:24 am, Beman Dawes wrote: * signals lib is failing all Intel and Microsoft tests; as recently as a few days ago the bulk of these were passing. Should be fixed now. I forgot to tell the library to link statically for the testcases. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Any, Function, and Signals documentation
I've removed the HTML-only documentation for these three libraries from CVS, as the documentation for each is now maintained in BoostBook. libraryname/index.html forwarding documents are in place to get to the generated documentation (in doc/html), and when we near the release I will provide a tarball/zip archive of the generated HTML, the contents of which should be extracted into $BOOST_ROOT before it is archived for release. Any questions/problems/objections/requests? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost_signals.dll contains no symbols
On Friday 14 February 2003 03:30 am, Aleksey Chernoraenko wrote: Oops..., I am sending again, now with files Would you please re-send slot.diff? It was sent as quoted-printable and ended up mangled on my end. Oddly enough, the others were perfectly fine. Thanks for doing this! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost_signals.dll contains no symbols
On Friday 14 February 2003 11:52 am, Douglas Gregor wrote: On Friday 14 February 2003 03:30 am, Aleksey Chernoraenko wrote: Oops..., I am sending again, now with files Would you please re-send slot.diff? It was sent as quoted-printable and ended up mangled on my end. Oddly enough, the others were perfectly fine. Please ignore this. I was able to get it from the archives. Thanks again for the patch. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Patch for function/function_base.hpp
On Thursday 13 February 2003 04:38 am, Daniel Frey wrote: Ah, that's the reason. But given my recent discomfort about unmaintainable code, look at it again: # if BOOST_WORKAROUND(__HP_aCC, = 33900) templatebool cond, typename T struct enable_if; # else templatebool, typename T struct enable_if; # endif Does this really makes sense? Shouldn't we just keep one version with names for template parameters? AFAICS this should work for all compilers and it could be a general boost coding guideline to always provide names for template parameters. Comments? FWIW, I didn't apply the patch directly but instead changed it to what you ask: templatebool cond, typename T struct enable_if; I'd be fine with making this a coding guideline... Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
On Thursday 13 February 2003 01:01 am, Lin Xu wrote: Attached is a prelimary replacement for function_traits.hpp. (When should I use the files section on yahoo? When should I attach? copy and paste code inline?) If it's really short, post a context diff. If it's short, attach. If it's longer than short, put it in the sandbox or files section. I added specializations for member function pointers, and for those specializations, a typedef class_type which is the class type of the pointer. For no-PTS compilers I added a set of template functions for function pointers. I would have expected that for member function pointers arg1_type would be typedef cv class_type* arg1_type; (where cv is the cv-qualifiers from the member function pointer). Unfortunely when I tried to test this by doing: cout boost::functionvoid (A::*)()::arity endl; The following errors occured: main.cpp: In instantiation of `boost::function_traitsvoid (A::*)()': main.cpp:33: instantiated from here main.cpp:33: base class `boost::detail::function_traits_helpervoid (A::**)()' has incomplete type It looks like the add_pointer doesn't know what to do with member function pointers. It knows what to do, it just doesn't do what we want. The add_pointer should only be performed when is_pointerT::value is false. This may affect many things, so I didn't touch anything else :) Would this affect boost::function? (from what I know it has some kind of member function pointer adaptor?) It won't affect boost::function (which doesn't even use function_traits). boost::signal could be affect, but only if function_traits stops working for function types. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [PRB] boost.function and Visual Age
On Thursday 13 February 2003 06:12 am, Markus Schöpflin wrote: Hi there, currently, boost.function and Visual Age don't get along very well. Unfortunately, I have no idea where to start in order to fix the problems. Could anyone please take a look at the regression logs and give me a hint where to start? That doesn't look good at all. function_n_test is the first testcase to work on, but it's giving some frightening errors: /home/auto/schoepf/src/extern/boost-cvs/libs/function/test/function_n_test.cpp, line 596.3: 1540-0130 (S) boost::function1 is not declared. /home/auto/schoepf/src/extern/boost-cvs/libs/function/test/function_n_test.cpp, line 636.5: 1540-0130 (S) boost::function2 is not declared. My first inclination would be to check the preprocessed output of the test, because it's possible that the preprocessor is failing miserably. Look for valid definitions of boost::function0, boost::function1, etc. (You can send me the preprocessed output privately if you'd like) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
On Thursday 13 February 2003 10:12 am, Peter Dimov wrote: --Compatibility-- This version of ref.hpp is backwards-compatible with the existing version of ref.hpp on a compiler that can handle the new ref.hpp (needs partial specialization and proper SFINAE handling). At some point I'll write a stripped-down version that other compilers can handle. I tried to do this once and failed. It's hard to make operator() work on deficient compilers (esp. the zero-arg version that is not a template) without breaking ref(x) where x is not a function object. Yep, this is the killer. Can't try to use result_type because it might not be there, can't detect result_type on broken compilers, and can't stop the declaration from being instantiated :(. Could just go with the limitation that arity 0 function objects won't work unless a return type is specified by the user. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
On Wednesday 12 February 2003 01:08 am, Lin Xu wrote: Yeah, I guess it would. The syntax I had before was limited by my lack of knowledge about how to extract the arguments and return type from a classtype. But I can use function_traits right? But that requires partial template specialization. Is there a way to get the types without PTS? How does boost::function do it? Maybe I can mirror the syntax of boost::Function. But boost::function doesn't have the function pointer as an actual template parameter. There is no known way to extract the argument types from function pointers or member function pointers without PTS. The class template boost::function only works when the compiler can handle it (which includes requiring PTS); otherwise the user is stuck with function0, function1, etc. I dont' know how to make that syntax work. I did originally want syntax like that, but I didn't know how to write it without PTS (or a least support non-PTS compilers nicely). Don't kill a good design because of bad compilers. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for function/function_base.hpp
On Wednesday 12 February 2003 12:37 pm, Markus Schöpflin wrote: Attached is a small patch for function_base.hpp. On line 302, there is a T missing. Markus Thanks. Applied. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for signals/trackable.hpp
On Wednesday 12 February 2003 12:41 pm, Markus Schöpflin wrote: Attached is a small patch for signals/trackable.hpp. According to 7.1.1(8), the mutable keyword cannot be applied on reference members and Visual Age flags this as an error. I just removed the mutable keyword an it compiles fine afterwards. Markus Thanks again. Applied. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::ref for function objects
We've discussed making boost::ref/boost::cref work for arbitrary functions objects before. I just committed a version of ref.hpp that supports this ability to the sandbox. With this code, you can write: std::transform(c.begin(), c.end(), out, boost::ref(f)); or, if you don't want the return type deduced, specify it as in Boost.Bind: std::transform(c.begin(), c.end(), out, boost::reffloat(f)); Features of this implementation: - Return type deduction (discussed below) - Argument type deduction (discussed below) - Able to handle function objects that have multiple arities (e.g., can be invoked with 0 or 2 arguments) The implementation is here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/boost/ref.hpp?rev=HEADcontent-type=text/plain Testcases are here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost-sandbox/boost-sandbox/libs/utility/ref_call_test.cpp?rev=HEADcontent-type=text/plain --Return type deduction-- - If the user specifies a return type, use it - Otherwise, if the class has a result_type typedef, use it - Otherwise, use Boost.Lambda-style sigarg_types::type --Argument type deduction-- - If typedefs arg1_type, arg2_type, ..., argN_type are available, use _precisely_ those argument types (as in Boost.Function) to define operator()(arg1_type), operator()(arg1_type, arg2_type), etc, up to 'N' for that particular class. - Otherwise, if the class has an argument_type typedef, define operator()(const argument_type). If the class also has first_argument_type and second_argument_type, define operator()(const first_argument_type, const second_argument_type); - Otherwise, if the class has first_argument_type and second_argument_type, define operator()(const first_argument_type, const second_argument_type); - Otherwise, define a bunch of function templates that deduce the argument types at call time, e.g., templatetypename T1, typename T2, ..., typename TN return-type-as-mentioned-before operator()(T1, T2, ..., TN); There is always an operator() that takes no arguments. --Compatibility-- This version of ref.hpp is backwards-compatible with the existing version of ref.hpp on a compiler that can handle the new ref.hpp (needs partial specialization and proper SFINAE handling). At some point I'll write a stripped-down version that other compilers can handle. The stripped-down version will feel a lot more like boost::bind: - Return type deduction will be limited to using a user-supplied return type, or else using ::result_type - Argument type deduction won't look for argN_types, argument_type, or first/second_argument_type, but will fall back to the set of function templates that deduce the argument types from the call. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::ref for function objects
On Wednesday 12 February 2003 07:15 pm, David Abrahams wrote: Douglas Gregor [EMAIL PROTECTED] writes: We've discussed making boost::ref/boost::cref work for arbitrary functions objects before. I just committed a version of ref.hpp that supports this ability to the sandbox. With this code, you can write: std::transform(c.begin(), c.end(), out, boost::ref(f)); What's the key feature? Overloaded operator() on reference_wrapper? Yes. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Reflection system in C++ using templates
On Wednesday 12 February 2003 09:11 pm, Lin Xu wrote: Hm... - Functionvoid (A::*)(),A::Setz if the compiler supports PTS; - If not, then the user would have to type in something like: Function0void,A,A::Setz. Looks good. Another (slightly offtopic) thing. I attempted to use function_traits with a member function type. GCC spat out errors, and looking at the source code I don't think it *should* work anyway. Correct? If so, shouldn't there be an additional set of specializations for function_traits that specialize for member function pointers? Right. function_traits was intended to work with function types (not function pointers, even), because that's what boost::function needed, but I'd be happy to see it extended to support member function pointers. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for boost::array test failures?
On Friday 07 February 2003 05:58 pm, Alisdair Meredith wrote: I have a potential patch for the boost::array tests that will pass under Borland 0x561 and probably under MSVC as well [I think it is the same issue] I am leary of resolving an issue by patching a test, but I think the issue is comparatively minor, especially in regard to most library use, and currently failing 40% of tests does not accurately reflect the case either. The problem is that borland (and likely MS) cannot use initialiser syntax for aggregates that are in turn made up of non-aggregate types. The failing tests (3 4) uses arrays of std::strings. Switching to const char * on the broken compiler 'resolves' the issue. Hence the proposed patch: [from CVS diff logs] I'm okay with this patch, but I would like to also keep a testcase that checks specifically for this failure so that we don't forget that this is indeed a potential problem for users. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] People and pictures?
On Friday 31 January 2003 08:02 pm, Beman Dawes wrote: It seems to me one solution is to move the pictures to some location other than CVS. Probably the Boost SourceForge disk allotment. The capsule biographies would stay on the CVS, and thus would continue to be part of the web site and distribution files. Because adding a new biography will be much simpler, anyone with CVS write access would be able to do it. We'd have to write up a little guideline, but that shouldn't be a problem. I like this solution best. No helpful comments from me, though :( Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC6 infinite loop with function/stateless_test
On Thursday 30 January 2003 05:41 am, David Abrahams wrote: The subject says it all. We should find a workaround for this or it'll screw up all vc6 testing pretty badly. When did you first start seeing this? Last night? I didn't change anything... Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Usability of http://boost.sourceforge.net/regression-logs
On Wednesday 29 January 2003 12:20 pm, David Abrahams wrote: It seems to me that while lib developers may be interested in the big table, most users, unless they care extraordinarily about portability, will want to know about individual compiler results. I wonder if we shouldn't be assembling the HTML on-the-fly for all tables, and just having testers upload jam logs? I know this goes against the grain of Beman's desire to produce the HTML with C++ code because of CGI portability issue, but I have the sense that until we have a true portable C++ virtual machine this might be the wrong kind of job for our favorite language. -Dave One option would be to dump the tests in some XML format, because we can easily transform that into the various HTML pages we'd want with an XSLT processor. Sourceforge has xsltproc available on its servers... [Yes, I'm beginning to sound like a broken record, but I really don't think we should ever be generating documentation directly from C++ code.] Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC6 infinite loop with function/stateless_test
On Thursday 30 January 2003 11:05 am, David Abrahams wrote: Douglas Gregor [EMAIL PROTECTED] writes: On Thursday 30 January 2003 05:41 am, David Abrahams wrote: The subject says it all. We should find a workaround for this or it'll screw up all vc6 testing pretty badly. When did you first start seeing this? Last night? Yes. I didn't change anything... I haven't run the test in weeks if not longer, so you might look backwards... It passed yesterday on Beman's setup. I'll see if I can duplicate the problem here. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Usability of http://boost.sourceforge.net/regression-logs
On Thursday 30 January 2003 11:05 am, David Abrahams wrote: [Yes, I'm beginning to sound like a broken record, but I really don't think we should ever be generating documentation directly from C++ code.] I can't see any relevance. Care to explain? I stated that _very_ poorly. I meant that I don't believe we should be writing HTML directly: not by ourselves for documentation, and not with C++ code for regression tests. As soon as we put data into HTML, we've lost most of the structure of the data. With documentation, losing structure means that it is harder to cross-reference information or pick out the most important information for a particular task; with the regression tests, we lose the ability to easily generate other kinds of regression test tables because all of the structure of the data was thrown out when the C++ program ended. I also find tweaking the HTML output from C++ code to be an unnecessarily time-consuming process. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
On Wednesday 29 January 2003 09:42 am, Daniel Frey wrote:
// given some is_base_and_derived B, D ::value
template typename T struct is
{
template typename U struct derived_from
{ enum { value = is_base_and_derived U, T ::value };
template typename U struct base_of
{ enum { value = is_base_and_derived T, U ::value };
};
// usage:
is D ::derived_from B ::value
is B ::base_of D ::value
Thoughts?
Regards, Daniel
It gets ugly in the common case (where D is a template parameter):
isD::template derived_fromB::value
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal for any_cast to references
On Tuesday 21 January 2003 04:24 pm, David Abrahams wrote: Unai Uribarri [EMAIL PROTECTED] writes: Currently, any_cast doesn't allow to cast to references. Instead, you have obscure castings from any* to T returning T*. That sounds like a design mistake on the face of it. This comment has come up before, and everyone seems to agree that we'd prefer the semantics that Unai proposes. I think the only reason that we haven't changed the semantics is that we don't want to change Kevlin's design without hearing the reasons for the existing design. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-docs] Integrating BoostBook documentation withHTMLdocumentation
On Monday 20 January 2003 01:44 pm, Beman Dawes wrote: I guess I'm still unsure how the generated HTML docs are going to be integrated with the rest of the web site and CVS. My understanding was that the docs in formats other than HTML would go on a separate web site, but that the source and HTML would be on the regular site. I assumed that also meant they would be in the regular CVS. --Beman I'm going to assume that library documentation for a particular release is not changed after the release. This is the way we do things now---www.boost.org has the library documentation for 1.29.0. When we release 1.30.0, it will have the 1.30.0 documentation and won't change until we release another version. So here is the suggestion: The documentation source (BoostBook format) will be in CVS. Whatever the stable documentation from the last release is, it will be on the regular site (www.boost.org). On another site (currently www.cs.rpi.edu), there will be a nightly script that keeps an up-to-date CVS tree and regenerates documentation in various formats (including HTML) from CVS. The main page at www.boost.org would look something like this: http://www.cs.rpi.edu/~gregod/boost/index.htm Instead of a single Documentation link, we have a link to the documentaiton for the most recently released Boost version, which will be to a local copy of the documentation (e.g., doc/html/libraries.html or libs/libraries.htm). The documentation is static---it may have been generated for the release, but it won't change after that. The second link, CVS, will always go to www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html (or wherever the nightly documentation generation puts the result). If a user is using Boost from CVS and wants a local copy of the HTML documentation, they should download boost-doc-html.tar.gz and extract it in the same place they checkout Boost CVS. Then the first link under documentation (for the current version) will reference the documentation they download. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Policy-based smart pointers revisisted
On Monday 20 January 2003 09:25 pm, Paul Mensonides wrote: - Original Message - From: Edward Diener [EMAIL PROTECTED] People disagree with others all the time based on their technical understanding. No one's opinion is exempt from reasonable discussions or arguments over what someone else perceives as the correct solution to a technical problem. In the example I mention, which was the sequence abstraction design of the MPL, there was a massive debate on the pros and cons of that design. Ultimately, I consensus was never reached because everybody got tired of arguing. That said, the design was (and probably still is) untested in real code, whereas the simpler design was. To that end, Andrei asked anyone to convince him with a practical code sample that justified the design. It never happened. We had a severe case of several experts fundamentally disagreeing. The only possible resolution was to display the validity of the design with an example, but instead, Andrei's concerns where disregarded altogether, and he was basically told to deal with it. Andrei's concerns were not disregarded. I acted as review manager for MPL when this discussion occurred, and I considered Andrei's comments along with the comments of every other reviewer prior to rendering a decision. In the review results, I commented that the usefulness of the iterator abstraction was not proven, and that only additional experience with the library would tell whether or not the abstraction is useful. You may read my comments here, if you would like: http://aspn.activestate.com/ASPN/Mail/Message/1341450 Andrei's opinion was in the minority, but it was not dismissed. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Sunday 19 January 2003 09:14 pm, Rene Rivera wrote: In order to make regression test browsing more pleasant for all of us. I decided to work up a little script to gather up all the test results that get posted to the boost.sourceforge.net site. So browse on over to: http://boost.sourceforge.net/regression-logs ..and take a look. Very nice! Do we get dancing monkey graphics if we hit 100% pass? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-docs] Integrating BoostBook documentation withHTMLdocumentation
On Sunday 19 January 2003 08:25 pm, Beman Dawes wrote: I'd like to see a bit more refinement first, and understand how the maintenance works. Let's take the last first. What does a developer do to add a new library? If the library documentation is in the BoostBook format, just make sure the Boost documentation includes the BoostBook source (e.g., by adding an appropriate xi:include element to boost.xml). If the library documentation is in HTML, the developer needs to add a library description to the file boost-sandbox/libs/documentation/examples/boost.xml. A library description looks like this: library name=Compressed Pair dirname=utility html-only=1 url=../../libs/utility/compressed_pair.htm libraryinfo author firstnameJohn/firstname surnameMaddock/surname /author author firstnameHoward/firstname surnameHinnant/surname /author librarypurposeEmpty member optimization/librarypurpose librarycategory name=category:data-structures/ librarycategory name=category:misc/ /libraryinfo /library I think the above is relatively self-explanatory. The library category names are in the same file (boost.xml), and are each defined like this: librarycategorydef name=category:string-text String and text processing /librarycategorydef As far as refinement goes: * Why the bloat of breaking libraries.html up into multiple files? For me, at least, this reduces the quality of the browsing experience. That's mostly an issue with the way I'm using DocBook. Will fix. * The navigation header and footer need more work, IMO: -- Some color and general site navigation help. If you don't like the usual Boost intermediate level page header (see the current libraries.htm), design another one. But the page needs something to give it a bit of life, identification with Boost, navigation back to home, etc. Will do. Sprucing up the headers has been on the task list for a while, but nobody has yet to take on the challenge :) -- Footer should have a revised date. I like the horizon rule, too. A generated date would be easy; a revised date isn't so easy, because it's not trivial to figure out when something used in the list changed. -- Personally, I dislike prev and next links in general, and particularly those that give no indication of what they are linking to. Hovering the cursor to see the link URL helps a bit, but only a little. The footer is much better than the header in this regard, because it actually gives names. * Have you tried single spacing the alpha and by category lists? The old single spacing seems a tiny bit easier to scan, although that is obviously very subjective. Done. I think it does look better. * The formatting of the HTML isn't very human reader friendly. Would it be possible to do a bit of formatting? I'm not sure. XSLT does have an indent property when transforming to another XML document, but AFAIK it's not considered safe to use when spacing is important. And spacing _is_ important, especially within the reference documentation. Have you check to verify there won't be any CVS churn once this becomes something that is checked into CVS? (Unless, of course, there is a real change on the page.) I'm not expecting this page to go into CVS, but to be autogenerated nightly along with the rest of the documentation. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [signals] Minor doc bug?
On Thursday 09 January 2003 07:43 pm, David B. Held wrote: Under: Passing values to and from slots in tutorial.html, it looks like the old syntax is being used: boost::signalvoid, float, float sig; The tables are correct. Only the references in the text appear wrong. Dave Thanks! The fix is now in CVS. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [C++-sig] weird bug of addressofT in MSVC 7
On Tuesday 07 January 2003 06:08 pm, David Abrahams wrote: This compiler bug was reported on the Python/C++-sig. Probably we should stick a const_cast in addressof just for vc7? Would you mind doing it? I don't have access to VC7 to test any changes. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression test program compiler_status slightlymodified...
On Friday 03 January 2003 11:43 am, Beman Dawes wrote: At 11:57 PM 1/2/2003, Douglas Gregor wrote: I've (slightly) modified the compiler_status program to search boost/status/testsuites.jam in addition to boost/status/Jamfile when trying to determine the type of a test. I think this will fix the problems with the testsuites generated from the BoostBook testsuite descriptions. Thanks! Compiled fine. Win32 tests being run now. --Beman Didn't work. Looks like I managed to omit a very necessary patch to boost/status/Jamfile. It's there now, so I believe that the regression tests should be back in working order after the next cvs update. (If it works, you'll notice a lot more Function testcases) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Location of generated documentation in Boost tree?
Where in the Boost tree should we put generated documentation? I'm ready to the use some of the documentation generated from C++XML/DocBook as the documentation for some of my libraries, but I would first like to establish some conventions. I suggest: - We create a directory boost/doc that will contain generated Boost documentation. This directory will have subdirectories for each documentation format (e.g., doc/html, doc/man, doc/pdf). - We create forwarding pages libs/library-name/index.html and libs/library-name/doc/index.html that reference the generated documentation. - We place the C++XML/DocBook sources for each library in libs/library-name/doc_src - We place the top-level DocBook sources in boost/doc_src Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: boost::function MSVC
On Friday 20 December 2002 08:14 am, Steven Ketcham wrote: Yes, every thing (STL stuff) works except boost. Turning off the STL filter made no difference. It only captures output and filters it. I am left with the impression that the #defines are wrong for my particular setup. Please remember that this is a brand new Win2000 install with all the patches, the new platform SDK and IE 6.0. I skipped 5.5 IE. Ah ha! I know the platform SDK has been known to cause some weird problems (this happened to at least one user of the Boost.Python lib). The platform SDK path needs to be first in the list of paths to the compiler. This page on the Wiki tells how one user did it: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?MsVc6 Are there any library differences between WinXP and Win2000? Not that I know of, but I'm no expert on the Windows development platform. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review: Optional library
On Monday 09 December 2002 11:55 am, Douglas Gregor wrote: The formal review of Fernando Cacciola's Optional library begins today and runs until the end of Wednesday, December 18. The review of Fernando Cacciola's Optional library has ended. I will post review results this weekend. A hearty thank you goes to all reviewers. Doug Gregor [EMAIL PROTECTED] (Optional review manager) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::function MSVC
On Thursday 19 December 2002 12:25 pm, Steven Ketcham wrote: boost_1_29_0\boost\function\function_template.hpp(73): error C2061: syntax error : identifier 'any_pointer' boost_1_29_0\boost\function\function_template.hpp(79): see reference to class template instantiation 'boost::detail::function::function_invoker0FunctionPtr,R' being compiled Hopefully this is obvious. Any suggestions? That's a really strange error, because it appears that boost::detail::function::any_pointer (defined in boost/function/function_base.hpp) never actually got defined. Have you tried re-extracting the Boost archive just in case something got mangled? (Note: I can't check your sample code at the moment, but you're using almost precisely the same configuration that I test on, and this problem has never come up). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::function MSVC
On Thursday 19 December 2002 03:36 pm, Steven Ketcham wrote:
** {BD Software Proxy CL v2.29} STL Message Decryption is ON! **
I'm beginning to suspect this little program (or perhaps the installation of
MSVC). The errors you are getting are in libraries that are well-tested on
your configuration (minus the STL Message Decryption). Do other non-Boost C++
programs compile? Can you try Boost without the STL message decryption?
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Function Binding
On Monday 16 December 2002 01:39 am, Greg Dehaas wrote: //Macros for binding functions + methods #define BINDMETHOD5(object,function) boost::bind(function,object,_1,_2,_3,_4,_5) #define BINDFUNCTION5(function) boost::bind(function,_1,_2,_3,_4,_5) #define BINDMETHOD4(object,function) boost::bind(function,object,_1,_2,_3,_4) #define BINDFUNCTION4(function) boost::bind(function,_1,_2,_3,_4) #define BINDMETHOD3(object,function) boost::bind(function,object,_1,_2,_3) #define BINDFUNCTION3(function) boost::bind(function,_1,_2,_3) #define BINDMETHOD2(object,function) boost::bind(function,object,_1,_2) #define BINDFUNCTION2(function) boost::bind(function,_1,_2) #define BINDMETHOD1(object,function) boost::bind(function,object,_1) #define BINDFUNCTION1(function) boost::bind(function,_1) #define BINDMETHOD(object,function) BINDMETHOD1(object,function) #define BINDFUNCTION(function) BINDFUNCTION1(object,function) The BINDFUNCTION macros aren't actually needed. Anywhere that you would have: boost::functionN... f; f = BINDFUNCTION(g); You could have just written: boost::functionN... f; f = g; I'd also strongly suggest that you don't use the BINDMETHOD macros, because sooner or later you'll find yourself needing to use more of bind's features. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal: Identifying libraries
On Monday 16 December 2002 09:17 am, Beman Dawes wrote: I'd like to propose changing that (particularly for headers) to: // See http://www.boost.org/library-name for documentation. I assume you mean http://www.boost.org/libs/library-name;? and require that it be the first instance of http://www.boost.org/; in a source file. That will make it easy to associate a header with the library it belongs to, and may also help users reach documentation quickly. Comments? --Beman Sounds good. I think we should try to do the conversion automatically, at least for all files in subdirectories (e.g., the file boost/xxx/yyy.hpp would be assumed to be a part of library xxx if libs/xxx exists) and for files boost/xxx.hpp where there is a library in libs/xxx. We don't want to do this conversion by hand :) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] function binding
On Friday 13 December 2002 07:21 am, Greg Dehaas wrote:
So far, I've got something like this:
CODE ---
#include boost/function.hpp
#include functional
//Simple Class
class CSimple
{
public:
void SimpleMethod()
{
printf(Simple Method Called\n);
}
};
//Entry point
void main()
{
boost::functionvoid oSimpleMethod;
oSimpleMethod =
std::bind1st(std::mem_fun(CSimple::SimpleMethod),oSimple);
oSimpleMethod();
}
Now it seems like it's to do with the way I'm trying to use std:bind1st
(which I've never used before)
However, the boost documentation shows examples doing exactly what I'm
doing!?!
Can anyone spot the mistake?
Greg
PS: I'm using VC++ 6
bind1st only works for binary function objects, but SimpleMethod is only
unary. The example in the Boost.Function documentation actually has a method
taking an int parameter, so it works. It's quite silly, actually, that
bind1st is so limited.
Anyway, with MSVC you'll want to use Boost.Bind along with Boost.Function. The
code will look like this:
boost::function0void oSimpleMethod;
oSimpleMethod = boost::bind(CSimple::SimpleMethod, oSimple);
oSimpleMethod();
Other than the bind change (it's much cleaner using Boost.Bind!), I've changed
boost::function to boost::function0 because MSVC can't currently handle
the boost::function class template very well. ('0' is the number of function
parameters it takes).
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Formal review: Optional library
The formal review of Fernando Cacciola's Optional library begins today and runs until the end of Wednesday, December 18. The Optional library provides a class template optionalT that either contains a value of type T or contains no value (i.e., having a value is optional). It is useful, for example, as the return type of functions that may or may not return a value, depending on their inputs. The Optional library can be downloaded from the Boost files section: http://groups.yahoo.com/group/boost/files/optional.zip Please state in review comments whether or not you believe that the library should be accepted into Boost. Further guidelines for writing reviews can be found here: http://www.boost.org/more/formal_review_process.htm#Comments Thank you, Doug Gregor (Optional (but not uninitialized) review manager) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
On Saturday 07 December 2002 06:47 am, John Maddock wrote: Maybe we need something new for those folks: something like BOOST_NO_WORKAROUNDS or whatever, that disables all compiler workarounds? To keep things centralised BOOST_NO_WORKAROUNDS should be defined by the compiler config when the compilers version is greater than the last known version and BOOST_STRICT_CONFIG is set, then boost workaround-code need only check for the presence of BOOST_NO_WORKAROUNDS or whatever in addition to the compiler version. How does this sound? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm I like it. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_CONFIG
On Wednesday 04 December 2002 08:53 am, David Abrahams wrote: It looks like some people (ahem! wink) have been using BOOST_NO_CONFIG where they should be using BOOST_STRICT_CONFIG. See boost/function/function_base.hpp. Oops. Fixed now. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_CONFIG
On Thursday 05 December 2002 08:51 am, David Abrahams wrote: Douglas Gregor [EMAIL PROTECTED] writes: F On Wednesday 04 December 2002 08:53 am, David Abrahams wrote: It looks like some people (ahem! wink) have been using BOOST_NO_CONFIG where they should be using BOOST_STRICT_CONFIG. See boost/function/function_base.hpp. Oops. Fixed now. Well, now John Maddock may be quarrelling with you over the correct approach. We need to decide how this will work. -Dave It seems like places that need BOOST_(STRICT|NO)_CONFIG in the source don't fit the documentation for either macro. BOOST_STRICT_CONFIG just tells the config system how pessimistic to be w.r.t. new compiler versions. BOOST_NO_CONFIG tells the config system not to include any of its configuration headers (i.e., don't define any defect/extension macros). As it stands now, I think the right way to write compiler/library/platform-dependent workarounds is to check for _both_ BOOST_STRICT_CONFIG and BOOST_NO_CONFIG. BOOST_STRICT_CONFIG disables the workaround when dealing with a new compiler version, whereas BOOST_NO_CONFIG disables the workaround when the user has asked not to configure for the compiler. Maybe BOOST_NO_CONFIG (actually, BOOST_NO_COMPILER_CONFIG) should define BOOST_STRICT_CONFIG? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
On Thursday 05 December 2002 02:41 pm, David Abrahams wrote: I propose: #ifndef BOOST_STRICT_CONFIG # define BOOST_WORKAROUND(symbol, test) (defined(symbol) symbol test) #else # define BOOST_WORKAROUND(symbol, test) 0 #endif Comments? I'm still not sure that BOOST_STRICT_CONFIG is the right macro to determine if workarounds are enabled or not, but if John agrees then I'm happy with it. Regardless of what macro determines which BOOST_WORKAROUND is used, I like the above definition (+ dumb compiler workarounds). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] SourceForge Vandalism
On Wednesday 04 December 2002 09:54 am, David Abrahams wrote: The Scons Wiki was recently vandalized. This is just a reminder about our exposed assets. If you have open-source resources which ought to be backed up, this might be a good time... Jeff, is our Wiki backed up at regular intervals? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: functor adapter
On Friday 22 November 2002 10:53 am, Martin Bosticky wrote: Thanks wery much for both commets, Douglas and Peter I will have a look at bind and lambda libraries but i remember i had trouble using the lambda library under VC6 together with bind1st Martin. Bind will work on VC6, Lambda will not. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
