Re: [boost] Compiler status for GCC 3.3

- Original Message - From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Monday, June 30, 2003 3:55 AM Subject: Re: [boost] Compiler status for GCC 3.3 > Beman Dawes <[EMAIL PROTECTED]> writes: > > > [...] > > | But some of the problems are cle

[boost] Re: boost::filesystem::path bug?

Tim Russell wrote: boost::filesystem::path p; p = boost::filesystem::path(" .txt"); .// Three spaces Have you tried p = boost::filesystem::path(" .txt", boost::filesystem::native); as this is how I have to construct paths on Windows because of the \ separater. Maybe this will work for you

[boost] Re: Boost::thread feature request: thread priority

Look at the thread_dev branch of boost::thread in the CVS. There are many changes (including priority) that haven't been finalised yet. Hopefully they will make it into 1.31.0 whenever that will be released. Cheers Russell Maxim Egorushkin wrote: Hello, I've been missing a feature in the t

[boost] Re: Draft of new Boost Software License

Fernando Cacciola wrote: [...] > > > > > Motivated by A. Terekhov concerns, I think the license should, if at all > > > > > possible, expressely PROHIBIT anyone, including the copyright holder, > > > > > from patenting the covered Software and any implied intellectual production. > > > > > > > > T

[boost] Re: Draft of new Boost Software License

Beman Dawes wrote: [...] >// See accompanying license for terms and conditions of use. http://www.eclipse.org/eclipse/eclipse-charter.html "Licensing All contributions to the Eclipse Project must adhere to the Common Public License http://www.eclipse.org/legal/cpl-v10.html. Notwithsta

Re: [boost] Compiler status for GCC 3.3

[EMAIL PROTECTED] (Joerg Walter) writes: | - Original Message - | From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> | To: "Boost mailing list" <[EMAIL PROTECTED]> | Sent: Monday, June 30, 2003 3:55 AM | Subject: Re: [boost] Compiler status for GCC 3.3 | | | > Beman Dawes <[EMAIL PROTECTED]> w

Re: [boost] Re: Draft of new Boost Software License

Beman Dawes wrote: > > Let's see what the lawyers say before worrying too much about what > may be a non-issue. I'd like to add some of my concerns to the list. First of all let me say that I fully realize that we just got a ton of free legal advice and that I do appreciate the efforts of everyon

Re: [boost] DLL hell

It was a long thread about this issue ... Look in archive for the subject "Thread Lib and DLL" arround the date: 3/30/2003 - Original Message - From: Martin Bosticky To: boost Sent: Sunday, June 29, 2003 2:29 AM Subject: [boost] DLL hell Hello everybody,   I j

[boost] Problem with filesystem attributes

[Previously posted on Boost::Users (to no response); perhaps this is better forum??] Hiya, I've been attempting to try out the attributes code in the boost-sandbox, but am running into some snags using VC++ version 7 (that comes with VS .NYET). One simple goal here would be to discern whether a

Re: [boost] thread::current() ?

Philippe A. Bouchard said: > Hi there, > > I was wondering if you were planning to implement some static thread > & > thread::current() that returns the current thread id (& thread). That > would be really useful. Can't be done with the current non-copyable semantics. (BTW, I'm assuming you

Re: [boost] DLL hell

Martin Bosticky said: > Hello everybody, > > I just got the boost_1.30.0 version. Some libraries (like thread) > require use of a DLL. However I would like to avoid the DLL hell. From > looking at the output of the thread build it looks like a statically > linkable library is not available. > > Is

Re: [boost] Re: thread::current() ?

Philippe A. Bouchard said: > Howard Hinnant wrote: > >> On Saturday, June 28, 2003, at 02:43 PM, Philippe A. Bouchard wrote: >> >>> Hi there, >>> >>> I was wondering if you were planning to implement some static >>> thread & >>> thread::current() that returns the current thread id (& thread).

Re: [boost] Boost::thread feature request: thread priority

Maxim Egorushkin said: > Hello, > > > > I've been missing a feature in the thread library: managing a thread > priority. And, BTW, the class encapsulating stopwatch functionality with > a millisecond precision would be very useful. It would help writing more > portable programs (as boost::thread i

[boost] Re: Re: Draft of new Boost Software License

Peter Dimov wrote: > > I'd like also to point out that it seems to me that the old "in all > copies" form is better than the new one; the legal system is > sufficiently flexible > to reliably recognize a "copy" (i.e. a password protected RAR archive > of an mp3 encoded song). The new wording seem

Re: [boost] Re: Re: Draft of new Boost Software License

Ed Brey wrote: > Peter Dimov wrote: >> >> I'd like also to point out that it seems to me that the old "in all >> copies" form is better than the new one; the legal system is >> sufficiently flexible >> to reliably recognize a "copy" (i.e. a password protected RAR archive >> of an mp3 encoded song).

[boost] Re: Re: thread::current() ?

William E. Kempf wrote: [...] >> Thanks... but is it possible to obtain the initial address of the >> functor object portably, given the current thread object? > > No, and why would you want to? Especially since it will be a pointer > to a _copy_ of the functor? Because I would like to access s

[boost] Re: thread::current() ?

William E. Kempf wrote: > Philippe A. Bouchard said: >> Hi there, >> >> I was wondering if you were planning to implement some static >> thread & >> thread::current() that returns the current thread id (& thread). >> That would be really useful. > > Can't be done with the current non-copyable s

[boost] Re: Interest in multiindex_set? (again)

This looks fine in general. I've needed something like it so I'm intereseted on seeing this on boost. Some issues: (1) Why 'index' instead of 'key'? Associative containers use the term key instead of index, since index is typically related with random access instead of look up access. (2) I wou

[boost] CW8 on Mac OSX

I was looking at the regerssion testing and I noticed that there are no results for Metrowerks Codewarrior 8 on Mac OS X. Is there a problem that leads to not including this result or is there just a lack of a test platform? If the problem is the lack of a test platform, I currently run CW8.3 (

[boost] Re: Draft of new Boost Software License

Peter Dimov wrote: > > Ed Brey wrote: > > Peter Dimov wrote: > >> > >> I'd like also to point out that it seems to me that the old "in all > >> copies" form is better than the new one; the legal system is > >> sufficiently flexible > >> to reliably recognize a "copy" (i.e. a password protected RA

[boost] Re: Boost::thread feature request: thread priority

"William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Priorities are implemented, but still undergoing design changes, in the > thread_dev branch. The timer, if I understand what you want, is trivial > to implement portably with the current Boost.Threads interfaces, bu

Re: [boost] Compiler status for GCC 3.3

At 06:06 AM 6/30/2003, Gabriel Dos Reis wrote: >| I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond already >| reported the issue, Paul also analyzed it here >| http://groups.yahoo.com/group/ublas-dev/message/676 >| >| In essence: setting -fabi-version=0 should solve the problem.

Re: [boost] Re: Re: thread::current() ?

Philippe A. Bouchard said: > William E. Kempf wrote: > > [...] > >>> Thanks... but is it possible to obtain the initial address of the >>> functor object portably, given the current thread object? >> >> No, and why would you want to? Especially since it will be a pointer >> to a _copy_ of the fun

[boost] Re: Draft of new Boost Software License

Alexander Terekhov wrote: >>> * Suppose I create a product containing executables that make use of >>> compiled boost libraries (only - no uncompiled boost source). I >>> consider the CD and its content to be the "work" and I copyright it >>> as such. It is a work derived from the Software (Boost

Re: [boost] Re: Boost::thread feature request: thread priority

Maxim Egorushkin said: > > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> Priorities are implemented, but still undergoing design changes, in >> the thread_dev branch. The timer, if I understand what you want, is >> trivial to implement portably with the cur

[boost] Re: Re: Re: thread::current() ?

William E. Kempf wrote: [...] > As already pointed out, to associate data with a thread you use > thread_specific_ptr. BTW, you still have to remember that the > functor is copied, and data passed to/in the functor is not > considered part of the thread in any event. Ok, how do you find out the

[boost] Re: Problem with filesystem attributes

Fanta, Richard wrote: > I've been attempting to try out the attributes code in the boost-sandbox, > but am running into some snags using VC++ version 7 (that comes with > VS .NYET). i am really glad that your are looking at this code. (un)fortunately i dont have vc++ available and did not implement

[boost] Re: Interest in multiindex_set? (again)

We may use this to provide a better table implementation for the Relational Template Library, we are currently working on. Right now we are using a sorted vector instead of a set, to implement our relational tables, because set doesn't allow us to search on a prefix of a key. Like if a table is i

[boost] Re: Interest in multiindex_set? (again)

Arkadiy wrote: > Right now we are using a sorted vector instead of a set, to implement > our relational tables, because set doesn't allow us to search on a > prefix of a key. Like if a table is indexed on a, b, c, we are not > able to use equal_range on a, b with the set. I was able to successful

Re: [boost] Re: Re: Re: thread::current() ?

Philippe A. Bouchard said: > William E. Kempf wrote: > > [...] > >> As already pointed out, to associate data with a thread you use >> thread_specific_ptr. BTW, you still have to remember that the >> functor is copied, and data passed to/in the functor is not >> considered part of the thread in a

[boost] Re: Re: Boost::thread feature request: thread priority

"William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Speaking about the timer I ment something like that: > > > > typedef int milliseconds; > > > > class stopwatch > > { > > public: > > stopwatch() > > : started_(::GetTickCount()) > > {} > > > > m

Re: [boost] Re: Re: Boost::thread feature request: thread priority

Maxim Egorushkin said: > > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> > Speaking about the timer I ment something like that: >> > >> > typedef int milliseconds; >> > >> > class stopwatch >> > { >> > public: >> > stopwatch() >> > : started_(::G

Re: [boost] CW8 on Mac OSX

on 6/30/03 10:58 AM, John Phillips at [EMAIL PROTECTED] wrote: > I was looking at the regerssion testing and I noticed that there are no > results for Metrowerks Codewarrior 8 on Mac OS X. Is there a problem that > leads to not including this result or is there just a lack of a test > platform? >

[boost] Re: Re: Re: Re: thread::current() ?

William E. Kempf wrote: > > Philippe A. Bouchard said: >> William E. Kempf wrote: >> >> [...] >> >>> As already pointed out, to associate data with a thread you use >>> thread_specific_ptr. BTW, you still have to remember that the >>> functor is copied, and data passed to/in the functor is not >

[boost] Re: Re: Re: Boost::thread feature request: thread priority

"William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Now, what you're describing sounds more like this: > > class timer > { > public: >timer(boost::function on_event, int ms, bool repeat=false); > }; > > Which do you really want? Yes, this is what I needed. > >

[boost] Filtered stream-buffer, part 2

For the past few weeks, some posters were talking about streambufs that can decorate another stream buffer. I wrote up a second version at . It moves the calling functions to the stream buffer class. It adds example filtering functi