- Boost-users - lists.boost.org

containers of boost::function objects
by Alisdair Meredith 02 Apr '03

02 Apr '03

I am trying to create a simple mechanism to register multiple callbacks with my class. My first simple-minded approach is to use std::list< boost::function2< [my params]> > Unfortunately, I cannot search this list to unregister callbacks, as any attempt to dereference a list::iterator tries to call the function, rather than return the function object. After spotting this problem in the standard algorithms I have been trying to hack around myself, explicitly calling operator* and even operator-> with no joy. Am I missing some easy way to get the function object out of the iterator as a value? And is this a bug in my compiler (BCB6) or a general issue for containers of function objects? -- AlisdairM

4 5

Compiling with Forte 7 generates Assertion errors - help?
by Chris Hackett 01 Apr '03

01 Apr '03

Hello, I am trying to build Boost with the Forte compiler and am getting many Assertion errors. I tried the same things Robert Reece tried (see Subject: type_traits/is_convertible crashes Forte 6.2u2 and Forte 7.0) and get the same results he described. I am using Forte 7, Solaris 8, and the latest version of Boost (1.30). My main.cpp file looks like: #include "boost/type_traits/detail/size_t_trait_def.hpp" // Try using the BOOST_TT_AUX_SIZE_T_TRAIT_DEF1 macro. namespace boost { BOOST_TT_AUX_SIZE_T_TRAIT_DEF1(alignment_of,T,::boost::detail::alignment_of_impl<T>::value) } // namespace boost int main( void ) { return 0; } and I compile with: CC -I$BOOST_DIR main.cpp The compiler prints an error: >> Assertion: (../lnk/init.cc, line 991) while processing main.cpp at line 3. The problems appear to be related to the use of BOOST_TT_AUX_SIZE_T_TRAIT_DEF1 and other similar #define macros. Has anyone come up with any work-arounds or solutions? You can email me at hackett_bae(a)yahoo.com. Thanks, Chris. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

1 0

regex++ use on binary data
by brian_hernacki 01 Apr '03

01 Apr '03

Maybe a newbiew question, but is there any way to use the regex++ libary to search chunks of binary data? (or more accurately to search a buffer of data of known length for a given pattern which may itself contain null bytes) --brian

2 1

linking Signals Library
by John Fletcher 01 Apr '03

01 Apr '03

System: Red Hat 8.0 with gcc 3.2 Boost 1_30_0 I have built the boost signals library using bjam. The test suite runs and passes all tests. How do I make the resulting libraries available to my own programs? Is there an equivalent of 'make install' which will move the results to somewhere from which linking is possible? I have searched the documentation on Boost Signal and also on building libraries and have found nothing on this. Thanks John Fletcher

2 3

[Signals-1.30.0] Linking problems
by Michael Kettner 01 Apr '03

01 Apr '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got problems in linking against the signals-library. I built the library defining <define>BOOST_SIGNALS_NAMESPACE=boost_signals and running bjam -sTOOLS=gcc-stlport -sBUILD=release Everythinig seemed to work fine, but when I now try to link against the shared library (see attached file), I get the following undefined references: undefined reference to `boost::boost_signals::detail::signal_base_impl::connect_slot(boost::any const&, boost::any const&, _STL::vector<boost::boost_signals::trackable const*, _STL::allocator<boost::boost_signals::trackable const*> > const&)' and undefined reference to `boost::boost_signals::detail::signal_base_impl::signal_base_impl[in-charge](boost::function2<bool, boost::any, boost::any, _STL::allocator<boost::function_base> > const&)' I'm using gcc-3.2.2 and STLport-4.5.3. May it be the case that something with the STL-namespace (std) went wrong? Thanks for any help, Michael - -- Dipl.-Ing. Michael Kettner, Wissenschaftlicher Mitarbeiter Institut für Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover Appelstr. 9A # Tel: ++49/(0)511/762-4273 D-30167 Hannover # Fax: ++49/(0)511/762-3001 http://www.ive.uni-hannover.de # kettner(a)ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+iIILkCdGnb0kVFMRAtewAJ9+MNdRW7hs4vHHbmnuashsi22d8gCaAm8W N8FnJqbRHiqU3S0EKDixD0U= =qEMK -----END PGP SIGNATURE----- [Non-text portions of this message have been removed]

3 5

[BGL] Problem with setS adjacency lists
by Pierre Barbier de Reuille 31 Mar '03

31 Mar '03

Hello, I want an undirected graph with non-multiple edges. So I use a graph defined as : adjacencylist<setS,vecS,undirectedS,SomeProperty> But, if I insert many times the same edge with: add_edge(2,3) add_edge(1,4) add_edge(2,3) add_edge(3,2) I obtain in fact 3 edges 2<->3 which I really don't want. Is there something else to do to avoid having multiple edges linking the same vertices ? And then, is there a way to user hash_set with g++-3.2 ? The problem being that hash_set is defined in the file ext/hash_set and in the namespace __gnu_cxx ... Thanks, -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

1 1

A bug in boost.lexical_cast 1.30
by Black Ice 31 Mar '03

31 Mar '03

When lexical_cast used under VC, and the option "Treat wchar_t as Build-in Type" is off The following code will cause compile error: int main(int argc, char * argv[]) { string str("10"); unsigned short n = lexical_cast<unsigned short>(str); return 0; } Because in lexical_cast::detail::widest_char, treat unsigned short as wchar_t!! -- /*******************/ ×ÔÓÉ£šliberty£©ÎÞ·ÇŸÍÊÇÕâÑùÒ»ÖÖ³ÐÅµ£ºÃ¿žöÈËœ«»áµÃµœÒ»ÖÖ±£ÕÏ£¬±£ÕÏÎÒÃÇ¿ÉÒÔÓë ÈšÍþ¡¢¶àÊý¡¢Á÷Ë×Œ°ÓßÂÛµÄÓ°ÏìÏà¿¹ºâ¡£ /*******************/

2 2

Another bug in boost.lexical_cast 1.30
by Black Ice 31 Mar '03

31 Mar '03

lexical_cast.hpp line 145: bool operator<<(const Source &input) { return stream << input; } Convert basic_stringstream & to bool? -- /*******************/ ×ÔÓÉ£šliberty£©ÎÞ·ÇŸÍÊÇÕâÑùÒ»ÖÖ³ÐÅµ£ºÃ¿žöÈËœ«»áµÃµœÒ»ÖÖ±£ÕÏ£¬±£ÕÏÎÒÃÇ¿ÉÒÔÓë ÈšÍþ¡¢¶àÊý¡¢Á÷Ë×Œ°ÓßÂÛµÄÓ°ÏìÏà¿¹ºâ¡£ /*******************/

2 2

Re: [boost] lexical_cast woes
by Terje Slettebø 31 Mar '03

31 Mar '03

>From: "Michel André" <michel.andre(a)swipnet.se> > 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

1 0

Bug in regex library?
by Andrey Sverdlichenko 30 Mar '03

30 Mar '03

boost::regex do not compile with STLPort-4.5.3 on FreeBSD 4.7-RELEASE-p3, gcc 2.95.4. This is a patch that fixed a problem. Is it just a typo in source? ==== //boost/libs/regex/src/cpp_regex_traits.cpp#1 - //boost/libs/regex/src/cpp_regex_traits.cpp ==== @@ -201,7 +201,7 @@ const std::messages<char>* pm = 0; #ifndef __IBMCPP__ - std::messages<char>::catalog cat = static_cast<std::messages<wchar_t>::catalog>(-1); + std::messages<char>::catalog cat = static_cast<std::messages<char>::catalog>(-1); #else std::messages<char>::catalog cat = reinterpret_cast<std::messages<wchar_t>::catalog>(-1); #endif

2 1