April 2004 - Boost - lists.preview.boost.org

suggestion on Serialization Library
by Allen Yao 15 Apr '04

15 Apr '04

It is not very convenient for me to use macros like BOOST_SERIALIZATION_SPLIT_FREE, BOOST_SERIALIZATION_SPLIT_MEMBER to deal with splitted load/save functions. Additionally, when dealing with load/save functions of template class, these macros help little. Users also have to read and understand what these macros actually do and write their own serialize function to call split_free or split_member accordingly. I suggest that these implementation details on how the serialization library determine to use single serialize function or splitted load/save functions should be totally encapsulated and hidden behind the scene. I suggest that a traits class to be used by the user instead of macros like BOOST_SERIALIZATION_SPLIT_FREE. For example, the traits class can be named "serialization_traits", its default implementation is somthing as follows: template <typename T> struct serialization_traits { static const bool has_split_load_save = false; }; It can be (partially) specialized for types that has split load/save functions. Then, the serialization library can use this traits class to determine whether to call a single serialize function or splitted load/save functions for a specific type. Am I missing something? Best regards. Yao, Zhen

2 1

Re: Big integer library
by Richard Peters 15 Apr '04

15 Apr '04

One note on portability: the example and test file compile under Visual C++ 7.1 and gcc 3.2.2 best regards, Richard Peters ----- Original Message ----- From: "Richard Peters" <r.a.peters(a)student.tue.nl> > Hello, > > A few months ago there was some discussion about an arbitrary magnitude > integer library. I have now implemented such a library, which is located at > http://groups.yahoo.com/group/boost/files/big_integer/. > > There are a few (incomplete) other libraries that provide the same kind of > functionality. The main difference between this library and other libraries > is that this library uses expression templates to avoid the creation of > temporary values, which when the values become large provide an increase in > performance. > > The library is not finished yet: most noticeably the test files are far from > complete, but there are also a few others things like the documentation > looks a bit ugly. Also a to-do is replacing the core operations like > addition and multiplication by more efficient ones, and provide options to > use external libraries like GNU MP. > I am presenting you already with this library though, to see if it meets the > desires for this kind of library, to see if there are things missing in this > library, and maybe get some help from other members interested in further > developing this library. > > best regards, > > Richard Peters >

1 0

[Boost-bugs] [ boost-Bugs-935605 ] constructor of special_values
by SourceForge.net 15 Apr '04

15 Apr '04

Bugs item #935605, was opened at 2004-04-15 13:13 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=935605&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: andrasiel (andrasiel) Assigned to: Nobody/Anonymous (nobody) Summary: constructor of special_values Initial Comment: I've a problem when trying to use the ptime constructor of special values ptime(special_values sv) Constructor for infinities, not-a-date-time ptime t1(neg_infin); ptime t2(pos_infin); ptime t3(not_a_date_time); gcc does not find this constructor and indeed it is not listed in the candidate list. the exact error is : -------------------------------------------------------- database.cpp:241: error: no matching function for call to ` boost::posix_time::ptime::ptime(boost::date_time::special_values)' /usr/include/boost/date_time/posix_time/ptime.hpp:32: error: candidates are: boost::posix_time::ptime::ptime(const boost::posix_time::ptime&) /usr/include/boost/date_time/posix_time/ptime.hpp:45: error: boost::posix_time::ptime::ptime(const boost::posix_time::int64_time_rep&) /usr/include/boost/date_time/posix_time/ptime.hpp:42: error: boost::posix_time::ptime::ptime(boost::gregorian::date) /usr/include/boost/date_time/posix_time/ptime.hpp:39: error: boost::posix_time::ptime::ptime(boost::gregorian::date, boost::posix_time::time_duration) --------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935605&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-935596 ] to_simple_string link problem
by SourceForge.net 15 Apr '04

15 Apr '04

Bugs item #935596, was opened at 2004-04-15 13:00 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=935596&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: andrasiel (andrasiel) Assigned to: Nobody/Anonymous (nobody) Summary: to_simple_string link problem Initial Comment: 935571 time_from_string link problem (i'm the anonymous poster of that request ) I tried some other things like conversions from ptime std::string ts("2002-01-20 23:59:59.000"); std::cout<<boost::posix_time::to_iso_string(t1)<<std::endl; std::cout<<boost::posix_time::to_simple_string(t1)<<std::endl; std::cout<<boost::posix_time::to_iso_extended_string(t1)<<std::endl; the conversion from ptime to simple string return also a link error: Linking prog ... database.o(.gnu.linkonce.t._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthENS0_13simple_formatEE12format_monthERKS3_RSo+0x13): dans la fonction « boost::date_time::month_formatter<boost::gregorian::greg_month, boost::date_time::simple_format>::format_month(boost::gregorian::greg_month const&, std::basic_ostream<char, std::char_traits<char> >&)»: : undefined reference to `boost::gregorian::greg_month::as_short_string() const' (conversions to iso and iso extended are working) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935596&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

intel-win32 8.x config/ADL problem
by David Abrahams 15 Apr '04

15 Apr '04

Check it out, I can't get the following program to compile, even with -Qoption,c,--arg_dep_lookup: namespace ns1 { class X{}; int swap(X&, X&); } namespace ns2 { template <class T> void swap(T&, T&); } int main() { ns1::X x; using ns2::swap; int y = swap(x,x); } Shouldn't we be setting BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL for this compiler? It's actually a different bug in some details, I realize, but the macro does say the right thing. Also, where is the test for that macro? I don't see any in libs/config/test. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 7

regex lib: bug with sets and back ref
by Benzinger, Ralph 15 Apr '04

15 Apr '04

Hello, The following behavior seems to be a bug: * regex '([a-c]+)\1' finds 'abcabc' at offset 0 in text 'abcabc' * regex '([abc]+)\1' finds 'bcbc' at offset 1 in text 'abcbc' * regex '([a-c]+)\1' finds nothing in text 'abcbc' ??? Can anybody confirm this? Tried both POSIX and Perl syntax/match mode. Ralph

2 1

[Boost-bugs] [ boost-Bugs-935571 ] time_from_string link problem
by SourceForge.net 15 Apr '04

15 Apr '04

Bugs item #935571, was opened at 2004-04-15 04:46 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=935571&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: time_from_string link problem Initial Comment: I'm using libboost-date-time1.31.0 I have a link error when trying this code example : std::string ts("2002-01-20 23:59:59.000"); boost::posix_time::ptime t(boost::posix_time::time_from_string(ts)); Linking prog ... database.o(.gnu.linkonce.t._ZN5boost9date_time19month_str_to_ushortINS_9gregorian10greg_monthEEEtSs+0x119): dans la fonction « unsigned short boost::date_time::month_str_to_ushort<boost::gregorian::greg_month>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)»: : undefined reference to `boost::gregorian::greg_month::get_month_map_ptr()' collect2: ld a retourné 1 code d'état d'exécution source : http://www.boost.org/libs/date_time/doc/class_ptime.html ptime time_from_string(const std::string&) >From delimited string. std::string ts("2002-01-20 23:59:59.000"); ptime t(time_from_string(ts)) thank you al_x7(a)hotmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=935571&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: [static_assert] Bad compiler message
by Reece Dunn 15 Apr '04

15 Apr '04

Vladimir Prus wrote: >Brian McNamara wrote: > > More generally, I would really like a Boost library which lets me > > generate custom error messages portably. >[snip] > > Is there interest in this? > >Sure. In particular, I'd like to see a number of static assertions added to >BGL, to make error messages less confusing. I would be interested in it, especially in relation to meta-programming intensive libraries like Spirit that can generate somewhat unwieldy error messages! Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

1 0

Burgeoning Move Semantics Library
by David Abrahams 15 Apr '04

15 Apr '04

I have to stop playing with this stuff and get back to work now, but over the weekend I started a library that allows a "reasonably convenient, useful amount" of move semantics. Many compilers implement enough (N)RVO that implicit moving from rvalues is unneccessary, and those seem to coincide roughly with the compilers where we have to internally shut off some capability because of the compiler's interpretation of 8.5.3/5 (**). So it seems you can pretty much eliminate all needless copies. Here's what you can do with the current state of the move library, which supplies macros (eeeeew!) to avoid code duplication: struct X : boost::movable<X> { BOOST_LVALUE_COPY_CTOR( X, (rhs)(: initializers...), { // copy ctor body }) BOOST_LVALUE_ASSIGN( X, (rhs), { // copy assign body }) X(move_from<X> rhs) { // move ctor logic } X& operator=(move_from<X> rhs) { // move assign logic } }; boost::movable<X> just encapsulates the conversion to move_from<X> and makes the copy ctor/assignment private, so you can always replace it with a written-out conversion to move_from<X> if you don't like the "MI non-EBO" (or other) impact of library-mandated inheritance. This work owes inspiration to Rani Sharoni's "improved auto_ptr" (http://tinyurl.com/2rxpj) and of course one must acknowledge Andrei Alexandrescu for being crazy enough to even try doing this in a library in the first place (Mojo). Eric Friedman had an earlier boost/move.hpp in the sandbox based on Mojo (which I replaced with his permission), and I adapted his tests, in addition to my own, to work with the new code. It might make sense to use this library to optimize selected Boost components; shared_ptr, any, and dynamic_bitset come to mind, just off the top of my head. You can find the code in boost/move.hpp and tests in libs/move/test/*.cpp. It "basically works" with all MSVC versions, Borland, gcc-2.95, gcc-3.3.1, comeau (strict warnings mode only, until I find out how to detect that we're in strict errors mode), and all intel-win32 versions. I don't know how to make gcc-3.2 work yet. The places where it fails, certain things seem to compile which one would prefer to cause an error. Enjoy, Dave (**) see http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1610.html -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 11

[serialization] all wide tests were failing
by Robert Ramey 15 Apr '04

15 Apr '04

> What this means is that destructor of archive *really should* call 'flush' > on the stream. After I've made basic_text_oprimitive's destructor to flush > stream: > template<class OStream> > basic_text_oprimitive<OStream>::~basic_text_oprimitive(){ > os.flush(); > } > The test_vector passed with wide stream. I'm rerunning other tests now. Good call. I never would have guessed this. > In fact, I'm getting suspicious about changing codecvt at all. I suppose > that if somebody is using wide streams, he already deals with encoding > somehow, so why serialization library should try to second-guess the user? I have also started to have second thoughts about this. In the original version I didn't concern myself with codecvt . This created problems however: a) the i/o library silently used a codecvt facit that just narrowed the output characters - silently throwing away the high order bits on wide characters. This behavior was surprising, confusing and hard to find. b) even on char ouput, the default codecvt facet when through a large amount of code when all that was really necessary was to pass the characters through without change. That is, the standard library implementation picks a facet which may not behave in the manner that we (the user) expects. So I determined that I would "fix" this in the library. The state-saver system worked in perfectly. The possibility that it might not possible change the codecvt facet after the file is opened has made me wonder about this. I'm still undecided. The dinkumware library definitely works in this way and I believe that STL Port does also. Removing "automatic" imbue/unimbue to for the library would simplify the library and remove some "hidden" behavior - which I like. But it would also guarantee that many (or most) users would be getting something other than what they expect. I'm still considering this. Robert Ramey

2 1