On Thursday 09 January 2003 22:40, Rene Rivera wrote:
> [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?
from the man pages of aCC/cc :
-AeIn aC++, invokes
- 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
[2003-01-09] Rene Rivera wrote:
>[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 ;-)
>>
Daniel Frey <[EMAIL PROTECTED]> writes:
> On Thu, 09 Jan 2003 19:28:17 +0100, David Abrahams wrote:
>
>> typedef mpl::vector legal_types;
>> BOOST_STATIC_ASSERT((mpl::contains::value));
>
> Now that's elegant! I think I should have a look at the MPL soon :))
> One question: 'contains' seem
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,
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 orient
At 09:40 PM 1/9/2003, Toon Knapen wrote:
>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
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
>sufficie
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 on
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();
Under: Passing values to and from slots in tutorial.html, it looks
like the old syntax is being used:
boost::signal sig;
The tables are correct. Only the references in the text appear
wrong.
Dave
___
Unsubscribe & other changes: http://lists.boost
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
> > >
>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_same::v
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
- Original Message -
From: "Thorsten Ottosen" <[EMAIL PROTECTED]>
> "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
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 por
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
- 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$1
[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
[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 m
"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-consul
> 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 wha
On Thu, 09 Jan 2003 19:28:17 +0100, David Abrahams wrote:
> typedef mpl::vector legal_types;
> BOOST_STATIC_ASSERT((mpl::contains::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 wh
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 d
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> 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::fil
"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_same::value ||\
> boost::is_same:
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
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
> 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
- Original Message -
From: "Terje Slettebø" <[EMAIL PROTECTED]>
> > You can just do this as well:
> >
> > BOOST_STATIC_ASSERT(
> > ( boost::is_same::value ) ||
> > ( boost::is_same::value ) ||
> > ( boost::is_same::value ) ||
> > ( boost::is_same::value );
> > )
> >
> > In
>From: "Paul Mensonides" <[EMAIL PROTECTED]>
> 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:
> > >>
> > >> te
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 rega
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 PROTE
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 filesy
> 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 PROTECT
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 as
[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
- 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
> >> bool SetOption(COpti
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 previou
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
>> bool SetOption(COptionInfo& o, const char* key, const T& value) {
>> BOOST_STATIC_ASSERT( boost::
At 09:53 AM 1/9/2003, William E. Kempf wrote:
>> 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
> From: Beman Dawes <[EMAIL PROTECTED]>
> 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 compilat
Terje Slettebø <[EMAIL PROTECTED]> writes:
>>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,
>
- Original Message -
From: "Terje Slettebø" <[EMAIL PROTECTED]>
> > 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 t
- Original Message -
From: "Terje Slettebø" <[EMAIL PROTECTED]>
> Looks good. What should we call it? size_descriptor, like here?
I'm not suggesting you do it exactly that way. Rather, I'm just suggesting
that you don't use the pp-lib for something so trivially solved by the
template mec
- Original Message -
From: "Daniel Frey" <[EMAIL PROTECTED]>
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 the
Gennaro Prota <[EMAIL PROTECTED]> writes:
> 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, Davi
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 l
On 09 Jan 2003 18:02:51 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
>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
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
Daniel Frey wrote:
Uhm... don't know about MPL, but isn't this a good example for
type_traits? Something like:
template
bool SetOption(COptionInfo& o, const char* key, const T& value)
{
BOOST_STATIC_ASSERT( boost::is_same< T, bool >::value ||
boost::is_same<
> From: "Stefano Delli Ponti" <[EMAIL PROTECTED]>
> I would dare to suggest that the "basic" thread class, if the thread concept
> is supported, had _all_ of its methods available and implemented (or dummy)
> for _all_ the platforms (!).
> I would be inclined to have an "advanced" attribute like t
- Original Message -
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]>
> > > > > "Willia
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:
"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
>> bool SetOption(COptionInfo& o, const char* key, const T& value)
>> {
>> assert( typeid(T)==typeid(bool)
>
> 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
> > > LessT
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
> 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 misse
> 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
> > > Les
Derek Ross wrote:
>
> Hello,
>
> I'd like to convert this run-time assertion to a compile time MPL check:
>
> template
> bool SetOption(COptionInfo& o, const char* key, const T& value)
> {
> assert( typeid(T)==typeid(bool)
> || typeid(T)==typeid(int)
> || typeid(T)==type
> 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 ha
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.
>
"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,
>
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
From: "Derek Ross" <[EMAIL PROTECTED]>
> Hello,
>
> I'd like to convert this run-time assertion to a compile time MPL check:
>
> template
> bool SetOption(COptionInfo& o, const char* key, const T& value)
> {
> assert( typeid(T)==typeid(bool)
> || typeid(T)==typeid(int)
> || typeid(T)==typeid(dou
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
[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 #!/
Hello,
I'd like to convert this run-time assertion to a compile time MPL check:
template
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 c
>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 n
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
"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 th
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"
__
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 tru
> 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 o
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
"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:
>> > >>
[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
>>> pi
[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 pla
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 p
[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 obje
[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
> 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
> 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 ex
> 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 wo
"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
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
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 compar
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 qu
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 pref
"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
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
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 p
> 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
OK, I've been thinking about the issue of conditional compilation brought up by the
boost::thread proposal. I see to complaints involved with conditional compilation, as
used there:
1) It's generally agreed that the PP should be avoided because it doesn't respect
namespace boundaries (among ot
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 we
"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
> 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 saf
> 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 eas
"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 sta
1 - 100 of 133 matches
Mail list logo
