Boost Users :

Yan.Zhang_at_[hidden]

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991
------------------------------
Message: 4
Date: Tue, 5 Sep 2006 20:59:36 +0200
From: "Stephan Diederich" <S.Diederich_at_[hidden]>
Subject: Re: [Boost-users] [BGL] filtered graph missing vertex
	function
To: boost-users_at_[hidden]
Message-ID:
	<ef236d4b0609051159h3ac51ce5m6f688c4d236c84f1_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Moritz,
2006/9/5, moritz Hilger <moritz.hilger_at_[hidden]>:
- Zitierten Text anzeigen -
> is there a particular reason that the filtered graph is missing a
> vertex_descriptor vertex(vertices_size_type, const& filtered_graph)
> function? of course this would return exactly the same as the one of
the
> underlying graph, nevertheless it would be handy for code treating
filtered
> graphs the same way as normal ones.
I think the problem here is the return value of the function. If you
have a VertexPredicate set, it would be possible that the vertex you
specify through the index doesn't exist in the filtered graph.
Maybe a null_vertex() could be returned in that case (But, IIRC, that
null_vertex() doesn't exist in every graph).
Cheers,
Stephan
------------------------------
Message: 5
Date: Tue, 05 Sep 2006 22:08:34 +0100
From: Eoin <eoin-keyword-boostusers.07781a_at_[hidden]>
Subject: [Boost-users] [variant] MSVC7.1 produces an Internal Compiler
	error	when variant	gets too complicated
To: boost-users_at_[hidden]
Message-ID: <44FDE752.7070504_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello I am developing a library which uses a variant like this one
class my_class {};
typedef boost::make_recursive_variant<
    my_class,
    int ,
    std::string,
    boost::posix_time::ptime,
    std::vector<boost::recursive_variant_>,
    std::map<std::string, boost::recursive_variant_>
    >::type param;
Under a Debug build when the type my_class is not present everything 
compiles perfectly, however with my_class I get internal compiler errors
such as the ones below;
G:\Program Files (x86)\Microsoft Visual Studio .NET 
2003\Vc7\include\xstring(827) : fatal error C1001: INTERNAL COMPILER
ERROR
        (compiler file 'msc1.cpp', line 2701)
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more 
information
c1xx : fatal error C1063: INTERNAL COMPILER ERROR
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more 
information
While playing around with the code and making adjustments (like 
reordering the types for the variant) I once got the compiler to display
this error;
fatal error C1067: compiler limit : debug information module size
exceeded
Searchs on the net pointed to using the #pragma component (mintypeinfo, 
on ) around the offending code, but even when I include this pragam 
enclosing the entire header containing my variant type I continue to get
the Internal Compiler Error for some files, though it does go away for 
others.
As hinted to by searches on the net this problem seems to be related to 
debug information and indeed everything does work fine under a release 
build. However as I am developing a library for use by others I cannot 
force them to avoid debug builds :^) . Everything works fine with the 
lastest MinGW debug or release.
Any suggestions would be very much appreciated. Kind Regards, Eoin.
------------------------------
Message: 6
Date: Tue, 5 Sep 2006 21:36:09 +0000 (GMT)
From: Peter Piehler <ppiehler_at_[hidden]>
Subject: [Boost-users] portable way to determine return type from
	class	member function
To: Boost-users_at_[hidden]
Message-ID: <20060905213609.24010.qmail_at_[hidden]>
Content-Type: text/plain; charset=us-ascii
Hello,

 i look for a portable way to determine the return-type of a member
function:

 #include <boost/utility/result_of.hpp>
 #include <boost/type_traits/function_traits.hpp>

 class CMyClass
 {
     public:
         int method( void ) {return 5;}
 };

 template< typename T >
 struct result_of
 {};

 template< typename R, typename A >
 struct result_of< R(*)(A) >
 {
         typedef R type;
 };
 template< typename R >
 struct result_of< R(*)(void) >
 {
         typedef R type;
 };
 template< typename R, typename C >
 struct result_of< R(C::*)(void) >
 {
         typedef R type;
 };
 template< typename R, typename C, typename A >
 struct result_of< R(C::*)(A) >
 {
         typedef R type;
 };
 /*...some other specialisations...*/

 /* (1) OK, but I must now return-type and signature */
 //typedef int (CMyClass::*fnPointer_t)(void); 

 /* (2) OK, but I must now return-type and signature */
 //typedef typeof(int(CMyClass::*)(void)) fnPointer_t;

 /* (3) OK, compiler determine return-type and signature if
CMyClass::method non-ambiguous */
 typedef typeof(&CMyClass::method) fnPointer_t;

 int main( )
 {
     fnPointer_t p = &CMyClass::method;

     /* (4) OK */
     result_of< fnPointer_t >::type i;

     /* (5) OK, if CMyClass::method non-ambiguous  */
     result_of< typeof(&CMyClass::method) >::type i2;

     /* (6) Failure, type expected */
     //result_of< p >::type i3;

     /* (7) OK */
     result_of< typeof(p) >::type i4;

     /* (8) Failure, no function pointer support */
     //boost::result_of< fnPointer_t >::type i5;

     /* (9) Failure, no function pointer support */
     //boost::result_of< typeof(&CMyClass::method) >::type i6;

     /* (10) Failure, no function pointer support */
     //boost::function_traits< fnPointer_t >::result_type i7;

     /* (11) Failure, no function pointer support */
     //boost::function_traits< typeof(&CMyClass::method) >::result_type
i8;
 }

 Which is a portable way? My prefered solution is number 5, but i dont
now whether typeof(&CMyClass::method) is portable.
 Why function  pointer are not supported by boost::result_of and
boost::function_traits templates?

 Thanks and Greetings,
 Peter
------------------------------
Message: 7
Date: Tue, 05 Sep 2006 18:07:33 -0400
From: Jason House <jasonhouse_at_[hidden]>
Subject: Re: [Boost-users] [test] Running either unit tests or normal
	program based off of command line switches
To: boost-users_at_[hidden]
Message-ID: <edkseq$9mc$1_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Which version of boost test does this apply to?  I downloaded the latest
stable boost version of 1.33.1 and grep -r gives no matches for 
BOOST_TEST_NO_MAIN or BOOST_TEST_DYN_LINK.  I also see no definitions 
for a function named unit_test_main.  There's a header file with that 
name, but it defines a normal main regardless of what is #define'd.
I suspect that maybe this is a feature with the CVS version?
Gennadiy Rozental wrote:
> "Jason House" <jasonhouse_at_[hidden]> wrote in message 
> news:edhfuf$dth$1_at_sea.gmane.org...
> 
>>As I currently understand boost.test, it provides its own main
function.
>> If I want to make a separate executable to run the tests, that seems
>>straight forward.  But how would I embed the testing inside a normal
>>program with a simple command-line switch for running them?
> 
> 
> Depends how you build UTF:
> 
> 1. Static library/"included" version
>   1.a. define BOOST_TEST_NO_MAIN during library/executable build
>   1.b. in your main file call unit_test_main():
> 
>    if( /* call unit test */ )
>        return boost::unit_test::unit_test_main( argc, argv );
> 
> 2. Dynamic library
>   2.a. define BOOST_TEST_NO_MAIN during library build
>   2.b. define BOOST_TEST_DYN_LINK during both library and executable
build
>   2.c. In the file containing function main() include 
> <boost/test/unit_test.hpp> and define BOOST_TEST_MAIN
>   2.d. in your main file call unit_test_main():
> 
>    if( /* call unit test */ )
>        return boost::unit_test::unit_test_main( &init_unit_test, argc,
> argv );
> 
> Gennadiy 
------------------------------
Message: 8
Date: Wed, 6 Sep 2006 00:58:39 +0200
From: "moritz Hilger" <moritz.hilger_at_[hidden]>
Subject: Re: [Boost-users] [BGL] filtered graph missing vertex
	function
To: boost-users_at_[hidden]
Message-ID:
	<b48649090609051558v6f03a5dcy9b31f47045614754_at_[hidden]>
Content-Type: text/plain; charset="iso-8859-1"
On 9/5/06, Stephan Diederich <S.Diederich_at_[hidden]> wrote:
>
> Hi Moritz,
>
> 2006/9/5, moritz Hilger <moritz.hilger_at_[hidden]>:
> - Zitierten Text anzeigen -
> > is there a particular reason that the filtered graph is missing a
> > vertex_descriptor vertex(vertices_size_type, const& filtered_graph)
> > function? of course this would return exactly the same as the one of
the
> > underlying graph, nevertheless it would be handy for code treating
> filtered
> > graphs the same way as normal ones.
>
> I think the problem here is the return value of the function. If you
> have a VertexPredicate set, it would be possible that the vertex you
> specify through the index doesn't exist in the filtered graph.
> Maybe a null_vertex() could be returned in that case (But, IIRC, that
> null_vertex() doesn't exist in every graph).
hmm, the null_vertex() function is part of the graph concept (
http://www.boost.org/libs/graph/doc/Graph.html) and  should return "a
special boost::graph_traits<G>::vertex_descriptor object which does not
refer to any vertex of graph object which type is G." so why not return
this
if the VertexPredicate excludes the requested vertex?
cheers,
moritz
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 9
Date: Tue, 05 Sep 2006 16:45:31 -0700
From: Tim Robertson <timr_at_[hidden]>
Subject: [Boost-users] Using boost::enable_if with template copy
	constructors
To: boost-users_at_[hidden]
Message-ID: <44FE0C1B.4030508_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Can anyone explain why the following won't compile (using g++ 3.3.2 
under Linux):
#include <boost/utility/enable_if.hpp>
#include <boost/type_traits/is_convertible.hpp>
using namespace std;
struct Foo
{
   Foo() {}
   template <typename T>
   Foo(T const & src,
       typename boost::enable_if<
       boost::is_convertible<T,Foo>, void >::type * dummy = 0)
  {
    int i = 1;  // filler.
  }
   template <typename T>
   Foo(T const & src,
       typename boost::disable_if<
       boost::is_convertible<T,Foo>, void >::type * dummy = 0)
  {
    int i = 2;  // ditto.
  }
};
int main()
{
   Foo f;
   Foo f2(f);
   return 0;
};
When I attempt to compile this code with g++ 3.3.2, I get the following 
error messages:
/boost/boost/type_traits/is_convertible.hpp: In instantiation of 
`boost::disable_if<boost::is_convertible<Foo, Foo>, void>':
/boost/boost/type_traits/is_convertible.hpp:128:   instantiated from 
`boost::detail::is_convertible_basic_impl<Foo&, Foo>'
/boost/boost/type_traits/is_convertible.hpp:228:   instantiated from 
`boost::detail::is_convertible_impl<Foo, Foo>'
test.cpp:36:   instantiated from 
`boost::detail::is_convertible_impl_dispatch<Foo, Foo>'
test.cpp:36:   instantiated from `boost::is_convertible<Foo, Foo>'
test.cpp:36:   instantiated from 
`boost::enable_if<boost::is_convertible<Foo, Foo>, void>'
test.cpp:36:   instantiated from here
/boost/boost/type_traits/is_convertible.hpp:128: error: `value'
    is not a member of type `boost::is_convertible<Foo, Foo>'
/boost/boost/type_traits/is_convertible.hpp: In instantiation of 
`boost::detail::is_convertible_basic_impl<Foo&, Foo>':
/boost/boost/type_traits/is_convertible.hpp:228:   instantiated from 
`boost::detail::is_convertible_impl<Foo, Foo>'
test.cpp:36:   instantiated from 
`boost::detail::is_convertible_impl_dispatch<Foo, Foo>'
test.cpp:36:   instantiated from `boost::is_convertible<Foo, Foo>'
test.cpp:36:   instantiated from 
`boost::enable_if<boost::is_convertible<Foo, Foo>, void>'
test.cpp:36:   instantiated from here
/boost/boost/type_traits/is_convertible.hpp:128: error:
    initializing argument 1 of `static yes_type
    boost::detail::checker<T>::_m_check(T, int) [with T = Foo]'
If I use boost::is_same<> in place of boost::is_convertible<>, 
everything is fine.  Is there something that I'm missing, or is this a
bug?
Thanks in advance,
Tim
------------------------------
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
End of Boost-users Digest, Vol 1018, Issue 3
********************************************