Hi,
I have problem accessing the sandbox cvs. I'm using developer access through ssh.
During cvs update, I get following message:
cvs server: [23:55:48] waiting for yok's lock in
/cvsroot/boost-sandbox/boost-sandbox/boost/numeric
It is possible to update other directories separately, but not
Unai Uribarri Rodríguez wrote:
any_cast, as is implemented in boost 1.29, has one weakness; it doesn't
allow to compile this piece of code:
any x=int(5);
++any_castint(x);
because any_cast tries to instanciate a pointer to int. The attached
patch solved this problem using
http://cpp-experiment.sourceforge.net/boost/libs/dynamic_any/doc/tutorial.html
It's very raw but I don't have time now to fishish it.
Anonymous CVS access to sources:
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/cpp-experiment login
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/cpp-experiment co
Rozental, Gennadiy wrote:
Now about config file feature.
I have 2 major issues with your design.
1. You again placed 2 eggs into same basket.
There are 2 levels of configuration file reading
a) level that is responsible for comments lines, empty lines, continued
lines, include, ifdef,
Rozental, Gennadiy wrote:
I would say that it's a big question how much flexibility is
needed. My
position is that the command line should not go beyond
existing styles.
Could you list all existent styles?
I think you did so yourself, in a message included in the doc directory
of my
Rozental, Gennadiy wrote:
There are only syntactic differences with
http://zigzag.cs.msu.su:7813/program_options/html/variables_map.html
No. I don't think so. You present fixed rigid interface. In my case almost
everything is optional. You don't have parameter description - you don't
provide
I can't find any good documentation about boost::mpl::find_if. The syntax is
different to that of std::find_if and std::find_if cannot be applied to
lists of boost::shared_ptr's. So I created my own find_if by modifying the
std one.:
code
#include iostream
#include list
#include
This seems to be a problem with the PP lib and MPL, anyone any ideas?
I tried to compile the boost libs on my solaris 2.8 system with Sun
WorkShop
6.u2 C++ 5.3 Patch 111685-05 64 bit compiler. Below you can see the
command
line which I executed and the result of it. Do you have a hint for me
Ulrich Eckhardt [EMAIL PROTECTED] writes:
On Wednesday 15 January 2003 15:49, you wrote:
At 04:25 AM 1/15/2003, Steven Kirk wrote:
windows. Judging by the naming convention used by the other current boost
libraries, shouldn't this library be called libboost_filesystem.lib?
Yes, I guess.
[EMAIL PROTECTED] writes:
From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]]
What would the advantage be over using boost::numeric_cast
directly, and
thus explicitly?
you would't have to worry about if you forgot a numeric_cast
somewhere in
your code
or if you compiled on a platform
Markus Pesti [EMAIL PROTECTED] writes:
I can't find any good documentation about boost::mpl::find_if.
http://www.mywikinet.com/mpl/ref/Reference/find_if.html
The syntax is different to that of std::find_if
that's because it's only an analogy. mpl::find_if is not a function;
it's a
John Maddock [EMAIL PROTECTED] writes:
This seems to be a problem with the PP lib and MPL, anyone any ideas?
Suggest that he try it with Boost.Build first.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training,
David Abrahams [EMAIL PROTECTED] schrieb im Newsbeitrag
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Or you can use the indirect iterator adaptor from the boost sandbox
(boost/iterator/iterator_adaptors.hpp)
bool find(const std::listboost::shared_ptrA Alist, int v) {
return stdfind_if(
[EMAIL PROTECTED] wrote in message
3D8559AE95B4D611B02C0002557C6C8B3C45C1@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45C1@STH-EXCH...
[snip]
I might also be beneficial when you are chaning a variable
from one type to
another; the change
might cause conversion problems some
- Original Message -
From: John Maddock [EMAIL PROTECTED]
This seems to be a problem with the PP lib and MPL, anyone any ideas?
The config should never even see the BOOST_PP_CHECK_... macros. It should
be using the Borland configuration:
#define BOOST_PP_CONFIG_FLAGS()
Paul Mensonides [EMAIL PROTECTED] writes:
- Original Message -
From: John Maddock [EMAIL PROTECTED]
This seems to be a problem with the PP lib and MPL, anyone any ideas?
The config should never even see the BOOST_PP_CHECK_... macros. It should
be using the Borland configuration:
Peter Dimov said:
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
The fact that who() returns a function name is not important; it is
not a mini call stack. A function name is used as a token that
identifies the point of failure. What failed? An attempt to open a
file? An
William E. Kempf [EMAIL PROTECTED] writes:
Peter Dimov said:
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
The fact that who() returns a function name is not important; it is
not a mini call stack. A function name is used as a token that
identifies the point of failure. What
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
[...]
How would you use a call stack to generate an user friendly error
message?
I wouldn't. User friendly error messages would only be generated close to
the throw point, where *I* have enough contextual information to
[2003-01-16] David Abrahams wrote:
Ulrich Eckhardt [EMAIL PROTECTED] writes:
On Wednesday 15 January 2003 15:49, you wrote:
At 04:25 AM 1/15/2003, Steven Kirk wrote:
windows. Judging by the naming convention used by the other current
boost
libraries, shouldn't this library be called
Rene Rivera [EMAIL PROTECTED] writes:
[2003-01-16] David Abrahams wrote:
Ulrich Eckhardt [EMAIL PROTECTED] writes:
On Wednesday 15 January 2003 15:49, you wrote:
At 04:25 AM 1/15/2003, Steven Kirk wrote:
windows. Judging by the naming convention used by the other current
boost
From: David Abrahams [mailto:[EMAIL PROTECTED]]
The huge advantage appears when you start looking at arithmetic
expressions. The result of
if (t u)
{
x = y + z * w;
}
could be a lot more predictable if we were working with types that
didn't perform implicit lossy conversions.
[2003-01-16] David Abrahams wrote:
Rene Rivera [EMAIL PROTECTED] writes:
[2003-01-16] David Abrahams wrote:
Ulrich Eckhardt [EMAIL PROTECTED] writes:
On Wednesday 15 January 2003 15:49, you wrote:
At 04:25 AM 1/15/2003, Steven Kirk wrote:
windows. Judging by the naming convention used by
[EMAIL PROTECTED] wrote in message
3D8559AE95B4D611B02C0002557C6C8B3C45CC@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45CC@STH-EXCH...
From: David Abrahams [mailto:[EMAIL PROTECTED]]
The huge advantage appears when you start looking at arithmetic
expressions. The result of
if (t
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
[...]
Knowing that no such file or directory was
thrown by open_file doesn't help the end user when the action he
took was to change a configuration option, for instance.
The end user isn't interested in the function name,
From: William E. Kempf [EMAIL PROTECTED]
Peter Dimov said:
[...] It is exceptions that
occur in the course in the normal operation that I'm talking about.
And those, in order to be dealt with in a useful manner, have to be
handled at a point close to the throw point, in order to be able
From: David Abrahams [EMAIL PROTECTED]
In general I agree with Bill. The more code gets refactored and
encapsulated, the less useful the name of the throwing function will
be. Take for example boost::throw_exception. I know that one doesn't
really count, because the exception is
I'd like to draw an analogy with shared_ptr. You can provide
smart pointer
with 5 policy parameters, that user can redefine. Still, I would use
boost::shared_ptr, just because I don't want 10 incompatible
smart pointers in
my program due to small advantage each one has in special
William E. Kempf wrote:
[...]
Recovery is hardly meaningless in this case. The recovery consisted of
informing the user of his mistake,
I'd say application's environmental problems [or something like
that] that can't be handled/recovered from by the application...
but it actually MAY try to
Alexander Nasonov wrote:
Unai Uribarri Rodríguez wrote:
any_cast, as is implemented in boost 1.29, has one weakness; it doesn't
allow to compile this piece of code:
any x=int(5);
++any_castint(x)
Boost.dynamic_any has extract functinos which work this way.
But this patch adds that
Rene Rivera wrote:
Not totally right... It should be:
libboost_name_API-tag.lib.version
Putting the version at the end is somewhat standard. And in my current case
of OpenBSD required.
That may be standard on OpenBSD, but it's not on Windows, where the last
part of the filename is used
Hi...
What happened to this mailing list? Did you create a list to announce your
new to do ideas?
Mohammed
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Paul Mensonides [EMAIL PROTECTED] writes:
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
This seems to be a problem with the PP lib and MPL, anyone any ideas?
The config should never even see the BOOST_PP_CHECK_... macros. It
should
be using the Borland
What is with the Mailing List archive? It doesn't seem to have more than 50 messages
in it for January. Also it seems the search function doesn't seem to work in a
predictable way.
Robert Ramey
___
Unsubscribe other changes:
I have a small class that uses the union/find algorithm to implement a
dynamic equivalence relation. With some work, it could probably also be
used to iterate through the equivalent partition.
Would this be a good thing to add to boost?
Jeffrey Yasskin
Rozental, Gennadiy wrote:
Does your parser supported all of them?
Maybe not. However, the unsupported one probably differ on in prefix
(/ vs -). And something really custom (-fno-unsigned-char) can
be handled via additional_parser mechanism (there's an
example of it in
the documentation.
Do
36 matches
Mail list logo
