Daniel Frey wrote:
On Wed, 12 Feb 2003 18:37:51 +0100, Markus Schöpflin wrote:
Attached is a small patch for function_base.hpp. On line 302,
there is a T missing.
Just a stupid question: Why is it "missing"? What is this patch
supposed to fix?
This was the original source:
template struct
The following is a sketch of a potential use case for the newly-accepted and
already very useful 'optional' class.
Suppose you have a pure RAII guard/locker which unconditionally does its
job:
struct RAII_lock
: boost::noncopyable
{
RAII_lock(entity& e);
~RAII_lo
Hi, everybody
Today I committed second revision to Boost.Test library. I am not planning
any more code changes in this release. If I have time I will try to reflect
changes made in revision one and two in documentation (Release notes with
changes log will be present in any case). Here is approxima
Markus Schöpflin wrote:
>
> Daniel Frey wrote:
>
> > On Wed, 12 Feb 2003 18:37:51 +0100, Markus Schöpflin wrote:
> >
> >> Attached is a small patch for function_base.hpp. On line 302,
> >> there is a T missing.
> >
> > Just a stupid question: Why is it "missing"? What is this patch
> > supposed t
Aleksey Gurtovoy writes:
>
> The following is a sketch of a potential use case for the newly-accepted and
> already very useful 'optional' class.
>
> Suppose you have a pure RAII guard/locker which unconditionally does its
> job:
>
> struct RAII_lock
> : boost::noncopyable
Hi,
The "for-each" in mpl is used to generate codes, which apply some function to each
element in a sequence. Well, I wonder if there could be more generators, "select"(a
better name?) for example.
"select" is used to apply some function to a specified element in a sequence(the case
in the FS
Daniel Frey wrote:
Markus Schöpflin wrote:
When posting the patch, I didn't even realize that the code was legal
and that this is a problem with VACPP6. And the aCC workaround fixes
the problem for VA, too.
This was the original source:
template struct enable_if;
---^
V
> > Having internal properties means the mapping edge_descriptor -> 'edge
> > color' and vertex_descriptor -> 'vertex color' is needed.
>
> I don't understand what you mean,
I'm using customized-internal properties that do not have 'color'
information. Now, algorithms (undirected_dfs() for examp
Markus Schöpflin wrote:
>
> Daniel Frey wrote:
>
> > Markus Schöpflin wrote:
>
> >>This was the original source:
> >>
> >>template struct enable_if;
> >>---^
> >>
> >>Visual Age doesn't like this, it needs a name here.
> >
> > ^^
> >
> > Ah, that's the reason. But g
I've noticed that toolsets for the Sun WorkShop C++ compiler, both with and
without STLport support have appeared in boost/tools/build/.
Does anyone on the list have any indication as to when this compiler will
make it to "fully supported" status?
I've seen previous mailings that suggest that sup
I was just looking at the win32 implementation of the
condition variable class in the thread library and
noticed something odd. In version 1.7 of
condition.cpp, there is a bug fix for
condition::notify_one. At the beginning of the
function, a mutex is acquired, but not all control
paths resulted
Hi there,
currently, boost.function and Visual Age don't get along very well.
Unfortunately, I have no idea where to start in order to fix the problems.
Could anyone please take a look at the regression logs and give me a
hint where to start?
Some examples of the error messages are:
"/home/au
Pavel Vasiliev wrote:
[...]
> pthread_refcount_enroll_one() (== "increment_if_non_zero()") may be
> emulated in Win32 (using InterlockedCompareExchange()).
Yeah, archaic Win95(/Intel386) aside. AFAIK, InterlockedCompareExchange
(/cmpxchg) "Requires Windows 98 or later" (/486+).
>
> The problem
Pavel Vasiliev wrote:
[...]
> Interestingly. pthread_refcount_enroll_one() in your implementation
> really eliminates need in any explicit locking.
I hope so. Yeah, as you wrote ...problem is much the same:
"test and conditionally increment" .
>
> Your code showed also that I overlooked the m
vladimir josef sykora wrote:
> > > Having internal properties means the mapping edge_descriptor -> 'edge
> > > color' and vertex_descriptor -> 'vertex color' is needed.
> >
> > I don't understand what you mean,
>
> I'm using customized-internal properties that do not have 'color'
> information. N
I noticed that boost::lambda library has a complete implementation of
the type inference for the operator results (i.e. inferring that char +
int returns an int). I would really like to be able to use that in my
code, however, the Lambda implementation is currently undocumented.
What's the entr
Boosters,
with one (1) day before the branch for release, there's still time to get
those copyright statements in place without needing to merge and tag the
files - please try to add them as soon as possible. As we've just recently
concluded that copyright statements are needed for the various buil
-Original Message-
From: Gary Gale [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 10:35 AM
To: Boost Mailing List ([EMAIL PROTECTED])
Subject: [boost] Status of Boost, Solaris and Sun WorkShop 6 Compiler?
I've noticed that toolsets for the Sun WorkShop C++ compiler, both w
On Wednesday 12 February 2003 17:38, Rene Rivera wrote:
> [2003-02-11] Beman Dawes wrote:
>
> >At 09:01 AM 2/10/2003, Toon Knapen wrote:
> >
> > >I think the traffic-light colors should suffice. I find adding black
> > >confusing.
> >
> >I agree. The traffic-light metaphor falls apart when you add
Hello,
I am implementing an algorithm that requires a heap.
In my algorithm, I need to do two operations, similar
to that required by Dijkstra's algorithm:
1. Use a secondary array to index the nodes of the
heap. This is so that a node in the heap can be found
in constant time.
2. Decrease the k
At 11:38 AM 2/12/2003, Rene Rivera wrote:
>[2003-02-11] Beman Dawes wrote:
>
>>At 09:01 AM 2/10/2003, Toon Knapen wrote:
>>
>> >I think the traffic-light colors should suffice. I find adding black
>> >confusing.
>>
>>I agree. The traffic-light metaphor falls apart when you add black.
>
>Yea, but bl
> Ah, that's the reason. But given my recent discomfort about
> unmaintainable code, look at it again:
>
> # if BOOST_WORKAROUND(__HP_aCC, <= 33900)
> template struct enable_if;
> # else
> template struct enable_if;
> # endif
>
> Does this really makes sense? Shouldn't we jus
> I'm newish to C++ and very new to boost.
>
> I've just tried to build the object library for regex
> in Borland Builder 5 Pro on Windows XP. I ran the make
> on bcb5, got no errors at that stage, but when I try to compile
> my app within the Builder IDE I get a fatal linker error:
> Cannot load
> At 10:07 PM 2/7/2003, Dave Gomboc wrote:
> >> I suggest adding another boost defect: BOOST_BROKEN_ADL (or similar)
> >
> >How about BOOST_LIBRARY_IMPL_VULNERABLE_TO_ADL? It's not that the
> >compiler's ADL implementation is broken, it's that the library
> >implementation isn't protected aga
> So, Let introduce one. I need something for coming release.
Done: it's called BOOST_HAS_SIGACTION
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> >The two defects are:
> >The various std::isdigit, islower, isalnum etc. convenience functions
> >will not compile.
>
> Please could you post a concrete example?
#include
int main()
{
return std::isupper('c', std::locale()); // error overload not found.
}
but can be fixed with:
#include
> >> Could we subordinate BOOST_HAS_LONG_LONG to
> >> defined(BOOST_ENABLE_LONG_LONG)?
> >
> >Even if we're willing to break user code and tell them they have to
> >define that macro explicitly, we'd have to be very careful; we have
> >tests that exercise long long and we don't want to break those
I notice that the links to the source files and library documentation in the
regression test tables are broken: should they be directed to www.boost.org
rather than sourceforge.net/boost ?
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
__
boost::is_polymorphic documentation is written in a slightly larger font
than the rest of the items and there's also a spelling error ('magority')
in the following text.
/Fredrik
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinf
On Thursday 13 February 2003 04:38 am, Daniel Frey wrote:
> Ah, that's the reason. But given my recent discomfort about
> unmaintainable code, look at it again:
>
> # if BOOST_WORKAROUND(__HP_aCC, <= 33900)
> template struct enable_if;
> # else
> template struct enable_if;
> #
That's exactly what happened!
What an a**e!
Thanks for replies
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of John Maddock
Sent: 13 February 2003 11:11
To: Boost mailing list
Subject: Re: [boost] Linker trouble when building regex lib
> I'm newi
Dave Gomboc wrote:
>
> > Ah, that's the reason. But given my recent discomfort about
> > unmaintainable code, look at it again:
> >
> > # if BOOST_WORKAROUND(__HP_aCC, <= 33900)
> > template struct enable_if;
> > # else
> > template struct enable_if;
> > # endif
> >
> > Does t
On Thursday 13 February 2003 01:01 am, Lin Xu wrote:
> Attached is a prelimary replacement for function_traits.hpp. (When should I
> use the files section on yahoo? When should I attach? copy and paste code
> inline?)
If it's really short, post a context diff. If it's short, attach. If it's
longe
On Thursday 13 February 2003 06:12 am, Markus Schöpflin wrote:
> Hi there,
>
> currently, boost.function and Visual Age don't get along very well.
> Unfortunately, I have no idea where to start in order to fix the problems.
>
> Could anyone please take a look at the regression logs and give me a
>
> >
> > I'm using customized-internal properties that do not have 'color'
> > information. Now, algorithms (undirected_dfs() for example) need to map
> > each vertex and edge to its respective color, so in the previous case,
the
> > maps must be passed as arguments to the algorithms (OTOH, if I we
Alexander Terekhov wrote:
[...]
> Pavel Vasiliev wrote:
>> I place here the corrected version of my previous code.
> Well,
> Given: two threads -- A and B,
>thread A has "strong" one,
>thread B has "weak" one,
>strong_count == 1, weak_count == 2.
> Thread A, in release
- Original Message -
From: "Anthony Williams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, February 13, 2003 7:05 AM
Subject: Re: [boost] 'optional' - request for extension
> Aleksey Gurtovoy writes:
> >
> > The following is a sketch of a potential us
Douglas Gregor wrote:
> We've discussed making boost::ref/boost::cref work for arbitrary
> functions
> objects before. I just committed a version of ref.hpp that supports
> this
> ability to the sandbox. With this code, you can write:
>
> std::transform(c.begin(), c.end(), out, boost::ref(f));
>
On Thursday 13 February 2003 10:12 am, Peter Dimov wrote:
> > --Compatibility--
> > This version of ref.hpp is backwards-compatible with the existing
> > version of
> > ref.hpp on a compiler that can handle the new ref.hpp (needs partial
> > specialization and proper SFINAE handling). At so
Hi
Consider this case of boost::mem_fn applied to data members and in
association with boost::iterator_adaptors.
#include
#include
struct foo {
int m_data;
// ..
};
std::vector data;
...
boost::make_projection_iterator(data.begin(), boost::mem_fn(&foo::m_data))
The line above "should"
I'm just a lurker and maybe I missed something, but what you describe
sounds like SCTP (RFC 2960 - the 'other' stream protocol). If the generic
socket library supported SCTP, would that meet your requirements?
"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:
> Hi, everybody
>
> Today I committed second revision to Boost.Test library.
Wow, is that a good idea one day before we branch for release?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
__
Gary Gale <[EMAIL PROTECTED]> writes:
> I've noticed that toolsets for the Sun WorkShop C++ compiler, both with and
> without STLport support have appeared in boost/tools/build/.
>
> Does anyone on the list have any indication as to when this compiler will
> make it to "fully supported" status?
>
Title: Message
Hello,
Did somebody
manage to link shared library with HP aCC and run the jgrep example
?
It links but the
excutable crashed !! (OK with the library is static built)
Thanks.
Pascal.
Sure.
In NR they propose to do pretty much what
you are doing, but they made one step further to avoid sin/cos calls.
Here is the code from NR:
if (iset == 0) { //We don't have an extra
deviate handy, so
do {
v1=2.0*ran1(idum)-1.0;
//pick two uniform numbers in the s
> > Hi, everybody
> >
> > Today I committed second revision to Boost.Test library.
>
> Wow, is that a good idea one day before we branch for release?
I should have done it week ago, but was really sick. Anyway, It does not
contain anything that should break backward compartibility.
Gennadiy.
_
On Thu, 13 Feb 2003 12:01:47 -, "John Maddock"
<[EMAIL PROTECTED]> wrote:
>I'm not sure if this is due to a compiler bug or what, but basically it's
>due to the way that STLport is set up: the names are declared in namespace
>stlport (which is an alias for either _STL or _STLD depending upon t
Rene Rivera <[EMAIL PROTECTED]> writes:
> [2003-02-11] Beman Dawes wrote:
>
>>At 09:01 AM 2/10/2003, Toon Knapen wrote:
>>
>> >I think the traffic-light colors should suffice. I find adding black
>> >confusing.
>>
>>I agree. The traffic-light metaphor falls apart when you add black.
>
> Yea, but b
On Thu, 13 Feb 2003 11:52:59 -, "John Maddock"
<[EMAIL PROTECTED]> wrote:
[..]
>I hear what you say, but I keep coming back to: this is largely an Intel
>compiler specific problem,
No, it's a matter of not making a silent use of non standard features.
>and most users really do expect their l
Stats are definitely a must-have for Boost, but as ever, the presentation is not
so easy to agree upon.
But it is also crucial to get the most accurate answer, and be able to prove it.
For example, B D McCullough, American Statistician Nov 1998 52(4), 358 and 1999
53(2) 149-159 assessed several st
Miroslav Silovic wrote:
> I noticed that boost::lambda library has a complete implementation of
> the type inference for the operator results (i.e. inferring that char
> +
> int returns an int). I would really like to be able to use that in my
> code, however, the Lambda implementation is currently
Hey, that's a cool find.
I also found a homepage for SCTP http://www.sctp.de/
I've CC'd the point of contact from the website.
>From what I've read (which is fairly minimal :[), it looks like SCTP
would work well for what I was thinking.
I guess that my original commentary could be revised to
John Maddock wrote:
> I think I like that - do you want to put together the headers?
Sorry, been out the country on short notice all this week.
I suspect it's a bit close to 1.30 to be making such a change in config
now, but I'll try to get something together next week for testing after
it's bra
At 12:35 PM 2/13/2003, David Abrahams wrote:
>Whatever we do with color, most of the text that needs to be readable
>should be black on white. That's been shown to be most readable for
>most people, on average.
That's a good point. Color-blind people may have trouble with anything that
depends
At 11:53 AM 2/13/2003, Gennadiy Rozental wrote:
>> > Hi, everybody
>> >
>> > Today I committed second revision to Boost.Test library.
>>
>> Wow, is that a good idea one day before we branch for release?
>
>I should have done it week ago, but was really sick. Anyway, It does not
>contain anything t
[2003-02-13] Beman Dawes wrote:
>At 11:53 AM 2/13/2003, Gennadiy Rozental wrote:
>
> >> > Hi, everybody
> >> >
> >> > Today I committed second revision to Boost.Test library.
> >>
> >> Wow, is that a good idea one day before we branch for release?
> >
> >I should have done it week ago, but was rea
At 01:47 AM 2/12/2003, David B. Held wrote:
>...I hope there's still a chance for it to be considered for the
>next version of the standard library.
The April meeting deadline is not for the next version of the Standard
Library; rather it is for the Library Technical Report.
While nothing has b
At 11:02 AM 2/13/2003, David Abrahams wrote:
>That said, the level of support for Sun compilers is likely to depend
>on two things in the future:
>
> 1. Sun's willingness to address the serious bugs in their compiler
> implementation which prevent much progress at all from being
> made
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason House
> Sent: Thursday, February 13, 2003 9:09 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [boost] Re: Sockets - what's the latest?
> I guess that my original commentary could
"Boris Schäling" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> Noone knows as there is no consensus on how the library's
> architecture should look like. There are different approaches and
> proposals at Boost Wiki and in the sandbox but what's still mi
[2003-02-13] Beman Dawes wrote:
>At 12:35 PM 2/13/2003, David Abrahams wrote:
>
> >Whatever we do with color, most of the text that needs to be readable
> >should be black on white. That's been shown to be most readable for
> >most people, on average.
>
>That's a good point. Color-blind people ma
> However, problems with Boost.Test broke a lot of Metrowerks tests.
For some reason I could not locate Metrowerks compilation errors on Test
Status page.
As for Metrowerks linking errors I have a suspicion that it has something to
do with Metrowerks toolset.
Also I could not locate errors from e
>> Noone knows as there is no consensus on how the library's
>> architecture should look like. There are different approaches and
>> proposals at Boost Wiki and in the sandbox but what's still missing
>> is the big picture. As far as there are no ideas of how to get a
>> reasonable model which inco
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David B. Held
> Sent: Thursday, February 13, 2003 10:57 PM
> To: [EMAIL PROTECTED]
> Subject: [boost] Re: Sockets - what's the latest?
> [...]
> How about borrowing ideas from ACE, but implementing th
Boris Schäling <[EMAIL PROTECTED]> writes:
>> [...]
>> How about borrowing ideas from ACE, but implementing them in
>> modern C++? Or has that been discussed already? Or is the ACE
>> framework too obsolete-C++ to be a useful design?
>
> We probably should at least consider ACE ideas. But I gue
Rene Rivera <[EMAIL PROTECTED]> writes:
> [2003-02-13] Beman Dawes wrote:
>
>>At 11:53 AM 2/13/2003, Gennadiy Rozental wrote:
>>
>> >> > Hi, everybody
>> >> >
>> >> > Today I committed second revision to Boost.Test library.
>> >>
>> >> Wow, is that a good idea one day before we branch for release?
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Thu, 13 Feb 2003 11:52:59 -, "John Maddock"
> <[EMAIL PROTECTED]> wrote:
>
> [..]
>>I hear what you say, but I keep coming back to: this is largely an Intel
>>compiler specific problem,
>
> No, it's a matter of not making a silent use of non stand
At 04:56 PM 2/13/2003, Rene Rivera wrote:
>OK, I've made some changes to the page... Added an "Age" column, removed
>green from the age color scheme, and moved the age color scheme to the
age
>column only.
>
>Comments?
The changes seem nice improvements to me.
Dropping the Age colors entirely w
At 04:19 PM 2/13/2003, Rene Rivera wrote:
>>When I got back, random_test had been looping for six hours. Sigh. I
don't
>>know that's related.
>
>I had similar problems with the OpenBSD tests. It ran last night and I
woke
>up to it still hung, using 99% CPU, in one test (thread/test_condition).
>
At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote:
>> However, problems with Boost.Test broke a lot of Metrowerks tests.
>
>For some reason I could not locate Metrowerks compilation errors on Test
>Status page. As for Metrowerks linking errors I have a suspicion that it
>has something to do with Met
On Wednesday, February 12, 2003, at 03:11 PM, Jason House wrote:
Once I heard there was a generic socket library in development, I
thought I'd add
a quick feature request. I would like to see the ability to have
multiple
streams through the same socket.
This is pseudo-doable over TCP, by enco
At 08:17 PM 2/13/2003, Beman Dawes wrote:
>At 05:12 PM 2/13/2003, Rozental, Gennadiy wrote:
>
> >> However, problems with Boost.Test broke a lot of Metrowerks tests.
> >
> >For some reason I could not locate Metrowerks compilation errors on
Test
> >Status page. As for Metrowerks linking errors I h
On Thursday, February 13, 2003, at 12:08 PM, Jason House wrote:
* How easy will support for SCTP be to work into the boost socket
library? ... and how easy would the interface be to use?
I looked at the docs on www.sctp.de and downloaded the source, and the
fatal flaw seems to be what I found
> No, it is some sort of configuration problem.
Look on "metrowerks linking errors" thread. It about the same issue with
different undefined symbol
There was also compilation error with metrowerks. I fixed it couple hours
ago. Unfortunately I do not have direct access to this compiler so
metrower
Anthony Williams wrote:
> Aleksey Gurtovoy writes:
> >
> > The following is a sketch of a potential use case for the
> > newly-accepted and already very useful 'optional' class.
> >
> > Suppose you have a pure RAII guard/locker which unconditionally
> > does its job:
> >
> > struct
> > So, Let introduce one. I need something for coming release.
>
> Done: it's called BOOST_HAS_SIGACTION
>
> John.
Why it doesn't get defined for Visual Age C++ on AIX?
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listi
I would have expected that for member function pointers arg1_type would be
typedef cv class_type* arg1_type;
But isn't the class_type pointer hidden? AFAIK, you can't call a member
function pointer as if it's function pointer with an explicit 'this'
parameter. So how is the arg1_type classtype
77 matches
Mail list logo
