January 2007 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-1631210 ] serialization of classes with overloaded operator & fails
by SourceForge.net 09 Jan '07

09 Jan '07

Bugs item #1631210, was opened at 2007-01-08 23:28 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=1631210&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: serialization of classes with overloaded operator & fails Initial Comment: the serialization of the following class fails to compile at line 363 in detail/iserializer.hpp, struct load_standard, method invoke, line void * x = & const_cast<typex &>(t); class wrapped_value { public: const int* operator & () { // returns the address of the wrapped integer, which may noy be the same as the address of the instance return &a; } template <typename Archive> void serialize(Archive& ar, const unsigned version) { ar & a; } private: int a; }; due to the overloaded '&' operator getting the address of the instance fails. a proposed patch is void * x = boost::addressof( const_cast<typex &>(t) ); which seems to compile and work correctly cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1631210&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[1.34.0] Status Report II
by Thomas Witt 09 Jan '07

09 Jan '07

Hi, This is the status of the 1.34.0 release as I see it. I'll update it on a roughly weekly basis. The main purpose of this is to make people aware of outstanding issues and maybe motivate some volunteers. Well by now everybody should have noticed that the beta release did not happen before new years. Lets try the same thing for 2007 then. That being said we are slowly inching forward. Some of the issues in the last report have been fixed. For a (probably incomplete) list of things please look at the end of this message New Issues ********** - build Possible documentation issue. http://article.gmane.org/ gmane.comp.lib.boost.devel/152751. No known fix. - date_time Fails qcc-3.3.5_gpp. No known fix. Possible documentation issue. http://article.gmane.org/ gmane.comp.lib.boost.devel/152753. No known fix. - ptr_map Thorsten proposed a patch as a follow up of this message http:// article.gmane.org/gmane.comp.lib.boost.devel/152788. I'd really like to have another set of eyes look at this before it goes in. - test http://article.gmane.org/gmane.comp.lib.boost.devel/152728. So far I did not get a definitive answer on whether this is a problem or not. - thread http://article.gmane.org/gmane.comp.lib.boost.testing/3790. Roland what is the status on this one? Existing Issues *************** Regression Tests ================ - concept_check Regressions for borland 5.8.2 and msvc 6.5. These should all be marked expected. Jeremy is going to take care of this. Jeremy? - regex Fails msvc-6.5 no known fix. - test Fails darwin-4.0.1, cw-9.4 no known fix. - utility Fails gcc-3.4.5_linux_x86_64 no know fix. As I said we are getting close, but we *really* need people to look at the outstanding issues. Build ===== - v2 transition There still seem to exist vestiges of the old build system in some places. See here: http://article.gmane.org/gmane.comp.lib.boost.build/14768 This issue is unresolved as of now. We are seeking help and input. Inspection ========== - File name guidelines We still have 4 file/directory names issues in the following components boost/archive/basic_streambuf_locale_saver.hpp: *N* name exceeds 31 characters tools/build/v2/example/make/main.cpp.pro: *N* name contains more than one dot character ('.') libs/test/build/msvc71_proj/config_file_iterator_test.vcproj: *N* name exceeds 31 characters regression/.htaccess: *N* leading character of ".htaccess" is not alphabetic I consider these showstoppers for the final release. Could the respective library authors please take care of this, now? - Broken Links We still show 116 broken links. Is the report broken or the docs? - License Copyright We still have large number of license copyright issues. To me the do we really need a license/copyright for xxx discussion is not very productive. My personal attitude is get over it and fix it. While this is not a showstopper fixing them will be well received by our users and now is the time to do it. Fixed Issues ************ - Lots of probably configuration related regressions in some msvc tests. Configuration fixed. Thanks Aleksey. - iostreams Fixed for cw-9.4. Thanks Joaquin. - Getting Started Guide This is now ready for release as I understand it. Thanks Dave! - File name guidelines The following were fixed boost/graph/maximum_cardinality_matching.hpp: *N* name exceeds 31 characters libs/graph/doc/lengauer_tarjan_dominator_tree.htm: *N* name exceeds 31 characters libs/graph/doc/sorted_erdos_renyi_generator.html: *N* name exceeds 31 characters Please let me know of issues not covered here. I'll add them to the list. Thanks Thomas Thomas Witt witt(a)acm.org

3 4

Re: [boost] Boost threads library compilation
by akonix acnt 09 Jan '07

09 Jan '07

Running "bjam.exe -sTOOLS=vc-7_1 -gdp boost_thread" produces "libboost_thread-vc71-mt-sgd-1_33_1.lib" Close but no cigar. ----- Original Message ---- From: Andrey Semashev <andysem(a)mail.ru> To: akonix acnt <boost(a)lists.boost.org> Sent: Monday, January 8, 2007 2:02:45 PM Subject: Re: [boost] Boost threads library compilation Hello akonix, Monday, January 8, 2007, 9:46:40 PM, you wrote: > 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? See: http://www.boost.org/more/getting_started.html According to this, "gdp" means debug mode compilation with debug-version of CRT, with STLPort. -- Best regards, Andrey mailto:andysem@mail.ru _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[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