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

date_time-1_33_1 - Get rid of warnings...
by Paolo Invernizzi 18 Mar '06

18 Mar '06

Hi all, Sorry in advance if this is not the proper way for suggest a little patch... Compilation with VC71 raise tons of possible loss of data warning when using the microsec_clock::local_time() or universal_time(), warnings that can be avoided adding cast to (int) and to (boost::uint32_t) in: date_time\microsec_time_clock.hpp(156) date_time\microsec_time_clock.hpp(175) //The following line will adjusts the fractional second tick in terms //of the current time system. For example, if the time system //doesn't support fractional seconds then res_adjust returns 0 //and all the fractional seconds return 0. int adjust = (int)resolution_traits_type::res_adjust()/1000000; boost::uint32_t sub_sec = (boost::uint32_t)(filetime % 10000000) / 10; // microseconds What is the correct procedure to supply a patch? thanks in advance. --- Paolo Invernizzi

2 1

Error with C linkage and how to configure Boost-1_33_1 on MAC OSX 10.4..
by Gaurav Kumar 18 Mar '06

18 Mar '06

hi all, My OS is MAC OSX 10.4 with gcc 4.0 and Xcode 2.2. I have downloaded the tar file boost-1_33_1.tar.gz from boost.org. I need to port COM component on Windows to MAC OSX. I have problems in Compiling the tar file. Commands i use to compile are Step 0: cd /usr/local/boost-1_33_1/ Step 1: ./configure Step 2: make It gives error as /usr/bin/ld undefined Symbol, ld returned with status 1.And at last it shows .......Failed updating 6 targets ........ .......Skipped 6 targets............. ........Updated 766 targets.......... Step 3:make install After this i open project in Xcode and on build it gives hundreds of error as error in C linkage. Suggest me a proper solution.So, that i can compile boost on MAC OSX 10.4. Can also provide me some configuration setting need to be done prior to installation of boost for Darwin. If u need anymore information do mail me. -Gaurav

1 0

[shared_ptr] Shall we add operator[]?
by Daniel Frey 18 Mar '06

18 Mar '06

Hello Boosters, haven't found whether or not this was proposed before, so here we go: What about adding an operator[] to shared_ptr: [...] #include <cstddef> // for std::size_t [...] // e.g. below operator* reference operator[] (std::size_t index) const // never throws { BOOST_ASSERT(px != 0); return px[index]; } [...] This makes it easier to wrap memory from system calls: Before: char** sym = ::backtrace_symbols(addr,n); // Lots of code here sym[0]; // access sym by index ::free(sym); // could be forgotten, code in between could throw, ... After: shared_ptr< char* > p( ::backtrace_symbols(addr,n), &::free ); // Lots of code here, allowed to throw now :) sym[0]; // still access by index, no funny syntax needed // no need to call ::free explicitly :) Hope you get the idea :) What do you think? Any problem with adding operator[] to make it more similar to a plain old C-pointer (while still being safe AFAICT)? Regards, Daniel

2 2

[Boost-bugs] [ boost-Bugs-1453180 ] mpl::remove compile error with gcc 4.1.0
by SourceForge.net 18 Mar '06

18 Mar '06

Bugs item #1453180, was opened at 2006-03-18 15:10 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=1453180&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: mpl Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eelis (eelis) Assigned to: Aleksey Gurtovoy (agurtovoy) Summary: mpl::remove compile error with gcc 4.1.0 Initial Comment: The following four lines fail to compile using gcc 4.1.0 with boost 1.33.1: #include <boost/mpl/vector.hpp> #include <boost/mpl/remove.hpp> template <typename> struct X { struct type {}; }; typedef boost::mpl::remove<boost::mpl::vector<int>, X<int>::type>::type T; Error: boost/mpl/aux_/preprocessed/gcc/template_arity.hpp: In instantiation of âconst int boost::mpl::aux::template_arity_impl<X<int>::type, 1>::valueâ: boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:93: instantiated from âconst int boost::mpl::aux::template_arity<X<int>::type>::valueâ boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98: instantiated from âboost::mpl::aux::template_arity<X<int>::type>â boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:123: instantiated from âboost::mpl::lambda<boost::mpl::same_as<X<int>::type>, mpl_::void_, mpl_::int_<1> >â boost/mpl/remove_if.hpp:57: instantiated from âboost::mpl::aux::remove_if_impl<boost::mpl::vector<int, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::same_as<X<int>::type>, boost::mpl::back_inserter<boost::mpl::vector0<mpl_::na> > >â boost/mpl/remove.hpp:33: instantiated from âboost::mpl::aux::remove_impl<boost::mpl::vector<int, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, X<int>::type, boost::mpl::back_inserter<boost::mpl::vector0<mpl_::na> > >â boost/mpl/remove.hpp:48: instantiated from âboost::mpl::remove<boost::mpl::vector<int, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, X<int>::type, mpl_::na>â t.cpp:4: instantiated from here boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:85: error: call of overloaded âarity_helper(boost::mpl::aux::type_wrapper<X<int>::type>, boost::mpl::aux::arity_tag<1>)â is ambiguous boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:30: note: candidates are: char (& boost::mpl::aux::arity_helper(...))[1] boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:37: note: char (& boost::mpl::aux::arity_helper(boost::mpl::aux::type_wrapper<F<T1> >, boost::mpl::aux::arity_tag<1>))[2] [with F = X< <template-parameter-1-1> >::type, T1 = int] boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:37: note: char (& boost::mpl::aux::arity_helper(boost::mpl::aux::type_wrapper<F<T1> >, boost::mpl::aux::arity_tag<1>))[2] [with F = X< <template-parameter-1-1> >::type, T1 = int] The code compiles fine with gcc 4.0.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1453180&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [multi index] Warnings withlevel 4 on Microsoft compiler
by JOAQUIN LOPEZ MU?Z 18 Mar '06

18 Mar '06

Hello Alexei ----- Mensaje original ----- De: Alexei Alexandrov <alexei.alexandrov(a)gmail.com> Fecha: Viernes, Marzo 17, 2006 7:37 pm Asunto: Re: [boost][multi index] Warnings withlevel 4 on Microsoft compiler [...] > But what about > > boost\multi_index\detail\hash_index_node.hpp(89) : warning C4610: > struct > 'boost::multi_index::detail::hashed_index_node_trampoline<Super>' can > never be instantiated - user defined constructor required > > This warning seems to have more sense and should not be disabled > perhaps. Do > you think it should be disabled on whole Boost level as well? All these node classes are really never constructed, as they're placed directly in memory and used. C++ allows this when the class have so-called "trivial constructors" (see std 12.1.5) The idea is that these classes are nothing but structures of pointers and integral variables, so not calling any constructor is an allowed optimization --in the usual case, i.e. creating an object on the stack or on on the heap via new, the trivial ctor call gets optimized anyway (and cannot be avoided by the very rules of C++), but not necessarily so when creating objects thru an allocator interface, which decouples storage creation (allocate) from construction (construct). This issue is explicitly dealt with in std 3.8 "Object limetime". Now, strictly speaking the compiler is right that the object cannot be instantiated, since the std seems to mandate that a trivial constructor really exist, not merely that it would be trivial if it could be automatically generated --in this case it cannot because of base classes with private (trivial) ctors. To sum it up, the compiler is probably right that such an object cannot be instantiated according to C++ std, even resorting to the trivial-ctor allowance. Consequently, I'll rewrite this so that the warning disappears. On the other hand, I'm not very happy with this kind of "forward thinking" warnings: If I never construct such an object, why should the compiler complain? A warning should be aimed IMHO at making you think about idioms hiding potential programming errors, not techniques which *could* result in non-compilable programs, as is the case with all the warnings you've cited in this thread. Thanks for the information, best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[old-shmem] Updated boost-sandbox cvs with bug-fixes
by Ion Gaztañaga 18 Mar '06

18 Mar '06

Hi to all, Several people have reported some bugs against Shmem 0.9 that I've tried to correct: -> deque not including allocator_utilities -> named_semaphore bug in windows in timed_wait -> broken named_mutex in unix -> broken try_receive in shared_message_queue Since shmem -> interprocess transformation will need some time I will try to fix Shmem 0.9 bugs in sandbox-cvs. Regards, Ion

1 0

[serialisation] reading and writing reals
by John Maddock 18 Mar '06

18 Mar '06

Attached is a sketch of how reals can be serialised in hex notation, without data loss when round-tripping from binary-to-text-to-binary. Note: 1) The iostream code could be improved, particularly formatting errors on reading, if any iostream experts would like to give it the once over they're very welcome. 2) There is no check on reading that the target type is large enough to hold all the bits that were previously written out (neither is there for decimal io come to that). 3) I've only tested this code with VC8, so portability may vary. 4) I've made no attempt to beautify the output format, it's frankly rather ugly to read at present. 5) It's not clear whether on output the digit before the decimal point should always be a 1: at present it's a full hex digit, which means the value "1" comes out as 0x8p-3 rather than 0x1p0 6) Zero still needs to handled as a special case, at present it prints as 0x0p-3 rather than 0x0p0: it makes no difference on input, but it would be nice to print it prettily :-) 7) I've been unable to reproduce the original problem with native << and >> operators with either random value tests, or with sequential nextafter tests, unless I start with the specific value that caused all the fuss in the first place :-( Any ideas for better tests much appreciated. Enjoy, John.

2 3

[ANN] Wave V1.2.4 in CVS
by Hartmut Kaiser 18 Mar '06

18 Mar '06

Hi all, I've just committed the version of Wave (V1.2.4) which will be part of the upcomming Boost release. It has a bunch of new features in it (with kind approval by Thomas Witt) and some bugfixes applied making it worth to have a look at: - automatic include guard detection - full interactive mode of the Wave tool, now you can use the Wave tool just like Python or Perl for instance to interactively try out your BOOST_PP macros - load/save macro tables to store the state of interactive sessions (that's implemented using the Boost.Serialization library) - performance improvements by upto 30-40% - new pragmas allowing to control certain library features from inside the preprocessed sources (partial output redirection, control of generated whitespace and #line directives) - and bunch of fixes For a full list of changes please look at: http://boost-consulting.com/boost/libs/wave/ChangeLog Feedback is as always welcome! Regards Hartmut

1 0

missing __volatile__ tags in sp_counted_base_gcc_xxx.hpp
by Howard Hinnant 18 Mar '06

18 Mar '06

Hello, I've been investigating some failures on Mac OS X, ppc concerning shared_ptr. One of the things that has struck me is that in boost/ detail/sp_counted_base_gcc_ppc.hpp, the __asm__ block in atomic_decrement is decorated with __volatile__, but the __asm__ blocks in atomic_increment and atomic_conditional_increment are not. The failure I'm seeing disappears when the __volatile__ attribute is added in the two missing places. Would this be a proper fix to boost/ detail/sp_counted_base_gcc_ppc.hpp? Should boost/detail/ sp_counted_base_gcc_x86.hpp be treated similarly? Thanks, Howard

2 8

[Boost-bugs] [ boost-Patches-1452743 ] [regex] fixes warning on mingw
by SourceForge.net 17 Mar '06

17 Mar '06

Patches item #1452743, was opened at 2006-03-17 22:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452743&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Baraclese (baraclese) Assigned to: Nobody/Anonymous (nobody) Summary: [regex] fixes warning on mingw Initial Comment: [regex] [current cvs] mingw automatically defines NOMINMAX in bits/ os_defines.h to protect some standard headers. Compiler thus emits a warning about redefinition of NOMINMAX in static_mutex.cpp. [solution] Add #undef NOMINMAX before #define NOMINMAX to file libs\regex\src\static_mutex.cpp(27) Other files which define this are: libs\regex\src\regex.cpp(31) libs\regex\src\w32_regex_traits.cpp(27) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1452743&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0