[boost] Non-homogeneous trees manipulation library
Hi, I put a write-up of several ideas on generic tree manipulation library on Yahoo: http://groups.yahoo.com/group/boost/files/tree_manipulation_20030331.tgz This document is far from being complete base for library implementation, but before going further I would like to determine interest and get some feedback. The approach is a little bit more general than one discussed recently in the thread 'A generic tree manipulation library', since it is also intended for handling trees whose nodes may have distinct types visible to generic algorithms (like e.g. parse trees). The approach introduces isolation between a tree and an algorithm which effectively removes the well-known visitor (=algorithm) dependency on the tree implementation, making it possible to create library of generic tree mainpulation algorithms for non-homogeneous trees (e.g. tree diff, subtree search, traversals). Comments welcome. Regards Grzegorz ## # Grzegorz Jakacki Huada Electronic Design # # Senior Engineer, CAD Dept. 1 Gaojiayuan, Chaoyang # # tel. +86-10-64365577 x2074 Beijing 100015, China # # Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. # ## ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] When to use which ETI workaround?
Andreas Huber wrote:
> Hi Aleksey,
Hi Andreas,
Sorry for the late reply, got too many things on my plate.
> I've stumbled over ETI again. Browsing through MPL I have found
> different ways to circumvent it. In my case the following workaround
> seems to be sufficient:
>
> template< class State >
> struct get_context_ptr_type
> {
> typedef typename State::context_ptr_type type;
> };
>
> template<>
> struct get_context_ptr_type< int >
> {
> typedef int type;
> };
>
> I.e. by simply specializing a given metafunction with int.
Yep, in most cases that's enough. It's _always_ enough with MSVC 6.0, but
7.0 sometimes uses another, unknown, type for the instantiation's
placeholder argument, so you cannot simply specialize the template anymore,
but have to use 'is_msvc_eti_arg' predicate instead (which is based on the
knowledge that the type is still int-convertible; most probably it's an
enum), e.g.:
template< class State >
struct get_context_ptr_type_impl
{
typedef typename State::context_ptr_type type;
};
template< class State >
struct get_context_ptr_type
: if_c<
is_msvc_eti_arg::value
, identity
, get_context_ptr_type_impl
>
{
};
> How do you decide when to use which workaround? Have you established
> rules or do you simply work your way through them until one works?
The VC 7.0-specific case is rare enough to always try the 'int'
specialization first (which is obviously less painful than the other), and
then switch to the 'is_msvc_eti_arg'-based workaround if that doesn't help.
VC 7.0 is not our production environment here at work, so I didn't have
enough experience with it to be able to figure out when exactly these cases
occur.
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comeau and regression testing
At 06:30 PM 3/30/2003, Giovanni Bajo wrote: >is it possible to add Comeau to the automatic daily regression testing? I'm >willing to go through the bugs and prepare patches as needed to fix >compatibility with it. I've got an action item for the C++ committee meeting next week to corner Greg Comeau to give me a hand installing Comeau C++ on my notebook machine. If he isn't there, maybe someone else can look over my shoulder and see what I'm doing wrong. Speaking of regression tests, I won't be running the regular Win32 tests between April 1st and April 18th. Carl Daniel is going to try to run them on his machine during that period, but has been tied up with other projects so I don't know if he will get to it. I'll try to run VC++ 7.1 and Metrowerks tests once in awhile on my notebook machine, but Win32 testing is likely to be a little sparse during that period. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression logs
Douglas Gregor <[EMAIL PROTECTED]> writes: > On Saturday 29 March 2003 09:46 am, David Abrahams wrote: >> I just returned from PyConDC 2003, where a system was described which >> will watch a CVS repository for checkins, launch new remote tests on >> any number of platforms, collect the results, and notify people of >> failures (e.g. via mail or even IRC chat). It can be set up to bother >> the person at fault first, and then bother a different group, for >> example. http://buildbot.sourceforge.net/. It looks like it could >> be really useful for us. >> >> Brian Warner expressed interest in helping us get that BuildBot up for >> Boost if we want to use it. >> >> Thoughts? > > This sounds great, but do we have access to enough hardware to make this > feasible? I don't know the answer for sure, but I think we do. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL::lambda on MSVC
Jaap Suter wrote:
> Hi,
Hi Jaap,
>
> I apologize, but once again I'm unable to get a lambda
> expression working with the MPL.
>
> The code works fine with the Intel and GCC compiler. On MSVC I get the
> following error:
>
> error C2039: 'lhs_index' : is not a member of 'boost::mpl::arg'
It's the same problem we dealt with here -
http://lists.boost.org/MailArchives/boost/msg41700.php. The easiest way to
fix it within the current code base would be this:
template< typename T > struct lhs_index_impl
: T::lhs_index
{
};
template< typename T > struct lhs_index
: mpl::if_<
mpl::is_placeholder
, T
, lhs_index_impl
>
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,lhs_index,(T))
};
template< typename T > struct rhs_index_impl
: T::rhs_index
{
};
template< typename T > struct rhs_index
: mpl::if_<
mpl::is_placeholder
, T
, rhs_index_impl
>
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,rhs_index,(T))
};
template < class Signature, class LhsIndex, class RhsIndex >
struct predicate
{
typedef typename mpl::and_<
typename mpl::equal_to<
typename lhs_index::type, LhsIndex
>::type,
typename mpl::equal_to<
typename rhs_index::type, RhsIndex
>::type
>::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT( 3,
predicate, (Signature, LhsIndex, RhsIndex) )
};
// Test code:
typedef mpl::vector< signature< 1, 1, 1 >,
signature< 4, 4, 0 >,
signature< 5, 5, 0 >,
signature< 4, 5, 1 > > signatures;
typedef mpl::find_if<
signatures,
predicate<
mpl::_1,
mpl::size_t< 4 >,
mpl::size_t< 5 >
>
>::type iter_0;
That's not to say that it's something obvious and easy to figure out - I'll
look if there is a simple way to workaround the compiler's deficiency that
doesn't have this idiosyncrasy.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] lexical_cast woes
>From: "Michel André" <[EMAIL PROTECTED]> > I get the following errors when compiling with the lexical_cast version in > CVS on MSVC 7.0 do I have to enable wchar_t support on the command line or > disable it via DISABLE_WIDE_CHAR_SUPPORT or whats the solution. This problem was reported at the Boost-Users list, as well. It turns out that testing for MSVC 6, and disabling wide character support in that case, wasn't enough, as the same needs to be done if MSVC 7 is set to have wchar_t not as intrinsic type. I've therefore removed the "BOOST_MSVC <= 1200" test, again, and restored "BOOST_NO_INTRINSIC_WCHAR_T" test, which used to be, earlier. The reason the the test for MSVC was used first, was that the config for Intel C++ also defined BOOST_NO_INTRINSIC_WCHAR_T, regardless of whether it was the case or not, as the compiler didn't set a macro for it. However, it appears that the latest version of Intel C++ do get correct wide character support, when it's enabled. I've also changed bad_lexical_cast, to return the types used, in source()/target(), as given in Kevlin's suggestion (http://article.gmane.org/gmane.comp.lib.boost.devel/18240). As a small change, the warning with MSVC 7 for void * -> bool conversion is removed, using Kevlin's suggestion (http://article.gmane.org/gmane.comp.lib.boost.devel/18253). I've run the tests for Intel C++ 7.0 (strict mode), MSVC 7.0 (with and without wchar_t as intrinsic type), and MSVC 6.0, and it works. This is now fixed in the CVS. Thanks for the feedback. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comeau and regression testing
Hello, is it possible to add Comeau to the automatic daily regression testing? I'm willing to go through the bugs and prepare patches as needed to fix compatibility with it. Giovanni Bajo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression logs
Beman Dawes <[EMAIL PROTECTED]> writes: > At 09:46 AM 3/29/2003, David Abrahams wrote: > >Beman Dawes <[EMAIL PROTECTED]> writes: > > > >> I think Alisdair's raised some good points. While I'm not sure > >> regression testers will want to put a lot of effort into back tests, I > >> think it would be good if from here on out we segregated current from > >> past tests. > >> > >> So I'd say give it a bit more thought and see what you can come up > >> with. It will probably be easier to leave everything in one directory, > >> but have the script display each release separately. Maybe default to > >> current state, but with an option to look at past tests. > >> > >> Keep in mind the number of test platforms is likely to increase as > >> time goes on. That also argues for better separation between releases > >> and the current CVS state. > > > >I just returned from PyConDC 2003, where a system was described which > >will watch a CVS repository for checkins, launch new remote tests on > >any number of platforms, collect the results, and notify people of > >failures (e.g. via mail or even IRC chat). It can be set up to bother > >the person at fault first, and then bother a different group, for > >example. http://buildbot.sourceforge.net/. It looks like it could > >be really useful for us. > > > >Brian Warner expressed interest in helping us get that BuildBot up for > >Boost if we want to use it. > > > >Thoughts? > > I think we really need something like that. Is it something we can > dabble with first to see if it really works for Boost? It's Python; how hard can it be? ;-) Seriously, I have no idea. I get the sense we'll want some hand-holding to get it set up, so it might be better to start working with Brian immediately rather than dabbling on our own. If you're feeling adventurous, though, feel free to dive in. I'm sure you'll stop when it becomes inefficient. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression logs
On Saturday 29 March 2003 09:46 am, David Abrahams wrote: > I just returned from PyConDC 2003, where a system was described which > will watch a CVS repository for checkins, launch new remote tests on > any number of platforms, collect the results, and notify people of > failures (e.g. via mail or even IRC chat). It can be set up to bother > the person at fault first, and then bother a different group, for > example. http://buildbot.sourceforge.net/. It looks like it could > be really useful for us. > > Brian Warner expressed interest in helping us get that BuildBot up for > Boost if we want to use it. > > Thoughts? This sounds great, but do we have access to enough hardware to make this feasible? Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL::lambda on MSVC
David Abrahams <[EMAIL PROTECTED]> writes:
> I'm looking at it to see if I can find a way to get has_rebind to
> work without instantiating T.
Well, I did it, but although it passes my local tests it seems to
fail for your example. I'm not sure what to tell you; the patch is
below:
Index: boost/mpl/aux_/has_rebind.hpp
===
RCS file: /cvsroot/boost/boost/boost/mpl/aux_/has_rebind.hpp,v
retrieving revision 1.8
diff -w -u -r1.8 has_rebind.hpp
--- boost/mpl/aux_/has_rebind.hpp 25 Feb 2003 23:10:54 - 1.8
+++ boost/mpl/aux_/has_rebind.hpp 30 Mar 2003 21:46:07 -
@@ -17,6 +17,9 @@
#ifndef BOOST_MPL_AUX_HAS_REBIND_HPP_INCLUDED
#define BOOST_MPL_AUX_HAS_REBIND_HPP_INCLUDED
+#include
+
+#ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
#include "boost/mpl/aux_/has_xxx.hpp"
#include "boost/mpl/if.hpp"
#include "boost/mpl/bool.hpp"
@@ -37,5 +40,33 @@
};
}}}
+
+#else
+
+# include
+# include
+# include
+
+namespace boost { namespace mpl { namespace aux {
+
+no_tag has_rebind_test(...);
+
+template
+struct rebind_base
+{
+friend yes_tag has_rebind_test(T);
+};
+
+template
+struct has_rebind
+ {
+ typedef type_wrapper wrapper;
+ BOOST_STATIC_CONSTANT(bool, value = sizeof(aux::has_rebind_test(wrapper())) ==
sizeof(yes_tag));
+ typedef bool_ type;
+ };
+
+}}}
+
+#endif
#endif // BOOST_MPL_AUX_HAS_REBIND_HPP_INCLUDED
Index: boost/mpl/aux_/lambda_support.hpp
===
RCS file: /cvsroot/boost/boost/boost/mpl/aux_/lambda_support.hpp,v
retrieving revision 1.9
diff -w -u -r1.9 lambda_support.hpp
--- boost/mpl/aux_/lambda_support.hpp 7 Mar 2003 11:38:59 - 1.9
+++ boost/mpl/aux_/lambda_support.hpp 30 Mar 2003 21:46:07 -
@@ -104,16 +104,22 @@
/**/
# if !defined(__BORLANDC__)
+
+# include
+
# define BOOST_MPL_AUX_LAMBDA_SUPPORT(i, name, params) \
BOOST_MPL_AUX_LAMBDA_SUPPORT_SPEC(i, name, params) \
}; \
-class BOOST_PP_CAT(name,_rebind) \
+class BOOST_PP_CAT(name,_rebind) :
::boost::mpl::aux::rebind_base \
{ \
public: \
+template \
+
BOOST_PP_CAT(name,_rebind)(::boost::mpl::aux::type_wrapper
>*); \
+\
template< BOOST_MPL_PP_PARAMS(i,typename U) > struct apply \
: name< BOOST_MPL_PP_PARAMS(i,U) > \
{ \
-}; \
+};
/**/
# else
# define BOOST_MPL_AUX_LAMBDA_SUPPORT(i, name, params) \
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression logs
At 09:46 AM 3/29/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> I think Alisdair's raised some good points. While I'm not sure >> regression testers will want to put a lot of effort into back tests, I >> think it would be good if from here on out we segregated current from >> past tests. >> >> So I'd say give it a bit more thought and see what you can come up >> with. It will probably be easier to leave everything in one directory, >> but have the script display each release separately. Maybe default to >> current state, but with an option to look at past tests. >> >> Keep in mind the number of test platforms is likely to increase as >> time goes on. That also argues for better separation between releases >> and the current CVS state. > >I just returned from PyConDC 2003, where a system was described which >will watch a CVS repository for checkins, launch new remote tests on >any number of platforms, collect the results, and notify people of >failures (e.g. via mail or even IRC chat). It can be set up to bother >the person at fault first, and then bother a different group, for >example. http://buildbot.sourceforge.net/. It looks like it could >be really useful for us. > >Brian Warner expressed interest in helping us get that BuildBot up for >Boost if we want to use it. > >Thoughts? I think we really need something like that. Is it something we can dabble with first to see if it really works for Boost? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast woes
I get the following errors when compiling with the lexical_cast version in CVS on MSVC 7.0 do I have to enable wchar_t support on the command line or disable it via DISABLE_WIDE_CHAR_SUPPORT or whats the solution. I tried to read up on the new lexical_cast woes with the 1.30 release but failed to find something. C:\Packages\boost\work\boost\lexical_cast.hpp(161) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'std::basic_stringstream<_Elem,_Traits,_Alloc>::_Mystr' (or there is no acceptable conversion) with [ _Elem=wchar_t, _Traits=std::char_traits, _Alloc=std::allocator ] C:\Packages\boost\work\boost\lexical_cast.hpp(157) : while compiling class-template member function 'bool boost::detail::lexical_stream::operator >>(std::string &)' with [ Target=std::string, Source=boost::socket::port_t ] C:\Packages\boost\work\boost\lexical_cast.hpp(189) : see reference to class template instantiation 'boost::detail::lexical_stream' being compiled with [ Target=std::string, Source=boost::socket::port_t ] server_test.cpp(128) : see reference to function template instantiation 'Target boost::[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@ 2@@std@@G(Source)' being compiled with [ Target=std::string, Source=boost::socket::port_t ] btw boost::socket::port_t is unsigned short which gets mixed up with wchar_t. Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL::lambda on MSVC
"Jaap Suter" <[EMAIL PROTECTED]> writes: >> The error occurs on the line with the boost static constant. > > Never mind that, I changed the code after I wrote the message. > > Here's the code in hopefully better formatting. Looks to me like this code has the exact same problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL::lambda on MSVC
"Jaap Suter" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I apologize, but once again I'm unable to get a lambda expression working
> with the MPL.
>
> The code works fine with the Intel and GCC compiler. On MSVC I get the
> following error:
>
> error C2039: 'lhs_index' : is not a member of 'boost::mpl::arg'
>
> The error occurs on the line with the boost static constant. It does not
> happen if the template is not instantiated. I have tried using the
> AUX_VOID_SPEC macro, but that didn't really help. I even tried closing my
> own namespace, and doing an AUX_VOID_SPEC inside the MPL namespace, as done
> in http://aspn.activestate.com/ASPN/Mail/Message/1387917.
>
> I also tried deriving predicate from mpl::equal_to that simply compares the
> result to true_c, hoping that mpl::equal_to would give me the lambda support
> for free. That didn't work either.
>
> Any advice would be greatly appreciated.
I think you could rewrite your code to be clearer (see below) but
that's not really the problem we're having. The problem is that
lambda support requires has_rebind, which instantiates the predicate
on its argument. When the argument is a placeholder (arg), it
doesn't have ::lhs_index or ::rhs_index members, and the predicate
instantiation is an error.
I'm looking at it to see if I can find a way to get has_rebind to
work without instantiating T.
-
template struct lhs_index : T::lhs_index
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1, lhs_index, (T));
};
template struct rhs_index : T::rhs_index
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1, rhs_index, (T));
};
template < size_t LhsIndex, size_t RhsIndex, int Sign >
struct signature
{
typedef mpl::size_t< LhsIndex > lhs_index;
typedef mpl::size_t< RhsIndex > rhs_index;
typedef mpl::int_< Sign > type;
};
template < class Signature, class LhsIndex, class RhsIndex >
struct predicate
: mpl::and_<
mpl::equal_to, LhsIndex>
, mpl::equal_to, RhsIndex>
>
{
BOOST_MPL_AUX_LAMBDA_SUPPORT( 3, predicate, (Signature, LhsIndex,RhsIndex) )
};
// Test code:
typedef mpl::vector< signature< 1, 1, 1 >,
signature< 4, 4, 0 >,
signature< 5, 5, 0 >,
signature< 4, 5, 1 > > signatures;
typedef mpl::find_if< signatures, predicate< mpl::_1, mpl::size_t< 4 >,
mpl::size_t< 5 > > >::type iter_0;
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problems compiling microsec_time_clock with cygwin/gcc
I get the following error when trying to compile date_time/microsec_time_clock.hpp from the current CVS with cygwin/gcc. C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse error before `;' token + -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline -I"..\..\..\libs\soc ket\build" -I"C:\Packages\boost\sandbox" -I"C:\Packages\boost\boost" -I"C:\P ackages\boost\work" -o "..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-d ynamic\socket_option.obj" "../src\socket_option.cpp" ...failed gcc-C++-action ..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-dy namic\socket_option.obj... gcc-C++-action ..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-dy namic\default_socket_impl.obj In file included from C:/Packages/boost/work/boost/date_time/posix_time/posix_time_types.hpp:9, from C:/Packages/boost/sandbox/boost/socket/config.hpp:32, from C:/Packages/boost/sandbox/boost/socket/impl/default_socket_impl.hpp:19, from ../src/default_socket_impl.cpp:21: C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp: In static member function `static time_type boost::date_time::microsec_clock::create_time(timeval*)': C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse error before `;' token + -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline -I"..\..\..\libs\soc ket\build" -I"C:\Packages\boost\sandbox" -I"C:\Packages\boost\boost" -I"C:\P ackages\boost\work" -o "..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-d ynamic\default_socket_impl.obj" "../src\default_socket_impl.cpp" ...failed gcc-C++-action ..\..\..\libs\socket\build\bin\libboost_socket.lib\gcc\debug\runtime-link-dy namic\default_socket_impl.obj... Regards /Michel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL::lambda on MSVC
> The error occurs on the line with the boost static constant.
Never mind that, I changed the code after I wrote the message.
Here's the code in hopefully better formatting.
template < size_t LhsIndex, size_t RhsIndex, int Sign >
struct signature
{
typedef mpl::size_t< LhsIndex > lhs_index;
typedef mpl::size_t< RhsIndex > rhs_index;
typedef mpl::int_< Sign > type;
};
template < class Signature, class LhsIndex, class RhsIndex >
struct predicate
{
typedef typename mpl::and_<
typename mpl::equal_to<
typename Signature::lhs_index, LhsIndex
>::type,
typename mpl::equal_to<
typename Signature::rhs_index, RhsIndex
>::type
>::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT( 3,
predicate, (Signature, LhsIndex, RhsIndex) )
};
// Test code:
typedef mpl::vector< signature< 1, 1, 1 >,
signature< 4, 4, 0 >,
signature< 5, 5, 0 >,
signature< 4, 5, 1 > > signatures;
typedef mpl::find_if<
signatures,
predicate<
mpl::_1,
mpl::size_t< 4 >,
mpl::size_t< 5 >
>
>::type iter_0;
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL::lambda on MSVC
Hi,
I apologize, but once again I'm unable to get a lambda expression working
with the MPL.
The code works fine with the Intel and GCC compiler. On MSVC I get the
following error:
error C2039: 'lhs_index' : is not a member of 'boost::mpl::arg'
The error occurs on the line with the boost static constant. It does not
happen if the template is not instantiated. I have tried using the
AUX_VOID_SPEC macro, but that didn't really help. I even tried closing my
own namespace, and doing an AUX_VOID_SPEC inside the MPL namespace, as done
in http://aspn.activestate.com/ASPN/Mail/Message/1387917.
I also tried deriving predicate from mpl::equal_to that simply compares the
result to true_c, hoping that mpl::equal_to would give me the lambda support
for free. That didn't work either.
Any advice would be greatly appreciated.
Sincerely,
Jaap Suter
___
template < size_t LhsIndex, size_t RhsIndex, int Sign >
struct signature
{
typedef mpl::size_t< LhsIndex > lhs_index;
typedef mpl::size_t< RhsIndex > rhs_index;
typedef mpl::int_< Sign > type;
};
template < class Signature, class LhsIndex, class RhsIndex >
struct predicate
{
typedef typename mpl::and_<
typename mpl::equal_to< typename Signature::lhs_index, LhsIndex
>::type,
typename mpl::equal_to< typename Signature::rhs_index, RhsIndex
>::type
>::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT( 3, predicate, (Signature, LhsIndex,
RhsIndex) )
};
// Test code:
typedef mpl::vector< signature< 1, 1, 1 >,
signature< 4, 4, 0 >,
signature< 5, 5, 0 >,
signature< 4, 5, 1 > > signatures;
typedef mpl::find_if< signatures, predicate< mpl::_1, mpl::size_t< 4 >,
mpl::size_t< 5 > > >::type iter_0;
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] (no subject)
Paul A Bristow wrote:
This is quite neat, and works for me using MSVC 7.0 but:
Thanks. Comments always welcome.
1 The layout is screwed up by the mail attachment process and requires some
editing to avoid compile errors.
I have zipped the file. This should prevent the layout being modified by the
mail program. I chose not to modify the format as this would destroy the
layout rules I use to make the code, in my opinion, easier to read and use.
2 The filename formatlist.hpp might be better?
I agree. The change has been made in the supporting file.
3 Requires language extensions enabled.
[snip]
for the line
std::cout << "list = " << stl::formatlist( v ) << '\n';
This is because stl::formatlist has the signature:
namespace stl
{
template< typename ForwardIterator >
inline formatlist_t< ForwardIterator > formatlist
(
ForwardIterator first,
ForwardIterator last
);
}
returning a non-reference type. This is needed because of the way it works,
but the problem lies in the output operator:
template< typename CharT, class TraitsT, typename ForwardIterator >
inline std::basic_ostream< CharT, TraitsT > & operator<<
(
std::basic_ostream< CharT, TraitsT > & os,
formatlist_t< ForwardIterator > & fi
);
I suspect this can be cured to make it more Standard and more portable?
The solution is to make the above:
template< typename CharT, class TraitsT, typename ForwardIterator >
inline std::basic_ostream< CharT, TraitsT > & operator<<
(
std::basic_ostream< CharT, TraitsT > & os,
formatlist_t< ForwardIterator > const & fi
);
4 I haven't tried with the all important 3 and more dimensions like
matrixes.
I shall look at adding support for 2D or nD output, however, this was not in
the initial design plans. As the name formatlist suggests, this was intended
for list outputting (1D) only.
5 Many more examples and documentation desirable, of course. My slightly
longer test file attached. (Last example might suit input to a spreadsheet
using
tab as a separator?)
I was gauging interest before I worked on more complicated examples. As for
documentation, I was looking at getting the design stabilized first,
otherwise there may be problems synchronizing the documentation with the
code.
I have produced a more complicated set of examples that demonstrate the
applicability of my formatlist manipulator.
and finally a nit - Separator is wrongly spelled.
This has been corrected. Thanks.
I have a few ideas on where I would like to take this:
[1] I would like to parametize the seperator and open/close list types to a
template type. This will allow the character type used by my current
implementation, as well as a character array, std::string and possibly other
types like wide characters.
[2] I have recently had a look at the "I/O operationd for STL containers"
thread. Is there a way we can merge these two threads, or should they be
kept seperate? There are similarities and differences to both approaches.
Both are an attempt to solve a similar problem from different angles.
The io_format approach is very nice - I like the way it hooks into the I/O
stream state mechanism to make the usage for a type intuative; it does,
however have a complex setup for each type on each output stream that uses
that type. Also, what are the run-time overheads for the use of the xalloc
mechanism, especially if a lot of different containers need to be outputted?
My approach does not handle std::pair or nD object output, nor does it
support seperators or list brackets that are wide characters or strings
(although I am looking at generalizing this). The point of my version was to
allow the output of a list specified between two iterators with a
specialization for containers to save writing:
std::formatlist( c.begin(), c.end())
every time you needed to output the entire container. I also wanted an
implementation that has a small run-time overhead.
[3] Would it be possible to combine both approaches into a single library,
where the user can choose which version to use: state objects (io_format);
or manipulators (formatlist)?
[4] I am intending on changing the stl namespace to something more
appropriate. Any suggestions are welcome.
[5] I'm thinking of removing the spacing options from my formatter in favor
of the string approach used by io_format. This would be used in combination
of templatizing the string parameter as in item [1].
-rhd-
mailto:[EMAIL PROTECTED]
_
formatlist.zip
Description: Zip compressed data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] How do I install boost::filesystem?
With MSVC you need to ensure that the libary build that you use is built with exactly the same run time library options as your .exe file - if that isn't the case you will see a lot of linker errors about multiply defined symbols as you found. Probably the easiest way is to just add the source for the library (in libs/filesys/src) to a static lib project in your IDE and build from there. It's not rocket science, but sometimes it can feel like it :-) John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Multithreaded Scaling Issues with regex
> Thanks for the quick response. Any chance that the revised memory > allocation is in a current beta version? It's in a cvs branch called "regex-4". Important: do not try to switch an existing cvs copy over to this branch - if you do most of boost will disappear as it's not been tagged with that branch label, instead check out into a clean directory. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] request vc7-stlport support in regex libs
> I'd like to request that the Visual C++ 7.0 with STLport become a supported > configuration for the regex library. Visual C++ 6.0 with STLport is already > a supported configuration. I get the feeling many people were only using > STLport with vc6 because the bundled STL was broken, and they switched to > the native STL when upgrading to vc7. I use STLport for a different > reason -- I develop software on several platforms and want a consistent STL > across all of the platforms -- so I intend to keep using STLport even though > the bundled STL has been improved. Will do, I've added that and vc-7.1 makefiles to the regex-4 branch that will form the next release. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
