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
template
void f(Result,T) {}
template
void f(Result,std::basic_string) {}
template
void f(std::basi
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:
"These systems are provided as a convenience for developers and systems
integrators
>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_TEMPLAT
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
> >
> >commercia
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 (re
>From: "Daniel Frey" <[EMAIL PROTECTED]>
> 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:
>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]; \
> > > /**/
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
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
> 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 con
> 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
> >>
> 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 an
> 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/
> 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 ... ?
> 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
>
> template
> void f(Result,T) {}
>
> template
> void f(Result,std::basic_string) {}
>
> template
> 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
>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 on
Toon Knapen <[EMAIL PROTECTED]> writes:
> 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 platform
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) \
>
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.
Why don't you take a look
"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.
--
David Abrahams
[EM
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 situat
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 se
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 info
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://li
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 f
> 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
> 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 infor
> 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 an
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 sta
> 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
> 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
"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
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
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
> 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
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: "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
"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: 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
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]>
[...]
> > 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
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
"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: "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
> 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: "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
[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
[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
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] 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
[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
"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:
>> > >>
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
> 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.
>
> Should it tru
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 th
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
>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
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
[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 #!/
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
> bool SetOption(COptionInfo& o, const char* key, const T& value)
> {
> assert( typeid(T)==typeid(bool)
> || typeid(T)==typeid(int)
> || typeid(T)==typeid(dou
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
"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.
>
> 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
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]>
> > > 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
> 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
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: "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
"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)
>
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:
- 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
> 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
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<
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
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
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
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
- 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
- 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: "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
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,
>
> 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
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
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 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
- 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
[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
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
> 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 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
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
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
1 - 100 of 133 matches
Mail list logo
