[boost] Possibly new configuration macro for Boost.Config
Hi.
While working on the lexical_cast proposition, I found that the following
code works on Comeau C++, GCC 3.2 and Borland C++ Builder 6.0, but fails on
Intel C++ 7.0, in strict mode:
#include string
templateclass Result,class T
void f(Result,T) {}
templateclass Result,class CharType,class CharTraits,class Allocator
void f(Result,std::basic_stringCharType,CharTraits,Allocator) {}
templateclass CharType,class CharTraits,class Allocator,class Source
void f(std::basic_stringCharType,CharTraits,Allocator,Source) {}
void f(std::string,std::string) {} // Error here
int main()
{
int i;
std::string str;
f(i,i);
f(str,i);
f(i,str);
f(str,str);
}
This gives the error:
error: ambiguous guiding declaration -- more than one function template f
[with Result=_STL::string, CharType=char,
CharTraits=_STL::char_traitschar, Allocator=_STL::allocatorchar]
matches type void (_STL::string, _STL::string)
void f(std::string,std::string) {}
^
I've filed a problem report with Intel about this. Maybe we could get a
configuration macro for this, to be set for Intel C++? The same error also
occurs for version 6.0.
If ok, I can submit a proper test file for Boost.Config. This appears pretty
compiler-specific, so maybe something like BOOST_INTEL_OVERLOAD_BUG could be
used.
Also, while we're at it, as Dave Abrahams notes in
boost/config/compiler/intel.hpp, there is a difference between version 5.0
and 6.0, in that the latter supports template template arguments, while the
former does not, so it should probably set BOOST_NO_TEMPLATE_TEMPLATES for
versions prior to 6.0.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Possibly new configuration macro for Boost.Config
From: Terje Slettebø [EMAIL PROTECTED]
Hm. Given that BCB 6.0 gives an error on another part of the test program
(the call f(str,str) is reported as ambiguous), and I need to check for that
compiler, as well, maybe one could have a more general configuration macro,
like BOOST_FUNCTION_TEMPLATE_PARTIAL_ORDERING_BUG. (Intel C++ and BCB 6.0
has partial ordering in general, but don't handle more complex cases, such
as the example below.) This would avoid a proliferation of compiler-specific
macros.
#include string
templateclass Result,class T
void f(Result,T) {}
templateclass Result,class CharType,class CharTraits,class Allocator
void f(Result,std::basic_stringCharType,CharTraits,Allocator) {}
templateclass CharType,class CharTraits,class Allocator,class Source
void f(std::basic_stringCharType,CharTraits,Allocator,Source) {}
void f(std::string,std::string) {} // Error here
int main()
{
int i;
std::string str;
f(i,i);
f(str,i);
f(i,str);
f(str,str);
}
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
On Wednesday 08 January 2003 17:16, Rene Rivera wrote: [2003-01-08] Beman Dawes wrote: At 07:58 AM 1/8/2003, John Maddock wrote: This is another call for volunteers to come forward to help run the boost regression tests on more platforms, particularly needed are the commercial Unix variants (Solaris, HP, SGI Irix etc), but also Free|Net|OpenBSD and MacOS X. I'm working on the port to HPUX (recently I've send a few msg's out on this) but have trouble compiling the regression-reporting tools. Already patched a few things in MPL but now the filesystem lib is causing headeaches. If you and/or Jens (did previous ports to HP) could help me out ... ? Once these tools compile, I'll provide fresh status pages every friday like I do for IBM. toon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Metaprogramming: Using static const or enum?
Gabriel Dos Reis wrote: I'm not one the authors of the book mentioned but I will say what I know (from experience both as a user and casual implementor). The issue of enum/static const is an endless debate. However, one thing is sure: Even with the amended paragraph in the Standard (redefinition of used), passing an lvalue to a function that expects a const reference more or less takes the referenced entity's address, and as such makes the static const object used, therefore a definition is required. One looses the purely compile-time constant aspect. This matches my experience (as a user only :) Yes, a smarter compiler may do better, but such smarter compilers are quite rare :-) Yes, the thingy ends up in the link map (as a local symbol). Just to make sure: Do you vote in favor of enums? I have seen problems with 'static const ...', but I have never seen problems with enums (although they theoretically exist). Both have their drawbacks, it seems we have to choose the petty evil... -- Gaby Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Small thing: yes_type and no_type made public?
From: Hartmut Kaiser [EMAIL PROTECTED]
David Abrahams wrote:
// The following expands to
//
// typedef char (sizeN_t)[N];
//
// for N = 1..BOOST_MAX_SIZETYPE_COUNT
#define SIZETYPE(z, n, nil) \
typedef char (size ## n ## _t)[n]; \
/**/
Careful; isn't the symbol _t reserved to the implementation
in this context?
The purpose of the macros was to generate a couple of
typedef char (sizeN_t)[N]; // for N=1..MAX
Statements, so _t is never seen by the compiler.
But anyway the solution proposed by Paul is cleaner, so I vote for it.
From Paul's posting:
You can achieve the effect you want easily:
templateint I struct size_descriptor {
typedef char ( type)[I];
};
typedef size_descriptor1::type yes_type;
typedef size_descriptor2::type no_type;
...or something similar, which solves the problem once and for all.
Looks good. What should we call it? size_descriptor, like here?
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Metaprogramming: Using static const or enum?
Terje Slettebø wrote: Just to make sure: Do you vote in favor of enums? I have seen problems with 'static const ...', but I have never seen problems with enums (although they theoretically exist). Not just theoretically. As mentioned in an earlier posting in this thread, BCC doesn't work well with enums, but it does work with static const. Also, there's the issues pointed out by Paul Mensonides, due to the fact that enums are UDTs. Sorry, I should have been more exact. Of course we can only choose a default implementation. If a compiler is buggy, we need to work-around anyway. The drawback of enums, mentioned by Paul, is the one I call theoretically, as I have never found this to be a problem in the real world (well, in *my* real world :). A problem like this can be *created* but special code which I have yet to see in normal programs. OTOH I have already seen a colleage wondering about link-failures due to passing a 'static const int ...' to a function which took a 'const T'. I consider this much more likely to happen in daily programming, YMMV :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] What is MPL anyway?
Hi, I've been following the discussion on a HelloWorld for the MPL framework with great interrest, in the hope of understanding what this MPL thing really is, sadly enough, I am no further than I was a week ago. Could anybody please explain what MPL is, what it does, why I should wish to use it, when I should use it and why it is better than the alternative solutions that may exist for the problems the MPL was meant to solve? Is there any problem for which MPL is the ideal (if not the only) solution and are there cases in which MPL is a clear winner over standard C++ code? I'm sure you Boost guys have created as wonderful a tool with MPL as you have with some of your other libraries but at the moment it just seems like a really complicated way of doing things. If performance is the only reason for choosing MPL than I doubt whether it would outweight the added development effort. Please regard me as the ultimate HelloWorld testcase and educate me into the ways of the MPL :) regards, Martijn van der Lee p.s. Still looking for people to help with ditto.sourceforge.net __ http://www.wanadoo.nl/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread
From: Alberto Barbati [EMAIL PROTECTED] William E. Kempf wrote: * Are there concerns about using conditional compilation and optional portions of the library, as POSIX does? I believe this is the only way Boost.Threads and the C++ standard will be able to provide portable threading libraries that don't restrict implementation to a least common denominator approach. What about using property maps? (I mean the Boost Property Map Library). I looked at that once before and decided it wasn't a viable option... but for the life of me I can't remember why. So I'll have to reevaluate it again. * Are there issues with throwing std::invalid_argument for both invalid and unsupported values? Should I define Boost.Threads specific exceptions instead, seperating out the two exception types? If you want to use std:: exception classes, for unsupported value you could also use std::domain_error. Defining two new classes in the boost namespace is also an option. That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: notation question
On Wed, Jan 08, 2003 at 12:06:33PM -0500, David Abrahams wrote:
Vladimir Prus [EMAIL PROTECTED] writes:
David Abrahams wrote:
Vladimir Prus [EMAIL PROTECTED] writes:
I'd prefer the latter variant, so that non-broken platforms use more natural
syntax. Another question is whether we could use only the second version.
Theoretically, if you call the second version on const string, then InputT
should be deduced as const string. You can then write a simple wrapper to
select const_iterator or iterator.
The only problem is, IIRC, borland drops const on template arguments
sometimes, and that's not possible to fix. Also, the simple wrapper
requires partial specialization. So, I'm not sure this approach is
viable, either.
There are mostly-transparent solutions. Something like:
// find_first sequence const version
template typename InputT, typename SearchT
inline iterator_range typename InputT::const_iterator
find_first_impl( const InputT Input, const SearchT Search, 0 )
{
...
}
I'm guessing the last parameter should be int?
No, sorry. It should be ...
// find_first sequence non-const version
template typename InputT, typename SearchT
inline iterator_range typename InputT::const_iterator
find_first_impl( InputT Input, const SearchT Search, int )
{
...
}
// find_first sequence
template typename InputT, typename SearchT
inline iterator_range typename InputT::iterator
find_first( InputT Input, const SearchT Search )
{
find_first_impl(Input, Search, 0);
}
Should work on vc6. Can't vouch for Borland, though :(
Unfortunately, first_first will return the same plain (non-const) iterator
in all cases. And we'd need to return const_iterator when string is const.
OK, let me fix that:
// find_first sequence
template typename InputT, typename SearchT
inline iterator_range
typename mpl::if_
is_constInputT
, typename InputT::const_iterator
, typename InputT::iterator
::type
find_first( InputT Input, const SearchT Search )
{
find_first_impl(Input, Search, 0);
}
Looking at the name of the function, it occurs to me that dispatching
to separate implementations might not be needed.
The only restriction on this one is that it doesn't work when the
Input parameter is an non-const rvalue.
Is this approach feasible for boost? IIRC, somebody mentioned, that BCC does
not handle correctly const templace paramenters, and so, is_constInputT would
not work
I would rather prefer one not-the-pretiest-but-working solution to one which
works only 90% of time without a possible workaround ...
What is the stretegy in Boost development?
Pavol
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Rene Rivera [EMAIL PROTECTED]
[2003-01-08] William E. Kempf wrote:
From: Rene Rivera [EMAIL PROTECTED]
[2003-01-08] William E. Kempf wrote:
I'd appreciate comments on the above design. Specifically I have these
questions:
* Are there concerns about using conditional compilation and optional
portions of the
library, as POSIX does? I believe this is the only way Boost.Threads
and
the C++
standard will be able to provide portable threading libraries that
don't
restrict
implementation to a least common denominator approach.
I rather dislike the conditional compilation solution. It makes it rather
harder to write portable code as it makes for doing conditional PP code
outside of the library. Would it not be preferable to throw some form of
unimplemented/unsupported exception? Another option would be a
discovery
interface to find out what's supported in the platform. Such a discovery
interface could be used with MPL to get the equivalent of PP.
Note that we do throw exceptions in many cases where things aren't
supported. However,
if a large category of functionality is not available, such as scheduling,
there's
reasons to prefer conditional compilation. First, you can get rid of
unecessary code.
Second, you know from attempts to compile whether or not code can actually
be ported to
a given platform. IOW, the exception approach is only useful when you can
compensate
for the lack of a feature at run time.
Yes, I can see how the exception approach is not ideal, not just for the
library but also for the user.
But as a user I would expect something other than an internal
BOOST_THREAD_ATTRIBUTES_STACKSIZE to tell me that setting the stacksize is
supported in the platform. At minimum I would expect a standard symbol, PP
or otherwise, that tells me if I can use that feature. I would much rather
see something like this... instead of a set of PP symbols:
struct thread_traits
{
#if defined(BOOST_THREAD_ATTRIBUTES_STACKSIZE)
typedef attributes_stacksize yes_type;
BOOST_STATIC_CONSTANT(bool, supports_attributes_stacksize = true);
#else
typedef attributes_stacksize no_type;
BOOST_STATIC_CONSTANT(bool, supports_attributes_stacksize = false);
#endif
#if defined(BOOST_THREAD_ATTRIBUTES_STACKADDR)
typedef attributes_stackaddress yes_type;
BOOST_STATIC_CONSTANT(bool, supports_attributes_stackaddress = true);
#else
typedef attributes_stackaddress no_type;
BOOST_STATIC_CONSTANT(bool, supports_attributes_stackaddress = false);
#endif
#if defined(BOOST_THREAD_PRIORITY_SCHEDULING)
typedef priority_scheduling yes_type;
BOOST_STATIC_CONSTANT(bool, supports_priority_scheduling = true);
#else
typedef priority_scheduling no_type;
BOOST_STATIC_CONSTANT(bool, supports_priority_scheduling = false);
#endif
};
... or something like that ;-)
I have no problems with that, necessarily, but how would you use this? What benefits
does it provide? Would this be in addition to the _documented_ PP symbols?
Was there ever any consideration/discussion on exposing some form of
thread
ID? (appart from the implicit ID in operator==)
Yes... but I'm still trying to determine the requirements for that. If the
only usage
for an ID is for comparison, and for diagnostic messages, then all that's
missing in the
current proposed design is an operator(ostream). Otherwise, what's
missing is an id()
method and an ID type.
The one place I would like to have such a thing it would have to be id().
I have one, very overused, place in my code where I have to iterate on a
list of objects, which have thread pointers to find the object given the
current thread. It would somewhat cleaner and easier to understand if I
could have a std::mapthread::ID,object* instead.
That doesn't necessarily speak for an ID type in addition to boost::thread. It only
adds another requirement that could be met by boost::thread itself. Either an
operator(), knowing that the ordering is arbitrary, or follow the same route as
std::type_info and include a before(). Thoughts?
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Beman Dawes [EMAIL PROTECTED] At 05:17 PM 1/8/2003, William E. Kempf wrote: From: Rene Rivera [EMAIL PROTECTED] I rather dislike the conditional compilation solution. It makes it rather harder to write portable code as it makes for doing conditional PP code outside of the library. Would it not be preferable to throw some form of unimplemented/unsupported exception? Another option would be a discovery interface to find out what's supported in the platform. Such a discovery interface could be used with MPL to get the equivalent of PP. Note that we do throw exceptions in many cases where things aren't supported. However, if a large category of functionality is not available, such as scheduling, there's reasons to prefer conditional compilation. First, you can get rid of unecessary code. Second, you know from attempts to compile whether or not code can actually be ported to a given platform. IOW, the exception approach is only useful when you can compensate for the lack of a feature at run time. I'm not a fan of conditional compilation either. I'd rather see the functions always supplied, even as stubs, unless it is absolutely sure that every use represents a serious error. For example, setting the stack size may have no effect on some platforms, but why should it be considered an error? There could be a compile time way to tell if the feature has any effect, so if the user wishes to tailor the code, it is possible to do so. Particularly between major platforms like POSIX and Windows, I'd hope that programs could be moved back and forth without user code being concerned about presence or absence of features. That's the rub, though. Some features are killer for portability when an application must maintain realtime constraints. If a platform doesn't support the features you need for realtime programming, you simply can't target that platform, and a stubbed approach is going to cause you more problems than it's going to help. But I understand why people don't like conditional compilation... and that's precisely why I brought the subject up. If there's a solution I'm not thinking of, I'd prefer to have another approach as well. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Beman Dawes [EMAIL PROTECTED] At 03:03 PM 1/8/2003, William E. Kempf wrote: The sched_fifo, sched_rr, sched_other, scope_process, and scope_system values are implementation defined, and on POSIX correspond to SCHED_FIFO, SCHED_RR, SCHED_OTHER, PTHREAD_SCOPE_PROCESS and PTHREAD_SCOPE_SYSTEM respectively. Do these values apply reasonably well to Windows? Yes, in that you can fullfill the requirements of POSIX here on the Windows platform. But that's true only because you can report at run time that some values are unsupported. In point of fact, the only values that are usable on Windows are SCHED_OTHER and PTHREAD_SCOPE_SYSTEM. However, the other possibilities are essential for realtime programmers, and can't be factored out because any platform, even one as prevelant as Windows, does not support them. thread::cancel() indicates that the thread of execution should throw thread_cancel at the next call to a cancellation point. thread::test_cancel() is a cancellation point and will throw thread_cancel if thread::cancel() has been called on the current thread of execution. thread::sleep() and thread::yield() have not changed, except they are now considered cancellation points and may throw thread_cancel. Are there other cancellation points? Yes. Significant to Boost.Threads are the condition wait operations. Most others are std:: functions, such as read/write, for which Boost can't offer much of a solution but I'll have to document for the standard. Is there a way to force preemptive cancellation? Just to be clear, what do you mean by preemptive cancellation? Given that there has been a great deal of concern about cancellation, I'd like to see a fuller explanation of the cancellation model you are using. Also a simple example or two. There will be. I plan to work on the documentation next... but there were enough questions about the design of attributes that I thought I'd post early. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
Good! This may be useful to some of the compiler suppliers, too. Would you be willing to add it to tools/regression? Done. Just yesterday I committed a simple tools/regression/index.htm file. A mention with link to the script could go there, and perhaps a bit of documentation in more/regression.html. At the least, there should be a link in more/regression.html. Done. In looking at the script, perhaps it could be made a bit clearer what needs to be changed to tailor it to a particular system. Or perhaps that could be done in the docs. Anyhow, this should be a helpful addition. Thanks, I'll try and add more comments as any problems show up. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possibly new configuration macro for Boost.Config
While working on the lexical_cast proposition, I found that the following
code works on Comeau C++, GCC 3.2 and Borland C++ Builder 6.0, but fails
on
Intel C++ 7.0, in strict mode:
#include string
templateclass Result,class T
void f(Result,T) {}
templateclass Result,class CharType,class CharTraits,class Allocator
void f(Result,std::basic_stringCharType,CharTraits,Allocator) {}
templateclass CharType,class CharTraits,class Allocator,class Source
void f(std::basic_stringCharType,CharTraits,Allocator,Source) {}
void f(std::string,std::string) {} // Error here
int main()
{
int i;
std::string str;
f(i,i);
f(str,i);
f(i,str);
f(str,str);
}
This gives the error:
error: ambiguous guiding declaration -- more than one function template f
[with Result=_STL::string, CharType=char,
CharTraits=_STL::char_traitschar, Allocator=_STL::allocatorchar]
matches type void (_STL::string, _STL::string)
void f(std::string,std::string) {}
^
I've filed a problem report with Intel about this. Maybe we could get a
configuration macro for this, to be set for Intel C++? The same error also
occurs for version 6.0.
If ok, I can submit a proper test file for Boost.Config. This appears
pretty
compiler-specific, so maybe something like BOOST_INTEL_OVERLOAD_BUG could
be
used.
If it is that compiler specific, and is only effecting one library, then why
not use BOOST_WORKAROUND ?
Also, while we're at it, as Dave Abrahams notes in
boost/config/compiler/intel.hpp, there is a difference between version 5.0
and 6.0, in that the latter supports template template arguments, while
the
former does not, so it should probably set BOOST_NO_TEMPLATE_TEMPLATES for
versions prior to 6.0.
I'm hoping that the section:
#if (__EDG_VERSION__ = 244) !defined(BOOST_NO_TEMPLATE_TEMPLATES)
# define BOOST_NO_TEMPLATE_TEMPLATES
#endif
in common_edg.hpp does that ?
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
John would you mind if I improve on the script. I'd like to run it on my OpenBSD server to help out. But I would have to add fetching of Boost from CVS as a step. -- I could document it more as I do this ;-) No absolutely go for it! I guess there really should be a extra step at the end as well to upload the resulting table. Actually I did wonder if these steps would be better as a separate script (that calls mine), to cater for off-line testers as well as on-line ones... John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possibly new configuration macro for Boost.Config
From: John Maddock [EMAIL PROTECTED] While working on the lexical_cast proposition, I found that the following code works on Comeau C++, GCC 3.2 and Borland C++ Builder 6.0, but fails on Intel C++ 7.0, in strict mode: If it is that compiler specific, and is only effecting one library, then why not use BOOST_WORKAROUND ? Yes, that can be done. I had seen the discussion here about it a while ago, but as I didn't find anything like that in the Boost.Config docs, I didn't think of it. I've found it now in boost/detail/workaround.hpp, though. Also, while we're at it, as Dave Abrahams notes in boost/config/compiler/intel.hpp, there is a difference between version 5.0 and 6.0, in that the latter supports template template arguments, while the former does not, so it should probably set BOOST_NO_TEMPLATE_TEMPLATES for versions prior to 6.0. I'm hoping that the section: #if (__EDG_VERSION__ = 244) !defined(BOOST_NO_TEMPLATE_TEMPLATES) # define BOOST_NO_TEMPLATE_TEMPLATES #endif in common_edg.hpp does that ? Ah, I hadn't noticed that one. No wonder there were so few #define's in intel.hpp. :) Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Small thing: yes_type and no_type made public?
Terje Slettebø [EMAIL PROTECTED] writes:
From: Hartmut Kaiser [EMAIL PROTECTED]
David Abrahams wrote:
// The following expands to
//
// typedef char (sizeN_t)[N];
//
// for N = 1..BOOST_MAX_SIZETYPE_COUNT
#define SIZETYPE(z, n, nil) \
typedef char (size ## n ## _t)[n]; \
/**/
Careful; isn't the symbol _t reserved to the implementation
in this context?
The purpose of the macros was to generate a couple of
typedef char (sizeN_t)[N]; // for N=1..MAX
Statements, so _t is never seen by the compiler.
But anyway the solution proposed by Paul is cleaner, so I vote for it.
From Paul's posting:
You can achieve the effect you want easily:
templateint I struct size_descriptor {
typedef char ( type)[I];
};
typedef size_descriptor1::type yes_type;
typedef size_descriptor2::type no_type;
...or something similar, which solves the problem once and for all.
Looks good. What should we call it? size_descriptor, like here?
I already have such a metafunction in Boost.Python. It's called
char_array, since after all that's what it produces.
boost/boost/python/detail/char_array.hpp
--
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] Boost boo-boos
I written a C++ program to inspect the Boost directory tree looking for various problems. The program is in CVS - see boost-root/tools/inspect. It replaces a hodge-podge of scripts written in three or four other languages, and should be much easier to maintain. It can be used by developers to see if potential additions have problems. See output below. Here are the counts: 4926 files scanned 390 directories scanned 305 problems reported problem counts: 60 files with tabs 15 file names too long 2 bookmarks with invalid characters 85 invalid urls 121 broken links 22 unlinked files I'd appreciate it if developers could fix any problems identified in their libraries. Cheers, --Beman any libs/any/test.hpp: tabs in file build tools/build/boost_build_v2.html: broken link: features_properties, broken link: link_compatibility, unlinked file tools/build/examples-v2/make/Jamfile: tabs in file tools/build/test/project-test1/dir2/Jamfile: tabs in file tools/build/test/test_system.html: unlinked file concept_check libs/concept_check/stl_concept_covering.cpp: tabs in file config libs/config/config.htm: broken link: user.hpp libs/config/test/boost_no_ded_typename.cxx: tabs in file conversion libs/conversion/test.hpp: tabs in file date_time boost/date_time/c_local_time_adjustor.hpp: tabs in file boost/date_time/wrapping_int.hpp: tabs in file libs/date_time/build/Jamfile: tabs in file libs/date_time/doc/class_greg_base_facet.html: unlinked file libs/date_time/example/gregorian/localization.cpp: tabs in file libs/date_time/test/gregorian/testdate_iterator.cpp: tabs in file detail boost/detail/dynamic_bitset.hpp: tabs in file dynamic_bitset boost/dynamic_bitset.hpp: tabs in file libs/dynamic_bitset/bitset_test.hpp: tabs in file libs/dynamic_bitset/dyn_bitset_unit_tests1.cpp: tabs in file graph boost/graph/dijkstra_shortest_paths.hpp: tabs in file boost/graph/graph_as_tree.hpp: tabs in file boost/graph/johnson_all_pairs_shortest.hpp: tabs in file boost/graph/relax.hpp: tabs in file boost/graph/transitive_closure.hpp: tabs in file boost/graph/undirected_dfs.hpp: tabs in file libs/graph/build/Jamfile: tabs in file libs/graph/doc/Buffer.html: broken link: ../../boost/pending/mutable_queue.hpp libs/graph/example/filtered_graph_edge_range.cpp: tabs in file libs/graph/example/graph_as_tree.cpp: tabs in file libs/graph/example/iohb.c: tabs in file libs/graph/example/undirected_dfs.cpp: tabs in file libs/graph/src/graphviz_parser.h: tabs in file libs/graph/test/adj_list_test.cpp: tabs in file libs/graph/test/bellman-test.cpp: tabs in file libs/graph/test/johnson-test.cpp: tabs in file lambda boost/lambda/detail/member_ptr.hpp: tabs in file libs/lambda/doc/lambda_docs_as_one_file.html: unlinked file libs libs: unlinked file math libs/math/Jamfile: tabs in file more more: unlinked file more/download.html: broken link: ../boost_all.tar.gz, broken link: ../boost_all.zip more/writingdoc/design.html: broken link: template%5Coverview.html more/writingdoc/introduction.html: broken link: index.htm more/writingdoc/structure.html: broken link: index.htm mpl boost/mpl/if.hpp: tabs in file boost/mpl/remove_if.hpp: tabs in file libs/mpl/doc/ref/Reference/advance.html: broken link: ../Reference.html, invalid URL: ../../../../../\boost/mpl/advance.hpp (many similar removed for brevity) multi_array libs/multi_array/doc/reference.html: broken link: ./iterator_categories.html#concept_RandomAccessTraversalIterator, broken link: ./iterator_categories.html#concept_ReadableIterator, broken link: ./iterator_categories.html#concept_WritableIterator libs/multi_array/doc/user.html: broken link: ../../array_traits/index.html numeric boost/numeric/ublas/matrix_sparse.hpp: tabs in file boost/numeric/ublas/vector_sparse.hpp: tabs in file libs/numeric/ublas/Jamfile: tabs in file pool boost/pool/detail/mutex.hpp: tabs in file preprocessor libs/preprocessor/doc/blank.html: unlinked file libs/preprocessor/doc/headers.html: broken link: headers/wstringize.hpp.html libs/preprocessor/doc/headers/enum_params_with_a_default.hpp.html: filename 31 chars libs/preprocessor/doc/headers/enum_params_with_defaults.hpp.html: filename 31 chars libs/preprocessor/doc/headers/list/to_tuple.hpp.html: broken link: ../../ref/to_tuple.html, broken link: ../../ref/to_tuple_r.html libs/preprocessor/doc/headers/repetition/enum_params_with_a_default.hpp.html: filename 31 chars libs/preprocessor/doc/headers/repetition/enum_params_with_defaults.hpp.html: filename 31 chars libs/preprocessor/doc/headers/repetition/enum_trailing_binary_params.hpp.html: filename 31 chars libs/preprocessor/doc/ref.html: broken link: ref/wstringize.html libs/preprocessor/doc/ref/bool.html: broken link: bool.hpp libs/preprocessor/doc/ref/enum_trailing_binary_params.html:
Re: [boost] Re: Next revision of boost::thread
From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. Agreed. And we should keep coherence with the filesystem library. Sted ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] status of array_traits?
IIRC, the array_traits library was pulled off of the boost main page and moved into the sandbox a while ago. What is its current status? Is being actively developed or is it currently in stasis? cheers, ron ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Metaprogramming: Using static const or enum?
Daniel Frey [EMAIL PROTECTED] writes: | Yes, a smarter compiler may do better, but such smarter compilers are | quite rare :-) | Yes, the thingy ends up in the link map (as a local symbol). | | Just to make sure: Do you vote in favor of enums? I'm a long term pro-enum (mostly because for the meta programming stuff I had to do, it works very well), but I do understand the potential drawbacks raised by the pro-'static const' camp. | I have seen problems | with 'static const ...', but I have never seen problems with enums | (although they theoretically exist). Both have their drawbacks, it seems | we have to choose the petty evil... Yeah, that happens to be my opinion as well for the time I'm writing and using advanced template programs. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
I did a bunch of testing on and porting to HP, but I wasn't using filesystem or the post-processing tools. If it's giving you trouble you might consider just using bjam to run tests for a while as you pick off the low-hanging fruit. It might well be that Filesystem is broken because of some simpler library it depends on. At the moment I'm going for John's suggestion : compile the tools with gcc and then proceed with aCC. I had my own script to do all the work but I figured I might as well use/contribute to the script in tools/regression/run_tests.sh. One question though, the line : cd $BOOST_ROOT/tools/build/jam_src \ make CC=gcc YACC= LOCATE_TARGET=bin is giving me trouble due to the LOCATE_TARGET. This apparantly makes that the sources are searched for in the bin subdir ?! Should'nt it be removed ? toon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. What extra information do you want provided? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Beman Dawes [EMAIL PROTECTED] At 03:03 PM 1/8/2003, William E. Kempf wrote: The sched_fifo, sched_rr, sched_other, scope_process, and scope_system values are implementation defined, and on POSIX correspond to SCHED_FIFO, SCHED_RR, SCHED_OTHER, PTHREAD_SCOPE_PROCESS and PTHREAD_SCOPE_SYSTEM respectively. A similar situation came up in the Filesystem Library exception classes where we needed enums for some error codes. In the end, we decided that meaningful names were more important than compatibility with POSIX. Most of the ones you list above seem OK as-is. But sched_rr? What does that mean? How about renaming it sched_round_robin? If you put round robin scheduling into Google, you get links to pages clearly explaining the concept. If you put sched_rr into Google, you get links to pages which are much less enlightening. I'm not married to any of the names. I can easily rename it to sched_round_robin. I'd even be willing to spell sched out in all of these names, if that's what's preferred. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-build] CVS: boost/tools/build/new builtin.jam,1.41,1.42
David Abrahams wrote: Vladimir Prus [EMAIL PROTECTED] writes: David Abrahams wrote: -declare-type NT : STATIC_LIB : a : LIB : main ; +declare-type NT : STATIC_LIB : a : LIB : main ; # this is a lie, should be lib. declare-type : STATIC_LIB : a : LIB : main ; Just to clarify: should this really be lib? Yes. OK, changed. Even for cygwin? No. OK, made gcc toolset use a suffix on all platforms. As I recall, just a few days ago Pavol Droba has complained on Boost ml that lib extension is not regognized by cygwin... Or are NT and CYGWIN different things? Yes. That's why both names appear in that file. What are the differences, when one uses the gcc toolset? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: status of array_traits?
Ronald Garcia [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... IIRC, the array_traits library was pulled off of the boost main page and moved into the sandbox a while ago. What is its current status? Is being actively developed or is it currently in stasis? I recently looked into the array_traits because I needed it for the container algorithms if they should work for built.in arrays too. However, after a long time I came to the conclusion that they will never work on non-conforming compilers like vc6/7. The problem is simply the inability to deduce the array size by this overload: template typename T, int sz void foo( T (a) [sz] ); If somebody knows how to remedy this, it would enable array_traits for those compilers. regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost boo-boos
From: Beman Dawes [EMAIL PROTECTED] I written a C++ program to inspect the Boost directory tree looking for various problems. The program is in CVS - see boost-root/tools/inspect. It replaces a hodge-podge of scripts written in three or four other languages, and should be much easier to maintain. It can be used by developers to see if potential additions have problems. Great. Have you, or can you, write some documentation on this? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: Stefano Delli Ponti [EMAIL PROTECTED] From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. Agreed. And we should keep coherence with the filesystem library. I'm not sure there's any coherence to keep here. Do you have specific concerns/thoughts here? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread
William E. Kempf [EMAIL PROTECTED] writes: From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. What extra information do you want provided? For example, that it was a threading library exception. Information carried by the type identity may be enough. -- 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] Call for regression test volunteers
Toon Knapen [EMAIL PROTECTED] writes: I did a bunch of testing on and porting to HP, but I wasn't using filesystem or the post-processing tools. If it's giving you trouble you might consider just using bjam to run tests for a while as you pick off the low-hanging fruit. It might well be that Filesystem is broken because of some simpler library it depends on. At the moment I'm going for John's suggestion : compile the tools with gcc and then proceed with aCC. I had my own script to do all the work but I figured I might as well use/contribute to the script in tools/regression/run_tests.sh. One question though, the line : cd $BOOST_ROOT/tools/build/jam_src \ make CC=gcc YACC= LOCATE_TARGET=bin is giving me trouble due to the LOCATE_TARGET. This apparantly makes that the sources are searched for in the bin subdir ?! Should'nt it be removed ? No, it means that targets will be placed in the bin subdir. However, Rene has put together some new build scripts for bjam. The new recommended procedure is: bash ./build.sh I know that build.sh starts with #!/bin/sh, but in fact it seems to require bash on my machine. My sh doesn't know about 'function'. -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] Call for regression test volunteers
On Thursday 09 January 2003 16:06, David Abrahams wrote: is giving me trouble due to the LOCATE_TARGET. This apparantly makes that the sources are searched for in the bin subdir ?! Should'nt it be removed ? No, it means that targets will be placed in the bin subdir. OK, found the problem. Apparantly on my HP machine I should leave out the CC=gcc. BTW John I made sure that no command-line options are needed on the command-line to compile jamboost so I certainly prefer to remove the CC=gcc. Is that OK ? However, Rene has put together some new build scripts for bjam. The new recommended procedure is: bash ./build.sh Apparantly does not know aCC yet ;( But why is it necessary. Had no trouble recently compiling jam_src with make on all platforms (I know, I should follow the discussions in the jamboost-ml more closely but so little time;( ? toon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: spirit and compile speed
Vincent Finn [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, I assume this is the right place to post questions on Spirit now that it is part of boost! If not here, where? My question is about compile speed. Is there any way to speed it up or at least seperate it from the project? I have added 2 parsers to my code base and the compile time (VC6) has gone from 10 mins to 30mins :-( I love Spirit for its syntax and ease of use, but I must also admit that compile times are´ very long, even for debug builds. I think I read something about a debug mode in uBLAS which was used to reduce compilation time; Could something similar be done in Spirit? regards Thorsten Ottosen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] [...] Was there ever any consideration/discussion on exposing some form of thread ID? (appart from the implicit ID in operator==) Yes... but I'm still trying to determine the requirements for that. If the only usage for an ID is for comparison, and for diagnostic messages, then all that's missing in the current proposed design is an operator(ostream). Otherwise, what's missing is an id() method and an ID type. I think that a reasonable requirement that we already mentioned several times is that the ID should be CopyConstructible, Assignable and LessThanComparable, for use in sets/maps. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: Peter Dimov [EMAIL PROTECTED] I don't see any drawback in throwing something derived from std::runtime_error, and not std::runtime_error itself. This lets you provide more information for clients that catch(thread_error) and still lets others catch(std::runtime_error). As for the extra information, on POSIX it would be a good idea to provide the errno-compatible error code returned by pthread_*, and it _might_ be a good idea to supply a portable error code, too, as the filesystem library does. Fully agreed. That is an example of what I meant with coherence between the two libraries. Sted ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Shared_ptr mini garbage collector
Greg Colvin [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 09:23 AM 1/7/2003, Peter Dimov wrote: From: William E. Kempf [EMAIL PROTECTED] [...] A smart pointer approach is the only way I know to write a portable collector, but it is not really the best way to write a high-performance collector. My preference is to have a special new(gc) allocator for collectable objects, and compiler support for a collector that can scan all objects for pointers to collectable objects. If new(gc) is never called there need be no overhead. This was the main idea behind new (gc), new (rc) and new (os) of placed_ptr. Is now using a compile-time trait (defaults to gc): http://groups.yahoo.com/group/boost/files/placed_ptr/ Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Peter Dimov [EMAIL PROTECTED] Date: 2003/01/09 Thu AM 11:13:23 EST To: Boost mailing list [EMAIL PROTECTED] Subject: Re: Re: [boost] Next revision of boost::thread From: William E. Kempf [EMAIL PROTECTED] [...] Was there ever any consideration/discussion on exposing some form of thread ID? (appart from the implicit ID in operator==) Yes... but I'm still trying to determine the requirements for that. If the only usage for an ID is for comparison, and for diagnostic messages, then all that's missing in the current proposed design is an operator(ostream). Otherwise, what's missing is an id() method and an ID type. I think that a reasonable requirement that we already mentioned several times is that the ID should be CopyConstructible, Assignable and LessThanComparable, for use in sets/maps. This misses the need for outputting in diagnostic messages, for one thing. And all of this can be supplied directly by boost::thread with no need for a boost::thead::id. I just want to make sure we've not missed some other need, which may mean we DO need a seperate id type. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Peter Dimov [EMAIL PROTECTED] I think that a reasonable requirement that we already mentioned several times is that the ID should be CopyConstructible, Assignable and LessThanComparable, for use in sets/maps. Should it truly be LessThanComparable, or should it follow the design of std::type_info with a before() method? I'm happy either way, I just want to understand the rationale for the design choice. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] John Maddock wrote: John would you mind if I improve on the script. I'd like to run it on my OpenBSD server to help out. But I would have to add fetching of Boost from CVS as a step. -- I could document it more as I do this ;-) No absolutely go for it! I guess there really should be a extra step at the end as well to upload the resulting table. Actually I did wonder if these steps would be better as a separate script (that calls mine), to cater for off-line testers as well as on-line ones... I'm changing it so it is still usefull for both uses. I think a single script make for a better interface in this case. It's much easier to point people to a single script and say Here, configure, and run it! -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
[2003-01-09] William E. Kempf wrote: From: Rene Rivera [EMAIL PROTECTED] The one place I would like to have such a thing it would have to be id(). I have one, very overused, place in my code where I have to iterate on a list of objects, which have thread pointers to find the object given the current thread. It would somewhat cleaner and easier to understand if I could have a std::mapthread::ID,object* instead. That doesn't necessarily speak for an ID type in addition to boost::thread. It only adds another requirement that could be met by boost::thread itself. Either an operator(), knowing that the ordering is arbitrary, or follow the same route as std::type_info and include a before(). Thoughts? Having an operator() would work, but not be as convenient as an ID. In my simple thread.ID - object* sample I would have to change it to thread* - object* and add the dereference ops accordingly. So I would still prefer the ID, it's just cleaner and easier to understand. -- 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: Metaprogramming: Using static const or enum?
Gennaro Prota [EMAIL PROTECTED] writes: | On 09 Jan 2003 15:29:30 +0100, Gabriel Dos Reis | [EMAIL PROTECTED] wrote: | | I'm a long term pro-enum (mostly because for the meta programming | stuff I had to do, it works very well), but I do understand the | potential drawbacks raised by the pro-'static const' camp. | | Ok. Now for the most stupid question of the year: what would be wrong | if the rule was that the name of a static const data member was an | lvalue if and only if the member is not initialized in-class? So you propose that the presence/absence of an initializer turns an expression designating a static data member into an rvalue or lvalue? I can't speak for the committee. Personnally, I do know that that proposal won't get my support. I believe the lvalue/rvalue thingy is already confused enought to add such a fragile, more confusing, non-uniform rule to the language. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] Toon Knapen wrote: On Thursday 09 January 2003 16:06, David Abrahams wrote: is giving me trouble due to the LOCATE_TARGET. This apparantly makes that the sources are searched for in the bin subdir ?! Should'nt it be removed ? No, it means that targets will be placed in the bin subdir. OK, found the problem. Apparantly on my HP machine I should leave out the CC=gcc. BTW John I made sure that no command-line options are needed on the command-line to compile jamboost so I certainly prefer to remove the CC=gcc. Is that OK ? However, Rene has put together some new build scripts for bjam. The new recommended procedure is: bash ./build.sh Apparantly does not know aCC yet ;( It's doesn't because I haven't had time to add it since the toolset appeared in Boost.Build ;-) I'll try and add ASAP. ... Question on this... Is it a possibility to install only the C compiler (cc) without the C++ compiler (aCC)? I'm asking to see if I can use the presense of aCC as an indicator that it's all installed. But why is it necessary. Had no trouble recently compiling jam_src with make on all platforms (I know, I should follow the discussions in the jamboost-ml more closely but so little time;( ? It was necessary for when I built on Win32 with CW, which is why I added a build.bat. And then to make things consistent I also added a build.sh to mirror it. It does have the benefit that it's much easier to use than trying to remember the option to pass to make to compile on each platform. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] David Abrahams wrote: Toon Knapen [EMAIL PROTECTED] writes: I did a bunch of testing on and porting to HP, but I wasn't using filesystem or the post-processing tools. If it's giving you trouble you might consider just using bjam to run tests for a while as you pick off the low-hanging fruit. It might well be that Filesystem is broken because of some simpler library it depends on. At the moment I'm going for John's suggestion : compile the tools with gcc and then proceed with aCC. I had my own script to do all the work but I figured I might as well use/contribute to the script in tools/regression/run_tests.sh. One question though, the line : cd $BOOST_ROOT/tools/build/jam_src \ make CC=gcc YACC= LOCATE_TARGET=bin is giving me trouble due to the LOCATE_TARGET. This apparantly makes that the sources are searched for in the bin subdir ?! Should'nt it be removed ? No, it means that targets will be placed in the bin subdir. However, Rene has put together some new build scripts for bjam. The new recommended procedure is: bash ./build.sh I know that build.sh starts with #!/bin/sh, but in fact it seems to require bash on my machine. My sh doesn't know about 'function'. Hmm, I thought I fixed that :-( I'll fix ASAP as I move over to compiling on OpenBSD as it has a real sh. I'm also changing the test script to the new method. -- 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: Next revision of boost::thread
Peter Dimov [EMAIL PROTECTED] writes: From: William E. Kempf [EMAIL PROTECTED] From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. What extra information do you want provided? For example, that it was a threading library exception. Information carried by the type identity may be enough. It's the may that concerns me here. I have absolutely no problem using a domain specific exception type here... I just want to insure doing so covers _all_ the needs. I don't see any drawback in throwing something derived from std::runtime_error There might be, depending on how the implementation handles the std::string argument, and when you create these exception objects. The standard exception hierarchy is sticky. and not std::runtime_error itself. This lets you provide more information for clients that catch(thread_error) and still lets others catch(std::runtime_error). I think I'm going to recommend that we throw an exception type which uses virtual derivation from std::exception. -- 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: Re: [boost] Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED]
From: Peter Dimov [EMAIL PROTECTED]
I think that a reasonable requirement that we already mentioned several
times is that the ID should be CopyConstructible, Assignable and
LessThanComparable, for use in sets/maps.
This misses the need for outputting in diagnostic messages, for one thing.
No, this is an additional requirement that you missed; you already had the
output requirement in place.
And all of this can be supplied directly by boost::thread with no need for
a
boost::thead::id.
Just to clarify, do you mean
std::mapboost::thread *, int, dereferenced_compare map;
?
boost::thread itself is not copyable, so it can't be a key.
How would this work?
void my_function()
{
thread current;
map_type::iterator i = map.find(current); // 'get' is fine
map[current] = 5; // but 'set' is not, as current will become invalid
soon
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Rene Rivera [EMAIL PROTECTED] [2003-01-09] William E. Kempf wrote: From: Rene Rivera [EMAIL PROTECTED] The one place I would like to have such a thing it would have to be id(). I have one, very overused, place in my code where I have to iterate on a list of objects, which have thread pointers to find the object given the current thread. It would somewhat cleaner and easier to understand if I could have a std::mapthread::ID,object* instead. That doesn't necessarily speak for an ID type in addition to boost::thread. It only adds another requirement that could be met by boost::thread itself. Either an operator(), knowing that the ordering is arbitrary, or follow the same route as std::type_info and include a before(). Thoughts? Having an operator() would work, but not be as convenient as an ID. In my simple thread.ID - object* sample I would have to change it to thread* - object* and add the dereference ops accordingly. So I would still prefer the ID, it's just cleaner and easier to understand. I don't follow this. First, why are you using a thread* in the first place? Why not just a thread? (Remember that the new thread design is Copyable and Assignable.) Seems the map should just be: typedef std::mapboost::thread, Object* my_map; which works if we make thread LessThanComparable. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] I think that a reasonable requirement that we already mentioned several times is that the ID should be CopyConstructible, Assignable and LessThanComparable, for use in sets/maps. Should it truly be LessThanComparable, or should it follow the design of std::type_info with a before() method? Something that meets the requirements stated above can be used in std::mapK, V as a 'K'... but since boost::thread is not CopyConstructible, it doesn't matter whether it's LessThanComparable. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] (Remember that the new thread design is Copyable and Assignable.) That's news to me. :-) http://lists.boost.org/MailArchives/boost/msg41451.php class BOOST_THREAD_DECL thread : private noncopyable ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Next revision of boost::thread
William E. Kempf wrote:
[...]
I think that a reasonable requirement that we already mentioned several
times is that the ID should be CopyConstructible, Assignable and
LessThanComparable, for use in sets/maps.
This misses the need for outputting in diagnostic messages, for one thing.
And all of this can be supplied directly by boost::thread with no need for
a boost::thead::id. I just want to make sure we've not missed some other
need, which may mean we DO need a seperate id type.
I, for one, DO need something along the lines of:
http://groups.google.com/groups?selm=3D613D44.9B67916%40web.de
(Subject: Re: High level thread design question)
Well, futures aside for a moment, how about the following concept
(just an illustration/ideas):
new_thread{ thread }( function{, ...args...} );
{exception_propagator exception{, ...exceptions...} ::}
{thread_attr_object.}new_thread( function{, args} );
{exception_propagator thread, exception{, ...exceptions...} ::}
{thread_attr_object.}new_thread( function{, args} );
For example, given:
void operation(); // Oh, BTW, in the next release this might throw std::bad_alloc
We could then have:
a) no propagation of exceptions on join [default]:
new_thread( operation );
new_thread my_fancy_thread ( operation );
thread::attr().set_name( 007 ).
new_thread( operation );
my_fancy_thread::attr().set_something( something ).
new_thread( operation );
b) propagation of exceptions [specified at thread CREATION point] on join:
exception_propagator std::bad_alloc ::
new_thread( operation );
exception_propagator my_fancy_thread,std::bad_alloc ::
new_thread( operation );
exception_propagator std::bad_alloc ::
attr().set_name( 007 ).
new_thread( operation );
exception_propagator my_fancy_thread,std::bad_alloc ::
attr().set_something( something ).
new_thread( operation );
where my_fancy_thread would be something along the lines of:
class my_fancy_thread : public thread {
public:
class attr : public thread::attr {
public: /*...add some fancy stuff...*/ };
/*...add some fancy stuff...*/ };
(with thread fields, custom on_thread_start() and
on_thread_termination() hooks, etc. )
Basically, the idea is to use exception_propagator beast to communicate
the typelist of exceptions that need to be caught, stored and propagated
on join to the thread template -- it would simply have discriminated
union for storing result (void* for void functions; just to have
something instead of void) PLUS all exceptions from that typelist.
This typelist should be properly ordered and will be used for generic
catch-and-store-it-in-a-union finalization in the launching/landing
pad routine. Join operations would simply fire a visitor pattern to
throw this or that exception caught and stored in the joinee thread.
Generic code would have to be parameterized to let users specify a
typelist containing any exception types s/he wants to catch-and-
propagate-on-join for this or that async. operation invocation.
Well, I'd also probably could live with something along the lines of:
(ES: exception specification/throw({...})-spec; ES_stuff_only: things
specified in the ES excluding thread_cancel and thread_exit exceptions;
well, I'm somewhat unsure with respect to thread_restart exception ;-) )
new_thread_that_will_propagate_on_join_ES_stuff_only( operation );
new_thread_that_will_propagate_on_join_ES_stuff_only
my_fancy_thread ( operation );
thread::attr().set_name( 007 ).
new_thread_that_will_propagate_on_join_ES_stuff_only( operation );
my_fancy_thread::attr().set_something( something ).
new_thread_that_will_propagate_on_join_ES_stuff_only( operation );
but I don't think that this can be done in the current C++... its
standard-required-and-utterly-silly unwinding on ES violations aside
for a moment.
http://groups.google.com/groups?selm=3D514E1B.E3CF5716%40web.de
(Subject: Boost.Thread: Threads Exceptions/Enhanced call_once())
Peter Dimov wrote:
[...]
To put things in perspective:
int foo()
{
return 10;
}
std::cout boost::thread(foo).join() std::endl;
Nah, using namespace whatever
int my_operation( int );
class my_fancy_thread : public thread {
public:
class attr : public thread::attr {
public: /*...add some fancy stuff...*/ };
/*...add some fancy stuff...*/ };
// called by thread::attr::new_thread function(s)
thread* create_thread_object( const my_fancy_thread::attr );
// overloads NOOP defaults; called in the context of NEW thread
void on_thread_start( my_fancy_thread* );
void on_thread_termination( my_fancy_thread* );
void thread::main()
{
joinable_thread_ptr int,my_fancy_thread pthread =
my_fancy_thread::attr().set_system_contention_scope()
.set_sched_policy( sched::FIFO )
[boost] Compiling Boost with MinGW - Please lead the blind ...
Hiya, Compiling Boost with MinGW has produced .obj and .lib files in directories such as boost_1_29_0\libs\date_time\build\bin\libboost_date_time.lib\mingw\debug\run time-link-dynamic (when run on a Win2k PC). e.g. libboost_date_time.lib, gregorian_types.obj, etc. This happens for all Boost libs projects when compiling with bjam -sTOOLS=mingw -sBUILD='debug release'. Two things seem wrong with this picture: a) .lib is not dynamic but static b) .lib and .obj files would seem to be in Microsoft .COFF format, rather than the .a and .o GNU formats. Hence, I'm unable to link the bjam produced libs from a separate application of mine that uses simple Makefiles and MinGW/MSYS provided (Gnu) compilers (which produce .o and .a files, etc). I've tried to convert libraries like libboost_date_time.lib to libboost_date_time.a using the reimp MinGW tools but that fails (out of memory). Could someone please enlighten me on how to overcome these simple obstacles? I'm clearly missing something at the moment. Much thanks, Rick Important Notice to Recipients It is important that you do not use e-mail to request, authorize or effect the purchase or sale of any security or commodity, to send fund transfer instructions, or to effect any other transactions. Any such request, orders, or instructions that you send will not be accepted and will not be processed by Morgan Stanley. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Metaprogramming: Using static const or enum?
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
And since there are techniques for making out-of-class definitions
easier
(and automatic), which may be instantiated if needed, like you showed,
then
static const seems clearly best.
That's not nearly so easy to take care of if the metafunction in
question is something like alignment_ofT which could potentially
have lots of values, depending on the T chosen.
In what way would this affect Paul's suggestion:
templateclass T, T V struct map_integral {
static const T value = V;
};
templateclass T, T V const T map_integralT, V::value;
By the way, this could have been done with mpl::integral_c, as well,
provided the out-of-class definition is given.
Do you maybe refer to that each value may take up space in the executable,
if used in such a way that instantiation is needed? That's right, and that's
not the case for enum. Still, there are the issues for enum, as well.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] How to do this in with boost -- assert(typeid(T)==typeid(bool) )
Hello,
I'd like to convert this run-time assertion to a compile time MPL check:
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
assert( typeid(T)==typeid(bool)
|| typeid(T)==typeid(int)
|| typeid(T)==typeid(double)
|| typeid(T)==typeid(string));
...etc...
As you can probably guess, this is a template function that should only
be called with types of int, bool, std::string or double.
From what I've read in this newsgroup, the boost::mpl library should be
able to handle this. But, I wouldn't be surprised if there was an easy
C++ solution too.
Thanks,
Derek Ross.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] Rene Rivera wrote: [2003-01-09] David Abrahams wrote: No, it means that targets will be placed in the bin subdir. However, Rene has put together some new build scripts for bjam. The new recommended procedure is: bash ./build.sh I know that build.sh starts with #!/bin/sh, but in fact it seems to require bash on my machine. My sh doesn't know about 'function'. Hmm, I thought I fixed that :-( I'll fix ASAP as I move over to compiling on OpenBSD as it has a real sh. OK, it's fixed :-) I also added aCC toolset. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: max, min, width, precision, promotion and other toys(0/1)
On Wed, 08 Jan 2003 12:08:40 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
I basically agree with everything you've said, especially about the
separate traits (metafunctions)! I was just pointing out some overlap
with existing libraries.
Ok, here's what I propose:
a) cleaning up the whole implementation of boost/detail/limits.hpp by
- getting rid of all the stuff like:
template
class numeric_limitsbool
: public _Integer_limitsbool, false, true, 0
{};
template
class numeric_limitschar
: public _Integer_limitschar, CHAR_MIN, CHAR_MAX
{};
template
class numeric_limitssigned char
: public _Integer_limitssigned char, SCHAR_MIN,
SCHAR_MAX
{};
because, of course, max_of and min_of can be used for this.
Example:
static T min() throw() { return min_ofT::value; }
[Or, if you prefer... ;-)
return implicit_castT (min_ofT::value);
]
- in general, calculating values instead of providing them
explicitly when this is feasible in a portable way.
Example: for built-in integers, instead of having a hack like
template class _Int,
_Int __imin,
_Int __imax,
int __idigits = -1
class _Integer_limits : public _Numeric_limits_base_Int
that either calculates (wrongly) digits or takes the opposite
of the value that the user passes (__idigits), we could have:
BOOST_STATIC_CONSTANT(int, digits, precisionT::value);
Note, as to digits and digits10, that a similar clean up is
possible for floating point types too, by adding e.g.:
template typename T struct digits {
BOOST_STATIC_CONSTANT(int, value = 0); // dummy value;
(debatable)
};
template struct digitsfloat
{ BOOST_STATIC_CONSTANT(int, value = FLT_MANT_DIG); };
template struct digitsdouble
{ BOOST_STATIC_CONSTANT(int, value = DBL_MANT_DIG); };
template struct digitslong double
{ BOOST_STATIC_CONSTANT(int, value = LDBL_MANT_DIG);};
b) Modifying integer_traits.hpp to use max_of and min_of. This is just
for backward compatibility because I think integer_traits should be
simply deprecated (if the information one wants to provide is
const_max and const_min for what reason should he add that information
somewhere else, like numeric_limits? And what is the derivation good
for?)
What do you think? If there aren't objections I could at least upload
the needed code to the boost sandbox.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] How to do this in with boost --assert(typeid(T)==typeid(bool) )
From: Derek Ross [EMAIL PROTECTED]
Hello,
I'd like to convert this run-time assertion to a compile time MPL check:
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
assert( typeid(T)==typeid(bool)
|| typeid(T)==typeid(int)
|| typeid(T)==typeid(double)
|| typeid(T)==typeid(string));
...etc...
As you can probably guess, this is a template function that should only
be called with types of int, bool, std::string or double.
This would make a nice MPL Hello World example.
Here is one non-MPL low tech old fashioned C++ solution.
inline void assertSetOption(bool const *) {}
inline void assertSetOption(int const *) {}
inline void assertSetOption(double const *) {}
inline void assertSetOption(string const *) {}
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
assertSetOption(value);
// ...
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: intrusive tagging allows omision of unneeded headers
Thorsten Ottosen wrote:
- Original Message -
From: Dirk Gerrits [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Wednesday, January 08, 2003 6:15 PM
Subject: [boost] Re: intrusive tagging allows omision of unneeded headers
Thorsten Ottosen wrote:
[snip]
class X
{
public:
class tag {};
typedef tag X_tag;
^
};
class bar
{
public:
class tag {};
typedef tag bar_tag;
^^^
};
Why these typedefs? Why would one write X::X_tag instead of X::tag for
example?
how can we specifiy that we want to specialize for a particular class
otherwise? Only by establising a convetion
that all (involved) classes have a unique typedef can we destinguish the
classes. For example
template typename C
void foo_impl( const C c, typename C::bar_tag )
{
cout bar specialised version endl;
}
will only be a candidate when C actually has a typedef bar_tag. due to
SFINAE the instantiation is allowed
to fail for classes that does not have a bar_tag typdef. And because the
above foo_impl is more specialized
than
template typename C, typename Tag
void foo_impl( const C c, Tag t )
{
cout default version endl;
}
the first foo_impl will be chosen as a better match.
Ahh, I guess I didn't fully understand everything that was going on.
This makes sense. Thanks!
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Compiling Boost with MinGW - Please lead the blind ...
Fanta, Richard [EMAIL PROTECTED] writes: Hiya, Compiling Boost with MinGW has produced .obj and .lib files in directories such as boost_1_29_0\libs\date_time\build\bin\libboost_date_time.lib\mingw\debug\run time-link-dynamic (when run on a Win2k PC). e.g. libboost_date_time.lib, gregorian_types.obj, etc. This happens for all Boost libs projects when compiling with bjam -sTOOLS=mingw -sBUILD='debug release'. Two things seem wrong with this picture: a) .lib is not dynamic but static What's wrong with that? If you don't get a DLL, it means the date_time library doesn't supply one (perhaps for good reasons). b) .lib and .obj files would seem to be in Microsoft .COFF format, rather than the .a and .o GNU formats. The extensions used by Boost.Build are currently determined by the OS on which bjam was built. However, Boost.Build doesn't do anything special to set the output format of the tools; these files should be in whatever format MinGW produces by default. You can either change the extensions on the files, or force Boost.Build to use different extensions by passing -sSUFLIB=.a -sSUFOBJ=.o on the command-line. Hence, I'm unable to link the bjam produced libs from a separate application of mine that uses simple Makefiles and MinGW/MSYS provided (Gnu) compilers (which produce .o and .a files, etc). That really surprises me. I think it's just a naming issue, not a format issue. -- 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: max, min, width, precision, promotion and other toys (0/1)
Gennaro Prota [EMAIL PROTECTED] writes:
On Wed, 08 Jan 2003 12:08:40 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
I basically agree with everything you've said, especially about the
separate traits (metafunctions)! I was just pointing out some overlap
with existing libraries.
Ok, here's what I propose:
a) cleaning up the whole implementation of boost/detail/limits.hpp by
- getting rid of all the stuff like:
template
class numeric_limitsbool
: public _Integer_limitsbool, false, true, 0
{};
template
class numeric_limitschar
: public _Integer_limitschar, CHAR_MIN, CHAR_MAX
{};
template
class numeric_limitssigned char
: public _Integer_limitssigned char, SCHAR_MIN,
SCHAR_MAX
{};
because, of course, max_of and min_of can be used for this.
Example:
static T min() throw() { return min_ofT::value; }
[Or, if you prefer... ;-)
return implicit_castT (min_ofT::value);
]
Uh, wait a sec. Is it a good idea to mess with
boost/detail/limits.hpp? It's just a workaround for broken/missing
numeric_limits implementations, and it was a pain to get right. Did
you mention this before? If so, I guess I missed it.
- in general, calculating values instead of providing them
explicitly when this is feasible in a portable way.
Example: for built-in integers, instead of having a hack like
template class _Int,
_Int __imin,
_Int __imax,
int __idigits = -1
class _Integer_limits : public _Numeric_limits_base_Int
that either calculates (wrongly) digits or takes the opposite
of the value that the user passes (__idigits), we could have:
BOOST_STATIC_CONSTANT(int, digits, precisionT::value);
I guess if you think it's doing something wrong and you can fix it,
it's worth doing.
Note, as to digits and digits10, that a similar clean up is
possible for floating point types too, by adding e.g.:
template typename T struct digits {
BOOST_STATIC_CONSTANT(int, value = 0); // dummy value;
(debatable)
};
template struct digitsfloat
{ BOOST_STATIC_CONSTANT(int, value = FLT_MANT_DIG); };
template struct digitsdouble
{ BOOST_STATIC_CONSTANT(int, value = DBL_MANT_DIG); };
template struct digitslong double
{ BOOST_STATIC_CONSTANT(int, value = LDBL_MANT_DIG);};
Not sure if this will work portably.
b) Modifying integer_traits.hpp to use max_of and min_of. This is
just for backward compatibility because I think integer_traits
should be simply deprecated (if the information one wants to provide
is const_max and const_min for what reason should he add that
information somewhere else, like numeric_limits? And what is the
derivation good for?)
This was the part I thought I was agreeing with; I don't know.
What do you think? If there aren't objections I could at least
upload the needed code to the boost sandbox.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
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: Re: [boost] Next revision of boost::thread
From: Peter Dimov [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] (Remember that the new thread design is Copyable and Assignable.) That's news to me. :-) Ahh... I see the confusion. I cut too much out when I sent out the e-mail. (And it also looks like I have some code locally that's not in thread_dev.) Sorry, the intent all along was for boost::thread to meet these requirements. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] How to do this in with boost -- assert(typeid(T)==typeid(bool) )
Derek Ross wrote:
Hello,
I'd like to convert this run-time assertion to a compile time MPL check:
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
assert( typeid(T)==typeid(bool)
|| typeid(T)==typeid(int)
|| typeid(T)==typeid(double)
|| typeid(T)==typeid(string));
...etc...
Uhm... don't know about MPL, but isn't this a good example for
type_traits? Something like:
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
BOOST_STATIC_ASSERT( boost::is_same T, bool ::value ||
boost::is_same T, int ::value ||
boost::is_same T, double ::value ||
boost::is_same T, std::string ::value );
...etc...
}
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
From: Peter Dimov [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] I think that a reasonable requirement that we already mentioned several times is that the ID should be CopyConstructible, Assignable and LessThanComparable, for use in sets/maps. This misses the need for outputting in diagnostic messages, for one thing. No, this is an additional requirement that you missed; you already had the output requirement in place. There's a bit of confusion here. I'm referring to the proposed design (and implementation in the thread_dev branch), not to the current boost::thread. The proposed design is already CopyConstructible. (It should have been assignable as well... chalk that up to a stupid oversight on my part.) I did miss the need for LessThanComparable (or equivalent utility). I didn't miss the need for output in my description, though it's not in the proposed interface. And all of this can be supplied directly by boost::thread with no need for a boost::thead::id. Just to clarify, do you mean std::mapboost::thread *, int, dereferenced_compare map; ? With the proposed boost::thread (with a few additional tweaks), yes. boost::thread itself is not copyable, so it can't be a key. How would this work? I was not trying to claim that the current boost::thread in the latest release fullfilled any of the needs. What I'm trying to nail down are all of the requirements for a thread ID, and whethor or not boost::thread itself can meet those needs with out the addition of another type. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread
From: Alexander Terekhov [EMAIL PROTECTED]
William E. Kempf wrote:
[...]
I think that a reasonable requirement that we already mentioned several
times is that the ID should be CopyConstructible, Assignable and
LessThanComparable, for use in sets/maps.
This misses the need for outputting in diagnostic messages, for one thing.
And all of this can be supplied directly by boost::thread with no need for
a boost::thead::id. I just want to make sure we've not missed some other
need, which may mean we DO need a seperate id type.
I, for one, DO need something along the lines of:
http://groups.google.com/groups?selm=3D613D44.9B67916%40web.de
(Subject: Re: High level thread design question)
Well, futures aside for a moment, how about the following concept
(just an illustration/ideas):
new_thread{ thread }( function{, ...args...} );
{exception_propagator exception{, ...exceptions...} ::}
{thread_attr_object.}new_thread( function{, args} );
{exception_propagator thread, exception{, ...exceptions...} ::}
{thread_attr_object.}new_thread( function{, args} );
For example, given:
void operation(); // Oh, BTW, in the next release this might throw std::bad_alloc
We could then have:
a) no propagation of exceptions on join [default]:
new_thread( operation );
new_thread my_fancy_thread ( operation );
thread::attr().set_name( 007 ).
new_thread( operation );
my_fancy_thread::attr().set_something( something ).
new_thread( operation );
b) propagation of exceptions [specified at thread CREATION point] on join:
exception_propagator std::bad_alloc ::
new_thread( operation );
exception_propagator my_fancy_thread,std::bad_alloc ::
new_thread( operation );
exception_propagator std::bad_alloc ::
attr().set_name( 007 ).
new_thread( operation );
exception_propagator my_fancy_thread,std::bad_alloc ::
attr().set_something( something ).
new_thread( operation );
Planned, but not as part of boost::thread. Like parameter passing, I still believe
this logic belongs in the function object. I just plan to develop a reusable
component for building such function objects, in order to make life easy on the user.
William E. Kempf
[EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Next revision of boost::thread
Stefano Delli Ponti wrote: From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. Agreed. And we should keep coherence with the filesystem library. Agreed. Alberto ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] How to do this in with boost --assert(typeid(T)==typeid(bool) )
Peter Dimov [EMAIL PROTECTED] writes:
From: Derek Ross [EMAIL PROTECTED]
Hello,
I'd like to convert this run-time assertion to a compile time MPL check:
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
assert( typeid(T)==typeid(bool)
|| typeid(T)==typeid(int)
|| typeid(T)==typeid(double)
|| typeid(T)==typeid(string));
...etc...
As you can probably guess, this is a template function that should only
be called with types of int, bool, std::string or double.
This would make a nice MPL Hello World example.
Except that it's an example of how to prevent something from
happening, I agree ;-)
typedef mpl::vectorbool,int,double,string legal_types;
BOOST_STATIC_ASSERT((mpl::containslegal_types,T::value));
-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] Compiling Boost with MinGW - Please lead the blind ...
Doh! It is a simple naming thing. Copying the .lib to .a resolves the g++/linker problems... Much thanks, Rick -Original Message- From: David Abrahams [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:08 PM To: Boost mailing list Cc: '[EMAIL PROTECTED]' Subject: Re: [boost] Compiling Boost with MinGW - Please lead the blind ... Fanta, Richard [EMAIL PROTECTED] writes: Hiya, Compiling Boost with MinGW has produced .obj and .lib files in directories such as boost_1_29_0\libs\date_time\build\bin\libboost_date_time.lib\m ingw\debug\run time-link-dynamic (when run on a Win2k PC). e.g. libboost_date_time.lib, gregorian_types.obj, etc. This happens for all Boost libs projects when compiling with bjam -sTOOLS=mingw -sBUILD='debug release'. Two things seem wrong with this picture: a) .lib is not dynamic but static What's wrong with that? If you don't get a DLL, it means the date_time library doesn't supply one (perhaps for good reasons). b) .lib and .obj files would seem to be in Microsoft .COFF format, rather than the .a and .o GNU formats. The extensions used by Boost.Build are currently determined by the OS on which bjam was built. However, Boost.Build doesn't do anything special to set the output format of the tools; these files should be in whatever format MinGW produces by default. You can either change the extensions on the files, or force Boost.Build to use different extensions by passing -sSUFLIB=.a -sSUFOBJ=.o on the command-line. Hence, I'm unable to link the bjam produced libs from a separate application of mine that uses simple Makefiles and MinGW/MSYS provided (Gnu) compilers (which produce .o and .a files, etc). That really surprises me. I think it's just a naming issue, not a format issue. -- 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 Important Notice to Recipients It is important that you do not use e-mail to request, authorize or effect the purchase or sale of any security or commodity, to send fund transfer instructions, or to effect any other transactions. Any such request, orders, or instructions that you send will not be accepted and will not be processed by Morgan Stanley. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to do this in with boost -- assert(typeid(T)==typeid(bool))
Daniel Frey wrote:
Uhm... don't know about MPL, but isn't this a good example for
type_traits? Something like:
template class T
bool SetOption(COptionInfo o, const char* key, const T value)
{
BOOST_STATIC_ASSERT( boost::is_same T, bool ::value ||
boost::is_same T, int ::value ||
boost::is_same T, double ::value ||
boost::is_same T, std::string ::value );
...etc...
It doesn't compile because the commas in the is_same template confuse
the macro preprocessor.
The error message is:
macro BOOST_STATIC_ASSERT passed 5 arguments, but takes just 1
Thought you might be interested...
Derek.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] max min width etc.
Dave, I have shortened the subject since it seemed, so far, to be
changed at each post preventing grouping the messages 'by thread' (at
least with my reader). Now, it should have been changed once for all.
On Thu, 09 Jan 2003 13:21:12 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Uh, wait a sec. Is it a good idea to mess with
boost/detail/limits.hpp?
Gulp! I thought I was proposing simplifying it, not messing! :-)
It's just a workaround for broken/missing
numeric_limits implementations, and it was a pain to get right. Did
you mention this before? If so, I guess I missed it.
No, I didn't mention it. As I said, I never saw the code before.
Anyway it seems simply copied by some SGI implementation, so I doubt
it was such a pain to get right (no offense intended, really)
- in general, calculating values instead of providing them
explicitly when this is feasible in a portable way.
Example: for built-in integers, instead of having a hack like
template class _Int,
_Int __imin,
_Int __imax,
int __idigits = -1
class _Integer_limits : public _Numeric_limits_base_Int
that either calculates (wrongly) digits or takes the opposite
of the value that the user passes (__idigits), we could have:
BOOST_STATIC_CONSTANT(int, digits, precisionT::value);
I guess if you think it's doing something wrong and you can fix it,
it's worth doing.
It depends on what you mean by wrong. It works on all the compilers
supported by boost but is uselessly complicated and not portable.
Note, as to digits and digits10, that a similar clean up is
possible for floating point types too, by adding e.g.:
template typename T struct digits {
BOOST_STATIC_CONSTANT(int, value = 0); // dummy value;
(debatable)
};
template struct digitsfloat
{ BOOST_STATIC_CONSTANT(int, value = FLT_MANT_DIG); };
template struct digitsdouble
{ BOOST_STATIC_CONSTANT(int, value = DBL_MANT_DIG); };
template struct digitslong double
{ BOOST_STATIC_CONSTANT(int, value = LDBL_MANT_DIG);};
Not sure if this will work portably.
Do you mean that we have implementations that don't provide the
x_MANT_DIG macros? Otherwise the code is perfectly portable by
18.2.1.2 of the standard.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
At 11:44 AM 1/9/2003, William E. Kempf wrote: As for conditional compilation... the Boost.Filesystem stuff has no need for this, while Boost.Threads has a very definate need. The reason that Boost.Filesystem doesn't have conditional compilation is that a design decision was made to limit the library to features which could be implemented in both POSIX and Windows. Otherwise it would have been shot full of optional/conditional features. I'm not saying Boost.Threads should take exactly the same approach, but I'd rather not see a lot of optional/conditional features to support operating systems other than those two O/S families. What I found doing research for the Filesystem library was that most of the remaining legacy systems have been retrofitted to support POSIX, while new O/S designs tend to support POSIX right from the start. What is left are features that are so system specific that those wishing to take advantage of the features should just use the operating system's native API. The programs aren't going to be portable in any case, so why provide an illusion of portability where there is none? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
At 04:48 AM 1/9/2003, Toon Knapen wrote: I'm working on the port to HPUX (recently I've send a few msg's out on this) but have trouble compiling the regression-reporting tools. Already patched a few things in MPL but now the filesystem lib is causing headeaches. If you and/or Jens (did previous ports to HP) could help me out ... ? Toon, let me know what about the filesystem is causing problems. It is supposed to be deliberately straightforward code to minimize porting problems. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: How to do this in with boost --assert(typeid(T)==typeid(bool) )
- Original Message -
From: Daniel Frey [EMAIL PROTECTED]
On Thu, 09 Jan 2003 20:18:08 +0100, Derek Ross wrote:
Daniel Frey wrote:
Uhm... don't know about MPL, but isn't this a good example for
type_traits? Something like:
template class T
bool SetOption(COptionInfo o, const char* key, const T value) {
BOOST_STATIC_ASSERT( boost::is_same T, bool ::value ||
boost::is_same T, int ::value ||
boost::is_same T, double ::value ||
boost::is_same T, std::string ::value );
...etc...
It doesn't compile because the commas in the is_same template confuse
the macro preprocessor.
The error message is:
macro BOOST_STATIC_ASSERT passed 5 arguments, but takes just 1
Thought you might be interested...
Yes, sorry. I haven't tested this stuff, this is why I said Something
like ;)
Then how about:
template class T
bool SetOption(COptionInfo o, const char* key, const T value) {
typedef boost::is_same T, bool is_bool_;
typedef boost::is_same T, int is_int_;
typedef boost::is_same T, double is_double_;
typedef boost::is_same T, std::string is_string_;
BOOST_STATIC_ASSERT( is_bool_::value ||
is_int_::value ||
is_double_::value ||
is_string_::value );
...etc...
(That's the usual work-around for the comma-in-macro problem :)
Regards, Daniel
You can just do this as well:
BOOST_STATIC_ASSERT(
( boost::is_sameT, bool::value ) ||
( boost::is_sameT, int::value ) ||
( boost::is_sameT, double::value ) ||
( boost::is_sameT, std::string::value );
)
In other words, just parenthesize the expressions.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] Beman Dawes wrote: At 04:48 AM 1/9/2003, Toon Knapen wrote: I'm working on the port to HPUX (recently I've send a few msg's out on this) but have trouble compiling the regression-reporting tools. Already patched a few things in MPL but now the filesystem lib is causing headeaches. If you and/or Jens (did previous ports to HP) could help me out ... ? Toon, let me know what about the filesystem is causing problems. It is supposed to be deliberately straightforward code to minimize porting problems. Speaking of that... What are the requirements for getting the filesystem code to compile? I'm trying to get GCC2.95.3 on OpenBSD to compile it for the regression testing. Is there a specific version of GCC required? Or would using STLport be sufficient? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] From: Stefano Delli Ponti [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] From: Stefano Delli Ponti [EMAIL PROTECTED] From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. Agreed. And we should keep coherence with the filesystem library. I'm not sure there's any coherence to keep here. Do you have specific concerns/thoughts here? I was thinking about keeping similar design patterns between these two libraries. (because they are conceptually similar as they both give a portable view of operating system functionalities). So if we use domain specific exception in the filesystem library, the thread library should follow the same pattern too. The same for the issue of conditional compilation. I'll look at this closer, but the domains are different enough that I'm not sure there's anything that carries over. OK, I've been looking at boost::filesystem_error. Here's my thoughts: boost::filesystem_error could be benefited by splitting it up into more exception types. I know this was suggested in the review, but don't know what the plan was in regard to this. In Boost.Threads case, so far we have need for 4 different errors: lock errors, resource errors, invalid arguments and unsupported errors. Some have suggested carrying the OS error code, but given only 4 possible error conditions, does this even sound reasonable? Or are people suggesting Boost.Threads should use a single exception type and carry the error code, as filesystem_error currently does? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
At 01:32 PM 1/9/2003, William E. Kempf wrote: From: William E. Kempf [EMAIL PROTECTED] From: Stefano Delli Ponti [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] From: Stefano Delli Ponti [EMAIL PROTECTED] From: David Abrahams [EMAIL PROTECTED] William E. Kempf [EMAIL PROTECTED] writes: That's a good idea. So would users prefer new exception types here, or should I use the std:: exceptions? IMO, it's always safer to use an exception type which provides more-specific information. Agreed. And we should keep coherence with the filesystem library. I'm not sure there's any coherence to keep here. Do you have specific concerns/thoughts here? I was thinking about keeping similar design patterns between these two libraries. (because they are conceptually similar as they both give a portable view of operating system functionalities). So if we use domain specific exception in the filesystem library, the thread library should follow the same pattern too. The same for the issue of conditional compilation. I'll look at this closer, but the domains are different enough that I'm not sure there's anything that carries over. OK, I've been looking at boost::filesystem_error. Here's my thoughts: boost::filesystem_error could be benefited by splitting it up into more exception types. I know this was suggested in the review, but don't know what the plan was in regard to this. In Boost.Threads case, so far we have need for 4 different errors: lock errors, resource errors, invalid arguments and unsupported errors. Some have suggested carrying the OS error code, but given only 4 possible error conditions, does this even sound reasonable? Or are people suggesting Boost.Threads should use a single exception type and carry the error code, as filesystem_error currently does? I think it depends on how useful the four different types and the OS error code are for recovery purposes. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] OK, I've been looking at boost::filesystem_error. Here's my thoughts: boost::filesystem_error could be benefited by splitting it up into more exception types. I know this was suggested in the review, but don't know what the plan was in regard to this. In Boost.Threads case, so far we have need for 4 different errors: lock errors, resource errors, invalid arguments and unsupported errors. POSIX actually distinguishes out of memory errors (ENOMEM) from other lack of resource errors (EAGAIN), and POSIX functions can fail with an access denied error (EPERM). There are also several types of POSIX lock errors (EINVAL, EBUSY, EAGAIN, EDEADLK, EPERM.) Boost.Threads has two additional lock errors associated with the Lock concept that have no POSIX equivalent. Some have suggested carrying the OS error code, but given only 4 possible error conditions, does this even sound reasonable? If the reason for the failure can be identified by the type of the exception, there should be no immediate need to carry an OS error code, although you should consider the how do I translate this to a localized error message problem. Or are people suggesting Boost.Threads should use a single exception type and carry the error code, as filesystem_error currently does? No, this would be a step backward. IIUC filesystem_error is expected to evolve into a hierarchy as exception categories of interest to callers are identified. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
Toon Knapen [EMAIL PROTECTED] writes: On Thursday 09 January 2003 14:51, Beman Dawes wrote: At 04:48 AM 1/9/2003, Toon Knapen wrote: I'm working on the port to HPUX (recently I've send a few msg's out on this) but have trouble compiling the regression-reporting tools. Already patched a few things in MPL but now the filesystem lib is causing headeaches. If you and/or Jens (did previous ports to HP) could help me out ... ? Toon, let me know what about the filesystem is causing problems. It is supposed to be deliberately straightforward code to minimize porting problems. I know but the problem reports soth. like (I'm at home so I can't give you the actual output now) namespace nesting too deep. IMO it's not an error in the fslib but I just have to find some workaround to prevent the error from occuring. I'll keep you informed. Yeah, the abysmal error reports from that compiler make it very hard. That's one reason I was suggesting you start with simpler libraries, like type_traits, so you can cut the examples down until they stop failing. -- 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] Call for regression test volunteers
Toon Knapen [EMAIL PROTECTED] writes: On Thursday 09 January 2003 12:12, Rene Rivera wrote: It's doesn't because I haven't had time to add it since the toolset appeared in Boost.Build ;-) I'll try and add ASAP. ... Question on this... Is it a possibility to install only the C compiler (cc) without the C++ compiler (aCC)? I'm asking to see if I can use the presense of aCC as an indicator that it's all installed. I guess cc is installed by default (like on all unices) and aCC is a commerical product. So cc is always there and aCC is'nt. Anyway, to compile jam_src you can use cc (with the -Ae option though) as you can see in the Jambase. Yeah, I think on Unix, defaulting to cc unless the script knows better is a god idea. It would've prevented this issue with getting aCC to build it in the first place. That's what the Perforce makefile does, too. -- 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: How to do this in withboost--assert(typeid(T)==typeid(bool) )
Paul Mensonides [EMAIL PROTECTED] wrote in message 000901c2b823$1e7f4aa0$8c00a8c0@c161550b">news:000901c2b823$1e7f4aa0$8c00a8c0@c161550b... - Original Message - From: Terje Slettebø [EMAIL PROTECTED] [...] BOOST_STATIC_ASSERT((\ boost::is_sameT, bool::value ||\ boost::is_sameT, int::value ||\ boost::is_sameT, double::value ||\ boost::is_sameT, std::string::value )); And this is still bulkier and less elegant than the two-line MPL solution. ;) Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] (And is it useful to distinguish between memory and other resource errors?) This, I have no ready answer for... but when in doubt, do what POSIX does. Why (in regards to do what POSIX does)? They can make mistakes as easily as the rest of us. Because they've had the time to find and correct their mistakes, I'd expect. :-) If we do seperate them, is there any reason to provide a thread specific memory exception, or should we use std::bad_alloc? Good question. I'll face the same problem when I finally decide to fix the POSIX lightweight_mutex to check for error returns. :-) [As a side note, do you plan to integrate lightweight_mutex into Boost.Threads?] I'm not sure which piece of information is more important here, the no memory part or the this is a thread exception part, although I'm leaning towards a std::bad_alloc derived exception (boost::posix_enomem? boost::thread::out_of_memory?) An error code (OS or portable) can be of help when one needs to catch all thread-related (or better yet, all error code providing) exceptions in a single catch clause. Usually this is only needed to report an error, though, so if thread exceptions provide some other common mechanism to identify the error (like specific what() values), carrying an error code won't be necessary. And would the above mentioned localized message be enough to satisfy this requirement? I think that it would be enough for my needs. Can't speak for others. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: Peter Dimov [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] (And is it useful to distinguish between memory and other resource errors?) This, I have no ready answer for... but when in doubt, do what POSIX does. Why (in regards to do what POSIX does)? They can make mistakes as easily as the rest of us. Because they've had the time to find and correct their mistakes, I'd expect. :-) Doesn't seem to apply, to me. If there's no reason to supply both but it had been standardized that way in the past, I'd expect they'd be loathe to change the standard, since having the seperation won't hurt. But that doesn't necessarily mean that if they had it to do over, they wouldn't simplify things by folding the error codes. If we do seperate them, is there any reason to provide a thread specific memory exception, or should we use std::bad_alloc? Good question. I'll face the same problem when I finally decide to fix the POSIX lightweight_mutex to check for error returns. :-) [As a side note, do you plan to integrate lightweight_mutex into Boost.Threads?] Sort of. The theory was that boost::mutex should be a lightweight mutex, but that that's an implementation detail. So my plan was just to address the implementation when I had the time. I'm not sure which piece of information is more important here, the no memory part or the this is a thread exception part, although I'm leaning towards a std::bad_alloc derived exception (boost::posix_enomem? boost::thread::out_of_memory?) Naming will drive me nuts here, but I don't like using posix when it's not POSIX specific. An error code (OS or portable) can be of help when one needs to catch all thread-related (or better yet, all error code providing) exceptions in a single catch clause. Usually this is only needed to report an error, though, so if thread exceptions provide some other common mechanism to identify the error (like specific what() values), carrying an error code won't be necessary. And would the above mentioned localized message be enough to satisfy this requirement? I think that it would be enough for my needs. Can't speak for others. Well, I'm addressing everyone :). William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] Toon Knapen wrote: Anyway, to compile jam_src you can use cc (with the -Ae option though) as you can see in the Jambase. PS. What does the -Ae option do? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Metaprogramming: Using static const or enum?
You would have to have more than one map_integral with a different value
name, where the values are dependent on one another and are part of the
public interface. It isn't a complete solution, but it does work in most
cases.
For future metaprogramming work (or intermediate values), it might be nice
to add a tag class to map_integral (default it to 'void' for the common
case), and define a BOOST_NEW_STATIC_CONSTANT(type, name, val) which expands
to:
struct name { enum { value = (val); }; }
for enum-based compilers, and:
struct boost__secret_ ## name { };
typedef ::boost::map_integraltype, (val), boost__secret_ ## name name
for static-const-based compilers.
The idea being that what once was referred to as T::name would now become
T::name::value
This solution is nice because it takes care of automatic definitions of any
number of compile-time values, but it is sadly non-backwards-compatible. :(
-Steve
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )
Paul Mensonides [EMAIL PROTECTED] writes: Which could be even shorter yet if we could get away with template template parameters. We can and do. How would you imagine it would be spelled with TTP? -- 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: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )
- Original Message - From: David B. Held [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 1:16 PM Subject: [boost] Re: Re: How to do this in withboost--assert(typeid(T)==typeid(bool) ) Paul Mensonides [EMAIL PROTECTED] wrote in message 000901c2b823$1e7f4aa0$8c00a8c0@c161550b">news:000901c2b823$1e7f4aa0$8c00a8c0@c161550b... - Original Message - From: Terje Slettebø [EMAIL PROTECTED] [...] BOOST_STATIC_ASSERT((\ boost::is_sameT, bool::value ||\ boost::is_sameT, int::value ||\ boost::is_sameT, double::value ||\ boost::is_sameT, std::string::value )); And this is still bulkier and less elegant than the two-line MPL solution. ;) Which could be even shorter yet if we could get away with template template parameters. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
[2003-01-09] David Abrahams wrote: Toon Knapen [EMAIL PROTECTED] writes: On Thursday 09 January 2003 12:12, Rene Rivera wrote: It's doesn't because I haven't had time to add it since the toolset appeared in Boost.Build ;-) I'll try and add ASAP. ... Question on this... Is it a possibility to install only the C compiler (cc) without the C++ compiler (aCC)? I'm asking to see if I can use the presense of aCC as an indicator that it's all installed. I guess cc is installed by default (like on all unices) and aCC is a commerical product. So cc is always there and aCC is'nt. Anyway, to compile jam_src you can use cc (with the -Ae option though) as you can see in the Jambase. Yeah, I think on Unix, defaulting to cc unless the script knows better is a god idea. It would've prevented this issue with getting aCC to build it in the first place. That's what the Perforce makefile does, too. OK that seems like a good idea. I'll add generic Unix cc toolset for building bjam. But for aCC, can one of you tell what the output of 'uname' is. At least I can test that in this case. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
From: William E. Kempf [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] OK, I've been looking at boost::filesystem_error. Here's my thoughts: boost::filesystem_error could be benefited by splitting it up into more exception types. I know this was suggested in the review, but don't know what the plan was in regard to this. In Boost.Threads case, so far we have need for 4 different errors: lock errors, resource errors, invalid arguments and unsupported errors. POSIX actually distinguishes out of memory errors (ENOMEM) from other lack of resource errors (EAGAIN), and POSIX functions can fail with an access denied error (EPERM). EPERM is not an issue (I believe) for anything in Boost.Threads (yet). But won't it become relevant when you add the thread attributes? MSDN doesn't really say whether it's possible to get ERROR_ACCESS_DENIED from thread functions but I wouldn't rule out the possibility. :-) But this doesn't really answer my basic question. Is it better to carry these error codes in a single exception, or have multiple exception types? I believe I answered this question below. No, it is not better to lump the different errors into a single exception. Separate exceptions are fine. (And is it useful to distinguish between memory and other resource errors?) This, I have no ready answer for... but when in doubt, do what POSIX does. If the reason for the failure can be identified by the type of the exception, there should be no immediate need to carry an OS error code, although you should consider the how do I translate this to a localized error message problem. Any suggestions on that one? I haven't really seen any viable answers provided yet. The easiest is to simply return e.g. boost::thread_resource_error from what(), but it might prove controversial. :-) No, this would be a step backward. IIUC filesystem_error is expected to evolve into a hierarchy as exception categories of interest to callers are identified. Then why *ever* carry the OS error code. The exception type would likely mirror every OS error code possible (with some folding, where appropriate, where I'd expect the precise code to be irrelevant). I don't understand what the OS error code would add. An error code (OS or portable) can be of help when one needs to catch all thread-related (or better yet, all error code providing) exceptions in a single catch clause. Usually this is only needed to report an error, though, so if thread exceptions provide some other common mechanism to identify the error (like specific what() values), carrying an error code won't be necessary. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: max min width etc.
On Thu, 09 Jan 2003 14:40:26 -0500, David Abrahams [EMAIL PROTECTED] wrote: Do you mean that we have implementations that don't provide the x_MANT_DIG macros? Otherwise the code is perfectly portable by 18.2.1.2 of the standard. No, I mean that those specializations might not be portable to all compilers. Remember that this file is for broken implementations to begin with. Odd. Because detail/limits.hpp itself uses similar specializations. Anyhow, we can't know before trying :-) If you agree I'll boostify the templates I've attached with the initial post, and add something (like 'digits' above) for floating points too. If that works I'll send (without committing) a new detail/limits.hpp that makes use of them. Whether we can then commit the new version of detail/limits.hpp depends on whether we can use my new stuff in the boost release. I'm willing to propose it for a new library or for integrating it with Daryle's integer library, no problem. The important thing is that we have clean, portable, maintainable code, which is an advantage for everybody. For instance, wandering through the boost code this morning I've found that several libraries either have their own solution, in the detail namespace, to numeric_limits problems (e.g. cast.hpp) or include numeric_traits.hpp which, in turn, duplicates much of the code. I think this is the sort of proliferation we should avoid. All these 'ad hoc' solutions could simply be removed in favor of the new templates, with advantage of maintainability, source code size and maybe compile speed too. I know there's reluctance to touch something that works, but I think at some point it becomes the best long term solution. It's obvious that I don't want to force anyone either, so if you all think I'm a madman, or a code purity obsessed, feel free to tell me! :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] What is MPL anyway?
Disclaimer: I'm not an MPL expert, but I think I get the gist of it. Martijn van der Lee [EMAIL PROTECTED] writes: Hi, I've been following the discussion on a HelloWorld for the MPL framework with great interrest, in the hope of understanding what this MPL thing really is, sadly enough, I am no further than I was a week ago. Don't worry, it took me a while to wrap my head around it, too. To me, MPL is as tough or tougher than generic programming and the STL was 5 years ago. It's a new perspective that we're not used to. Could anybody please explain what MPL is, what it does, why I should wish to use it, when I should use it and why it is better than the alternative solutions that may exist for the problems the MPL was meant to solve? Firstly, are you familiar with the concept of meta programming? In a nutshell, meta programming is writing programs to create or modify other programs (possibly recursively including other meta-programs). At its very simplest, you could consider search and replace on source files meta-programming. Breifly, consider native and external meta-programming. Writing a Perl script to modify C++ source files would be external. In C++, templates provide a native meta-programming facility. The upshot of native facilities: everybody can use them; the downside: native facilities can be limiting. In the specific case of C++, it turns out that some very clever (and rather non-obvious) use of templates can do some amazing things. Spirit and Lambda are libraries that mask cool template wizardry to make useful tools accessible. So, just like lambda makes writing lambda functions more accessible, MPL makes writing meta programs more accessible. In a sense, Why use MPL? boils down to, Why meta-program? I'll let the STL stand as an answer to that question. However, templates provide a somewhat limited meta-programming model. Since C++ is here to stay, we may as well make the most of what we have. MPL exploits the same template mechanisms that made the STL possible and develops a substantial compile time programming model. For actual examples, refer to the documentation that Dave mentioned. As to why you should use it: it is safer, more robust, more effecient, more flexible, etc etc than anything you are likely to write in a reasonable time. This is true of any good library. When you should use it it depends on what you do. Writing generic, reusable components is a good start. I expect that once I am comfortable with it, though, I will start using it in places I wouldn't anticipate now. Is there any problem for which MPL is the ideal (if not the only) solution and are there cases in which MPL is a clear winner over standard C++ code? Like any library, use it when you like the abstractions it provides and don't mind the design trade-offs. I'm sure you Boost guys have created as wonderful a tool with MPL as you have with some of your other libraries but at the moment it just seems like a really complicated way of doing things. If performance is the only reason for choosing MPL than I doubt whether it would outweight the added development effort. Is the STL written only for performance reasons? Did you fight tooth and nail against iterators because they were a really complicated way of doing things? Do you appreciate them now? Make it as simple as possible, and no simpler. I think MPL scores very well here, because the complexity it masks is mind-numbing. Without MPL or something like it, mere mortals would never attempt the things it does. Cheers- Augustus __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )
From: David B. Held [EMAIL PROTECTED] Paul Mensonides [EMAIL PROTECTED] wrote in message 000901c2b823$1e7f4aa0$8c00a8c0@c161550b">news:000901c2b823$1e7f4aa0$8c00a8c0@c161550b... From: Terje Slettebø [EMAIL PROTECTED] [...] BOOST_STATIC_ASSERT((\ boost::is_sameT, bool::value ||\ boost::is_sameT, int::value ||\ boost::is_sameT, double::value ||\ boost::is_sameT, std::string::value )); And this is still bulkier and less elegant than the two-line MPL solution. ;) I agree. I had actually missed Dave Abrahams (lastname used, as there's a lot of Dave's here. :) ) solution, but I found it, now. I think was an elegant way of doing it. And, yeah, I didn't think of that you don't need backslashes when _calling_ a macro, only when defining it. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Next revision of boost::thread
On Thu, Jan 09, 2003 at 01:31:28PM -0500, William E. Kempf wrote: From: Peter Dimov [EMAIL PROTECTED] From: William E. Kempf [EMAIL PROTECTED] From: Peter Dimov [EMAIL PROTECTED] I think that a reasonable requirement that we already mentioned several times is that the ID should be CopyConstructible, Assignable and LessThanComparable, for use in sets/maps. Should it truly be LessThanComparable, or should it follow the design of std::type_info with a before() method? Something that meets the requirements stated above can be used in std::mapK, V You can do the same with std::type_info by supplying a template parameter other than the default std::less. I understand this need, and I understand how simple it is when you truly are LessThanComparable (and lean that direction myself). I just want to make sure that someone isn't going to argue that we should have followed the type_info design, since there's no true ordering for this type. The real problem is the lack of a hash table library. AFAIK, there is no use of this type of ordering except for use in std::map, std::set. However, a tree is the wrong data structure -- tree operations (insert, find) are more expensive (O(log N)) than hash table operations (average case constant) assuming a good hash function, and the only reason to use a tree is the ordering, which is not used. Note that in order for thread to be usable in a hash table, a hash function would have to be provided or a thread id exposed. - Jeremy Maitin-Shepard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [signals] Minor doc bug?
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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problem with boost::char_separator
I have a minor complaint about the boost::char_separator class used in the tokenizer library. In its constructor it takes several const char *'s as parameters. This makes it difficult if I want to pass std::string's in. I'm not sure if the following code is safe: std::string getSeparatorChars(); boost::char_separatorchar mySeparator(getSeparatorChars().c_str()); Would it be possible to add a constructor to char_separator to take std::string's? Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Next revision of boost::thread
Peter Dimov wrote: From: William E. Kempf [EMAIL PROTECTED] (Remember that the new thread design is Copyable and Assignable.) That's news to me. :-) http://lists.boost.org/MailArchives/boost/msg41451.php class BOOST_THREAD_DECL thread : private noncopyable Not only to you. http://groups.google.com/groups?selm=3E1C9A86.30F0FF41%40web.de (Subject: Re: Next revision of boost::thread) This is a sort of FYI with just a few comments added. The OP can be found somewhere-in-the-moderated-boost-universe. class BOOST_THREAD_DECL thread : private noncopyable pthread_t IS copyable. The C++ version just ought to be thread_ptr/joinable_thread_ptr (current_thread_ptr aside for a moment). regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Call for regression test volunteers
At 03:29 PM 1/9/2003, Rene Rivera wrote: Speaking of that... What are the requirements for getting the filesystem code to compile? I'm trying to get GCC2.95.3 on OpenBSD to compile it for the regression testing. Is there a specific version of GCC required? Or would using STLport be sufficient? The only other Boost code Filesystem uses is a couple of the smart pointers plus iterator_adaptors.hpp. It normally doesn't stress a compiler at all, other than maybe iterator_adaptors.hpp. If push came to shove I could remove the use of iterator_adaptors.hpp. But I would be surprised if even older versions of GCC had problems with filesystem code. The other possibility for any system having compiler problems would be to download a recent version of GCC. I'm about as makefile averse as anyone, but must say that building gcc is painless even on Windows. Presumably it is even easier on UNIX systems. There are also binaries available for many systems. That way you will have at least one decent compiler and library available. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Call for regression test volunteers
At 03:44 AM 1/9/2003, Darryl Green wrote: I don't know what the restrictions are but it might be worth looking at http://testdrive.hp.com which claims to offer alpha, itanium, PA-RISC, StrongARM and x86 systems running BSD, HP-UX, Linux, OpenVMS and Tru64: Interesting, but it looks more oriented to quick tests than something like running the full Boost regression tests on a regular basis. Still, they might consider Boost a special case because Boost represents a whole community of developers rather than just one person or company. If someone wants to try to work with testdrive.hp, maybe give it a try and report back your experiences. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread
At 02:59 PM 1/9/2003, William E. Kempf wrote: From: Beman Dawes [EMAIL PROTECTED] I'm not saying Boost.Threads should take exactly the same approach, but I'd rather not see a lot of optional/conditional features to support operating systems other than those two O/S families. Well, everything that's optional in what I proposed for Boost.Threads (so far) happens to also be optional on POSIX (and by using the same conditional compilation scheme). So, don't provide Boost.Threads support for POSIX operating system flavors which don't provide important optional POSIX features. Do any of the important flavors of POSIX systems not provide these options? Remember, too, that you don't have to specify everything. You can leave it up to the implementor to decide what to do on a crippled operating system. I have a suspicion that is what the Standards committee may do with a lot of thread related changes that we always assumed would go into the core language execution model - don't mention the details, and just expect the library implementor to make it all work correctly in the eyes of users. Just as is done with the external effects of I/O operations now. People will be afraid to use Boost.Threads if they think that even on a fully-feature operating system some Boost.Threads features may not be available, or the features may be available with one compiler but not another. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: How to do this in with boost -- assert(typeid(T)==typeid(bool) )
Daniel Frey [EMAIL PROTECTED] writes: On Thu, 09 Jan 2003 19:28:17 +0100, David Abrahams wrote: typedef mpl::vectorbool,int,double,string legal_types; BOOST_STATIC_ASSERT((mpl::containslegal_types,T::value)); Now that's elegant! I think I should have a look at the MPL soon :)) One question: 'contains' seems to have the problem that it's not very obvious whether it takes the 'vector' as first or second argument. Is it possible to add a member function like this: typedef mpl::vector bool, int, double, std::string legal_types; BOOST_STATIC_ASSERT( legal_types::contains T ::value ); Possible but not desirable, IMO. Contains is a generalized sequence algorithm like std::find. -- 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: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
Paul Mensonides [EMAIL PROTECTED] writes:
Which could be even shorter yet if we could get away with template
template parameters.
We can and do.
How would you imagine it would be spelled with TTP?
You asked for it. ;) Beware, this is the work of a sick mind!
Basically, this implementation reduces the sample to an inline fold of the
form:
operation::stepX::stepY::stepZ::[ value | type ]
...where 'operation' is the type of operation and where '[ value | type ]'
is either 'value' or 'type'.
Ultimately, we get something similar to this (with the help of a macro to
handle the ::template that is sometimes necessary):
is_presentT
item bool
item int
item double
item std::string
::value
Also, the same underlying implementation is used to build
a completely linearized typelist mechanism:
typedef gen_typelist
item char
item signed char
item unsigned char
item short
item unsigned short
item int
item unsigned
item long
item unsigned long
::type integral_types;
Here is the implementation (from scratch):
// identity: yields its template argument as a typedef
templateclass T struct identity {
typedef T type;
};
// map_integral: everyone's favorite plus a typedef
//representing the type of its stored value
//(this is just a hack because I was too lazy to detect it,
//and you can't do it with partial specialization because
//of the dependent second parameter.)
templateclass T, T V struct map_integral : identityT {
static const T value = V;
};
templateclass T, T V const T map_integralT, V::value;
// has_member_value: metafunction that returns
// true if its template argument has a nested value
// named 'value'
templateclass T struct has_member_value {
private:
templatelong struct helper;
templateclass U static char check(helperU::value*);
templateclass U static char ( check(...))[2];
public:
static const bool value = sizeof(checkT(0)) == 1;
};
templateclass T const bool has_member_valueT::value;
namespace detail {
// fold_nil: placeholder for no previous state
// it is used by fold_right
struct fold_nil;
// fold_helper: the opposite of fold_nil
// it stores state needed for fold_right to reverse
// its the element order and use fold_left
templateclass parent, class element struct fold_helper { };
// fold_reversal: metafunction that participates in
// building a reversed list of elements.
templateclass build, class struct fold_reversal;
// specialization for no previous state
templateclass build struct fold_reversalbuild, fold_nil {
typedef build type;
};
// specialization otherwise
templateclass build, class parent, class element
struct fold_reversalbuild, fold_helperparent, element {
typedef typename fold_reversal
typename build::template stepelement, parent
::type type;
};
// value_if: yields a nested static constant if 'T' has
// a 'value' member. If so, 'T' must also have a member 'type'
// that denotes the 'type' of the static constant.
// This can be deduced, but I didn't feel like bothering to
// do it here. (This is the reason that map_integral above has
// a 'type' typedef.)
templateclass T, bool = has_member_valueT::value struct value_if { };
templateclass T struct value_ifT, true
: map_integraltypename T::type, T::value { };
} // detail
// the fold_left and fold_right meta-something-or-others
// perform an unraveled fold in a strange way:
//'fold_leftop, state, transform::stepX::stepY::stepZ::type'
//
//effectively yields:
//op(transform(Z), op(transform(Y), op(transform(X), state)))
//
// vice versa with fold_right.
//
// These 'metafunctions' contain a nested template 'step'
// which represents a fold step. These nested templates
// inject there own name via inheritance of their parent
// classes. This allows the syntax:
fold_left...::stepint::stepdouble
// etc.. I'm not sure if this is actually legal, but it works on Comeau
C++.
// If it isn't legal, I'd need some kind of jumper typedef that identifies
the
// base class, which would alter the final syntax to:
// fold_left...::stepint::base::stepdouble etc.
// ...which is trivial handled by local sugar macros anyway.
//
// the 'op' parameter is the fold operation, which is instantiated
// with the current element and the current state.
//
// the 'state' parameter is the initial state of the accumulation
//
// the 'transform' parameter is a simple way to modify each element
// however you like. The 'is_present' implementation uses this parameter
// with a partially bound 'is_same' metafunction, and uses a logical-or
// metafunction as the 'op' parameter. The 'identity' metafunction is
// the default and simply does nothing.
// fold_left
template
templateclass _element, class _state class op,
class state,
templateclass class transform = identity
struct fold_left {
[boost] spirit and compile speed
Hi, I assume this is the right place to post questions on Spirit now that it is part of boost! If not here, where? My question is about compile speed. Is there any way to speed it up or at least seperate it from the project? I have added 2 parsers to my code base and the compile time (VC6) has gone from 10 mins to 30mins :-( I considered building a lib but since it is templates almost all the code is in the header so I can't see the benefit Is there a method that works ??? Vin ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to do this in with boost -- assert(typeid(T)==typeid(bool) )
On Thu, 09 Jan 2003 19:28:17 +0100, David Abrahams wrote: typedef mpl::vectorbool,int,double,string legal_types; BOOST_STATIC_ASSERT((mpl::containslegal_types,T::value)); Now that's elegant! I think I should have a look at the MPL soon :)) One question: 'contains' seems to have the problem that it's not very obvious whether it takes the 'vector' as first or second argument. Is it possible to add a member function like this: typedef mpl::vector bool, int, double, std::string legal_types; BOOST_STATIC_ASSERT( legal_types::contains T ::value ); OK, this is just a quick thought. Sorry if it was discussed before, I'm just too lazy to search for it now... :)) Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
