- Boost - lists.boost.org

[documentation]Need for "programmar's guide" or "tech notes"
by Larry Evans 08 Jan '07

08 Jan '07

Periodically, and probably inevitably, someone thinks of a possibly better way to do something in a boost library. For example, I recently got the "brilliant" idea to maybe use inheritance to check whether an item was already in an mpl::set and thus reducing, what I assumed, was at least a linear time complexity for the has_key metafunction. Although: http://www.boost.org/libs/mpl/doc/refmanual/has-key.html claims "Amortized constant time" complexity, I assumed the compiler has to do a linear lookup at least once for each has_key instantiation. After that, for each occurrence of the has_key with the same template arguments, I guess the compiler has a constant time (using a hash map?) method for finding the instantiation. Anyhow, that was my motivation. The basic idea idea was to use inherit2<Member,TailSet> where Member was the Member to be inserted into a set, and TailSet was the members inserted before Member. Then has_key would simply use type_traits is_base_of<Member,TailSet> to see if Member was a member of TailSet before doing the insertion. If it was already a member, the just return TailSet, if not, then return inherit2<Member,TailSet>. Of course, before starting to code, I thought it might be a good idea to see how mpl currently implemented the associative containers in case this idea was already being used :) However, when I looked at the mpl code to try to understand the the implementation, I got lost. For example, the output from cpp produces: # 25 "/home/evansl/prog_dev/boost-cvs/ro/boost/boost/mpl/set/aux_/has_key_impl.hpp" 2 namespace boost { namespace mpl { template <> struct has_key_impl <aux::set_tag > { template < typename Set, typename T > struct apply # 47 "/home/evansl/prog_dev/boost-cvs/ro/boost/boost/mpl/set/aux_/has_key_impl.hpp" : bool_ < (sizeof (Set:: is_masked_ (aux::ptr_to_ref (static_cast < Set * >(0)), static_cast < aux::type_wrapper < T > *>(0))) == sizeof (aux::no_tag)) > { }; }; } } # 19 "/home/evansl/prog_dev/boost-cvs/ro/boost/boost/mpl/set/aux_/at_impl.hpp" 2 I couldn't figure out the purpose of static_cast or Set:: is_masked_ ; however, it seemed there was no counterpart to inherit2; so, I assumed I wasn't reinventing the wheel (of course I "conveniently" didn't notice that apparently no linear time complexity was involved). So, I forged ahead an implemented it ; however, I then realized that has_key<inhert2<Member,TailSet>,TailSet> would return true since TailSet was a supertype :( OK, so then I thought maybe using the template argument deduction method in section 9.10 of _C++ Template Metaprogramming_ (alias _C++TMP_) would avoid this. That's now in the boost vault under the "Template Metaprogramming" directory. Then I thought again. Using _C++TMP_ section 9.10 used a static_cast also; so I looked further in the cpp output and found: static aux::no_tag is_masked_ (s_item const &, aux::type_wrapper < T > *); and OOPS!, it was looking more like I'd reinvented the wheel after all :( (I'm not totally sure, but it looks like that's what was done. Please let me know if that's wrong.) A "programmer's manual" describing, at least briefly, the implementation, would help future redesigners find their way and avoid the pain of reinventing yet another wheel. This was called "technical notes" before: http://archives.free.net.ph/message/20051006.180034.8cd1ece3.en.html

5 4

Re: [boost] Review request: Boost.FSM
by Steven Watanabe 08 Jan '07

08 Jan '07

AMDG There is a potential deadlock in locking_state_machine.hpp locking_state_machine<...> fsm1; locking_state_machine<...> fsm2; Thread A fsm1.operator=(fsm2) { scoped_lock that_lock(fsm2.m_Mutex); Thread B fsm2.operator=(fsm1) { scoped_lock that_lock(fsm1.m_Mutex); The two threads deadlock. In Christ, Steven Watanabe

2 1

Boost threads library compilation
by akonix acnt 08 Jan '07

08 Jan '07

Hi folks, I'm having some trouble creating the exact threads library I need, which is "libboost_thread-vc71-mt-gdp-1_33_1.lib". I've tried a number of things after searching forums for similar problems, but still no go. The closest I've gotten is "libboost_thread-vc71-mt-1_33_1.lib" from running "bjam.exe -sTOOLS=vc-7_1 boost_thread". What am I missing? Thanks, ~Peter __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

[in_place] can't use initialization lists
by Mathias Gaunard 08 Jan '07

08 Jan '07

It is not possible to use initialization lists with in-place factories. Why that? Without that, in-place factories aren't really usable to forward to members. It would only require to make 'apply' return the address.

1 1

Re: [boost] [tools] gcc compiler version detection
by Sohail Somani 08 Jan '07

08 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Boris Gubenko > I said earlier, that to the best of my knowledge, we do not > provide prebuilt > gcc for our platforms. Turns out, my knowledge in this area > is incomplete > :-). For Tru64, we provide prebuilt binary on FreeWare CD. > For HP-UX, for > some versions of the OS, there is prebuilt package. For other > versions, the > customers need to build the compiler from sources. See, for example, > <http://hpux.cs.utah.edu/hppd/answers/4-5.html>. Sorry for > the confusion. Actually, I didn't see your @hp.com addy otherwise I would've told you that I've downloaded a prebuilt binary (64-bit gcc iirc) for HP-UX! Anyway, better safe than sorry! Sohail

2 1

Re: [boost] Review request: Boost.FSM
by Steven Watanabe 08 Jan '07

08 Jan '07

AMDG Andrey Semashev wrote: > Oh, you're right. But isn't it enough just to mark "m_fInitialized" as > "volatile"? According to 1.9/7 it would enforce the compiler to > initialize "m_StatesInfo" prior to setting "m_fInitialized". > No, m_StatesInfo has to be volatile too. In Christ, Steven Watanabe

2 1

[tr1/result_of] SFINAE propagation by design?
by Tobias Schwinger 08 Jan '07

08 Jan '07

Hi Doug and Boost community, I noticed that the Boost implementation of result_of uses inheritance to forward the type member of a nested result metafunction, so that result_of<...>::type can result in a substitution failure (and not an error when used in an appropriate context) if the nested result class template does not have a type member. It's surely a nice feature (also because it usually stops trace diagnostics at a reasonable point in case of an error). Should the standard text perhaps encforce that kind of implementation - e.g: [tr.func.ret.ret] 2 5 (b) If N>0, result_of<F(T1, T2, ... TN)> inherits from F::result<F(T1, T2, ... TN)> ? Comments? Regards, Tobias

3 4

Re: [boost] [tools] gcc compiler version detection
by Sohail Somani 08 Jan '07

08 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Boris Gubenko > > Sohail Somani wrote: > > Nice. I'd guess that those are the ones built by the > vendors though no? > > If you mean building the compiler on a target system as opposite to > installing some prebuilt binary, then yes, they are "built by > the vendors". > "vendors" being HP-UX and Tru64 customers in this case (to > the best of my > knowledge, we do not provide prebuilt gcc for our platforms). Yes that is what I meant. So in these cases, gcc 2.9-hppa-991112 != gcc 2.9 vanilla right? Of course, practically it probably makes no difference. Sohail

2 1

Re: [boost] [tools] gcc compiler version detection
by Sohail Somani 08 Jan '07

08 Jan '07

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Glenn Schrader > $> gcc --version Hi, is -dumpversion not a standard flag? # on redhat sohail@dev-tk-bld-rhel3:~$ gcc -dumpversion 3.2.3 # on cygwin $ gcc -dumpversion 3.4.4 Sohail

4 3

Re: [boost] [tools] gcc compiler version detection
by Sohail Somani 08 Jan '07

08 Jan '07

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Boris Gubenko > > Rene Rivera wrote: > > Hm, didn't know that existed... Looks like we can get the > relevant info > > by using both -dumpversion and -dumpmachine. > > Just be aware of the fact, that on HP-UX and Tru64 (and, may > be, some other > systems), the output of -dumpversion is not as "clean" as it > is on Linux: > > HP-UX > ----- > bash-2.03$ gcc -dumpversion > 2.9-hppa-991112 > bash-2.03$ > > Tru64 > ----- > cxxosf.zko.hp.com> gcc -dumpversion > 2.9-gnupro-99r1 > cxxosf.zko.hp.com> Nice. I'd guess that those are the ones built by the vendors though no?

2 1