- Boost - lists.boost.org

Boost.Test as DLL
by Gennadiy Rozental 25 Feb '05

25 Feb '05

Hi, I am trying to finally implement DLL version of Boost.Test components. Here is several issues/questions I have: 1. main() function AFAIK there is no way to put a main function in DLL on windows. What should we do instead? I reworked the framework specifically for the purpose of making this kind of separation easier. But I still would like to hear what people think in this regard. 2. main() function again On unix(s) there is a possibility to put main info dlls (If I am wrong please correct me). Should we use different semantic for Windows and Unix(s) or use the one I implement for windows? 3. init_unit_test_suite I need to call external function from inside of DLLs. How it should be declared? Cause I am getting unresolved symbols error 4. runtime-link In my Jamfile in default build section of build rule there is <runtime-link>static/dynamic. Should I keep this? Should I use static for lib rule and dynamic for dll rule? Nothing for lib dynamic for dll? Thanks, Gennadiy

4 9

[Boost-bugs] [ boost-Bugs-1151823 ] boost::filesystem::native() should reject '/' on non-Win32
by SourceForge.net 25 Feb '05

25 Feb '05

Bugs item #1151823, was opened at 2005-02-25 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1151823&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Bright (sircus) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::native() should reject '/' on non-Win32 Initial Comment: On Win32, filesystem::native() correctly checks paths for validity on Win32. For other systems, it just returns true, presumably on the theory that for Unix, anything goes. Unless I'm much mistaken though, the character '/' is not allowed in Unix filenames. As such, native() should be changed as follows: BOOST_FILESYSTEM_DECL bool native( const std::string &name ) { return name.find('/') == std::string::npos; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1151823&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

none_t in the boost namespace
by Fernando Cacciola 25 Feb '05

25 Feb '05

Hi people, In the users mailing list, Yuval Ronen pointed out that optional<> uses a type "detail::none_t", documented as such, thus prompting people to use a type in a namesapece which is supposed to be hidden to end users. A straightforward fix is to just move "none_t" out of the detail namespace directlty into boost. However, this little change introduces a new type in the (main) boost namespace, so before I do that I want to make sure it won't have any undesired impact. If you see any reason for not doing this (putting "none_t" right there in boost) please speak now. If no one objects, I'll do it. Best, Fernando Cacciola

2 2

[test] automatic test problem
by Jody Hagins 25 Feb '05

25 Feb '05

Working off current CVS, I have the following file... #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> BOOST_AUTO_UNIT_TEST( test1 ) { BOOST_CHECK(true); } BOOST_AUTO_UNIT_TEST( test2 ) { BOOST_CHECK(true); } as shown in the examples, but when I compile, I get liner errors for missing main and test functions. shandalle:jody> g++ -I${BOOST_ROOT} 5_2_8_1.cpp -o 5_2_8_1 /usr/lib/crt1.o: In function `_start': /usr/lib/crt1.o(.text+0x18): undefined reference to `main' /tmp/cccXBUDu.o: In function `test1()': /tmp/cccXBUDu.o(.text+0xec): undefined reference to `boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_ result const&, boost::basic_wrap_stringstream<char>&, boost::unit_test::basic_cstring<char const>, unsigned, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned, ...)' /tmp/cccXBUDu.o: In function `test2()': /tmp/cccXBUDu.o(.text+0x242): undefined reference to `boost::test_tools::tt_detail::check_impl(boost::test_tools::predicate_ result const&, boost::basic_wrap_stringstream<char>&, boost::unit_test::basic_cstring<char const>, unsigned, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned, ...)' /tmp/cccXBUDu.o: In function `boost::unit_test::make_test_case(boost::unit_test::callback0<boost::un it_test::ut_detail::unused> const&, boost::unit_test::basic_cstring<char const>)': /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test14make_test_caseERKN S0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE+0x3b): undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test ::basic_cstring<char const>)' /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test14make_test_caseERKN S0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE+0x70): undefined reference to `boost::unit_test::test_case::test_case[in-charge](boost::unit_test::ba sic_cstring<char const>, boost::unit_test::callback0<boost::unit_test::ut_detail::unused> const&)' /tmp/cccXBUDu.o: In function `boost::unit_test::ut_detail::auto_unit_test_suite()': /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test9ut_detail20auto_uni t_test_suiteEv+0x4e): undefined reference to `boost::unit_test::test_suite::test_suite[in-charge](boost::unit_test:: basic_cstring<char const>)' /tmp/cccXBUDu.o: In function `boost::unit_test::ut_detail::auto_unit_test_registrar::auto_unit_test_ registrar[in-charge](boost::unit_test::test_case*)': /tmp/cccXBUDu.o(.gnu.linkonce.t._ZN5boost9unit_test9ut_detail24auto_uni t_test_registrarC1EPNS0_9test_caseE+0x26): undefined reference to `boost::unit_test::test_suite::add(boost::unit_test::test_unit*, unsigned long, unsigned)' collect2: ld returned 1 exit status

2 1

exceptional handling at boost/serialization ( reading bad archive )
by junyi.sun＠supportlinux.net 25 Feb '05

25 Feb '05

Hi, I have a class using boost_1.32/serialization to save/restore object data and it's working fine for load & save its own archive. I tried to make it load an archive saved by an unrelated class in order to verify exception handling of reading wrong/ corrupt archive. It dumps core at basic_iarchive_impl::load_pointer. Is it a known issue or anyone has similar experience ? Thanks. Junyi Sun Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libtcl8.4.so...done. Loaded symbols for /usr/lib/libtcl8.4.so Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libstdc++.so.5...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 #0 0x081c16cb in boost::archive::detail::basic_iarchive_impl::load_pointer () (gdb) bt #0 0x081c16cb in boost::archive::detail::basic_iarchive_impl::load_pointer () #1 0x081c0d23 in boost::archive::detail::basic_iarchive::load_pointer () #2 0x08060344 in boost::archive::detail::load_pointer_type<boost::archive::text_iarchive, MyObjectP*>::invoke (ar=@0xfef3c240, t=@0xfef3bf74) at iserializer.hpp:450 #3 0x08060304 in load<boost::archive::text_iarchive, MyObjectP*> (ar=@0xfef3c240, t=@0xfef3bf74) at iserializer.hpp:529 #4 0x080602ea in load_override<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at basic_text_iarchive.hpp:60 #5 0x080602c6 in load_override<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at text_iarchive.hpp:59 #6 0x08060298 in operator&<MyObjectP*> (this=0xfef3c240, t=@0xfef3bf74) at interface_iarchive.hpp:92 #7 0x08060260 in serialize<boost::archive::text_iarchive> (this=0xfef3bc80, ar=@0xfef3c240) at nvp.hpp:58 #8 0x0806023d in serialize<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at access.hpp:106 #9 0x0806021b in serialize<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at serialization.hpp:78 #10 0x080601f9 in serialize_adl<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80, file_version=0) at serialization.hpp:121 #11 0x080601d8 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> >::load_only::invoke (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:318 #12 0x080601b6 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> >::invoke (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:366 #13 0x0806019c in load<boost::archive::text_iarchive, boost::serialization::nvp<MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bc80) at iserializer.hpp:529 #14 0x08060182 in load_override<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at basic_text_iarchive.hpp:60 #15 0x0806015e in load_override<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at text_iarchive.hpp:59 #16 0x08060130 in operator>><boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at interface_iarchive.hpp:105 #17 0x080600b8 in operator&<boost::serialization::nvp<MyObjectP*> > (this=0xfef3c240, t=@0xfef3bc80) at interface_iarchive.hpp:111 #18 0x0805fe43 in serialize<boost::archive::text_iarchive, std::string, MyObjectP*> (ar=@0xfef3c240, p=@0xfef3bf70) at utility.hpp:47 #19 0x0805f59f in serialize_adl<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bf70, file_version=1) at serialization.hpp:121 #20 0x0805f48f in boost::archive::detail::iserializer<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::load_object_data (this=0x8a3f6c0, ar=@0xfef3c240, x=0xfef3bf70, file_version=1) at iserializer.hpp:155 #21 0x081c143a in boost::archive::detail::basic_iarchive_impl::load_object () #22 0x081c0d00 in boost::archive::detail::basic_iarchive::load_object () #23 0x0805df95 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::load::invoke (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:328 #24 0x0805df6c in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> >::invoke (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:366 #25 0x0805df52 in load<boost::archive::text_iarchive, std::pair<std::string, MyObjectP*> > (ar=@0xfef3c240, t=@0xfef3bf70) at iserializer.hpp:529 #26 0x0805df38 in load_override<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at basic_text_iarchive.hpp:60 #27 0x0805df14 in load_override<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at text_iarchive.hpp:59 #28 0x0805dee6 in operator&<std::pair<std::string, MyObjectP*> > (this=0xfef3c240, t=@0xfef3bf70) at interface_iarchive.hpp:92 #29 0x0805deae in serialize<boost::archive::text_iarchive> (this=0xfef3bf60, ar=@0xfef3c240) at nvp.hpp:58 #30 0x0805de8b in serialize<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at access.hpp:106 #31 0x0805de69 in serialize<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at serialization.hpp:78 #32 0x0805de47 in serialize_adl<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ar=@0xfef3c240, t=@0xfef3bf60, file_version=0) at serialization.hpp:121 #33 0x0805de26 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > >::load_only::invoke (ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:318 #34 0x0805de04 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > >::invoke (ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:366 #35 0x0805ddea in load<boost::archive::text_iarchive, boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > ( ---Type <return> to continue, or q <return> to quit--- ar=@0xfef3c240, t=@0xfef3bf60) at iserializer.hpp:529 #36 0x0805ddd0 in load_override<boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at basic_text_iarchive.hpp:60 #37 0x0805ddac in load_override<boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at text_iarchive.hpp:59 #38 0x0805dd7e in operator>><boost::serialization::nvp<std::pair<std::string, MyObjectP*> > > (this=0xfef3c240, t=@0xfef3bf60) at interface_iarchive.hpp:105 #39 0x0805d2d2 in boost::serialization::stl::archive_input_map<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::operator() (this=0xfef3bfae, ar=@0xfef3c240, s=@0xe3693e4) at collections_load_imp.hpp:110 #40 0x0805d192 in load_collection<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > >, boost::serialization::stl::archive_input_map<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > >, boost::serialization::stl::no_reserve_imp<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > > (ar=@0xfef3c240, s=@0xe3693e4) at collections_load_imp.hpp:158 #41 0x0805d110 in load<boost::archive::text_iarchive, MyObjectP*, std::string, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > (ar=@0xfef3c240, t=@0xe3693e4) at map.hpp:61 #42 0x0805d0f5 in boost::serialization::free_loader<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::invoke (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at split_free.hpp:55 #43 0x0805d0d3 in split_free<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at split_free.hpp:66 #44 0x0805d0b1 in serialize<boost::archive::text_iarchive, MyObjectP*, std::string, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at map.hpp:81 #45 0x0805b339 in serialize_adl<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4, file_version=0) at serialization.hpp:121 #46 0x0805b03b in boost::archive::detail::iserializer<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::load_object_data (this=0x8a3f5b0, ar=@0xfef3c240, x=0xe3693e4, file_version=0) at iserializer.hpp:155 #47 0x081c143a in boost::archive::detail::basic_iarchive_impl::load_object () #48 0x081c0d00 in boost::archive::detail::basic_iarchive::load_object () #49 0x08058aa3 in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::load::invoke (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:328 #50 0x08058a7a in boost::archive::detail::load_non_pointer_type<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > >::invoke (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:366 #51 0x08058a60 in load<boost::archive::text_iarchive, std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (ar=@0xfef3c240, t=@0xe3693e4) at iserializer.hpp:529 #52 0x08058a46 in boost::archive::basic_text_iarchive<boost::archive::text_iarchive>::load_override<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at basic_text_iarchive.hpp:60 #53 0x08058a22 in boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::load_override<std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<std::string const, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at text_iarchive.hpp:59 #54 0x080579b8 in operator>><std::map<std::string, MyObjectP*, std::less<std::string>, std::allocator<std::pair<const std::string, MyObjectP*> > > > (this=0xfef3c240, t=@0xe3693e4) at interface_iarchive.hpp:83 #55 0x08056615 in encode_function (domain_id=208, bat=0xe728070, info=0xea2c339 "22 serialization::archive 3 0 0 4 1 1 3\n0 0 0 0 1\n1 0 1\n2 0 1\n3 0", info_len=65) at encode.cc:102

2 1

[Boost-bugs] [ boost-Bugs-1150829 ] Files missing in .exe
by SourceForge.net 25 Feb '05

25 Feb '05

Bugs item #1150829, was opened at 2005-02-24 00:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1150829&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Files missing in .exe Initial Comment: I downloaded boost_1_32_0.exe and boost_1_32_0.tar.gz, and noticed that many files present in the .gz file are not in the .exe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1150829&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

4 4

MSVC 7.1 bug with recursive template typedefs
by Samuel Krempp 24 Feb '05

24 Feb '05

As I said in the thread in [boost-users] about "using boost::format with STLPort" ( <421CC3D6.4010600(a)crans.ens-cachan.fr> ), I've come across a bug with recent MSVC's (tested on MSVC 7.1, and apparently MSVC 8 fails the same way). Does anyone know if this is a known MSVC bug ? Or should someone report that ? The following sample causes error C2244 ("unable to match function definition to an existing declaration") template<class T> struct A { typedef T* some_type; }; template<class T> struct B { typedef typename A<T>::some_type le_type; le_type some_f(); }; template<class T> typename B<T>::le_type B<T>::some_f() { le_type x; return x; } Replacing B<T>::le_type with A<T>::some_type when defining B<T>::some_f() seems to work around the bug. Regards, -- Samuel

2 1

RE: [boost] Re: Boost library inclusion: generic tree containers?
by Brian Braatz 24 Feb '05

24 Feb '05

Extremely interesting. I am working on a similar thing. Except I am doing this- the iterators take policies which tell how to get the parent and children of a node I am sorry I have not dug DEEP into either bodies of work yet. But in a nutshell, I am holding a tree of objects, and then using a template library (similar to BIL- except it is "classical Interface based programming") to QueryInterface (QI) the objects. (this is the opposite of how BIL works) I have gotten working the ability to QI the objects and apply operations to anything in the tree from X node down based on interface supported. This very curious technique is one I am working to evolve into something for controlling dynamic UI objects. In any case, I am writing this to share what I have been working on. Maybe it will give you some ideas. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Richard Peters Sent: Wednesday, February 23, 2005 12:44 AM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost library inclusion: generic tree containers? ----- Original Message ----- From: "Rene Rivera" <grafik.list(a)redshift-software.com> > Additionally, I'm also of the opinion that the "iterator" concept should > be kept as it's currently used in STL. An object that does more than an > iterator, because it happens to be an iterator in a tree should be > called something else, "cursor" comes to mind. If it's really > masquerading as a sub-tree, or a tree, then call it a tree. If it's a > pointer to a node in the tree, then perhaps a "node_pointer". Mixing the > terms will just cause more confusion than it's worth. Reading some of > your later posts I can see the confusion already creeping in. My > suggestion would be for you to formalize the different parts of a tree: > > * node; Holder for the value, structure pointers, and tree coloring > information > > * cursor; pointer to a node with tree specific operations to move the > cursor within the tree and to interrogate the tree > > * iterator; linear traversal of the nodes in the tree > > * tree; the container of nodes and producer of cursors and iterators, > and the needed allocators I think these formalizations of different parts of the tree is a very good start, but I'd like to see the iterator eliminated for a while, or at least totally decoupled from the tree: The reason for this is Separation of Concerns. A tree class is a container quite similar like the standard containers in that it stores values, but the big difference is that the structure of the tree matters, instead of the sequence. Therefore, I think the tree class should provide functions to navigate through the tree, and functions to alter the structure of a tree, like insertion, deletion, and rotation. These functions should probably work on things like the above-defined cursor. Once this tree class is built, then it is time to start thinking how the structure of the tree should be translated to flat sequences. There are of course a lot of options: depth first, breadth first, only a single level, or from top to a single node. Navigating in this way is done via 'normal' iterators. These iterators work on cursors, and should not be a part of the tree class itself (the iterator type should not be a member of the tree class). These iterators are like 'cursor-to-iterator adaptors'. So I guess my point is this: The tree doesn't need a normal or default or any iterator type, because it doesn't have a proper meaning: a tree is about structure, not about sequence. Translating that structure into a sequence can be done outside the tree. best regards, Richard Peters _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[typeof] template template parameters, etc.
by Arkadiy Vertleyb 24 Feb '05

24 Feb '05

Hi all, The typeof submission has been updated to include the latest features, most notably support for *template template parameters*. Please take it in the in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/ (typeof.zip). (Most credit for the template template parameters support goes to Peder). Among other additions are support for enum template parameters, and reused template parameters, such as in: template<class T, T n> class x; Also the REGISTER_TEMPLATE_X macro has been eliminated. Instead, the REGISTER_TEMPLATE macro has been "overloaded" to cover all the cases of template registration. Please see the documentation for more details. Regards, Arkadiy

3 2

RE: [boost] Re: ANN: review of FSM library starts
by Simon Gittins 24 Feb '05

24 Feb '05

Hi Andreas [snip guard discussion] > > The equivalent with a custom reaction would look as follows: > > struct StState : fsm::simple_state< StState, StOuter, > fsm::custom_reaction< EvEvent > > > { > fsm::result react( const EvEvent & evt ) > { > if ( cond ) > return transit< StRes0 >( &StRes0ActCtxt::Action0, evt ); > else > return transit< StRes1 >( &StRes1ActCtxt::Action1, evt ); > } > }; > > For a human, IMHO this is easier to read. Easier, but less consistent. In complicated fsms (many transitions, lots of state local data and functions), I find it extremely useful to separate the 'state' (as it would appear on a state chart) from the 'other stuff' (local variables, local functions - anything looking like 'normal' c++). Given that guards tend to be fairly common in real world fsms, we should be able to spot them in the same way we spot normal transitions. > > > I haven't thought about the implementation too much admittedly. > > Having > > this would be a big help in automatically generating UML state charts. > > Agreed. It is much easier to implement a tool that only needs to look at > the state declarations than one that additionally also needs to analyze > code inside functions. For this reason I think I will eventually add a > construct similar to the one you suggested. But, since such a tool does > not yet exist (to my knowledge), this is of fairly low priority at the > moment. > OK. My argument is largely philosophical. > > The library produces large binaries. > > The produced binaries certainly will never be small. Out of curiosity, > do you have any numbers (number of states -> size of executable)? > I just ran a few tests. The original camera example compiles to 103k using -O3 and -DNDEBUG (and the other options specified in the Makefile in the distribution). When stripped, the size came down to 56k. I added a new nonsense state in Shooting.hpp: struct Shooting2 : fsm::simple_state<Shooting2,Camera, fsm::transition<EvShutterRelease,NotShooting> > {}; I also changed Shooting's EvShutterRelease to transition to the new Shooting2 state. The compile size increased to 111k, and the stripped size increased to 61k. In my application (as described below), I added a state with 9 transitions that was empty otherwise. When compiled with -g and stripped (our current 'release mode'), the size of the executable increases by around 30k. I didn't spend too much time on these tests, and I ran them with a version of boost::fsm that is a few months old (my apologies). > > It does however, appear to scale > > reasonably well (anecdotally, it seems about linear with the number of > > states). The in memory footprint is of the same order of magnitude as > > the binary size. > > I guess that is for the hundreds of machine objects you mention below? Yes. The in memory size is not important for this application (we have far more RAM than persistent storage). Regards Simon Gittins ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

2 1