- Boost - lists.boost.org

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

message attachments missing?
by Robert Ramey 15 Apr '04

15 Apr '04

Am I the only one unable to open message attachments such as http://lists.boost.org/MailArchives/boost/attachments/20040415/31f013f2/mars halling.zip Or is something not functioning with the system? Robert Ramey

2 1

Yo, move semantics anyone - errors in move.cpp example
by Roman Yakovenko 15 Apr '04

15 Apr '04

Hi. The example "move.cpp" could not be compiled on MSVC 7.1. Reasons: 1. The obvious one X& operator=(X rhs) { std::cout << "ASSIGN #" << id << (owner?"":" (EMPTY)") << " <== #" << rhs.id << (rhs.owner?"":" (EMPTY)") << std::endl; owner = rhs.owner; rhs.owner = false; assert(owner); //MISSING RETURN VALUE; } 2. error C2664: 'sink' : cannot convert parameter 1 from 'const X' to 'X' Definitions: X const z7; void sink(X) Error location: std::cout << " ------ test 15, pass const lvalue by-value ------- " << std::endl; sink(z7); I think compiler is wrong here. It should call template <class T> X(T& rhs, typename enable_if_same<X const,T>::type = 0) constructor. Or may be I wrong, and missed something Roman > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Wednesday, April 14, 2004 5:05 PM > To: boost(a)lists.boost.org > Subject: [boost] Yo, move semantics anyone? > > > Hi, > > I'm just wondering if the deafening silence indicates a lack of > interest or whether something else is going on? > Feedback would be appreciated. > > Thanks! > > David Abrahams <dave(a)boost-consulting.com> writes: > > > 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 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

tools/regression/run_tests.sh
by Jody Hagins 14 Apr '04

14 Apr '04

Straight out of CVS, run_tests.sh has the following on line 88: export BOOST_BUILD_PATH="$boost_build_path" "$BOOST_BUILD_PATH" which, of course, generates an error. Does anyone know the intent of this line? I can think of two obvious possibilities... 1. Prepend $boost_build_path to BOOST_BUILD_PATH, in which case it should be something like: if [ "${BOOST_BUILD_PATH}" ]; then BOOST_BUILD_PATH="$boost_build_path:$BOOST_BUILD_PATH" else BOOST_BUILD_PATH="$boost_build_path" fi which is a bit verbose, but probably necessary for max /bin/sh portability. 2. Just set it to boost_build_path: BOOST_BUILD_PATH="$boost_build_path" However, there could be some other intent, so I am not sure how I want to fix this. Anyone know? Thanks! -- Jody Hagins

2 4

Re: [boost] Re: Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 14 Apr '04

14 Apr '04

Hi Rob, ----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 12, 2004 11:17 pm Asunto: Re: [boost] Re: Re: [indexed_set] revised naming proposal > From: =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= <joaquin(a)tid.es> > > De: Rob Stewart <stewart(a)sig.com> > > [index_list naming] > Now that I am, what about changing it to "indexes" or "indices" > according to your preference? IOW, I don't think "list" needs to > be part of the name at all. That name works fine regardless of > whether it is elaborated. It does not look bad, actually. But I'm really trying to narrow the target down now. Do you have strong objections to index_list? Nobody else complained. [moving into boost::container] > > Well, it's all about not wasting effort. Hopefully, some > > other boosters (and the authors of container libraries > > in Boost) will jump in and express themselves for a > > That will be ideal. I wasn't paying attention, but has this been > addressed in a separate thread with an appropriate subject in > order to garner their involvement? No. I don't feel like rising the noise level more than now by beginning a new thread. IMHO, it's unlikely that this will get any more attention (and it could be that it does not deserve it after all.) [philosophical discussion about convenience of 1st level namespaces] (excuse my snipping) Well, just for the record, what's your "vote" about pushing/not pushing into boost:container? It is not clear to me which side you're a supporter of. So far, noone has expressed any strong opinion on either option. (btw, thanks for involving into this discussion) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

RE: [boost] Re: Date-Time
by Powell, Gary 14 Apr '04

14 Apr '04

Rob wrote: >> >> Ok, but you need more than just LAST, you need LAST-1, LAST-2, and LAST-3 >Why? I can't imagine a good use case for wanting one, two, or >three days before the end of the month as a special form of date. To make this work: date d = January LAST-1; // the 30th add_month(d); d == February 27th or 28th depending on the leap year, add_month(d); d == March 30th; Which is why the specialized function is the way to go. LAST isn't enough and anything else is cumbersome, buggy and hard to maintain. Yours, -Gary-

2 1

RE: [boost] Re: Yo, move semantics anyone?
by Powell, Gary 14 Apr '04

14 Apr '04

>David Abrahams wrote: >> I'm just wondering if the deafening silence indicates a lack of >> interest or whether something else is going on? >The latter. Thanks for your efforts, I for my part will definitely have >a closer look on it when time allows. Stephan wrote: >BTW, what was the result of the proposal on clarification of this? Dave went to Sidney and pitched it. It passed as a Defect Report which is great news as it means that the current crop of compilers are required to fix this now not in N years when the C++0X standard is released. Yours, -Gary-

2 1

RE: [boost] Re: Date-Time
by Powell, Gary 14 Apr '04

14 Apr '04

>From: Jody Hagins <jody-boost-011304(a)atdesk.com> >> "Powell, Gary" <powellg(a)amazon.com> wrote: >> >> > That would surprise me as well. >> > >> > date = January 30; >> > >> > add_month(date); >> > add_month(date); >> > >> > date == March 30 ? Not March 28/29 No? >I'd expect April 1st or 2nd, depending upon whether it was a leap >year. I'm not sure what you're saying you'd expect. I'd expect March 30th. >For my expected result, it would simply increment the month and >then check for the corresponding day of the month. If it's past >the end of the month, it falls back to advancing by 30 days. >Then, the logic is repeated by the second call. I understand what you think you want but in practice I don't think it would work out as nicely as you think now. >> Or, instead, you use something like... >> >> date = January END or LAST; >> >> meaning the last day of the month. Then, adding a month would always >> jump to the last day of the next month. I imagine with... >That would work well. Ok, but you need more than just LAST, you need LAST-1, LAST-2, and LAST-3 That's why I use seconds.. >> date = February 28; >> add_month(date); >> >> you would want March 28, and not March 31??? >Yes. I would expect this as well. the 28th is either LAST, or just plain old 28th. Personally I like Jeff's solution, that you provide the increment function. Because it sounds like we have different use cases for "next month" The loose case of "see you for your next appointment next month", and "delivery is in One Month". Where 30 days is the "next month" vs the calendar end. Yours, -Gary-

2 1