- Boost - lists.boost.org

boost:filesystem::path throws eception on valid path name
by Andreas Pokorny 25 Apr '04

25 Apr '04

Hi, $ cat test.cpp #include <stdexcept> #include <iostream> #include <boost/filesystem/path.hpp> int main() { try { boost::filesystem::path p("/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/"); } catch( std::exception &e ) { std::cout << e.what() << std::endl; } catch(...) { std::cout << "Unknown exception" << std::endl; } } $ g++ test.cpp -o test -lboost_filesystem $ ./test boost::filesystem::path: invalid name "g++-v3" in path: "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/" Is that supposed to happen? Regards, Andreas Pokorny

2 1

Quick thought on Date-Time
by Daryle Walker 25 Apr '04

25 Apr '04

[NOTE: I haven't worked on this library; I'm just going by the posts I see here.] For this increment/decrement by a month problem, is there any way to store a date with only a month resolution? Nothing smaller will be stored, so day crossovers won't be a problem. Wouldn't something similar have/already-had been done when skipping days but ignoring the exact hour? (Or does every date-time object work at the fractional-second level? If so, maybe that's what needs fixing.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 11:19 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates [...] > > #include "boost/archive/basic_archive.hpp" > > #include "boost/serialization/split_free.hpp" > > #include "boost/serialization/string.hpp" > > > > I think the two first are unnecessary (could you > > try this out? thx) > > Actually none of them are necessary. Ah the wonder of templates :-) > Wonderful they are, you're right :) So, I guess this is as good as it can get. Slightly OT: this issue of POI could be taken a little further to allow interoperability between (not necessarily template-based) libraries without the headache of having to include portions of them. This is what I have in mind: suppose a header-based library A provides support for or somehow uses a non-header (i.e. requires linking) library B, like this: // lib A #include <b.hpp> inline foo(){...} // does not depend on B inline bar(){...} // does not depend on B inline mess_with_B(){...} Now, if B is not linked in the project mess_with_B won't compile, so one has to move this function to a separate header that the user will/won't include depending of whether she wishes that functionality. Instead, one can do the following: // lib A #include <b.hpp> inline foo(){...} inline bar(){...} template<typename dummy> inline mess_with_B(dummy* =0){...} Voila, A works even if B is not linked in. If the user has linked B and wants to use mess_with_B, then she just has to call mess_with_B() as usual, template instantiation model will do the rest. Maybe I'm missing something, but I think this approach could be investigated a little further. One good example of use is for interoperability with Boost.Threads, for instance. Totally OT: I've posted a question regarding multi_index and composite keys a few posts ago. You being one of the reviewers, your opinion on that is greatly appreciated :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 9:25 pm Asunto: Re: [boost] [serialization+date_time] Serialization Review: serialization of dates > On Sun, 25 Apr 2004 20:34:34 +0200, JOAQUIN LOPEZ MU?Z wrote > > > Regarding the need to include "greg_serialize.hpp", I think > > a better approach, from the point of view of the user, is > > that serialization support is already embedded into > > "boost/date_time/gregorian/gregorian_types.hpp" and > > automatically provided if one of the archive headers > > > >...snip details... > > > > See what I mean? For this to work with minimum > > overhead, we'd need some forward headers for serialize, > > save, load, etc. to be included by > > "boost/date_time/gregorian/gregorian.hpp". > > Yes, I agree on the user perspecitive. I'm sorry I forgot to say > that in the > first few emails. I did say it here: > http://lists.boost.org/MailArchives/boost/msg63885.php > > > I'm not sure whether this forward headers are already > > provided by Robert's library. > > Why would I need 'forward headers' for this? > Well, since serialization support is entirely contained in function templates, you don't need any actual definition till POI (I might be wrong here, but I guess I'm not.) This can help reduce compilation time if you're not going to serialize dates at all. Matter of fact, seeing the includes in your example #include "boost/archive/basic_archive.hpp" #include "boost/serialization/split_free.hpp" #include "boost/serialization/string.hpp" I think the two first are unnecessary (could you try this out? thx) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[static_assert] Bad compiler message
by Vladimir Prus 25 Apr '04

25 Apr '04

Hello, I've just found out that the following program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT(false); return 0; } compiled with gcc 3.3 produces: sa.cpp:6: error: invalid application of `sizeof' to an incomplete type which is not as nice as sa.cpp:6: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' that gcc 2.95 generates and sa.cpp:6: `sizeof' applied to incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' That 3.2 generates. The behaviour of 3.4 is the same as for 3.3. So, there are some questions: 1. Should I bug gcc developers about this? 2. Anybody knows another way to force better diagnostic? 3. Is it possible to make regression tests for static_assert always include compiler messages, so that we know the diagnostic is OK? - Volodya

6 7

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 0:37 am Asunto: [boost] [serialization+date_time] Serialization Review: serialization of dates > All - > > Since I'm the review manager I'm not doing a formal review of the > library, but > I thought I'd share some code and a few thoughts. If > serialization is > accepted users people will ask me and other library authors to provide > serialization support for some of the types in their libraries. So > to get a > feel for the difficulty of extending serialization for new types I > wrote the > serialization code for gregorian::date and some example code to > try it out. Regarding the need to include "greg_serialize.hpp", I think a better approach, from the point of view of the user, is that serialization support is already embedded into "boost/date_time/gregorian/gregorian_types.hpp" and automatically provided if one of the archive headers are included by the user program: // case 1 "boost/date_time/gregorian/gregorian.hpp" int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // does not work, text_oarchive not defined. oa << d; } // case 2 "boost/date_time/gregorian/gregorian.hpp" #include <boost/archive/text_oarchive.hpp> int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // OK, no need to include anything else fromd date-time oa << d; } See what I mean? For this to work with minimum overhead, we'd need some forward headers for serialize, save, load, etc. to be included by "boost/date_time/gregorian/gregorian.hpp". I'm not sure whether this forward headers are already provided by Robert's library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: >Well, I think it belongs in the library supplying the data type not in > serialization. Few reasons for this... ... good reasons listed 4) Many serialization implementations will turn out to be trivial. An example is Thorsten O? pointer container wrapper class which resulted in 6 lines of code. Furthermore these six lines were inline template member functions (two functions 3 lines each) which required no header inclusion at all. In cases such as this, the compiler/runtime cost is zero if the application doesn't use serialization. I believe that this will be a common case for many of the "utility" classes. FWIW - this gets my vote: > So for the particular case I posted I was planning on putting this code in > boost/date_time/gregorian/greg_serialize.hpp > Time could would go into > boost/date_time/posix_time/time_serialize.hpp Considering the above, you might want to think about tweaking date time. By making a default constructor (that initializes as "not a date"), you could implement serialization as template member functions along the lines of the above. In this way adding serialization would: a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used. Robert Ramey

3 3

Re:Re:Re: [boost] [serialization+date_time] Serialization
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: > > a) no extra compile time overhead > > b) no extra run-time overhead > > c) no extra file inclusion > > d) no extra "conceptual" overhead. That is one would never have to even > > think about it - it would always be there just lurking waiting to be > > of service. It would just work when used. > > Are you saying there is actually extra runtime overhead with the way I've > implemented serialization? If so, that needs to be in the docs b/c I was > under the impression that external versus internal implementations would > be > the same... > I didn't mean to imply your method had any runtime overhead - I was just restating all the features. However, the other points are real advantages of just putting it in with the class definition. BTW the non - intrusive version could also be put in the normal class header. However if its too complicated it might end up requiring more file inclusion so it would have to be considered on a case by case basis. I personally don't have a strong position on this. As far as serialization is concerned the alternatives are all equivalent. The decision where to but the serialization templates can be decided on other factors. Robert Ramey

2 1

New dynamic_bitset
by Gennaro Prota 25 Apr '04

25 Apr '04

Hi everybody, as I have mentioned in some post here, a new version of dynamic_bitset is in the sandbox. I've finished everything 4/5 days ago (including new and more tests) and thought to move it to the main repository, as Jeremy asked too. But I've had an important familiar problem and I'm looking for a job and an apartment at the same time. With all likelihood I'll be at my old home, where is my pc, just for a couple of hours on Saturday and Sunday (except for this weekend, where Monday is holidays too). There could be other free mornings here and there but I can't guarantee. So I ask: should I move everything to the main repository or should I wait until I can devote more time to follow discussions and fix possible regressions? If the next release is far away then 5 or 6 hours a week should be adequate to review the regression logs and fix any problems that could arise. I'll check the list again tomorrow. Sorry for the inconvenience. PS: I had a (very) quick look at the thread about the FC++ review result. Just want to say that I think Brian is a great asset to the C++ community at large. His only mistake is that he isn't posting anymore to the groups, if not sporadically. Please, come back soon, Brian :) Genny.

6 23

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Brian McNamara <lorgon(a)cc.gatech.edu> Fecha: Domingo, Abril 25, 2004 6:05 am Asunto: Re: [boost] [multi_index] composite keys: request for advice > On Sun, Apr 25, 2004 at 03:54:31AM +0200, JOAQUIN LOPEZ MU?Z wrote: > > > that if you call these two object "k" and "t" (key and tuple), > > > then you should have > > > k < t false > > > t < k false > > > t == k does not compile > > > That's just my quick hunch based on what I've quoted above; I > haven't> > considered what consequences it has for the library, > but that's my > > > intuitive notion of how tuples as "partial keys" ought to work. > > > > I guess I agree with you, but I wanted to bring this > > in to the list to gather some opinions. Following your > > approach, what should we do with > > > > k <= t > > t <= k > > > > The options are: > > > > a. they hold true > > b. they do not compile > > > > I don't have any strong argument in favor of any option. > > If there are other std:: or boost:: types which model the > StrictWeakOrdering concept (without having total orders), I would see > what they do and follow their lead. > > If not, I would make the "<=" operators not compile, since > k <= t > can always be rewritten by clients as > !(t < k) > and the narrower interface reduces the likelihood of someone > mistakenlygetting the impression that there's a total ordering > here (IMO). > I've scanned Boost and results are not conclusive. At least one class (shared_ptr) does define operator< and does not define <=, >= etc. so I'm not alone. I think I'll follow your advice and be conservative here (we'll always have time to extend this; the other way around is more problematic). So, the rules I'll stick with are: 1. if k and t have the same number of elements then k==t, k!=t, k<t, k>t, k<=t, k>=t, t==k, t!=k, t<k, t>k, t<=k, t>=k, are all defined and follow the lexicographical convention. 2. If k and t have different number of elements, then k<t,k>t, t<k,t>k are the only operators defined and follow the "clipping rule" (compare lexicographically taking the minimum of the lengths of the operands.) 3. std::less and std::greater are specialized to accept comparison between composite_key results and tuples, according to the previous definition. No other std comparison object is specialized. If nobody finds a problem with this, these are the rules that'll go into the implementation of composite_key. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0