[boost] Re: $egression tests -- no links for Win32 errors?
Beman Dawes wrote: There are two other versions we might want to consider eliminating (KISS): Messages only - Shows status only for tests with warnings or failures. Failures only - Shows status only for tests with failures. I never find myself looking at those. Does anyone else use them? I certainly use the Messages only view, although my primary view has become the one with differences emphasised. If we had messages only, differences emphasised, that would probably be my default oops, more work not less! I guess if I'm the only one using them though, there's no harm in letting them go. [I keep trying to find time to sneak in some more borland fixes, but every time you think the schedule has cleared...] -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
From: David Abrahams [EMAIL PROTECTED] Terje Slettebø [EMAIL PROTECTED] writes: Perhaps it might be possible to do some compile-time/run-time lambda (similar to Boost.Lambda for runtime, and MPL's lambda), so you could do something like: mpl::for_eachmy_list(my_function_(s)); It would then transform the function call my_function_(s) into an instantiated function object of the kind suitable for mpl::for_each. I'm afraid that particular syntax won't work for this particular case, though. If my_function is a function template, my_function_ is a function, and my_function_(s) calls that function. Yes, even with function template template parameters, the syntax would have to be changed. I realised that you can't just pass the address of a function, since in this case, it's a function template. Besides, it wouldn't help to use the placeholder in that place (unless you specialised the user-supplied function, but that would be no point). The above was just to sketch the idea of it. Since there are no (function template) template parameters, only (class template) template parameters, there doesn't appear to be any way to make this one particularly easy except by using the preprocessor to define some kind of function object. Yes, I realised that later, as well. Is there any good reason for not allowing function templates as template template parameters? I think it's amazing that we got the template facility that exists, in the standard, so maybe it simply wasn't time to consider this, to avoid delaying standardisation. If this was possible, you might have done something like this, instead (using TTP): mpl::for_eachmy_list, std::string , my_function(s); It appears to be just bad luck that higher order functional programming with function templates is impossible in C++. Well, it might be changed in a future revision of the standard, if it turns out to be practical. I can imagine something like this: templateclass Sequence, class T, templateclass void Function(T) struct for_each; Possibly using overloaded class templates, as well (another possible extension). Anyway, this goes beyond the topic of Boost. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
From: Terje Slettebø [EMAIL PROTECTED] I can imagine something like this: templateclass Sequence, class T, templateclass void Function(T) struct for_each; Possibly using overloaded class templates, as well (another possible extension). Come to think of it, the latter wouldn't be needed here, as for_each is a function template, and they can be overloaded. :) That would allow different arity for the the function template template parameter. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
From: David Abrahams [EMAIL PROTECTED]
I've been talking with Aleksey recently about how to improve the
syntactic situation without losing the separation of concerns that we
get, but we didn't come up with anything convincingly better. I think
a long time ago the for_each parameter used to look like:
class f
{
template class T
struct apply
{
static void execute() {...};
};
};
IOW, a metafunction class with a nested 'execute' function. However
that's not really any better syntactically, it has problems carrying
state, and it's anti-idiomatic.
The state problem is easy:
struct F
{
templateclass T void execute();
};
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] threads and gcc and BSD
I think I may be the one who broke a lot of the OpenBSD regression tests by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. IMO this is correct (OpenBSD supports pthreads right?), but it causes a problem: currently the gcc config unconditionally defines BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc on *BSD doesn't define anything when you build with -pthread - basically defining -pthread affects only the linker, so we can't detect when to turn on threading support). This in turn is breaking a lot of libraries: mainly those that depend upon smart pointers, which do internal thread synchronisation, and therefore need the -pthread option in order to link correctly. What should we do about this? Option 1: ~~ would putting: flags gcc CFLAGS threadingsingle : -DBOOST_DISABLE_THREADS ; fix the problem? Option 2: ~~ Add flags gcc CFLAGS threadingmulti : -pthread -D_REENTRANT ; to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for gcc. This one may have all sorts of unexpected side effects on other platforms though - even though philosophically it does seem the right thing to do. Option 3: ~~ Make -pthread the default build option in the gcc toolset for *BSD platforms ~~~ Any other ideas? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
Well the wording in the standardisation proposal says: value: defined to be true only if type From is implicitly-convertible to type To (4.0). Which really says it all IMO (by reference to section 4.0 of the standard. Gulp! In the ISO proposal??? OK it needs tightening up: in particular the preconditions need specifying (To must not be a void, function, incomplete or abstract type, From must not be void), and it should probably say value: defined to be true only if an expression of type From is implicitly-convertible to type To (4.0). Getting the wording right is difficult, but the semantics are intended to be the same as 4.0p3. Personally I would be happy if it were a precondition that neither To nor From were void types. It makes sense only if you want it to make sense. That is, like almost all other cases, it depends on your definition of is_convertible, which is exactly what we miss. The fact that I had to ask means that the definition in the documentation is not enough, and that I must *as a library user* go to look at the implementation to see what happens in my special case. The problem is that even then I remain in doubt: is this just a chance due to the way they have implemented it or is it intentional? If they'll change the implementation in the future can the value be different so that my code is unexpectedly broken? I agree, there should be no special cases, the wording should refer only to the standard, not to the implementation. From Peter Dimov: Nope, it says nothing AFAICS. A type cannot be convertible. Only values are. And you cannot say a value of type From is implicitly convertible to To (4.0) because you need to specify whether that value is an lvalue of type From or an rvalue of type From, and what do l- and r-values mean when applied to strange (array, reference, function, abstract, etc) types. I refer you back to 4.0p3, which talks about expressions of type T, which are treated as lvalues if the type is a reference, otherwise as an rvalue. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] undo library
Hello there!
I just wanted to ask if there would be someone interested in a framework
library for undo/redo-functionality. In other C++ groups sometimes the
question pops up, how to implement undo-functionality. Since I've written
such thing as part of a programm of mine and since I have it boostenised
already, I would like to introduce it briefly. Please feel free to give me
any comments about it...
Basicly there are two classes: boost::undo_list and boost::undo_action, the
latter is an abstract base class for any undo-function you want to
provide...
Instead of describing all the details I'll just give a short example of how
one could use the library...
//
#include string
#include iostream
using namespace std;
#include undo_action.hpp // class boost::undo_action
#include undo_list.hpp// class boost::undo_list
#include myown_undoactions.hpp // contains undo-action classes
int main() {
// 1. create the undo list somewhere
boost::undo_list undolist;
// 2. maybe you want to change the number of maximum undo steps
undolist.set_maxundo(100);
string teststring;
teststring = This is a simple test of the boost undo library;
cout Original string: teststring endl;
// Ok, someone want's to remove a part of that string.
// let's start with constructing the undo-action and adding that to
// the undo list. The class StringEraseUndo is a user defined
// undo class derived from undo_action
// 3. create and add an undo action
// NOTE: the constructor can look whatever the user wants it
// to look like (see example at end of posting)
undolist.add( new StringEraseUndo(10, 7,
teststring.substr(10, 7), teststring) );
// NOTE: All pointers added to the list make the objects
// be OWNED by the list, thus the list is responsable
// for cleaning up the memory
// 4. perform the will-be-made-undone action
// That means, let's finally delete that substring
teststring.erase(10, 7);
cout After erase: teststring endl;
// 5. and now let's make this undone...
undolist.undo_last();
cout After UNDO: teststring endl;
// 6. or re-done, if you like
undolist.redo_last();
cout After REDO: teststring endl;
};
//
Well, it is obvious that the biggest problem in using the undo-library will
be the implementation of the user defined undo/redo-classes.
For the example above the class StringEraseUndo could look like this:
class StringEraseUndo : public undo_action {
public:
// Ctor
StringEraseUndo(std::size_t start, std::size_t size,
const std::string snipped, std::string str)
: start_(start), size_(size), snipped_(snipped), str_(str) {};
virtual bool undo();
virtual void redo();
private:
std::size_t start_;
std::size_t size_;
std::string snipped_;
std::string str_;
};
bool StringEraseUndo::undo() {
str_.insert(start_, snipped_);
return true;
};
void StringEraseUndo::redo() {
str_.erase(start_, size_);
};
However, since the undo-classes can be whatever they want to be, including
non-C++-standard stuff like GUI things, this library can be used in almost
any circumstances. The Framework, that is the undo_list and the undo_action
classes can still be written in plain C++ without having to know anything
about the users environment. This clearly qualifies these classes as a
library.
Sorry for the long text, but with just describing the system shortly it
would have caused too much confusion :-)
The library itself (that is the undo_action.hpp, undo_list.hpp and
undo_list.cpp) are ready so far. Do you think this could be a useful
addition to the boost library?
Thanks for any comments!
Bye - Andreas
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
From: John Maddock [EMAIL PROTECTED] From Peter Dimov: Nope, it says nothing AFAICS. A type cannot be convertible. Only values are. And you cannot say a value of type From is implicitly convertible to To (4.0) because you need to specify whether that value is an lvalue of type From or an rvalue of type From, and what do l- and r-values mean when applied to strange (array, reference, function, abstract, etc) types. I refer you back to 4.0p3, which talks about expressions of type T, which are treated as lvalues if the type is a reference, otherwise as an rvalue. Thanks. I don't think that 4.0p3 explains everything, though. I doesn't talk about expressions of type T. It talks about converting an expression e to type T; it then explains that the result of that conversion is an lvalue when T (To in our case) is a reference type. It says that e is used as an lvalue if and only if the initialization T t(e) would have used it as an lvalue. This still doesn't solve the expression of type From problem since an expression can be either an lvalue or an rvalue, and there are no expressions of reference types, only expressions that are lvalues. Of course I'm not a core expert. For example, is an expression of type int[4] convertible to int[4]? To int () [4]? To int const [4]? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] undo library
Just one thought : couldn't much of this be achieved without having to
create your own undo classes by boost::functions and the boost::bind
library?
for example, to implement just the undo (untested code, just to give an
idea, I'm not suggesting that this wouldn't be better wrapped in an
undo_list class):
-
void string_erase_undo(std::string dest, int pos, std::string to_insert)
{
dest.insert(pos, to_insert);
}
std::vector boost::functionvoid() undolist;
std::string teststring = This is a simple test of the boost undo library;
undolist.push_back(boost::bind(string_erase_undo, teststring, 10,
std::string(teststring, 10, 7));
teststring.erase(10, 7);
// to undo:
undolist.back()()
-
Hello there!
I just wanted to ask if there would be someone interested in a framework
library for undo/redo-functionality. In other C++ groups sometimes the
question pops up, how to implement undo-functionality. Since I've written
such thing as part of a programm of mine and since I have it boostenised
already, I would like to introduce it briefly. Please feel free to give me
any comments about it...
Basicly there are two classes: boost::undo_list and boost::undo_action,
the
latter is an abstract base class for any undo-function you want to
provide...
Instead of describing all the details I'll just give a short example of
how
one could use the library...
//
#include string
#include iostream
using namespace std;
#include undo_action.hpp // class boost::undo_action
#include undo_list.hpp// class boost::undo_list
#include myown_undoactions.hpp // contains undo-action classes
int main() {
// 1. create the undo list somewhere
boost::undo_list undolist;
// 2. maybe you want to change the number of maximum undo steps
undolist.set_maxundo(100);
string teststring;
teststring = This is a simple test of the boost undo library;
cout Original string: teststring endl;
// Ok, someone want's to remove a part of that string.
// let's start with constructing the undo-action and adding that to
// the undo list. The class StringEraseUndo is a user defined
// undo class derived from undo_action
// 3. create and add an undo action
// NOTE: the constructor can look whatever the user wants it
// to look like (see example at end of posting)
undolist.add( new StringEraseUndo(10, 7,
teststring.substr(10, 7), teststring) );
// NOTE: All pointers added to the list make the objects
// be OWNED by the list, thus the list is responsable
// for cleaning up the memory
// 4. perform the will-be-made-undone action
// That means, let's finally delete that substring
teststring.erase(10, 7);
cout After erase: teststring endl;
// 5. and now let's make this undone...
undolist.undo_last();
cout After UNDO: teststring endl;
// 6. or re-done, if you like
undolist.redo_last();
cout After REDO: teststring endl;
};
//
Well, it is obvious that the biggest problem in using the undo-library
will
be the implementation of the user defined undo/redo-classes.
For the example above the class StringEraseUndo could look like this:
class StringEraseUndo : public undo_action {
public:
// Ctor
StringEraseUndo(std::size_t start, std::size_t size,
const std::string snipped, std::string str)
: start_(start), size_(size), snipped_(snipped), str_(str) {};
virtual bool undo();
virtual void redo();
private:
std::size_t start_;
std::size_t size_;
std::string snipped_;
std::string str_;
};
bool StringEraseUndo::undo() {
str_.insert(start_, snipped_);
return true;
};
void StringEraseUndo::redo() {
str_.erase(start_, size_);
};
However, since the undo-classes can be whatever they want to be, including
non-C++-standard stuff like GUI things, this library can be used in almost
any circumstances. The Framework, that is the undo_list and the
undo_action
classes can still be written in plain C++ without having to know anything
about the users environment. This clearly qualifies these classes as a
library.
Sorry for the long text, but with just describing the system shortly it
would have caused too much confusion :-)
The library itself (that is the undo_action.hpp, undo_list.hpp and
undo_list.cpp) are ready so far. Do you think this could be a useful
addition to the boost library?
Thanks for any comments!
Bye - Andreas
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Peter Dimov [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
I've been talking with Aleksey recently about how to improve the
syntactic situation without losing the separation of concerns that we
get, but we didn't come up with anything convincingly better. I think
a long time ago the for_each parameter used to look like:
class f
{
template class T
struct apply
{
static void execute() {...};
};
};
IOW, a metafunction class with a nested 'execute' function. However
that's not really any better syntactically, it has problems carrying
state, and it's anti-idiomatic.
The state problem is easy:
struct F
{
templateclass T void execute();
};
Which isn't usable portably on all broken platforms, nor is it that
different from:
struct F
{
template class T void operator()(T) { ... };
};
it's-a-bag-'o'-tradeoffs-ly y'rs,
dave
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: undo library
Hi Stefan!
Well you could implement it like this (if that works, didn't test it yet).
Although you would still need a wrapping undo_list class, to implement all
the undo/redo-relationship, the checks is the undo-vector already empty
etc., basically everything that's in my undo_list class already (at there
are quite a few bits). So in fact one would change the storage members and
change the interface for the user.
Instead of writing undo-classes with a constructor, an undo-function and a
redo-function (that makes 3) one would have to write two functions, that
take the appropriate parameters (so speaking in numbers, you would save 1
function).
BUT, when executing the undo-code one might want to add a redo-function to
the redo list and all shared properties/member-variables have to be copied
yourself:
void string_erase_undo(std::string dest, int pos, std::string to_insert) {
dest.insert(pos, to_insert);
// now add the redo function
redolist.push_back(boost::bind(string_erase_redo, dest, pos,
to_insert(size)));
// questions: 1. What is redolist? does every undo/redo-function need to
know this?
//2. Do I really have to copy all the function parameters?
//3. Why do I (the undo function) have to add the redo
function? This is
// multiplying the same code (in every undo and redo
function)
}
Ok, there you see some of the problems/disadvantages of this approach.
Well, there's another minor advantage of my solution. You wouldn't be
obliged to use other libraries (even though this are boost library
elements).
Thinking it over I came to the conclusion that the derived-undo_action-class
version is the most convenient and most flexible way of doing so... but
there's surely something I forgot to think of!?
Bye - Andreas
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Douglas Paul Gregor [EMAIL PROTECTED] writes: Why don't we have mpl::listint, float, double, std::string list_of_types; for_each(list_of_types.begin(), list_of_types.end(), f); ? Then an unqualified for_each call can handle type sequences, heterogeneous containers (e.g., tuple), and run-time sequences (e.g., vector). It's been done before, elsewhere, so why don't we do it in MPL? It's clever, but I'm not sure what problem it's solving. AFAICT it doesn't solve the problem that Andrei was pointing at. It also has at least one problem: it is intrusive on sequence types, requiring them to have begin()/end() member functions. If this was the only way to do it, it would break interoperability with 3rd-party type sequences. -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
John Maddock said: I think I may be the one who broke a lot of the OpenBSD regression tests by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. IMO this is correct (OpenBSD supports pthreads right?), but it causes a problem: currently the gcc config unconditionally defines BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc on *BSD doesn't define anything when you build with -pthread - basically defining -pthread affects only the linker, so we can't detect when to turn on threading support). This in turn is breaking a lot of libraries: mainly those that depend upon smart pointers, which do internal thread synchronisation, and therefore need the -pthread option in order to link correctly. What should we do about this? Option 1: ~~ would putting: flags gcc CFLAGS threadingsingle : -DBOOST_DISABLE_THREADS ; fix the problem? Option 2: ~~ Add flags gcc CFLAGS threadingmulti : -pthread -D_REENTRANT ; to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for gcc. This one may have all sorts of unexpected side effects on other platforms though - even though philosophically it does seem the right thing to do. Option 3: ~~ Make -pthread the default build option in the gcc toolset for *BSD platforms ~~~ Seems to me like this should be reversed. Have the config headers unconditionally NOT define BOOST_HAS_THREADS, and have the Jam toolsets define it when threading is requested. The reasoning is how this will work/effect people using Boost in their own projects when they do not use Jam for building. But even this is an unatractive solution. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
William E. Kempf [EMAIL PROTECTED] writes: John Maddock said: I think I may be the one who broke a lot of the OpenBSD regression tests by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. IMO this is correct (OpenBSD supports pthreads right?), but it causes a problem: currently the gcc config unconditionally defines BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc on *BSD doesn't define anything when you build with -pthread - basically defining -pthread affects only the linker, so we can't detect when to turn on threading support). This in turn is breaking a lot of libraries: mainly those that depend upon smart pointers, which do internal thread synchronisation, and therefore need the -pthread option in order to link correctly. What should we do about this? Option 1: ~~ would putting: flags gcc CFLAGS threadingsingle : -DBOOST_DISABLE_THREADS ; fix the problem? Option 2: ~~ Add flags gcc CFLAGS threadingmulti : -pthread -D_REENTRANT ; to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for gcc. This one may have all sorts of unexpected side effects on other platforms though - even though philosophically it does seem the right thing to do. Option 3: ~~ Make -pthread the default build option in the gcc toolset for *BSD platforms ~~~ Seems to me like this should be reversed. Have the config headers unconditionally NOT define BOOST_HAS_THREADS, and have the Jam toolsets define it when threading is requested. I don't love that idea because it ties a very boost-specific define into the core of Boost.Build, which is really supposed to be a general build system. How will people deal with the next such define for some other library? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
David Abrahams said: William E. Kempf [EMAIL PROTECTED] writes: John Maddock said: I think I may be the one who broke a lot of the OpenBSD regression tests by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. IMO this is correct (OpenBSD supports pthreads right?), but it causes a problem: currently the gcc config unconditionally defines BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc on *BSD doesn't define anything when you build with -pthread - basically defining -pthread affects only the linker, so we can't detect when to turn on threading support). This in turn is breaking a lot of libraries: mainly those that depend upon smart pointers, which do internal thread synchronisation, and therefore need the -pthread option in order to link correctly. What should we do about this? Option 1: ~~ would putting: flags gcc CFLAGS threadingsingle : -DBOOST_DISABLE_THREADS ; fix the problem? Option 2: ~~ Add flags gcc CFLAGS threadingmulti : -pthread -D_REENTRANT ; to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for gcc. This one may have all sorts of unexpected side effects on other platforms though - even though philosophically it does seem the right thing to do. Option 3: ~~ Make -pthread the default build option in the gcc toolset for *BSD platforms ~~~ Seems to me like this should be reversed. Have the config headers unconditionally NOT define BOOST_HAS_THREADS, and have the Jam toolsets define it when threading is requested. I don't love that idea because it ties a very boost-specific define into the core of Boost.Build, which is really supposed to be a general build system. How will people deal with the next such define for some other library? Sorry, sent prematurely. The response above was meant to be about option 1, and I fully agree that it's not a good solution (and said so in the text you deleted). To finish my thoughts on the other two options... Option 2 sounds like the right solution to me, though I'm not sure about the purpose for _REENTRANT. Is it expected that users will define this on POSIX systems, or is this a define that was expected to be defined by the implementation? Option 3 would cause unecessary overhead, so doesn't sound like the right solution. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
[2003-01-23] William E. Kempf wrote:
I think I may be the one who broke a lot of the OpenBSD regression tests
by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration.
IMO this is correct (OpenBSD supports pthreads right?),
Yes it does... with the -pthread flag.
but it causes a
problem: currently the gcc config unconditionally defines
BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc
on *BSD doesn't define anything when you build with -pthread - basically
defining -pthread affects only the linker, so we can't detect when to
turn on threading support).
Don't know about other *BSD-s but GCC on OpenBSD GCC defines
_POSIX_THREADS=1 when the -pthread is used. Here are the details...
red5of5:grafik {108} gcc -E -dM empty.c
#define __i386__ 1
#define __GNUC_MINOR__ 95
#define __unix__ 1
#define __OpenBSD__ 1
#define __GNUC__ 2
red5of5:grafik {109} gcc -E -dM -pthread empty.c
#define __i386__ 1
#define __GNUC_MINOR__ 95
#define _POSIX_THREADS 1
#define __unix__ 1
#define __OpenBSD__ 1
#define __GNUC__ 2
red5of5:grafik {110} /usr/local/gcc-3.2/bin/gcc -E -dM empty.c
#define __HAVE_BUILTIN_SETJMP__ 1
#define __OpenBSD__ 1
#define __unix__ 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __GNUC_PATCHLEVEL__ 0
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __GNUC__ 3
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __GXX_ABI_VERSION 102
#define i386 1
#define __GNUC_MINOR__ 2
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __tune_i386__ 1
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define __i386 1
#define __VERSION__ 3.2
red5of5:grafik {111} /usr/local/gcc-3.2/bin/gcc -E -dM -pthread empty.c
#define __HAVE_BUILTIN_SETJMP__ 1
#define __OpenBSD__ 1
#define __unix__ 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define _POSIX_THREADS 1
#define __GNUC_PATCHLEVEL__ 0
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __GNUC__ 3
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __GXX_ABI_VERSION 102
#define i386 1
#define __GNUC_MINOR__ 2
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __tune_i386__ 1
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define __i386 1
#define __VERSION__ 3.2
-- grafik - Don't Assume Anything
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- 102708583@icq
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
On Thu, 23 Jan 2003, David Abrahams wrote:
Douglas Paul Gregor [EMAIL PROTECTED] writes:
Why don't we have
mpl::listint, float, double, std::string list_of_types;
for_each(list_of_types.begin(), list_of_types.end(), f);
?
Then an unqualified for_each call can handle type sequences, heterogeneous
containers (e.g., tuple), and run-time sequences (e.g., vector). It's been
done before, elsewhere, so why don't we do it in MPL?
It's clever, but I'm not sure what problem it's solving.
I mentioned this before and cited the paper Static Data
Structures: Reconciling Template Metaprogramming and Generic Programming:
http://aspn.activestate.com/ASPN/Mail/Message/1304415
The title says it all: we have generic programming and template
metaprogramming, and they complement each other nicely, but at the barrier
between them I feel that we have a kludge. MPL and STL are built on the
same abstractions, with similar naming schemes and similar style, so why
is it that at the bridge between the two we have something that looks like
neither? I think the for_each syntax I'm referring to is a clean bridge
between the two, because it (logically, if not in code) maps the syntax of
STL iterators to the syntax of MPL iterators in standard algorithm calls.
The paper I referred to gave the most compelling argument for having
precisely the same syntax at the bridge: you can test with the run-time
version (short compile times) and release with the compile-time version
(short execution times): they needed only to switch the object from
std::vector to a compile-time vector, wait for KAI C++ to grind away for
24 hours, and they got 171 times the performance.
AFAICT it
doesn't solve the problem that Andrei was pointing at.
You mean the front/pop_front issue?
It also has at
least one problem: it is intrusive on sequence types, requiring them
to have begin()/end() member functions. If this was the only way to
do it, it would break interoperability with 3rd-party type sequences.
-Dave
That's easy to fix---I was just trying to keep the example small. A few
extra abstractions would be needed:
namespace mpl {
// Special type that for_each can pick up on
templatetypename Iterator
struct iterator
{
typedef Iterator type;
};
// Stores an MPL sequence defined by an iterator range
templatetypename Begin, typename End
struct sequence
{
iteratorBegin begin() const { return iteratorBegin(); }
iteratorEnd end() const { return iteratorEnd(); }
};
templatetypename Begin, typename End, typename F
F for_each(iteratorBegin first, iteratorEnd last, F f)
{
// ...
}
}
Just stick your third-party iterators into sequence and you're all set;
I'd expect that mpl::list, mpl::vector, etc. would just derive from
mpl::sequence to reduce the amount of typing in the common case.
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL usage for code generation
Including for_each.hpp on bcc561 gives Error E2230 c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hpp 20: In-line data member initialization requires an integral constant expression Any chance of finding a fix for this? I am having problems working through the code to see what to change. Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Douglas Paul Gregor [EMAIL PROTECTED] writes:
On Thu, 23 Jan 2003, David Abrahams wrote:
Douglas Paul Gregor [EMAIL PROTECTED] writes:
Why don't we have
mpl::listint, float, double, std::string list_of_types;
for_each(list_of_types.begin(), list_of_types.end(), f);
?
Then an unqualified for_each call can handle type sequences, heterogeneous
containers (e.g., tuple), and run-time sequences (e.g., vector). It's been
done before, elsewhere, so why don't we do it in MPL?
It's clever, but I'm not sure what problem it's solving.
I mentioned this before and cited the paper Static Data
Structures: Reconciling Template Metaprogramming and Generic Programming:
http://aspn.activestate.com/ASPN/Mail/Message/1304415
The title says it all: we have generic programming and template
metaprogramming, and they complement each other nicely, but at the barrier
between them I feel that we have a kludge. MPL and STL are built on the
same abstractions, with similar naming schemes and similar style, so why
is it that at the bridge between the two we have something that looks like
neither? I think the for_each syntax I'm referring to is a clean bridge
between the two, because it (logically, if not in code) maps the syntax of
STL iterators to the syntax of MPL iterators in standard algorithm calls.
The paper I referred to gave the most compelling argument for having
precisely the same syntax at the bridge: you can test with the run-time
version (short compile times) and release with the compile-time version
(short execution times): they needed only to switch the object from
std::vector to a compile-time vector, wait for KAI C++ to grind away for
24 hours, and they got 171 times the performance.
OK, point taken. I think it's worth examining.
AFAICT it
doesn't solve the problem that Andrei was pointing at.
You mean the front/pop_front issue?
No, I mean the complexity-of-expression issue.
It also has at
least one problem: it is intrusive on sequence types, requiring them
to have begin()/end() member functions. If this was the only way to
do it, it would break interoperability with 3rd-party type sequences.
-Dave
That's easy to fix---I was just trying to keep the example small. A few
extra abstractions would be needed:
namespace mpl {
// Special type that for_each can pick up on
templatetypename Iterator
struct iterator
{
typedef Iterator type;
};
// Stores an MPL sequence defined by an iterator range
templatetypename Begin, typename End
struct sequence
{
iteratorBegin begin() const { return iteratorBegin(); }
iteratorEnd end() const { return iteratorEnd(); }
};
templatetypename Begin, typename End, typename F
F for_each(iteratorBegin first, iteratorEnd last, F f)
{
// ...
}
}
Just stick your third-party iterators into sequence and you're all set;
I'd expect that mpl::list, mpl::vector, etc. would just derive from
mpl::sequence to reduce the amount of typing in the common case.
Maybe it would be better to define namespace-scope begin(), end(),
et. al which can operate on STL and MPL sequences.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Hugo Duncan [EMAIL PROTECTED] writes: Including for_each.hpp on bcc561 gives Error E2230 c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hpp 20: In-line data member initialization requires an integral constant expression Any chance of finding a fix for this? I am having problems working through the code to see what to change. Is this with the CVS or with boost 1.29.0? I don't think Borland support was very solid at 1.29.0. BC551 processes for_each.hpp just fine at the moment. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
Peter Dimov [EMAIL PROTECTED] writes: From: John Maddock [EMAIL PROTECTED] From Peter Dimov: Nope, it says nothing AFAICS. A type cannot be convertible. Only values are. And you cannot say a value of type From is implicitly convertible to To (4.0) because you need to specify whether that value is an lvalue of type From or an rvalue of type From, and what do l- and r-values mean when applied to strange (array, reference, function, abstract, etc) types. I refer you back to 4.0p3, which talks about expressions of type T, which are treated as lvalues if the type is a reference, otherwise as an rvalue. Thanks. I don't think that 4.0p3 explains everything, though. I doesn't talk about expressions of type T. It talks about converting an expression e to type T; it then explains that the result of that conversion is an lvalue when T (To in our case) is a reference type. It says that e is used as an lvalue if and only if the initialization T t(e) would have used it as an lvalue. This still doesn't solve the expression of type From problem since an expression can be either an lvalue or an rvalue, and there are no expressions of reference types, only expressions that are lvalues. Of course I'm not a core expert. For example, is an expression of type int[4] convertible to int[4]? To int () [4]? To int const [4]? If it's any help, here's what John Spicer says: David Abrahams [EMAIL PROTECTED] writes: Hi John, I realize there's a lot of material here, but I wonder if you wouldn't mind taking a look at it all the same? We're having problems understanding how to talk about the behavior of the is_convertible trait from the type traits library (and standard proposal). Any guidance you could give would be very helpful. I'm happy to voice an opinion, although I don't think I have anything to add that hasn't already been said. I think that is_convertible should be based as closely as possible on the definition in clause 4 of the standard. As has been pointed out, a problem with this is that the standard refers to a source expression, not a source type. I think this means that the definition of is_converible needs to say something like True if an lvalue of type From can be converted to type To according to 4p3 (or make it an rvalue, but you have to pick one). You could, of course, have two versions of is_convertible to handle both lvalues and rvalues. A few miscellaneous comments: - There are no expressions of reference type, so presumably a reference on the from type should be ignored (which it would based on a definition that used an expression having type From. - There were several mentions of prohibiting abstract types. Expressions of abstract class type can be the source of an implicit conversion, however. - There was a mention of special treatment of parameter types that are arrays. I don't think this is an issue as you are dealing with types and even if you declare a parameter of type X[], it has type X*. Hope this is of some use. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Review results: Optional library
Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 01:56 PM 1/22/2003, Douglas Paul Gregor wrote: On Wed, 22 Jan 2003, Fernando Cacciola wrote: So, what else should I do? Is there something I need to setup in order to add optional to the regression tests? You'll probably want to create a testing Jamfile libs/optional/test/Jamfile. The easy way to do that is to cut 'n' paste from, e.g., libs/filesystem/test/Jamfile and make the obvious changes. Then, add subinclude libs/optional/test/Jamfile ; to status/Jamfile and the Optional tests should start showing up with the next round of regression testing. Yes, but please test your lib specific Jamfile first, before changing the status/Jamfile. Developers should always make sure the local Jamfile works before subincluding it in the main Boost Jamfile. See the recently updated docs in more/regression.html OK. I've committed Jamfile to libs/optional/test. But I can't run bjam on my Win98 configuration (long command lines problem), so I can't test it. Could someone test the jamfile? If it works, I'l add the entry on status/Jamfile. TIA -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
On Thu, 23 Jan 2003, David Abrahams wrote: Douglas Paul Gregor [EMAIL PROTECTED] writes: On Thu, 23 Jan 2003, David Abrahams wrote: AFAICT it doesn't solve the problem that Andrei was pointing at. You mean the front/pop_front issue? No, I mean the complexity-of-expression issue. Hmmm, I don't see how that issue applies. STL users know how to write function objects. It's not a gigantic leap to write function objects with a templated function call operator (at least, it isn't if you've already decided to play with template metaprogramming). The rest of the syntax is inherited from STL. I don't see any extra complexity here. Granted, it means pulling in a lot more code than Andrei's version, but as one who has written that same bit of code approximately a billion times I'm ready for a simple, familiar abstraction. Just stick your third-party iterators into sequence and you're all set; I'd expect that mpl::list, mpl::vector, etc. would just derive from mpl::sequence to reduce the amount of typing in the common case. Maybe it would be better to define namespace-scope begin(), end(), et. al which can operate on STL and MPL sequences. I have two concerns with that: 1) begin and end are already class templates in MPL 2) There isn't much precedent for begin(container) and end(container); there is for container.begin() and container.end() Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] cstdint.hpp patch for Cray X1
The recent change to boost/cstdint.hpp for Cray systems is not appropriate for the Cray X1. It has a 16-bit short type, however there are performance penalties associated with it. The following patch for cstdint.hpp sets up the appropriate typedefs for this platform. diff -u -r1.29 cstdint.hpp --- boost/cstdint.hpp 22 Jan 2003 12:12:14 - 1.29 +++ boost/cstdint.hpp 23 Jan 2003 16:32:04 - @@ -160,7 +160,16 @@ // 16-bit types ---// -# if USHRT_MAX == 0x +# if defined(__crayx1) + // The Cray X1 has a 16-bit short, however it is not recommend + // for use in performance critical code. + typedef short int16_t; + typedef short int_least16_t; + typedef int int_fast16_t; + typedef unsigned short uint16_t; + typedef unsigned short uint_least16_t; + typedef unsigned intuint_fast16_t; +# elif USHRT_MAX == 0x typedef short int16_t; typedef short int_least16_t; typedef short int_fast16_t; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] -lrt on Mandrake 9.0
Sorry for this slightly off topic question, but I'm not a Linux user by trade. I've recently switched distributions to Mandrake 9.0, which comes with GCC 3.2 out of the box. When trying to compile Boost.Threads on this platform I encounter the following problem: gcc-Link-action .../../../libs/thread/test/bin/test_thread.test/gcc/debug/runtime -link-static/threading-multi/test_thread /usr/bin/ld: cannot find -lrt collect2: ld returned 1 exit status LD_LIBRARY_PATH=../../../libs/thread/build/bin/libboost_thread.so/gcc/debug/ runtime-link-static/shared-linkable-true/threading-multi export LD_LIBRARY_PATH g++ -static -g -pthread -o ../../../libs/thread/test/bin/test_thread.tes t/gcc/debug/runtime-link-static/threading-multi/test_thread -L../../../libs/t hread/build/bin/libboost_thread.so/gcc/debug/runtime-link-static/shared-linkable -true/threading-multi ../../../libs/thread/test/bin/test_thread.test/gcc/deb ug/runtime-link-static/threading-multi/test_thread.o ../../../libs/test/build /bin/libboost_unit_test_framework.a/gcc/debug/runtime-link-static/threading-mult i/libboost_unit_test_framework.a ../../../libs/test/build/bin/libboost_unit_te st_framework.a/gcc/debug/runtime-link-static/threading-multi/libboost_unit_test_ framework.a ../../../libs/test/build/bin/libboost_unit_test_framework.a/gcc/d ebug/runtime-link-static/threading-multi/libboost_unit_test_framework.a ../../ .../libs/test/build/bin/libboost_unit_test_framework.a/gcc/debug/runtime-link-sta tic/threading-multi/libboost_unit_test_framework.a -lrt -lboost_thread -Wl,- rpath-link,. Can anyone explain to me what's wrong on my system that -lrt isn't finding the library? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: undo library
Hi Andreas,
An undo library seems to be on a boundary between patterns and library
functions, so im interested in seeing how something like an undo library
plays out.
Some things ive come across include:
- The need to keep objects utilized in doIt() alive until they leave the
undo list (this sometimes is even beyond serialization). Implementers
of command objects frequently use some type of shared_ptr to keep things
alive after use (until they fall off the undo queue).
- The need to keep things simple, as Steven Kirk noted. This competes
with the need to employ a more complex (as applications grow) command /
command-manager interface. Providing a command-base-imp might be a way
to satisfy both users.
- The ability for commands that can not support undo to inform the
manager (sending an email, committing transactions, or a developer
testing new objects are examples of commands that do not support undo).
When these commands are executed, they clear the undo-stack (this can be
augmented in a UI app with a message informing the user they are about
to execute an undoable command).
- The need to support various command managers. People may want to
extend the behavior of the undo-manager, but often start out with a
default manager (templatizing the manager's container might also be an
option).
The code below might help illustrate the suggestions mentioned above
(and by S.Kirk in the previous email) for the command class (The manager
interface is a separate discussion probably :-).
- Steve
struct command
{
virtual void doIt() = 0; // Called first time
virtual void undoIt() = 0; // Called to undo
virtual void redoIt() = 0; // Called after first time
virtual bool supportsUndo() = 0;
virtual bool supportsRedo() = 0;
virtual ~command() {}
};
struct commandBinder : public command
{
commandBinder( const boost::functionvoid doItFn,
const boost::functionvoid redoItFn =
commandBinder::redoUnsupported,
const boost::functionvoid undoItFn =
commandBinder::undoUnsupported )
: m_doItFunction( doItFn ),
m_undoItFunction( undoItFn ),
m_redoItFunction( redoItFn ) {}
virtual void invokeCommand(
const boost::functionvoid fn, const std::string msg )
{
if ( fn.empty() )
throw undo_exception( msg.c_str() );
else
fn();
}
virtual void doIt()
{ invokeCommand( m_doItFunction,); }
virtual void redoIt()
{ invokeCommand( m_redoItFunction, redoIt unsupported ); }
virtual void undoIt()
{ invokeCommand( m_undoItFunction, undoIt unsupported ); }
virtual bool supportsUndo() { return !m_undoItFunction.empty(); }
virtual bool supportsRedo() { return !m_redoItFunction.empty(); }
boost::functionvoid m_doItFunction;
boost::functionvoid m_redoItFunction;
boost::functionvoid m_undoItFunction;
static void undoUnsupported() {}
static void redoUnsupported() {}
virtual ~commandBinder() {}
};
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Review results: Optional library
Fernando Cacciola said: I've committed Jamfile to libs/optional/test. But I can't run bjam on my Win98 configuration (long command lines problem), so I can't test it. Doesn't bjam have a fix for this issue? Could someone test the jamfile? If it works, I'l add the entry on status/Jamfile. It passes for me (well, sort of, toolset for vc7, vc71 and gcc-nocygwin pass, while msvc fails). However, shouldn't you be using run instead of unit-test in the Jamfile? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cstdint.hpp patch for Cray X1
Hi Dan, I don't think this will be needed since on the X1 USHRT_MAX should be 0x, and thus the default version will work. Note that the patch for the SV1 and other Crays that I submitted checks for USHRT_MAX being 0x and thus does not apply on the X1 anyways. On another note, I got jam to compile on the SV1, and have submitted a patch. Now I am running the regression tests on it. Not having access to an X1 yet (and the 4.2 compilers don't exist for other Crays), I can't run the tests there at the moment. Could you try to run it, once I have patched boost for the SV1? Best regards, Matthias On Thursday, January 23, 2003, at 05:49 PM, Dan Gohman wrote: The recent change to boost/cstdint.hpp for Cray systems is not appropriate for the Cray X1. It has a 16-bit short type, however there are performance penalties associated with it. The following patch for cstdint.hpp sets up the appropriate typedefs for this platform. diff -u -r1.29 cstdint.hpp --- boost/cstdint.hpp 22 Jan 2003 12:12:14 - 1.29 +++ boost/cstdint.hpp 23 Jan 2003 16:32:04 - @@ -160,7 +160,16 @@ // 16-bit types ---// -# if USHRT_MAX == 0x +# if defined(__crayx1) + // The Cray X1 has a 16-bit short, however it is not recommend + // for use in performance critical code. + typedef short int16_t; + typedef short int_least16_t; + typedef int int_fast16_t; + typedef unsigned short uint16_t; + typedef unsigned short uint_least16_t; + typedef unsigned intuint_fast16_t; +# elif USHRT_MAX == 0x typedef short int16_t; typedef short int_least16_t; typedef short int_fast16_t; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Review results: Optional library
William E. Kempf [EMAIL PROTECTED] writes: Fernando Cacciola said: I've committed Jamfile to libs/optional/test. But I can't run bjam on my Win98 configuration (long command lines problem), so I can't test it. Doesn't bjam have a fix for this issue? For most cases, yes. You can build bjam under Cygwin as a last resort. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Douglas Paul Gregor [EMAIL PROTECTED] writes: On Thu, 23 Jan 2003, David Abrahams wrote: Douglas Paul Gregor [EMAIL PROTECTED] writes: On Thu, 23 Jan 2003, David Abrahams wrote: AFAICT it doesn't solve the problem that Andrei was pointing at. You mean the front/pop_front issue? No, I mean the complexity-of-expression issue. Hmmm, I don't see how that issue applies. I don't know what you mean by that. Are you saying that Andrei was making an invalid argument? I wouldn't agree with that. STL users know how to write function objects. It's not a gigantic leap to write function objects with a templated function call operator (at least, it isn't if you've already decided to play with template metaprogramming). The rest of the syntax is inherited from STL. I don't see any extra complexity here. Granted, it means pulling in a lot more code than Andrei's version, And writing a lot more code. but as one who has written that same bit of code approximately a billion times I'm ready for a simple, familiar abstraction. Yeah, as I said I'm more comfortable with it too. Just stick your third-party iterators into sequence and you're all set; I'd expect that mpl::list, mpl::vector, etc. would just derive from mpl::sequence to reduce the amount of typing in the common case. Maybe it would be better to define namespace-scope begin(), end(), et. al which can operate on STL and MPL sequences. I have two concerns with that: 1) begin and end are already class templates in MPL 2) There isn't much precedent for begin(container) and end(container); there is for container.begin() and container.end() OK. I think it would be best to start by making an experimental layer on top of MPL in the sandbox. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cstdint.hpp patch for Cray X1
Hi Matthias, The reason for special-casing the Cray X1 here is so that int_fast16_t isn't defined to be short, as short has performance penalties associated with it on this platform. I can't guarantee I'll be able to test jam, but I'll let you know if I get to it. Dan On Thu, 2003-01-23 at 11:43, Matthias Troyer wrote: Hi Dan, I don't think this will be needed since on the X1 USHRT_MAX should be 0x, and thus the default version will work. Note that the patch for the SV1 and other Crays that I submitted checks for USHRT_MAX being 0x and thus does not apply on the X1 anyways. On another note, I got jam to compile on the SV1, and have submitted a patch. Now I am running the regression tests on it. Not having access to an X1 yet (and the 4.2 compilers don't exist for other Crays), I can't run the tests there at the moment. Could you try to run it, once I have patched boost for the SV1? Best regards, Matthias On Thursday, January 23, 2003, at 05:49 PM, Dan Gohman wrote: The recent change to boost/cstdint.hpp for Cray systems is not appropriate for the Cray X1. It has a 16-bit short type, however there are performance penalties associated with it. The following patch for cstdint.hpp sets up the appropriate typedefs for this platform. diff -u -r1.29 cstdint.hpp --- boost/cstdint.hpp 22 Jan 2003 12:12:14 - 1.29 +++ boost/cstdint.hpp 23 Jan 2003 16:32:04 - @@ -160,7 +160,16 @@ // 16-bit types ---// -# if USHRT_MAX == 0x +# if defined(__crayx1) + // The Cray X1 has a 16-bit short, however it is not recommend + // for use in performance critical code. + typedef short int16_t; + typedef short int_least16_t; + typedef int int_fast16_t; + typedef unsigned short uint16_t; + typedef unsigned short uint_least16_t; + typedef unsigned intuint_fast16_t; +# elif USHRT_MAX == 0x typedef short int16_t; typedef short int_least16_t; typedef short int_fast16_t; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] -lrt on Mandrake 9.0
On Thursday 23 January 2003 11:01 pm, William E. Kempf wrote: Can anyone explain to me what's wrong on my system that -lrt isn't finding the library? You need to install glibc-devel. Issuing urpmi glibc-devel as root should do it. Mandrake separates runtime and devel packages and thus if you want to do development you have to install the corresponding name-devel packages. -- Alkis ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Review results: Optional library
Fernando Cacciola said: William E. Kempf [EMAIL PROTECTED] wrote in message Fernando Cacciola said: However, shouldn't you be using run instead of unit-test in the Jamfile? Yes :-) I was looking at the wrong examples. Fixed now. (could you re-test it?) $ bjam Jamfile: line 25: syntax error at keyword ; Jamfile: line 25: syntax error at keyword ; Jamfile: line 26: syntax error at keyword } Jamfile: line 26: syntax error at keyword } found 8 targets... William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Review results: Optional library
William E. Kempf [EMAIL PROTECTED] writes: Fernando Cacciola said: William E. Kempf [EMAIL PROTECTED] wrote in message Fernando Cacciola said: However, shouldn't you be using run instead of unit-test in the Jamfile? Yes :-) I was looking at the wrong examples. Actually, unit-test just invokes run since 2003/01/05, so it's OK to use it. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Review results: Optional library
William E. Kempf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Fernando Cacciola said: William E. Kempf [EMAIL PROTECTED] wrote in message Fernando Cacciola said: However, shouldn't you be using run instead of unit-test in the Jamfile? Yes :-) I was looking at the wrong examples. Fixed now. (could you re-test it?) $ bjam Jamfile: line 25: syntax error at keyword ; Jamfile: line 25: syntax error at keyword ; Jamfile: line 26: syntax error at keyword } Jamfile: line 26: syntax error at keyword } found 8 targets... It looks like the syntax for the compile-fail (plus the define) is wrong... I've removed the fail cases altogether until I can test it myself so I don't abuse anymore of your time. It runs only the ordinary test now It should work I think. -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
On Thu, 23 Jan 2003 03:26:52 +0200, Vesa Karvonen [EMAIL PROTECTED] wrote: Hi, I'm sorry, but I have too little time to comment more extensively on this subject No problem. I just have to thank you for the attention and the useful comments. Feel also free to continue the discussion when you'll have more time even if this thread is then old, and/or to contact me by private mail. (other duties demand attention). Below you'll find an algorithm, that chooses a proper value of n from where to start the log2 algorithm presented earlier. Before resorting to the = sizeof hack I thought to several solutions. It's obvious that the value we need is just 1 + log2ULONG_MAX. So one solution would have been to use the trivial log2 = 1+log2(n/2) implementation for the initial value only, and the optimized binary search implementation for the rest. Since unsigned long are guaranteed to have at least 32 value bits, one could have done: const int initial_value = 31 + trivial_log2 (ULONG_MAX/2147483648ul) saving some thirty instantiations. Still it would give you an error with 64 bits ulongs and compilers with a small instantiation limit however, thus I gave up. It does not depend on limits and it should always produce a value that has the correct properties. Vesa, I really appreciate your attempt but your code assumes the required number to be a power of two (it just tries 32, 64, 128, etc.). What about 48 bits unsigned long? I'll think about the issue and see if I have anything better than this. If so I'll post it here. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Named Pairs
This is interesting stuff, but I think you should checkout Emily Winch's
more general compile-time associative list implementation also.
(http://groups.yahoo.com/group/boost/files/alist-feb14-02.zip seems to be
the latest)
What's the status of the Emily's lib btw? Is an MPL/Boost integration under
consideration?
Jason House [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
I tried to do the following implementation in visual studio 6 to see if
I could get a named pair class.
I tried a number of approaches, but none worked with my compiler. Is my
approach fundamentally flawed?
I think that something like this would be a useful utility to have.
Anyone have any ideas on how to improve the class?
template typename _T1, int _Name1, typename _T2, int _Name2
class named_pair{
public:
template int _Name
class var{};
class var_Name1{
public:
_T1 value;
}
class var_Name2{
_T2 value;
}
};
enum{ Cash, Name };
void main(int argc, char *argv[]){
named_pairfloat, Cash, char*, Name foobar;
foobar.varCash.value = 32.2;
foobar.varName.value = Fred;
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Named Pairs
First of all there are several glitches here:
template typename _T1, int _Name1, typename _T2, int _Name2
class named_pair{
public:
template int _Name
class var{};
template?
class var_Name1{
I am not sure that you allowed to use template parameter for defining
partial specialization.
public:
_T1 value;
}
;?
template?
class var_Name2{
public:
_T2 value;
}
;?
};
enum{ Cash, Name };
void main(int argc, char *argv[]){
named_pairfloat, Cash, char*, Name foobar;
foobar.varCash.value = 32.2;
foobar.varName.value = Fred;
Even if above class definition is allowed foobar.varCash will be invalud
cause varCash is a type name. So basically what you are doing is unusable.
}
Look on MPL example for inherit_linear. It may have what you need.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Named Pairs
Fredrik Blomqvist [EMAIL PROTECTED] wrote in message b0pj3o$p42$[EMAIL PROTECTED]">news:b0pj3o$p42$[EMAIL PROTECTED]... This is interesting stuff, but I think you should checkout Emily Winch's more general compile-time associative list implementation also. (http://groups.yahoo.com/group/boost/files/alist-feb14-02.zip seems to be the latest) Sorry, wrong link... should be: http://groups.yahoo.com/group/boost/files/associative_list/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Named Pairs
Look on MPL example for inherit_linear. It may have what you need. Well, as I said, I'm new... I can find mpl documentation, but searches for inherit_linear came up with nothing. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/ inherit_linearly.cpp?rev=1.1content-type=text/vnd.viewcvs-markup In the above example terms, what you want would look like: typedef mpl::int_c0 Cash; typedef mpl::int_c0 Name; field( foobar, Cash() ) = 32.2; field( foobar, Name() ) = Fred; IOW, this or another way implemented: tuples are your friends. Look onto boost::tuple lib, that supply full featured tuples. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
Al Stevens has an article in a past DDJ about a generic undo/redo library, can anyone dig it out? I recall it was interesting. Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
Andrei Alexandrescu [EMAIL PROTECTED] wrote in message b0pu01$bqd$[EMAIL PROTECTED]">news:b0pu01$bqd$[EMAIL PROTECTED]... Al Stevens has an article in a past DDJ about a generic undo/redo library, can anyone dig it out? I recall it was interesting. Can be purchased here: https://www.sdmediagroup.com/secure/?sid=954 and followup here: https://www.sdmediagroup.com/secure/?sid=914 /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: math constant - generic function circle_area example.
Hi Paul,
you wrote:
I've been looking into an earlier version of the proposed math constants
before and asked myself how to implement a generic function like
templateclass T
T circle_area (const T radius) {
return math_constantsT::pi * radius * radius;
}
How should this be done?
Thanks,
Joerg
Attached is an example using Michael Kenniston's Kunning Function
constants.
Briefly
template typename T
T circle_area(const T radius)
{
// Usage example: circle_areadouble( 2.) // Explicit type double.
// or circle_area(2.F) // Implicit type float.
return boost::math::constant T, boost::math::pi_tag () * radius *
radius;
}
OK. I've tried to compile this with GCC 3.2.1 and after applying some
remedies like
for example
#ifdef LATER
// Define constant is namespaces to hold three builtin floating-point
representations.
namespace float_constants
{
constant float, pi_tag const pi;
}
namespace double_constants
{
constant double, pi_tag const pi;
}
namespace long_double_constants
{
constant long double, pi_tag const pi;
}
#endif
/for example
it compiled and executed giving the expected results. How is this solution
related to your latest (Dec. 12) upload at groups.yahoo.com/group/boost?
It compiles with MSVC 7.0 (but not 6 - see MK's original example for why
not).
(long double == double for MSVC, so long double not fully
testable/useful).
It seems to do the trick, without too many surprises. I have displayed
the
output using the 17 significant digits for double so one can see the
difference
between a float pi 3.1415927410125732 and a double pi 3.1415926535897931
(even
though only 9 are really significant for float).
cout circle_areafloat(1.) =circle_areafloat(1.) endl; //
Explicit type float.
cout circle_areadouble(1.) =circle_areadouble(1.) endl;
//
Explicit type double.
cout circle_area(1.F) =circle_area(1.F) endl; // Implicit
type
float.
cout circle_area(1.) =circle_area(1.) endl; // Implicit type
double.
cout circle_area(1.L) =circle_area(1.L) endl; // implicit
type
long double.
cout circle_areadouble(1.F) =circle_areadouble(1.F)
endl; //
Explicit over-rides implicit.
And silly types like int fail helpfully.
// cout circle_area(1) =circle_area(1) endl; // Implicit
int -
does not link!
// cout circle_areaint(1.) =circle_areaint(1.) endl; //
Explicit int - does not compile!
Output is
Test test_circle_area.cpp Thu Jan 23 00:06:28 2003
float pi = 3.14159274
double pi = 3.1415926535897931
float pi = 3.1415927410125732
circle_areafloat(1.) = 3.1415927410125732
circle_areadouble(1.) = 3.1415926535897931
circle_area(1.F) = 3.1415927410125732
circle_area(1.) = 3.1415926535897931
circle_area(1.L) = 3.1415926535897931
circle_areadouble(1.F) = 3.1415926535897931
circle_arealong double(1.) = 3.1415926535897931
circle_areafloat(2.) = 12.566370964050293
circle_areadouble(2.) = 12.566370614359172
circle_area(2.F) = 12.566370964050293
circle_area(2.) = 12.566370614359172
circle_area(2.L) = 12.566370614359172
circle_areadouble(2.F) = 12.566370614359172
boost::math::constant float, boost::math::pi_tag () 3.1415927410125732
I haven't looked at any assembler to check on efficiency, but believe/hope
from
previous examples that it will be optimal if inlined.
Does this look sensible/useful?
Only if I learn to see the relation to your latest upload (which I'm
assuming your review request is related to).
Best,
Joerg
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL usage for code generation
On Wed, 22 Jan 2003 16:25:40 -0800, Andrei Alexandrescu [EMAIL PROTECTED]
wrote:
inline void do_my_function(string, void_) {}
template class Lst
inline void do_my_function(string s, Lst lst)
{
my_functionfrontLst::type(s);
do_my_function(s, pop_frontLst::type());
}
do_my_function(s, my_list());
This is interesting as it also gives run-time control of how much of the list
is iterated over.
eg.
template class Lst
inline void do_my_function(string s, Lst lst)
{
if (!my_functionfrontLst::type(s))
do_my_function(s, pop_frontLst::type());
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Review results: Optional library
At 02:21 PM 1/23/2003, Fernando Cacciola wrote: William E. Kempf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Fernando Cacciola said: William E. Kempf [EMAIL PROTECTED] wrote in message Fernando Cacciola said: However, shouldn't you be using run instead of unit-test in the Jamfile? Yes :-) I was looking at the wrong examples. Fixed now. (could you re-test it?) $ bjam Jamfile: line 25: syntax error at keyword ; Jamfile: line 25: syntax error at keyword ; Jamfile: line 26: syntax error at keyword } Jamfile: line 26: syntax error at keyword } found 8 targets... It looks like the syntax for the compile-fail (plus the define) is wrong... I've removed the fail cases altogether until I can test it myself so I don't abuse anymore of your time. It runs only the ordinary test now It should work I think. Yes, works here. I've added optional to the status/Jamfile. Always keep in mind that the jam language is whitespace sensitive. I can't tell you how many times that caught me at first, although I got used to it after awhile. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
David Abrahams wrote:
Terje Slettebø [EMAIL PROTECTED] writes:
Perhaps it might be possible to do some compile-time/run-time lambda
(similar to Boost.Lambda for runtime, and MPL's lambda), so you
could do something like:
mpl::for_eachmy_list(my_function_(s));
It would then transform the function call my_function_(s) into
an instantiated function object of the kind suitable for
mpl::for_each.
I'm afraid that particular syntax won't work for this particular case,
though. If my_function is a function template, my_function_ is a
function, and my_function_(s) calls that function.
Since there are no (function template) template parameters, only
(class template) template parameters, there doesn't appear to be any
way to make this one particularly easy except by using the
preprocessor to define some kind of function object.
It appears to be just bad luck that higher order functional
programming with function templates is impossible in C++.
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you care about higher-orderness of your
generic algorithms, a preferred implementation construct for those
algorithms is not a function template, but a static _function object_ (a
technique used in FC++):
struct my_function_
{
template typename U
void operator()(std::string const text, U)
{
// ...
}
} my_function; // here!
For ordinary uses, the above will act just like a plain function template
(minus ADL/explicit template arguments specification):
my_function(text, int());
and it will also allow one to do something like this:
std::string text(text);
mpl::for_each my_types (boost::bindvoid(my_function, text, _1));
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you care about higher-orderness of your
generic algorithms, a preferred implementation construct for those
algorithms is not a function template, but a static _function object_ (a
technique used in FC++):
struct my_function_
{
template typename U
void operator()(std::string const text, U)
{
// ...
}
} my_function; // here!
For ordinary uses, the above will act just like a plain function template
(minus ADL/explicit template arguments specification):
my_function(text, int());
and it will also allow one to do something like this:
std::string text(text);
mpl::for_each my_types (boost::bindvoid(my_function, text, _1));
This technique is adopted by Phoenix. With this, you can even do
(as suggested by Joel Young):
- \ \
double - /\ f . /\ x. f(f x)
- / \ / \
struct square_ {
template typename X
struct result { typedef X type; };
template typename X
X operator()(X x)
{
return x * x;
}
};
functionsquare_ square;
template typename F
struct ffx {
template typename X
struct result { typedef X type; };
ffx(F f_) : f(f_) {}
template typename X
X operator()(X x)
{
return f(f(x));
}
F f;
};
template typename F
functionffxF
doub(functionF f)
{
return functionffxF (f.op);
}
int
main()
{
cout doub(square)(5.0)() endl;
cout doub(doub(square))(5.0)() endl;
cout doub(doub(doub(square)))(5.0)() endl;
return 0;
}
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
PS Jaakko and I are working on the LL/Phoenix merger.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: undo library
Can I use this library to implement multiple undo/redo in GUI applications under Windows? For example in a word processor. Mohammed - Original Message - From: Pavel Vozenilek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 1:15 AM Subject: [boost] Re: Re: undo library Steven Mauceri [EMAIL PROTECTED] wrote in message 000f01c2c301$fca17ae0$[EMAIL PROTECTED]">news:000f01c2c301$fca17ae0$[EMAIL PROTECTED]... Hi Andreas, [snip] Some things ive come across include: [snip] Undo library may also provide features like: - user friendly description of what is going to be undoed/redoed, - ability to keep only N last undo steps in memory and save rest on disk (maybe with help of an serialisation library), - ability to group multiple undo commands to one (e.g. moves), - ability to generate 'change log' for any given time period. Most of it may be implemented by specialised command manager. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL::void_t
Hi,
Question why is mpl::void_t an incomplete type? Sometimes I need
to instantiate it. For example to signal a zero arity functor call:
typename actor_resultBaseT, tuple ::type
operator()() const
{
return this-eval(void_t());
}
template typename T0
typename actor_resultBaseT, tupleT0 ::type
operator()(T0 a0) const
{
return this-eval(a0);
}
Of course I can do it differently, but it wouldn't be as clean and
generic as above. Thoughts?
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problem with regression tests
Hi, I have now run the regression tests on a Cray SV1 but it seems there is still a problem in the postprocessing stage. I get output like: generating html tables: Using /u/ph/troyer/boost/status/bin/bind_test.test to determine compilers Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/bind_test.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/mem_fn_test.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/mem_fn_void_test.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/mem_fn_derived_test.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/config_info.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/array1.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/array2.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/array3.test/cray/debug Missing jam_log.xml in target /u/ph/troyer/boost/status/bin/array4.test/cray/debug ... Can anyone help me and point me to a location where I might start looking for the problem? Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Joel de Guzman [EMAIL PROTECTED] writes:
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you care about higher-orderness of your
generic algorithms, a preferred implementation construct for those
algorithms is not a function template, but a static _function object_ (a
technique used in FC++):
struct my_function_
{
template typename U
void operator()(std::string const text, U)
{
// ...
}
} my_function; // here!
For ordinary uses, the above will act just like a plain function template
(minus ADL/explicit template arguments specification):
my_function(text, int());
and it will also allow one to do something like this:
std::string text(text);
mpl::for_each my_types (boost::bindvoid(my_function, text, _1));
This technique is adopted by Phoenix. With this, you can even do
(as suggested by Joel Young):
- \ \
double - /\ f . /\ x. f(f x)
- / \ / \
struct square_ {
template typename X
struct result { typedef X type; };
template typename X
X operator()(X x)
{
return x * x;
}
};
This is similar to my universal identity suggestion from many months
back. However, result should be apply to make it an MPL
metafunction class wink.
Hum, that result template looks like identity, and not square. Am I
missing something? I'd have thought:
template typename X
struct result : mpl::timesX,X {};
functionsquare_ square;
template typename F
struct ffx {
template typename X
struct result { typedef X type; };
Mighty confused. Not
template typename X
struct result : mpl::applyF, typename mpl::applyF,X::type {};
??
If not, what's the point of result?
PS Jaakko and I are working on the LL/Phoenix merger.
Yay! What about my tuples question?
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Boost-docs] Integrating BoostBook documentationwith HTMLdocumentation
I've been watching this thread go by; kept a bunch of messages in my inbox because I didn't know what to make of them, and now I realize I still don't. It looks like there is going to be a big learning curve for me; I have practically no XML/XSLT experience to begin with, not to mention that I don't understand lots of other issues. Should I be doing something other than sitting on the sidelines? -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Boost-docs] Integrating BoostBook documentationwith HTMLdocumentation
On Thu, 23 Jan 2003, David Abrahams wrote: I've been watching this thread go by; kept a bunch of messages in my inbox because I didn't know what to make of them, and now I realize I still don't. It looks like there is going to be a big learning curve for me; I have practically no XML/XSLT experience to begin with, not to mention that I don't understand lots of other issues. Should I be doing something other than sitting on the sidelines? -Dave You won't need to know any XSLT unless you want to introduce additional features into BoostBook. The learning curve for XML is practically nonexistant. There's a few lines of boilerplate code for identifying a particular document as a BoostBook document. From there on, it's just a matter of matching tags :). I've found XML tools to be quite good: parser error messages are generally quite obvious, and some text editors can help avoid lots of dumb mistakes. In the next few days I'll be writing a tutorial on BoostBook, describing the documentation of a small library (boost::any). That should drastically reduce the hassle of learning BoostBook, and make it feasible for others to try it out. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
