- Boost - lists.boost.org

[test] How to structure tests where compilation should fail?
by Matthias Schabel 02 Mar '07

02 Mar '07

Naturally, for compile-time units there are some cases where compile- time failure is the correct behavior - how should I structure tests so that this is recognized? Presumably I need to have a separate test source file for each expected compilation error, right? Matthias

5 7

stack-based std::containers
by Michael Marcin 02 Mar '07

02 Mar '07

I have functions like say a quartic equation solver that can return a variable number of solutions. It would be clean IMO to return or pass by reference a std::vector or like container that store the solutions. However heap allocation is fairly expensive here so the usual solution is to have a local array with max solutions elements and pass that by reference into the solver and return the number of solutions. This is ugly to use and read. Is there a library for stack-based std-like containers? Alternatively is it possible to make an compatible stack-based allocator for std::vector using alloca? Thanks, Michael Marcin

3 2

Re: [boost] [serialization] performance comparison
by brass goowy 02 Mar '07

02 Mar '07

Martin Slater writes: >> >> We haven't yet been able to provide support for the build integration >> that you mention, but we've thought about it and hope to deliver >> something there. > >Anything that involves the build process contacting a webserver is >unacceptable as there is just far to much that can go wrong inbetween >that would mean a build cannot be done. I agree it is a tenuous system. On the other hand how much of a leap is it from using a network file system when building? There is usually more distance involved, but in both cases requests and replies are made. People around the world work on maintaining and improving the internet and it isn't like reliability is needed just for online code generation. >And I've yet to see any indication you support even a fraction of what >boost serialisation does, versioning and a fully general system for user >defined types and archives the first things that come to mind, In the past, differences between the B.Ser and EE approaches to version support have been discussed in this group. http://lists.boost.org/Archives/boost/2006/05/104748.php http://lists.boost.org/Archives/boost/2006/05/104882.php I don't think there is anything about the EE approach that prevents doing what B.Ser does with archives. >speed is >only a part of the equation and not something I have run up against with >boost serialisation that a small amount of work on a more custom archive >has solved (which was similar to the work done that is now in 1.34). No one has answered my question of how to obtain 1.34. I tested with 1.35. It was better than 1.33.1, but still more than three times slower than the EE approach in the list<int> test. >That's not to say I'm not interested in helping to find places where >boost.serialisation could be faster, hence why I'm in this discussion. What Ramey said earlier in the thread about possibly ditching streambufs makes sense to me. Beyond that it would be helpful to be able to review the code that compilers generate in a simple B.Ser use. I don't know of any compilers that have an option to reveal that though. You could compare the assembly code, but it shouldn't have to be done at that level. Sholom, Brian Wood Ebenezer Enterprises www _______________________________________ your personal webtop. @ http://www.goowy.com

2 1

[Boost-bugs] [ boost-Bugs-1672139 ] End time incorrect for Australian daylight savings
by SourceForge.net 02 Mar '07

02 Mar '07

Bugs item #1672139, was opened at 2007-03-02 12:51 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=1672139&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: date_time Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Magic OP (magic_op) Assigned to: Jeff Garland (az_sw_dude) Summary: End time incorrect for Australian daylight savings Initial Comment: The following line in boost-1_33_1\boost\date_time\local_timezone_defs.hpp Line 120: static int dst_end_offset_minutes() { return 120; } should be changed to static int dst_end_offset_minutes() { return 180; } If my understanding of this variable is correct, that is, it refers to the end time in daylight savings time. In this case at 3am dst the time is changed back to 2 am std time. The comments in the file for other places seem to suggest this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1672139&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

Re: [boost] boost::signal thread safety
by Stjepan Rajko 02 Mar '07

02 Mar '07

> From: "Philippe Vaucher" <philippe.vaucher(a)gmail.com> > Subject: [boost] boost::signal thread safety (implied question: is > boost::function thread safe ?) > Well, the subject says it all ;) > This question comes because boost::signal's documentation says it's not > thread safe, but I have trouble finding exactly why it isn't. > Another issue that might be of concern is whether a slot is being disconnected from a signal in one thread while a value is being sent through that same signal in another thread. If the one thread is iterating through the connected slots while the other is removing a slot from the list, unexpected behavior/crash might occur. Doug said that some people have recently been working on Boost.Signals and specifically addressed thread safety, but I'm not sure what the status of that is. Regards, Stjepan

3 2

[date_time] global locale affects to_iso_string(date)
by Andrew Gvozdev 01 Mar '07

01 Mar '07

There is a problem in date_time library with function to_iso_string(date) when a global locale is set. The library creates a stream to output year which applies global locale formatting including thousand separators, i.e. "2,002". Look at this test: Added to testtime_formatters.cpp: const std::locale& original_locale(std::locale::global(std::locale("en_US.utf8"))); check("simple+loc: [" + t1_result + "]==[" + to_simple_string(t1) + "]", t1_result == to_simple_string(t1)); check("iso+loc: [" + iso_result + "]==[" + to_iso_string(t1) + "]", iso_result == to_iso_string(t1)); check("iso ext+loc: [" + iso_ext_result + "]==[" + to_iso_extended_string(t1) + "]", iso_ext_result == to_iso_extended_string(t1)); std::locale::global(original_locale); results in: execute-test ../../../bin/boost/libs/date_time/test/testtime_formatters.test/gcc/debug/te sttime_formatters.run ====== BEGIN OUTPUT ====== 2002-Jan-01 01:02:03 ... FAIL :: simple+loc: [2002-Jan-01 01:02:03]==[2,002-Jan-01 01:02:03] FAIL :: iso+loc: [20020101T010203]==[2,0020101T010203] FAIL :: iso ext+loc: [2002-01-01T01:02:03]==[2,002-01-01T01:02:03] ... 14 Tests Executed: 3 FAILURES As email at the end suggests this problem is known for some time. Are there any plans to fix it? If I may suggest, the fix could be to imbue the stream with classic locale for the purpose of year output: date_formatting.hpp template<class ymd_type, class format_type, class charT=char> class ymd_formatter { public: static std::basic_string<charT> ymd_to_string(ymd_type ymd) { typedef typename ymd_type::month_type month_type; std::basic_ostringstream<charT> ss; ss.imbue(std::locale::classic()); // <--- The fix ss << ymd.year; ss.imbue(std::locale::locale()); // <--- The fix if (format_type::has_date_sep_chars()) { ss << format_type::month_sep_char(); } //this name is a bit ugly, oh well.... month_formatter<month_type,format_type,charT>::format_month(ymd.month,ss); if (format_type::has_date_sep_chars()) { ss << format_type::day_sep_char(); } ss << std::setw(2) << std::setfill(ss.widen('0')) << ymd.day; return ss.str(); } }; Thanks, Andrew > From: Jeff Garland <jeff <at> crystalclearsoftware.com> > Subject: Re: date serialization fails with non-standard locales > Newsgroups: gmane.comp.lib.boost.user > Date: 2005-05-28 14:39:38 GMT (1 year, 39 weeks, 4 days and > 15 minutes ago) > > On Sat, 28 May 2005 02:10:02 +0200, Paolo Coletta wrote > > I'm not sure if this is a bug or if I'm misusing the > library. It seems > > that serializing boost::posix_time_ptime fails when using > non-standard > > locale (Windows Xp OS - vc 7.1 compiler - boost updated > from CVS few > > days ago). > > > > As an example, try adding > > > > std::locale::global( std::locale( "en" ) ); > > > > as the first line of the testtime_serialize.cpp; this > causes the test > > to fail when doing > > > > ia >> pt2; > > > > I tried to understand what was happening, and it seems to > me that the > > problem is in keeping into account locale when serializing, while > > ignoring it while unserializing. > > In greg_serialize.hpp > > to_iso_string(d) > > may generate something like "2,0050527"; the method > > from_undelimited_string(ds) > > used to load the serialized date, expects a 4,2,2 format. > > It looks like the problem is that the stream output is > including a thousands seperator when it shouldn't. The > serialization should be 20050527 with no number seperators. > So it appears that we cannot depend on the stream not using > the thousands separtor in date_time/date_formatting.hpp (line > 81) where the year is actully output: > > std::basic_ostringstream<charT> ss; > ss << ymd.year; > > We'll look into fixing this... > > Jeff

2 1

[regex] patches for Tru64 and HP-UX
by Boris Gubenko 01 Mar '07

01 Mar '07

Attached patches for 3 regex library headers for the issues with regex library test concept_check on Tru64/cxx and HP-UX/aCC6 described in: <http://thread.gmane.org/gmane.comp.lib.boost.devel/154587> . concepts.hpp_patch (necessary for Tru64 and VMS) . concept_archetype.hpp_patch (necessary for HP-UX) . regex_traits.hpp_patch (necessary for HP-UX) . The patch for concepts.hpp adds char_type to the explicit specialization of template std::char_traits on type boost::char_architype. char_type is necessary for the platforms using Rogue Wave V2.0 (Tru64 and AlphaVMS) and RW V3.0 (iVMS). While it is not necessary for HP-UX/aCC6 using RW V2.2, it does not break it. Adding char_type also does not break compilation on HP-UX with Gnu libstdc++ and STLport. In the patch, char_type is conditionalized as the following: template<> struct char_traits<boost::char_architype>{ #if defined(__DECCXX) && BOOST_WORKAROUND(_RWSTD_VER, >= 0x0203) typedef boost::char_architype char_type; #endif }; so it affects only Tru64, AlphaVMS and iVMS. Actually, I don't think that any conditionalization is necessary because adding this typedef does not seem to do any harm. If this patch is applied, regex library test concept_check can be removed from explicit-failures-markup.xml for toolset "hp_cxx-71_006_tru64" (this is release platform). . The patch for concept_archetype.hpp adds overload for std::__iterator_category returning __unknown_iterator_tag. This overload allows std::basic_string to be constructed, as John Maddock put it in: <http://archives.free.net.ph/message/20060824.111121.1b255f03.en.html> from "iterator types it doesn't know about". This patch is necessary for RW V2.2. I've conditionalized it with: #if defined(__HP_aCC) && BOOST_WORKAROUND(_RWSTD_VER, == 0x02020100) but I think, that 'defined(__HP_aCC)' can be omitted because this is a pure Rogue Wave library issue. I conditionalized it the way I did out of fear of breaking other platforms using the RW library that I cannot test the patch on. . The patch for regex_traits.hpp changes aCC - specific conditionalization which is wrong for aCC6. I have no idea why this conditionalization was necessary in the first place, but I did not remove it: I just restricted it to pre-aCC6 compilers. With patches for concept_archetype.hpp and regex_traits.hpp, regex library test concept_check passes on HP-UX. Also, tr1 library tests std_test_regex and test_regex that were previously failing, now pass. If the patches for concept_archetype.hpp and regex_traits.hpp are acceptable, please, apply them. If they are applied to HEAD only, please, mark regex library test concept_check and tr1 library tests std_test_regex and test_regex expected failures in 1.34 on HP-UX/aCC6 (toolset "acc"). Thanks, Boris

3 11

[optional] optional<T &> and the arrow operator
by Joe Gottman 01 Mar '07

01 Mar '07

I’ve discovered that you can’t use the arrow operator with an object of type optional<T &>; For instance , the following code fails: vector<double> v; optional<vector<double> &> pv(v); pv->push_back(2); The code (*pv).push_back(2) succeeds. On MSVC 7.1 on Windows XP I get the following error message: (I get a similar one using gcc 3.4 on Unix). c:\code\boost\optional\optional.hpp(371) : error C2664: 'boost::optional_detail::optional_base<T>::pointer_const_type boost::optional_detail::optional_base<T>::cast_ptr(const boost::optional_detail::optional_base<T>::internal_type *,boost::optional_detail::optional_base<T>::is_not_reference_tag) const' : cannot convert parameter 2 from 'boost::integral_constant<bool,true>' to 'boost::optional_detail::optional_base<T>::is_not_reference_tag' with [ T=std::vector<double> & ] and [ T=std::vector<double> & ] No constructor could take the source type, or constructor overload resolution was ambiguous c:\code\boost\optional\optional.hpp(371) : while compiling class-template member function 'boost::optional_detail::optional_base<T>::pointer_type boost::optional_detail::optional_base<T>::get_ptr_impl(void)' with [ T=std::vector<double> & ] c:\code\boost\optional\optional.hpp(407) : see reference to class template instantiation 'boost::optional_detail::optional_base<T>' being compiled with [ T=std::vector<double> & ] c:\code\Networks\Computations\CppComputations\Forecasting\auto_DFS_2_00_computation.cpp(16) : see reference to class template instantiation 'boost::optional<T>' being compiled with [ T=std::vector<double> & ] Joe Gottman

6 10

[1.34][filesystem] missing inline in convenience.hpp
by arvid＠cs.umu.se 01 Mar '07

01 Mar '07

I'm testing the RC 1.34 branch and I believe there should be an inline statement in one of the macros at the top of the convenience.hpp header. from line 29 # define BOOST_FS_FUNC(BOOST_FS_TYPE) inline BOOST_FS_TYPE typedef boost::filesystem::path Path; -# define BOOST_FS_FUNC_STRING std::string +# define BOOST_FS_FUNC_STRING inline std::string # define BOOST_FS_TYPENAME # endif Otherwise the functions extension and basename will get multiple definitions errors while linking. thanks, -- Arvid Norberg

1 0

Re: [boost] [1.34.0] intel-vc8-win-9.1 errors
by Eric Niebler 01 Mar '07

01 Mar '07

Sean Huang wrote: > There are quite a few intel-vc8-win-9.1 errors but it seems they are all > caused by a single problem shown below. If we can find a workaround for this > problem then intel 9.1 + VC8 can be added back to the release platforms. See > Huang-WinXP-x86_32 test results in the regression reports at > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/in > dex.html. > <snip> > > c_traits.cpp > .\boost/xpressive/detail/utility/boyer_moore.hpp(64): error: more than one > instance of overloaded function "std::fill_n" matches the argument list: > function template "void __cdecl std::fill_n(_OutElem (&)[_Size], > _Diff, const _Ty &)" > function template "std::_Enable_if<<expression>, void>::_Result > __cdecl std::fill_n(_OutIt, _Diff, const _Ty &)" > argument types are: (unsigned char [256], int, unsigned char) > std::fill_n(this->offsets_, uchar_max + 1, this->length_); > ^ I just changed this to: std::fill_n(static_cast<unsigned char *>(this->offsets_), uchar_max + 1, this->length_); That should remove the (bogus) ambiguity. Change committed to HEAD and RC. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0