- Boost - lists.boost.org

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX
by JOAQUIN LOPEZ MU?Z 15 Oct '04

15 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 8, 2004 5:04 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX > Markus Schöpflin wrote: > > > Joaquín Mª López Muñoz wrote: > > > >> mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) > >> line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: > >> [very long expression] > > > > A quick google search indicates that this is a problem with gcc > on alpha > > when compiling with debug symbols. A possible workaround might > be to use > > -gstabs instead of -g, I'll try it ASAP. > > I did some experiments and the only way to compile these files it > to > disable debug symbols completely. I have done that on the toolset > for gcc > used for the regression runs, I hope it helps to clean up some of > the errors. > Hi Markus, I see that the failures are gone, thank you! Would you be so kind as to explain to me which compiler options you touched to make this work? I'd like to add that information on the "Compiler specifics" section of Boost.MultiIndex docs. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[filesystem] file size
by Stefan Slapeta 15 Oct '04

15 Oct '04

Is there any rationale behind the lack of a function that returns the file size of a directory entry? (or do I miss something?) Stefan

2 1

[Boost-bugs] [ boost-Bugs-1047775 ] object_protocol.hpp - setitem: void func cant return a value
by SourceForge.net 15 Oct '04

15 Oct '04

Bugs item #1047775, was opened at 2004-10-15 06:20 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=1047775&group_… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: David Abrahams (david_abrahams) Summary: object_protocol.hpp - setitem: void func cant return a value Initial Comment: boost/python/object_protocol.hpp: template <class Key, class Value> void setitem(object const& target, Key const& key, Value const& value) { return setitem(target, object(key), object(value)); } won't compile on Tru64 Unix C++6.2 because of the return statement in a void function. Regards, Dario Cimafonte ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1047775&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

type_traits::is_polymorphic
by Richard Smith 15 Oct '04

15 Oct '04

Is there any chance that the virtual function boost::detail::is_polymorphic_imp1<T>::d2::foo defined in boost/type_traits/is_polymorphic.hpp could be renamed to have a name less likely to cause conflicts? I appreciate that the unique struct prevents this function from overriding any virtual functions in the base class, but it still has the potential to hide base class functions, which, at suitable warning levels in many compilers, causes a lengthy warning to be emitted. Although foo is unlikely to be a common function name in production code (well, good production code, anyway), it is the sort of name that is frequently found within unit tests and so forth. (For example, the name ``foo'' is used 2657 times in the gcc testsuite.) Cheers, Richard Smith

3 3

extending boost::io
by Israel Fdez. Cabrera 14 Oct '04

14 Oct '04

Hi, I'm working with the boost's IOStream library adding compression/decompression methods others than zip, gzip and bzip2. I'm working too adding support to OLE Compound Documents to the same library, I'd like to "extract" a containt OLE Document using boost::io stream interface. The problem is I'm not sure how to "return or extract" more than one document or compressed file from a stream. All boost examples boost::io::copy() a whole stream to another but not just part of it. I'll appreciate any help, best regards and thank you for such a helpful library Israel

3 7

[tuple] regression with borland-5_6_4
by Joaquín Mª López Muñoz 14 Oct '04

14 Oct '04

Hi, I've noted that tuple_test_bench is marked as a regression for BCB 564: http://tinyurl.com/62plc However, in the the following page listing Boost 1.31 issues, this test seems to appear as a failure: http://tinyurl.com/6j68r The problem seems to be related with BCB having a hard time with specializations on const types. So my questions are: 1. Is this really a regression or an expected failure as it seems to be present back in Boost 1.31? 2. Scanning the list, some folks claim that the problem goes away with BCB 5.6.4, yet what we have have does not indicate so. Anyone knows the status of this problem wrt to the version of the Borland compiler? 3. tuple already has an alternative implementation for those compilers without PTS, driven by BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION (line 26 of boost/tuple/tuple.hpp). Could someone with local access to the Borland compiler try to apply the alternative implementation by replacing that line with the following? #if defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION)|| defined(BOOST_BCB_PARTIAL_SPECIALIZATION_BUG) (I don't know if BOOST_BCB_PARTIAL_SPECIALIZATION_BUG really relates to this particular problem, but its name fits perfectly well.) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

BLL on a vector of tuples
by Brian Riis 14 Oct '04

14 Oct '04

Hi list, I have a situation where I need to find a tuple from a vector based on the value of one of the tuple's values. vector<tuple<string, int, int> > v; Basically I need the last int, and all I'm supplied is the first int. I thought of using lambda expressions for this, and dug into the documentation for that (so, this is my first real experience with BLL...and any lambda expressions for that matter). After some experimentation, I ended up with something akin to this. typedef boost::tuple<std::string, int, int> myTuple; std::vector<myTuple> v; ... using namespace boost::lambda; int id = <the value for the first int, that I need to find> std::vector<myTuple>::iterator iter = std::find_if(v.begin(), v.end(), (bind(&myTuple::get<1>, _1) == id)); My compiler (MinGW-3.4.2) gives me an error message on that last line: "error: cannot resolve overloaded function `get' based on conversion to type `SOCKET'" I'm sure it's trying to tell me where I've messed up, but I can really see it. (no doubt it's due to lack of experience with BLL, or lack of intelligence; quite possibly both :)) Am I totally out to sea here? If so, I'd be joyous if someone would light a beacon for me! :) TIA -- /Brian Riis

2 2

TR1 library extensions in libstdc++ - SmartPtr
by Jonathan Wakely 14 Oct '04

14 Oct '04

Hi, The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf I have volunteered to look into modifying the Boost smart pointers to match the TR1 specs and the libstdc++ coding standards. I realise I can modify the files and include them under the terms of the Boost licence, but the last Boost code to be used in libstdc++ (the concept checks) were licensed under the GPL. I believe that was something Jeremy Siek (as copyright holder) allowed specially: http://gcc.gnu.org/ml/libstdc++/2001-04/msg00050.html Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations. That wouldn't affect the copies in the Boost tree, of course. Allowing this would greatly speed up the process of adding TR1 features to libstdc++ and tracking the draft TR as it evolves. I am prepared to rewrite the smart pointers without using Boost code if necessary, but would obviously prefer not to, when the Boost implementations are the reference ones that were used for the TR1. I eagerly await responses, as whether I have to rewrite the classes or not will have quite an impact on my free time :-) jon -- "The following story is true. By which I mean false. It's all lies. But they're entertaining lies. And in the end, isn't that the real truth. The answer, is no." - Leonard Nimoy, in "The Simpsons"

9 23

bug in boost/date/time/date_parsing.hpp - wrong wchar_t -> char conversion
by Vyacheslav E. Andrejev 14 Oct '04

14 Oct '04

Hi there, I've found wrong usage of std::stringstream::narrow in date_parsing.hpp template<class date_type, class iterator_type> inline date_type from_stream_type(iterator_type& beg, iterator_type& end, wchar_t) { std::stringstream ss(""); while(beg != end) { ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown } return parse_date<date_type>(ss.str()); } In the code above ss.narrow does nothing, because the argument of narrow function already has type char, not wchar_t at all. I think, that the right code should be like this: template<class date_type, class iterator_type> inline date_type from_stream_type(iterator_type& beg, iterator_type& end, wchar_t) { std::stringstream ss(""); while(beg != end) { ss << std::use_facet<std::ctype<wchar_t> >(std::locale()).narrow(*beg++, 'X'); } return parse_date<date_type>(ss.str()); } -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC E-mail: vandrejev(a)excelsior-usa.com ICQ: 7152604

1 0

bug in boost/date_time/time_system_split.hpp - wrong static_cast
by Vyacheslav E. Andrejev 14 Oct '04

14 Oct '04

Hi there I've found a minor bug in time_system_split.hpp. In the following code date_duration_type day_overflow(static_cast<int_type>(doff)); int_type is __int64 if BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG is on. But date_duration_type contructor expects int_adaptor<long> instead. So static_cast is useless here. I think, that right code should look like this: date_duration_type day_overflow(static_cast<date_duration_type::duration_rep_type>(doff)); Proposed patch's attached to this post. -- ______________________________ Vyacheslav E. Andrejev System Architect Excelsior, LLC E-mail: vandrejev(a)excelsior-usa.com ICQ: 7152604

1 0