I see that boost::thread has moved to a dll implementation (win32) in
1.30.0-b1. I have modified the JamFile for boost:thread so it builds
the lib as well as the dll. Default build be made to do both, rather
than just the dll? Or is boost moving to dll implementation only for
all libraries?
Eric Martel wrote:
Hi,
After a quick Google search, I found out that Joaquín M López, the
author of
a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct
2002
21:29:18) on the boost mailing list to promote his library. David B.
Held
replied about using his work to include the
Well, it was my intention then to probe the Boost community for interest
in the library, and my impression was it raised little impetus.
Ok, well I would be interested in seeing this in boost. A
project I am working on would have benefited from a birectional
map and it seems like a pretty
All -
I'm posting this review (with permission of the author) that
was not posted on the list during the review. This review was
considered as part of the library acceptance. Anyway, the review
may be of interest to other variant users as it is quite detailed
and implements a novel use of
Hi,
Is there any reason boost::filesystem::path doesn't
provide a swap(path ) function? If there is, I think
the docs should explain why, but if there isn't, well,
can it still be implemented before 1.30.0 goes gold?
Let me turn the question around and ask what your
expectations
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gennadiy Rozental
Sent: Tuesday, March 11, 2003 10:15 PM
To: [EMAIL PROTECTED]
Subject: [boost] Re: I/O library formal review
* newl needs a bit more rationale. How is cout newl different from
cout
Jeff Garland [EMAIL PROTECTED] writes:
Well, it was my intention then to probe the Boost community for interest
in the library, and my impression was it raised little impetus.
Ok, well I would be interested in seeing this in boost. A
project I am working on would have benefited from a
Markus Schöpflin wrote:
currently the constructors test of the multi array library fails for
VACPP6. This is due to the fact that the test uses an unsigned int where
a size_type should be used.
The attached patch replaces the unsigned int with size_t which allows
the test to pass for VACPP6
With GCC 3.3. there are a couple of warnings in the regex lib.
The warnings is about of the type of the array index.
Warning about char being used as index.
This patch fixes that. (by casting to unsigned int).
Index: libs/regex/src/c_regex_traits.cpp
Eric Martel wrote:
[snip]
Nearly 5 months later, did anyone work on this bimap? Will it be included
anytime soon in an official distribution of boost?
On a related issue: has anyone worked on boost::map? It was supposed to
be a generalisation of bimap, being able to work with an arbitrary
Markus Schöpflin wrote:
currently, the is_member_func_test fails for VACPP6 with the following
error messages:
snip
When looking at is_mem_fun_pointer_impl.hpp it looks like the Metrowerks
compiler has the same problem. Could anyone please add a check for
__IBMCPP__ =600 at line 345 of this
On Tue, 11 Mar 2003 17:14:43 -0500, Gennadiy Rozental
[EMAIL PROTECTED] wrote:
* newl needs a bit more rationale. How is cout newl different from
cout
'\n'? How is it better?
Maybe newl does not reset the manipulators? If it true it should be spelled
out explicitly. In any case I also like
On Wed, 12 Mar 2003 02:15:48 -0800, Jaap Suter
[EMAIL PROTECTED] wrote:
The effect is the same.
However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the
(potential?) problems you are worrying about. So why do you prefer
(b)?
Because if we do this to save time, we might as well make
Markus Schöpflin wrote:
currently, the is_member_func_test fails for VACPP6 with the
following error messages:
snip
When looking at is_mem_fun_pointer_impl.hpp it looks like the
Metrowerks compiler has the same problem. Could anyone please add
a check for __IBMCPP__ =600 at line 345
Aleksey Gurtovoy wrote:
Markus Schöpflin wrote:
currently, the is_member_func_test fails for VACPP6 with the
following error messages:
snip
When looking at is_mem_fun_pointer_impl.hpp it looks like the
Metrowerks compiler has the same problem. Could anyone please add
a check for __IBMCPP__ =600
I'm interested in a bi-direcional map as well. While I don't have a current
need for one, there have been several times in the past that I wished I had
one and made do with something else.
Mike
Joaquín Mª López Muñoz wrote:
Eric Martel wrote:
Hi,
After a quick Google search, I found out
Markus Schöpflin wrote:
Aleksey, thanks for the instructions. Could you tell me which PP you
used to generate the file before? I would like to minimize the diff
as much as possible?
VC 7.1, IIRC, but it shouldn't matter much because the header uses file
iteration PP technique, and for most
David Abrahams wrote:
It's similar for me. It's one of those things that you don't need
every day, but when you need it, you really need it. That may be why
there's not more vociferous interest. Anyhow, while bidirectional
maps are the most common case, they're not the most general:
Here is my list of outstanding patches and fixes. It would be great if we
could resolve the bulk of these for 1.30.0.
If you resolve any of these issues, please let me know so I can clear it
off the list.
Thanks,
--Beman
* lexical_cast changes
Kevlin and Terje doing final tests on changes.
At 11:19 PM 3/11/2003, Douglas Gregor wrote:
As it stands, the system itself is in good shape, and the documentation
for
libraries I've redocumented in BoostBook is quite reasonably. I still
think
a BoostBook overview/tutorial at Oxford would be beneficial.
Let's plan on it. Would Sunday
At 07:41 AM 2/13/2003, Fredrik Blomqvist wrote:
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.
Fixed. Thanks!
--Beman
___
Daniel Frey wrote:
I'd also be interested in a 'set' of 'tuples' with a user-defined set of
'views', where a view has its own sort-criterion and its own iterators,
find-functions, etc. At least this is what I imagine but I haven't
worked on it, so I don't know whether it's a realistic
At 07:11 AM 3/12/2003, Markus Schöpflin wrote:
Markus Schöpflin wrote:
currently the constructors test of the multi array library fails for
VACPP6. This is due to the fact that the test uses an unsigned int
where
a size_type should be used.
The attached patch replaces the unsigned int with
Aleksey Gurtovoy wrote:
Markus Schöpflin wrote:
Aleksey, thanks for the instructions. Could you tell me which PP you
used to generate the file before? I would like to minimize the diff
as much as possible?
VC 7.1, IIRC, but it shouldn't matter much because the header uses file
iteration PP
On Wed, 12 Mar 2003, Beman Dawes wrote:
At 07:11 AM 3/12/2003, Markus Schöpflin wrote:
Markus Schöpflin wrote:
currently the constructors test of the multi array library fails for
VACPP6. This is due to the fact that the test uses an unsigned int
where
a size_type should be
Beman Dawes wrote:
* Possible addition to operators library from Sam Partington
Daniel Frey and Sam discussing changes.
We need some discussion of it and I would like to see it in CVS and thus
in the regression tests for some time. When Sam started the proposal,
the branch for 1.30.0 has
On Wed, 12 Mar 2003, Beman Dawes wrote:
Here is my list of outstanding patches and fixes. It would be great if we
could resolve the bulk of these for 1.30.0.
* tuples::apply
Did this every get resolved? Aleksey? Jaakko?
Aleksey's message on Feb 15 had slipped by :(
Looking at his
Beman Dawes wrote:
Here is my list of outstanding patches and fixes. It would be great if
we could resolve the bulk of these for 1.30.0.
If you resolve any of these issues, please let me know so I can clear it
off the list.
Thanks,
--Beman
* lexical_cast changes
Kevlin and Terje doing
Beman Dawes wrote:
Here is my list of outstanding patches and fixes. It would be great if we
could resolve the bulk of these for 1.30.0.
* [bgl] pass by value
Awaiting response from Jeremy
Per off-list discussion, I've comitted the changes. They are also merged to
RC branch. There may be
A technical thing. The question is, what do we prefer? I personally
prefer a technical advantage as it creates safer overall code. I am
used
to work with several people in a large code-base and in my experience
it's always a very helpful thing if the interface of your code leads
to
Please disregard my other post, I hit the wrong button... :-(
Beman Dawes wrote:
* Multi-array constructor patch
Has been applied, but caused Win32 Metrowerks constructors
test failure.
I was just about to fix it but noticed, that Ronald already fixed it.
* PRB with
Beman Dawes wrote:
At 07:11 AM 3/12/2003, Markus Schöpflin wrote:
I just applied the patch. This cleared the error for VA6 and the
warning for Darwin.
Umm... Shouldn't that be std::size_t? Metrowerks is now failing,
saying it can't find undecorated size_t.
Yes of course, you're right. Sorry
Russell Hind said:
I see that boost::thread has moved to a dll implementation (win32) in
1.30.0-b1. I have modified the JamFile for boost:thread so it builds
the lib as well as the dll. Default build be made to do both, rather
than just the dll? Or is boost moving to dll implementation
At 06:18 AM 3/12/2003, Geurt Vos wrote:
Hi,
Is there any reason boost::filesystem::path doesn't
provide a swap(path ) function? If there is, I think
the docs should explain why, but if there isn't, well,
can it still be implemented before 1.30.0 goes gold?
Let me turn the question
On Wednesday 12 March 2003 08:05 am, Beman Dawes wrote:
At 11:19 PM 3/11/2003, Douglas Gregor wrote:
As it stands, the system itself is in good shape, and the documentation
for
libraries I've redocumented in BoostBook is quite reasonably. I still
think
a BoostBook overview/tutorial at
* [Boost.Test] Request for const fix in unit_test_suite.hpp
Posted 12 Feb 2003. Did this ever get resolved? Gennadiy?
Fixed in second revision.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Daniel Frey wrote:
Beman Dawes wrote:
* Possible addition to operators library from Sam Partington
Daniel Frey and Sam discussing changes.
We need some discussion of it and I would like to see it in CVS and
thus in the regression tests for some time. When Sam started the
proposal, the
Beman Dawes [EMAIL PROTECTED] writes:
* Boost.Python private email
Final changes promised for Wednesday night.
Those are done. I'd like to watch http://cci.lbl.gov/boost/ go
through one more successful test cycle.
* [Boost.Python] rpms and small fix for RedHat
Awaiting reply. Dave?
Beman Dawes [EMAIL PROTECTED] writes:
* [status/Jamfile] Jamfile patches for Borland
Need a decision. Dave?
I'm also not aware of these issues.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes:
Beman Dawes wrote:
Here is my list of outstanding patches and fixes. It would be great if we
could resolve the bulk of these for 1.30.0.
I have also reported and not seen rejected:
(easily lost in the volume surrounding a release)
[2 Random fixes also required for Graph]
Sam Partington wrote:
No, I agree. You're right, much better to squint at error messages than to
try and diagnose unexpected behaviour. Plus the messages I compared against
were not all that bad to look at anyway, and all of them said something to
the effect of can't convert class 'A' to
I see new features being added to RC_1_30_0.
Is this the right balance of innovation and stability?
I've spent several days cleaning up RC_1_30_0 for a large number of platforms.
It takes a long time to do all the compilations and tests. Do I have to do this
all over again to salvage my
On 12 Mar 2003 13:25:36 +0100, [EMAIL PROTECTED] (Lars Gullik Bjønnes)
wrote:
With GCC 3.3. there are a couple of warnings in the regex lib.
The warnings is about of the type of the array index.
Warning about char being used as index.
This patch fixes that. (by casting to unsigned int).
Unfortunately I don't understand this. It can go in the
documentation, with the work around to be :
if (!!a ...)
or
if (a)
if (...)
Of course. But I was hoping for a work-around at the library-side, not
at the user's side. What exactly are the overloads that the VC thinks
might
The multiply indexed set seems a most interesting container, and
as a matter of fact I'm working on something like that, but progress
is slow.
There's an issue I guess I should comment here before advancing
with this. The code is non-conformant in (at least) two points, neither
of which I've
At 06:06 AM 3/12/2003, Gennaro Prota wrote:
On Wed, 12 Mar 2003 02:15:48 -0800, Jaap Suter
[EMAIL PROTECTED] wrote:
The effect is the same.
However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the
(potential?) problems you are worrying about. So why do you prefer
(b)?
Because if we
Gennaro Prota [EMAIL PROTECTED] writes:
| On 12 Mar 2003 13:25:36 +0100, [EMAIL PROTECTED] (Lars Gullik Bjønnes)
| wrote:
|
|
| With GCC 3.3. there are a couple of warnings in the regex lib.
| The warnings is about of the type of the array index.
| Warning about char being used as index.
|
|
Sam Partington wrote:
Yes, library side fix would be much nicer. But I'm stuck on this. The
compiler is _really_ helpful here:
z:\test.cpp(37) : error C2593: 'operator ' is ambiguous
thats it! The compiler docs suggest to resolve the ambiguity you explicity
cast one or both of the
At 10:54 AM 3/12/2003, Vladimir Prus wrote:
Beman Dawes wrote:
Here is my list of outstanding patches and fixes. It would be great if
we
could resolve the bulk of these for 1.30.0.
* [bgl] pass by value
Awaiting response from Jeremy
Per off-list discussion, I've comitted the changes.
At 11:33 AM 3/12/2003, Gennadiy Rozental wrote:
* [Boost.Test] Request for const fix in unit_test_suite.hpp
Posted 12 Feb 2003. Did this ever get resolved? Gennadiy?
Fixed in second revision.
OK, removed from list.
Thanks,
--Beman
___
Unsubscribe
At 10:56 AM 3/12/2003, Markus Schöpflin wrote:
Beman Dawes wrote:
* Multi-array constructor patch
Has been applied, but caused Win32 Metrowerks constructors
test failure.
I was just about to fix it but noticed, that Ronald already fixed it.
OK, Metrowerks is now passing. Removed from
At 11:50 AM 3/12/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
* Boost.Python private email
Final changes promised for Wednesday night.
Those are done.
OK, removed from list.
I'd like to watch http://cci.lbl.gov/boost/ go
through one more successful test cycle.
Even
At 11:52 AM 3/12/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
* [status/Jamfile] Jamfile patches for Borland
Need a decision. Dave?
I'm also not aware of these issues.
See http://aspn.activestate.com/ASPN/Mail/Message/boost/1566296
Because it is a build related issue,
On Wed, 12 Mar 2003 11:13:51 -0700, Greg Colvin
[EMAIL PROTECTED] wrote:
Exactly. And if the time it takes is different then the effect is not
the same to me :-)
Measurements, please?
Be patient :-) I asked for empirics too and Jaap said he will do some
benchmark. Also, I said *if* the time it
Beman Dawes [EMAIL PROTECTED] writes:
Doesn't seem to be in the archives. It's from Neal D. Becker 10 Mar
2003. Here is the entire message:
I really appreciate the boost rpms that have been made available. I
hope we
can improve one thing in the upcoming release.
rpm -q --requires
Beman Dawes [EMAIL PROTECTED] writes:
At 11:52 AM 3/12/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
* [status/Jamfile] Jamfile patches for Borland
Need a decision. Dave?
I'm also not aware of these issues.
See
Indeed that's not very helpful. But at least - as you said - it fails
to compile so I consider it a non-issue for the operators library.
It's a
VC6 problem and the users need to life with it whether or not they use
the operators library, right?
Yup. It is six years old after all. Anyway it
On Wed, 12 Mar 2003 20:15:31 +0100, Sam Partington wrote:
I think we now have had a fair amount of discussion and as long as you
(or anyone else) don't find another problem, I'm looking forward for
your next patch-set. :)
Attached. Hopefully not made a mess of it. :-)
I'm not 100% sure
Beman Dawes wrote:
At 09:07 PM 3/11/2003, Edward Diener wrote:
While I realize it may be the only answer to the problems you
mention, making libraries link to the static RTL where they would
normally link to the dynamic RTL is IMHO a bad general solution. My
reason for thinking
this
is
1. I found this name a bit misleading. At first I though that it some king
of iteration through variant types
2. From quick glance on your code it seems that visit_helper class
unnessesarilly parameterized with T0 and T1.
Removing this parameterization (Use member templates instead) should
Dirk Gerrits [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Eric Martel wrote:
[snip]
Nearly 5 months later, did anyone work on this bimap? Will it be
included anytime soon in an official distribution of boost?
On a related issue: has anyone worked on boost::map? It was
Joaquín Mª López Muñoz [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Yes, what I cannot figure out is whether the Preliminary submission
step can be reached with a non boostified libary (like mine is now) or
whether it is assumed the library should be Boost-friendly by this stage.
At 06:03 PM 3/12/2003, David B. Held wrote:
On an unrelated note, one thing that might be a concern is that I did not
write the map from scratch. I used the STLport implementation of
std::map, which came from SGI or HP (or both, for all I remember). I
wonder if the license is Boost-compatible?
At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote:
The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc
3.2.2.
The error message appears at the top of:
http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test
.../boost/boost/lexical_cast.hpp:92: `wstring'
On Wed, 12 Mar 2003 17:07:54 -0600, David B. Held wrote
I'd say 6 or 7 people expressing interest is more than enough to justify
Boostifying the code at this stage.
I agree. Since you have written an article which clearly describes
the concept and provides an example it seems to me that you
Hello,
I promised to get back with some timings for the compiletime debug and
release discussion.
I've tested it with my own projets which makes heavy use of
BOOST_STATIC_ASSERTS in many places, particularly in the meta equivalent of
tight inner-loops. Here are some examples of static asserts
From: Beman Dawes [EMAIL PROTECTED]
At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote:
The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc
3.2.2.
The error message appears at the top of:
http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test
For the past few days, I've posted about not being able to get Boost
projects set up with the CodeWarrior Developement Studio, Mac OS X
Edition, v8, that I just got. I just want to make sure that it's not
my setup mistakes, and not the configuration files.
1. Is there anyone out there
From: Terje Slettebø [EMAIL PROTECTED]
The new
version of lexical_cast is Kevlin's own, which he recently made, not my
proposition. I think his version is better, though, as it's much shorter
and
removes duplication.
Just to point out that it's the kind of duplication which is not easily
69 matches
Mail list logo
