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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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];
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
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.
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:
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
[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
[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
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
[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
[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
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
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
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
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
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
___
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.
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
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
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
[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
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
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)
||
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
{
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,
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
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
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)
||
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
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
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
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)
||
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]
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 ||
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
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
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
- 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
[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
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
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
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
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
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)
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,
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
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
[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
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
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] *
- 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
[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
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.
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
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
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 ||\
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
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:
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
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.
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?
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
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
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
- 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. ;)
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
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
98 matches
Mail list logo
