Hello,
I'm just using BOOST_CHECK_THROW tool. It works ok, but in addition to
exception type I'd like to test the value of 'what()', just to be sure. Is
there any way. Would it be possible to add another tool, which checks both
type and 'what()' content?
TIA,
Volodya
P.S. I also think there is
David Abrahams wrote:
Nicodemus <[EMAIL PROTECTED]> writes:
I did it, but it didn't work. is_class::value evaluates to
true. 8/
I believe that is_polymorphic::value should evaluate to
false, since unions can't be polymorphic.
Sure, but if we don't have a way to reliably distinguish unions
Nicodemus <[EMAIL PROTECTED]> writes:
> I did it, but it didn't work. is_class::value evaluates to
> true. 8/
>
> I believe that is_polymorphic::value should evaluate to
> false, since unions can't be polymorphic.
Sure, but if we don't have a way to reliably distinguish unions from
classes, we're
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> Seems to me a special version of the code for
>>
>> BOOST_WORKAROUND(__GNUC__, == 2 && __GNUC_MINOR__ == 96)
>>
>> is in order.
>
> We know that the special code works with 2.95.3 (ac
David Abrahams wrote:
Nicodemus <[EMAIL PROTECTED]> writes:
Is this happening somewhere in the type traits code? Can you post an
instantiation backtrace?
It seems to be. Here's the error message:
I guess the question here is: "should
is_polymorphic::value compile?"
If so, then we
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> Seems to me a special version of the code for
>
> BOOST_WORKAROUND(__GNUC__, == 2 && __GNUC_MINOR__ == 96)
>
> is in order.
We know that the special code works with 2.95.3 (according to Gottfried), so
I've made this:
# elif BOOST_WORKAROUND
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
>> I've checked in the patch and we will restart the tests as soon as the
>> Sourceforge server is cooperating.
>
> This patch breaks the Tru64/cxx and IRIX/CC (MIPSpro) compilations
--- "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
> I've checked in the patch and we will restart the tests as soon as the
> Sourceforge server is cooperating.
This patch breaks the Tru64/cxx and IRIX/CC (MIPSpro) compilations :-(
tru64cxx65-C++-action
../../../libs/python/test/bin/opaque
> Just curious if anyone's doing something along these lines. A quick
> google search on boost turned up only Boost.Test, which (I think?) is
> something quite different.
This topic came up several times during last year. Nobody seems to
have reviewable results. I do have full-featured tracing/lo
> > > Notice the weird misspellings in the error messages. :)
> >
> > What do you mean?
>
> "boolle" and "intr"? :)
>
> Could this be a problem in the unit test framework?
Could be. What should it be?
I wil try to reproduce this locally after 1.30 is out.
Gennadiy
_
A fresh version of the Win32 regression tests has just been posted. See
http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html
There are seven new fails in date_time tests; presumably all caused by
lexical_cast.hpp problems. See typical error message below.
--Beman
D:\boost\si
Just curious if anyone's doing something along these lines. A quick
google search on boost turned up only Boost.Test, which (I think?) is
something quite different.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Chris Trengove" <[EMAIL PROTECTED]> writes:
> David Abrahams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Please let me know as you find patches; I'd be very happy to see
>> Borland supported (but, I'm afraid, reluctant to invest the effort
>> myself).
>
> I've got fixes for
Nicodemus <[EMAIL PROTECTED]> writes:
>>Is this happening somewhere in the type traits code? Can you post an
>>instantiation backtrace?
>>
>
> It seems to be. Here's the error message:
I guess the question here is: "should
is_polymorphic::value compile?"
If so, then we have a bug in is_polymo
David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Please let me know as you find patches; I'd be very happy to see
> Borland supported (but, I'm afraid, reluctant to invest the effort
> myself).
I've got fixes for most (but not all) of the issues involved in building th
>From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
>
> > > If these are omitted for g++ 2.95.x, all tests pass for that compiler.
> > > However, as it compiles without errors on both MSVC 6 and g++
> > > 2.95.x, maybe
> > > one shouldn't have any BOOST_WO
>From: "David Abrahams" <[EMAIL PROTECTED]>
> Terje Slettebø <[EMAIL PROTECTED]> writes:
>
> > Also these three tests, like MSVC 6, concerns tests where it doesn't
throw
> > when it's supposed to:
> >
> > BOOST_CHECK_THROW(lexical_cast(" 123"), boost::bad_lexical_cast);
> > BOOST_CHECK_THROW(lexic
>From: "Kevlin Henney" <[EMAIL PROTECTED]>
> Close inspection reveals that the config file
> studiously avoids accommodating g++ 2.95:
>
> #if defined(__GNUC__) && (__GNUC__ < 3) && \
> ((__GNUC_MINOR__ < 95) || (__GNUC_MINOR__ == 96)) && \
> !defined(__STL_USE_NEW_IOSTREAMS) || \
>d
>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > lexical_cast_test.cpp(105): error in
> > "test_conversion_to_intr": exception
> > boost::bad_lexical_cast is expected
> > lexical_cast_test.cpp(111): error in
> > "test_conversion_to_intr": exception
> > boost::bad_lexical_cast is expected
> > l
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> OK, checked into RC_1_30_0. I don't have vc7.1. Could someone please try it
> out?
The opaque test works on 7.1 now. I'm running all the other tests,
but you should assume they work unless I say otherwise.
--
Dave Abrahams
Boost Consulti
true. It was a one-off.
Malcolm Smith
Analyst Programmer
Comvision Pty Ltd
http://www.comvision.org
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Edward Diener
Sent: Wednesday, 19 March 2003 09:36
To: [EMAIL PROTECTED]
Subject: [boost] Re: Re: Regex and
An easier way to solve this problem is to start a command processor with
just the PATH environment you want and build. You can do this by creating a
batch file which sets your path as appropriate and invoke the Make file from
within the batch file. That is how I do all my regex builds. Then there i
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> should be:
>
>
> # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300)
> // MSC works without this workaround, but needs another one ...
> -# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
> +# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointe
At 04:42 PM 3/18/2003, Terje Slettebø wrote:
>BOOST_CHECK_THROW(lexical_cast(" 123"), boost::bad_lexical_cast);
>BOOST_CHECK_THROW(lexical_cast(std::string(" 123")),
>boost::bad_lexical_cast);
>BOOST_CHECK_THROW(lexical_cast(123), boost::bad_lexical_cast);
>
>If these are omitted for g++ 2.95.x, a
At 03:48 PM 3/18/2003, David Abrahams wrote:
>Terje Slettebø <[EMAIL PROTECTED]> writes:
>
>> - With wide character support in lexical_cast enabled for MSVC 6, three
>> tests (of 137) fail. These are omitted for that compiler version, using
>> BOOST_WORKAROUND and BOOST_TESTED_AT.
>
>You shouldn't
In article <[EMAIL PROTECTED]>, Beman
Dawes <[EMAIL PROTECTED]> writes
>
>My patience has been exhausted. The folks that care about configuring
>lexical_cast for GCC 2.95.3 with the SGI library need come forward
>immediately and tell us how to deal with this, or 1.30.0 will ship as is.
Ditto on
Yes, I renamed my BCB6 folder as an interim fix - all OK now.
Malcolm Smith
Analyst Programmer
Comvision Pty Ltd
http://www.comvision.org
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Russell Hind
Sent: Tuesday, 18 March 2003 23:30
To: [EMAIL PROTECTED]
Su
> lexical_cast_test.cpp(105): error in
> "test_conversion_to_intr": exception
> boost::bad_lexical_cast is expected
> lexical_cast_test.cpp(111): error in
> "test_conversion_to_intr": exception
> boost::bad_lexical_cast is expected
> lexical_cast_test.cpp(147): error in
> "test_conversion_to_boo
Terje Slettebø <[EMAIL PROTECTED]> writes:
> Also these three tests, like MSVC 6, concerns tests where it doesn't throw
> when it's supposed to:
>
> BOOST_CHECK_THROW(lexical_cast(" 123"), boost::bad_lexical_cast);
> BOOST_CHECK_THROW(lexical_cast(std::string(" 123")),
> boost::bad_lexical_cast);
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> > Beman, here is an idea: I could check in the patch now and restart our
>> > multi-platform Boost.Python regression tests. When we hear back from David
>> we
>> > have the results already. Th
>From: "David Abrahams" <[EMAIL PROTECTED]>
> Terje Slettebø <[EMAIL PROTECTED]> writes:
>
> > - With wide character support in lexical_cast enabled for MSVC 6, three
> > tests (of 137) fail. These are omitted for that compiler version, using
> > BOOST_WORKAROUND and BOOST_TESTED_AT.
>
> You shoul
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> > Beman, here is an idea: I could check in the patch now and restart our
> > multi-platform Boost.Python regression tests. When we hear back from David
> we
> > have the results already. Then we can decide what to do based on all the
> > information t
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> I have the patch ready to go and it fixes the gcc 2.96 problem. However, I am
> in limbo because I am waiting for a word from David. I don't think his concern
> above is valid, but I am not certain.
I'd like to know why you don't think it's
Terje Slettebø <[EMAIL PROTECTED]> writes:
> - With wide character support in lexical_cast enabled for MSVC 6, three
> tests (of 137) fail. These are omitted for that compiler version, using
> BOOST_WORKAROUND and BOOST_TESTED_AT.
You shouldn't be using BOOST_TESTED_AT for that compiler, since th
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> --- "Rozental, Gennadiy" <[EMAIL PROTECTED]> wrote:
>> > Not all^H^H^H^H^H^H^H^HNo compilers are perfectly standard-compliant.
>>
>> Ih this case I would not want to make this change. After all it's only
>> warning.
>
> The patch is only in
--- Beman Dawes <[EMAIL PROTECTED]> wrote:
> At 09:48 AM 3/18/2003, David Abrahams wrote:
>
> >[EMAIL PROTECTED] writes:
> >
> >>> it seems to me that these aren't actually legal specializations
> >>> (though I've never specialized functions before so I could be wrong).
> >>> Shouldn't that b
>From: "Beman Dawes" <[EMAIL PROTECTED]>
> My patience has been exhausted. The folks that care about configuring
> lexical_cast for GCC 2.95.3 with the SGI library need come forward
> immediately and tell us how to deal with this, or 1.30.0 will ship as is.
I've applied John Maddock's suggestion
--- "Rozental, Gennadiy" <[EMAIL PROTECTED]> wrote:
> > Not all^H^H^H^H^H^H^H^HNo compilers are perfectly standard-compliant.
>
> Ih this case I would not want to make this change. After all it's only
> warning.
The patch is only in RC_1_30_0.
The warnings are creating a lot of noise. As you said
> Not all^H^H^H^H^H^H^H^HNo compilers are perfectly standard-compliant.
Ih this case I would not want to make this change. After all it's only
warning.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"David B. Held" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > [...]
> > That's a pretty major problem, though. Your idea also cuts off
> > implicit conversions.
>
> Do you mean user-defined conversio
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "David B. Held" <[EMAIL PROTECTED]> writes:
>
> > Is this is a worthwhile idea to pursue? Am I missing any critical
> > details? I realize there is still a problem with const vs. non-const
> > references, but I won't e
"David B. Held" <[EMAIL PROTECTED]> writes:
> Is this is a worthwhile idea to pursue? Am I missing any critical
> details? I realize there is still a problem with const vs. non-const
> references, but I won't even try to solve that. ;)
That's a pretty major problem, though. Your idea also cuts
Hi
Me and my colleagues have come across an issue when using a shared_ptr.
void myFunction(shared_ptr const & vp_Pointer)
{
vp_Pointer->call any non-const function
}
i.e. a const shared_ptr doesn't prevent anyone from changing the
contents to which the pointer points. This makes s
> My patience has been exhausted. The folks that care about configuring
> lexical_cast for GCC 2.95.3 with the SGI library need come forward
Do you mean without? The regression tests with the SGI library look
fine...
> immediately and tell us how to
Does anybody know if this needs fixing, or is it my mistake. If it
needs fixing, is someone able to do it before 1.30.0 is released?
Thanks
Russell
Russell Hind wrote:
Sorry about last post, Mozilla decided to send when I tried to paste
stuff into the message (?). Strange, but probably finge
After thinking about boost::ref and the auto_ptr by_ref trick, I
wondered if these could be applied to the function forwarding
problem, like so:
template
R f(by_ref v1, by_ref v2, ...)
{
g(v1, v2, ...);
}
template
class by_ref
{
// ... like boost::reference_wrapper
};
template <>
class
Beman Dawes <[EMAIL PROTECTED]> writes:
> >Beman, can we get this in under the wire? It only affects
> >Boost.Python and then only a new feature of Boost.Python.
>
> Yes, if it is ready in the next couple of hours. Please let me know
> when it is committed.
OK, this is up to Ralf and Gottfried
"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:
> Does standard require/recomend inline in method declaration? I always
> thought it ignored
>
> class A
> {
> inline void foo();
>
> };
>
> inline void
> A::foo()
> {
>
> }
Not all^H^H^H^H^H^H^H^HNo compilers are perfectly stand
Thomas Witt <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Abrahams wrote:
> | [EMAIL PROTECTED] writes:
> |
> | I think we need to keep the argument for VC6 at least; the problem is
> | one that shows up at link time because VC6 seems to distinguish
> | fu
Hello,
I'm quite at a loss with this one:
#include
int main(int argc, char *argv[])
{
return 0;
}
is giving me the following output:
Compiling...
main.cpp
C:\BOOST_1_29_0\boost/graph/isomorphism.hpp(56) : error C2976:
'safe_iterator_property_map' : too few template arguments
C:\BOOS
At 09:48 AM 3/18/2003, David Abrahams wrote:
>[EMAIL PROTECTED] writes:
>
>>> it seems to me that these aren't actually legal specializations
>>> (though I've never specialized functions before so I could be wrong).
>>> Shouldn't that be:
>>>
>>> template <>
>>> inline type_info type_id(bo
I've been looking through the Boost.Random docs, and the "val" template
parameter is inconsistently documented in random-generators.html. E.g., for
boost::random::linear_congruential, the synopsis of has
it, but the synopsis of random::linear_congruential does not.
Either this parameter should b
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...]
> And until we get there, one reasonable boost practice has been to
> pass by value and ask the caller to use boost::ref(x) to get references
> across the call boundary.
I remember seeing this in the Boost.Bind do
Thanx for the patch. I did not forget about it. Applied.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Does standard require/recomend inline in method declaration? I always
thought it ignored
class A
{
inline void foo();
};
inline void
A::foo()
{
}
Gennadiy
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.c
> I think we need to keep the argument for VC6 at least; the problem is
> one that shows up at link time because VC6 seems to distinguish
> function template instantiations only by the types of the arguments
> and not the template parameters. If you amend the patch so that it
> still uses the defa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Abrahams wrote:
| [EMAIL PROTECTED] writes:
|
| I think we need to keep the argument for VC6 at least; the problem is
| one that shows up at link time because VC6 seems to distinguish
| function template instantiations only by the types of the arg
[EMAIL PROTECTED] writes:
> On my Linux system I'm using the gcc toolset for all my boost work.
> Recently I had to use a different version of gcc which is installed under a
> different name.
> Ok, I thought, time to use set the GXX and GCC Variables in order to use
> that different gcc version.
>
On my Linux system I'm using the gcc toolset for all my boost work.
Recently I had to use a different version of gcc which is installed under a
different name.
Ok, I thought, time to use set the GXX and GCC Variables in order to use
that different gcc version.
Here's what I tried (I'm using bash a
[EMAIL PROTECTED] writes:
>> it seems to me that these aren't actually legal specializations
>> (though I've never specialized functions before so I could be wrong).
>> Shouldn't that be:
>>
>> template <>
>> inline type_info type_id(boost::type*) {
>> return type_info(typeid(Poin
I'd like to thank those who took time to review the update to the Boost I/O Library
during the review period, which ended several days ago. The reviewers raised
important questions about the usefulness of the new portions of the library.
As review manager, I am pending my determination regardin
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > That change does not seem to make a difference. The compiler errors are
> still
> > exactly the same.
>
> Does 2.96 want the default argument (=0) to be repeated?
Is this what you mean?
Hi,
the attached patch fixes a typo in
libs/test/doc/execution_monitor.htm.
Regards,
m
Index: execution_monitor.htm
===
RCS file: /cvsroot/boost/boost/libs/test/doc/execution_monitor.htm,v
retrieving revision 1.10
diff -u -r1.10 execu
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > There are gcc 2.96 (Redhat 7.3) compilation error for
> > boost/libs/python/test/opaque.cpp:
> >
> > http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
> >
> > More recent gcc's don't seems to suffer from this problem.
> > I am not
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> That change does not seem to make a difference. The compiler errors are still
> exactly the same.
Does 2.96 want the default argument (=0) to be repeated?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
At 07:25 AM 3/18/2003, Markus Schöpflin wrote:
>Beman Dawes wrote:
>
>> At 07:17 AM 3/17/2003, Thomas Witt wrote:
>>
>> >the library name is still "fs". I was under the impression that this
>was
>> >only temporary and should be changed to a more boost compatible
>> >"boost_filesystem" before rel
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
>
> > There are gcc 2.96 (Redhat 7.3) compilation error for
> > boost/libs/python/test/opaque.cpp:
> >
> > http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
> >
> > More recent gcc's don't s
Aleksey Gurtovoy wrote:
Daniel Frey wrote:
it's still the question whether is_function could be "fixed" given
that is_reference seems to be available for compilers without partial
specialization.
Sure. By all means it would be appreciated if someone contributed a
comprehensive fix which would cl
At 01:11 AM 3/18/2003, Kevlin Henney wrote:
>>Look at the error messages from date_time testperiod below, and the
source
>>code lines they refer to. At least directly, they don't seem releated to
>>wide character support.
>
>They are not, but the question is what is meant by
>BOOST_NO_STRINGSTR
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> writes:
> There are gcc 2.96 (Redhat 7.3) compilation error for
> boost/libs/python/test/opaque.cpp:
>
> http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
>
> More recent gcc's don't seems to suffer from this problem.
> I am not sure this is impo
Gennaro Prota <[EMAIL PROTECTED]> writes:
> BTW, the following paper (which probably you know)
>
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
>
> has a nice discussion related to what you are doing.
And until we get there, one reasonable boost practice has been to pass
by va
Jaap Suter wrote:
> Hi,
Hi Jaap,
>
> In some of my MPL-using code I needed set-based functionality. So I wrote
a
> function that does an insertion into an ordered list of constants.
However,
> it seems that if I compare a list created from a bunch of constants to an
> explicit list, they don't en
On Mon, 17 Mar 2003 08:56:54 -0600, "David B. Held"
<[EMAIL PROTECTED]> wrote:
>"Gennaro Prota" <[EMAIL PROTECTED]> wrote
>> [...]
>> What monster are you creating, man? :-)
>
>I must be the only one here that actually writes application code,
>because it never ceases to amaze me how everyone else
John Maddock wrote:
It looks more likely that you actually compiled with Builder 6, as that
ships with (and uses) that lib.
I ran into this problem. Builder 6 puts itself at the head of the path,
so when you run make (for building regex), I ended up building with BCB6
make, and then tried linkin
Hi
I just noticed that my e-mail in the documentation for
math::quaternion/octonion (history page) is out of date.
Could someone with CVS access (Hubert?) change my mail to
[EMAIL PROTECTED] instead? (and that's Fredrik without a 'c' ;-) )
Thanks!
/Fredrik
__
Beman Dawes wrote:
At 07:17 AM 3/17/2003, Thomas Witt wrote:
>the library name is still "fs". I was under the impression that this was
>only temporary and should be changed to a more boost compatible
>"boost_filesystem" before release. From a pratical point of view "fs"
>seems like begging fo
Daniel Frey wrote:
> I'm still wondering what happened. Please check everything what I say,
> as I already made too many errors wrt type-traits:
>
> John added the test for is_function to the code that was intended for
> compilers that don't have partial specialization - which is why it
> failed
OK, here's chapter and verse on how the config macros are supposed to work:
BOOST_NO_STRINGSTREAM: implies that std::stringstream is not available, when
not defined does not imply that new style (or wide character) streams are
available.
BOOST_NO_INTRINSIC_WCHAR_T: whcar_t is either not defined,
> I just compiled the regex library under C++Builder 5.
>
> I've tried to compile an application and it complains about not being able
> to find STLPMT.LIB - I can find no information on this LIB.
It looks more likely that you actually compiled with Builder 6, as that
ships with (and uses) that li
I think it's OK to revert the patch to get 1.30.0 out, but for the
future, I think we should keep in mind that it's actually is_function
that is broken and needs to be fixed AFAICS. The patch to is_class would
work if is_function could be called with a reference, so I think it's
worth to consider f
80 matches
Mail list logo
