March 2005 - Boost - lists.preview.boost.org

Re: [boost] Re: Logo Contest Current Tally
by Iain Hanson 07 Mar '05

07 Mar '05

On Mon, 2005-03-07 at 12:48 -0500, David Abrahams wrote: > christopher diggins <cdiggins(a)videotron.ca> writes: > [snip] > Well, now Joel and Jeff Garland have both told me by private mail that > there doesn't seem to be anything wrong with having a discussion about > what's worth voting for, and I am basically convinced. I think certain > aspects of the logo are more important than others and should be > considered. But before I start blurting out any specifics, let's hear > from the group. Is there any reason we shouldn't talk about how to > choose? We do almost everything at boost by public consensus. Why > not this time? > I think it would be a good thing. If people are influenced by it will be no different than the review process. I also have no problem with the running tally. /ikh

1 0

FSM Review
by Peter Petrov 07 Mar '05

07 Mar '05

I have used and watched closely this library for more than a year, since its early versions. Initially, we needed a good modern state machine framework for a project at the company I work for. After evaluating the possibilities, we decided to take the risk and go with Andreas' FSM, despite its early-alpha state at the time. Now, one year later, that choice has proved to be correct. We have used FSM in one more project and are planning to use it in future projects too. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? The documentation is very adequate. I was able to quickly understand how to use the basic features of the library, and then proceed to the advanced ones. At that time I had experience with different kinds of state machines, but primarily SDL-specified. FSM's documentation was my first introduction to UML state charts, and did the job well. The tutorial is excellent. The FAQ and Rationale sections give important answers to questions which are likely to arise. There is also an extensive Reference section, which I needed very rarely. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? To me, the design is good and follows naturally from the objectives of the library. It imposes some restrictions, although they can be overcome if necessary (for me it has not been necessary). For example, machines don't recognize polymorphic events, therefore they cannot "forward" unknown events to another machine. This can be circumvented by using a "wrapper" event around such events, which works, but only with asynchronous machines. Another example is the way that state machines are inherited - it's not very flexible and only allows altering how a state machine reacts to an already recognized event. One cannot add support for new events, except using again the "wrapper event" trick. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? The name (boost::fsm, Boost.FSM) is fine for me. Regarding separating the library into two parts, I prefer it being separated, since the Worker part is useful by itself. * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? It's as obscure as its complexity requires. At the same time it is stable and bug-free, which is proved by extensive bulk-testing in our labs. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it usable for embedded systems? Is the documentation clear on performance tradeoffs? The documentation is definitely clear on performance tradeoffs, and it's up to the potential user to take an informed decision. One tradeoff is that dispatch time is linear to the number of nested states. In my experience this is not a problem, since there are rarely more than two nested states, and I have never seen more than three. A possible problem is that states are constructed using operator new(). The documentation clearly states that, and the library allows overcoming the issue by specifying a custom allocator for the state machine, as well as writing custom operator new()'s for all state classes. I personally am against the second requirement and think that it complicates things too much. Specifying a custom allocator for the state machine should be enough. (this is mentioned in the documentation, in the Rationale section under "Memory management customization") * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? The greatest distinction of code written using the FSM library is its manageability. It's very easy to write and subsequently evolve state machines and most common mistakes are caught at compilation time. When state machines are involved, using FSM is definitely a great improvement over using a primitive framework, or not using a framework at all (the notorious switch/case idiom). Especially if the library's advanced features are used. * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? Used with MSVC++ 7.1 and GCC 3.x. Currently without problems. In the early versions there were some minor issues which Andreas has addressed quickly. Regarding older compilers, I don't think they should be supported by this library. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth study, as well as real-world usage. * Are you knowledgeable about the problem domain? To a good extent. I have developed two different state machine frameworks, although both of them were significantly lower level than FSM. I have also worked extensively with various kinds of state machines, mainly protocol-related and in telecom applications. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. Definitely.

2 1

[interfaces] Hand written interfaces
by Jonathan Turkanis 07 Mar '05

07 Mar '05

Hi All, I'm working on ways to make the Boost Interfaces library easier to use. This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones. I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4: 1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming. The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it. So here's my question. Consider the interface: interface IBar { void foo(const char*); int foo(int, int); }; Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); } int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; }; typedef interface< ibar_impl<_, _, _> > IBar; Best Regards, Jonathan

4 8

RE: [boost] Re: review of proposed fsm library
by Dave Gomboc 07 Mar '05

07 Mar '05

> > Otherwise you would be able to mix both synchronous and > asynchronous > > states in one machine, which doesn't make sense. > > While tangential to my original point about naturally > recursive structures, I'll take time out to disagree here > too. It _can_ make sense to combine async and sync behaviour > in different parts of a state machine when one is modeling > electrical circuits, e.g. in certain regions of the circuit > one may know that the behaviour is sync and not want to spend > extra CPU by going through all the async motions. I will quickly add that this issue (combining async and sync fsms) will occur whenever one has prior components that one wishes to assemble together, where some are async and some are sync. Dave

1 0

Re: [boost] Re: review of proposed fsm library
by Dave Gomboc 07 Mar '05

07 Mar '05

> > The distinction made between state and state_machine, > which I > consider to be unfortunate, was not justified in > the rationale... > > There is at least one good reason - the library supports both > synchronous and asynchronous state machines, which are > essentially different beasts and are operated quite > differently. No such distinction exists for states, therefore > they shouldn't be treated the same way as state machines. However, asynchronous_state_machine is separated from both state_machine and state. Ergo, the reason must lie elsewhere. I didn't delve deeply into the library's support for asynchronicity, but I did consider it odd and amusing that at the level of hardware circuitry, asynchronous behaviour is the default, and work is done to get synchronous behaviour by adding latches and a clock, but that for fsm (and many, many other software components rather higher-level than a J-K flip-flop) the opposite was true. I do understand it, but I am not convinced that in this case it was the correct decision. Unforunately, I have to leave for work now. :-) > Otherwise you would be able to mix both synchronous and > asynchronous states in one machine, which doesn't make sense. While tangential to my original point about naturally recursive structures, I'll take time out to disagree here too. It _can_ make sense to combine async and sync behaviour in different parts of a state machine when one is modeling electrical circuits, e.g. in certain regions of the circuit one may know that the behaviour is sync and not want to spend extra CPU by going through all the async motions. Dave

1 0

Re: [boost] Re: RPC library
by Iain Hanson 07 Mar '05

07 Mar '05

On Sun, 2005-03-06 at 22:59 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > To sum up then, your position is that: > > 1) CORBA is the be-all and end-all of distributed programming. > No. Its just the best that we have available. > 2) Anything not projected to need CORBA-style scaleability is just a "toy" and > not worthy of library support. > Probably. But the problem is that people build quick and dirty apps that grow like Topsy. Its the danger of this that make me against non scalable solutions. > > I guess you don't find much need for networking at all in Boost? At least not > beyond lowlevel socket API wrappers and assorted utilites that might be useful > for something like realtime socket apps. Anything beyond that can, and should, > be done with CORBA, regardless of scale and scope. > Doug Schmidt certainly tends to argue in this direction. However, given that CORBA is not ubiquitous and is not ever likely to be then there is always going to be a need for sockets. /ikh

1 0

Help need reed related to libboost_filesystem.lib
by Thota, Vimal 07 Mar '05

07 Mar '05

Dear friends, I am using the boost libraries for my project. When I am compiling the (libboost_filesystem.lib) with my project files libraries which is available in the ibs\filesystem\build\bin\libboost_filesystem.lib\vc7.1\release\runtime-l ink-dynamic , I am facing with the Linking issues which I have listed down. Are you people able to guess where I have gone wrong. Thanks, Vimal Thota Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::~dir_it(void)" (??1dir_it@filesystem@boost@@QAE@XZ) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0dir_it@filesystem@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@@Z) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(void)" (??0dir_it@filesystem@boost@@QAE@XZ) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_directory>::operator bool(void)const " (??B?$get@Uis_directory@filesystem@boost@@@filesystem@boost@@QBE_NXZ) Disk Manager error LNK2001: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator++(void)" (??Edir_it@filesystem@boost@@QAEAAV012@XZ) Disk Manager error LNK2001: unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::filesystem::dir_it::operator*(void)const " (??Ddir_it@filesystem@boost@@QBE?AV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@XZ) Disk Manager error LNK2001: unresolved external symbol ___argc Disk Manager error LNK2001: unresolved external symbol ___argv Disk Manager error LNK2001: unresolved external symbol __mbctype Disk Manager error LNK2001: unresolved external symbol __mbctype Disk Manager error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in msvcprtd.lib(newop_s.obj) Disk Manager error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in msvcprtd.lib(newaop_s.obj) Disk Manager error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in MSVCRTD.lib(MSVCR71D.dll) Disk Manager error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in MSVCRTD.lib(MSVCR71D.dll) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::~dir_it(void)" (??1dir_it@filesystem@boost@@QAE@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0dir_it@filesystem@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(void)" (??0dir_it@filesystem@boost@@QAE@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::ctime>::operator long const *(void)const " (??B?$get@Uctime@filesystem@boost@@@filesystem@boost@@QBEPBJXZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_archive>::operator bool(void)const " (??B?$get@Uis_archive@filesystem@boost@@@filesystem@boost@@QBE_NXZ) referenced in function "public: bool __thiscall DirectoryWatcher::next_archived(void)const " (?next_archived@DirectoryWatcher@@QBE_NXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_directory>::operator bool(void)const " (??B?$get@Uis_directory@filesystem@boost@@@filesystem@boost@@QBE_NXZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::mtime>::operator long const *(void)const " (??B?$get@Umtime@filesystem@boost@@@filesystem@boost@@QBEPBJXZ) referenced in function "public: long __thiscall DirectoryWatcher::next_age(void)const " (?next_age@DirectoryWatcher@@QBEJXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall DMWorkflowInterface::~DMWorkflowInterface(void)" (??1DMWorkflowInterface@@QAE@XZ) referenced in function "public: void * __thiscall DMWorkflowInterface::`scalar deleting destructor'(unsigned int)" (??_GDMWorkflowInterface@@QAEPAXI@Z) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall DMWorkflowInterface::DMWorkflowInterface(void)" (??0DMWorkflowInterface@@QAE@XZ) referenced in function "public: virtual void __thiscall DiskManagerService::MainThread(void)" (?MainThread@DiskManagerService@@UAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: bool __thiscall boost::filesystem::dir_it::operator!=(class boost::filesystem::dir_it const &)const " (??9dir_it@filesystem@boost@@QBE_NABV012@@Z) referenced in function "private: void __thiscall DiskManagerService::check_watchers(class std::map<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class DirectoryWatcher *,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class DirectoryWatcher *> > > &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?check_watchers@DiskManagerService@@AAEXAAV?$map@V?$basic_string@DU?$ch ar_traits@D@std@@V?$allocator@D@2@@std@@PAVDirectoryWatcher@@U?$less@V?$ basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@V?$allocat or@U?$pair@$$CBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@ std@@PAVDirectoryWatcher@@@std@@@2@@std@@ABV?$basic_string@DU?$char_trai ts@D@std@@V?$allocator@D@2@@3@@Z) Disk Manager error LNK2019: unresolved external symbol "public: bool __thiscall boost::filesystem::dir_it::operator==(class boost::filesystem::dir_it const &)const " (??8dir_it@filesystem@boost@@QBE_NABV012@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator++(void)" (??Edir_it@filesystem@boost@@QAEAAV012@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator=(class boost::filesystem::dir_it const &)" (??4dir_it@filesystem@boost@@QAEAAV012@ABV012@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::filesystem::dir_it::operator*(void)const " (??Ddir_it@filesystem@boost@@QBE?AV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol __mbctype referenced in function "protected: long __thiscall CEditView::OnFindReplaceCmd(unsigned int,long)" (?OnFindReplaceCmd@CEditView@@IAEJIJ@Z) Disk Manager fatal error LNK1120: 17 unresolved externals Disk Manager warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

[optional]output
by Gennadiy Rozental 07 Mar '05

07 Mar '05

Hi, Maybe it's something that I missed, but why optional doesn't define output operator something like this: template<typename T> inline std::ostream& operator<<( std::ostream& ostr, optional<T> const& v ) { if( v ) ostr << *v; return ostr; } Gennadiy

1 0

Boost Logo Contest Request for independent tally
by Joel de Guzman 07 Mar '05

07 Mar '05

Hi, Jonathan noted a minor error in the recent (initial) tally where his entry got listed twice. In the interest of fairness... I would like to request for help. If anyone is interested in doing an independent tally, I'd gladly provide him/her with access to the submitted votes. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 2

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by Jonathan Turkanis 07 Mar '05

07 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

3 9