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

Seialization library current status
by Robert Ramey 26 Aug '04

26 Aug '04

Here is short summary of the current status of the serialization library. Its based on tests on my own machine and others. In some cases I'm anticipating results of next tests. Linux - 100 % passing all compilers Except intel 8.0 - problem with serialization some collections - list, map, set, and array. Darwin - 100 * passsing Except - one test of demo fail Windows Mingw - 100 % of all char archives 0 % of wchar_t archives. Apparently mingw doesn't support wchar_t. Itel 100 % all versions Borland - mostly passing - this is the best I can do here VC <= 7.0 - mostly passing - this is the best I can do here VC 7.1 - 100% VC 8.0 - 0% - I don't know the status of this compiler. Library fails to build due to syntax error compiling spirit headers. I'm not prepared to address this. Commeau - 100 % EXCEPT archives which use wide characters. I believe it would be easy to find if I could figure out a way to debug this. Metrowerks CodeWarrior - This is a little confusing. One tester shows 100% success. The best I have is all pass EXCEPT tests which use export facility or wchar_t archives. Another tester has the same result I do. All tests that fail have unexpected linker warnings. I suspect a build issue but have been unable to find it. So that's it I could use help with Intel 8.0 array, list, set and map. Its probably one error in collection loading. Comeau - problems with wchar_t. Very likely related to codecvt facit usage Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which use utf8_codecvt_facet and which use export. Export seems to fail due to an over zealous link time optimizer eliminating what might look like dead code. Robert Ramey

3 3

Re:[boost] Re: Seialization library current status
by Robert Ramey 26 Aug '04

26 Aug '04

>"Robert Ramey" <ramey(a)rrsd.com> writes: >> Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which >> use utf8_codecvt_facet and which use export. Export seems to fail due to an >> over zealous link time optimizer eliminating what might look like dead code. >?? CW doesn't support export ?? Export refers to one of the features of the serialization library - not to be confused with all the other ways we use this word. Sorry if there is any confusion here. >Are you aware that some of the facet stuff is only supported in the >*statically-linked* version of the MW standard library? ><runtime-link>static might be a requirement of these tests. I'm certainly not aware of that. I looked carefully through all the information I could find and didn't see anything like that. However, that would explain at least test failures associated with utf8 codecvt. I'll try this. Robert Ramey

2 1

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Beman Dawes 26 Aug '04

26 Aug '04

At 09:33 AM 8/25/2004, Bennett, Patrick wrote: > If I can't write a >portable (to at least Linux and Windows), internationalizable >application with boost::filesystem then it's of no use to (at least) me. And a lot of other people. I'd like to see the library become part of std::tr2, and lack of internationalization is the main impediment to that. I've spent a lot of time for the last two years looking into the issues, and am pretty close to being ready to make a detailed proposal. >This is why I suggested that UTF-8 be used as boost::filesystem's >encoding. It can be passed through as-is or converted as needed on each >platform and it would be backwards compatible with existing >boost::filesystem code. For standardization (and I don't have any interest in internationalization except in the context of standardization) I don't think any proposal will fly unless it is in sync with current standard library internationalization. That means that the internal encodings must be char, wchar_t, or a template parameter charT. Once the Unicode TR being worked on is accepted, then those character types will be presumably be added. Just as with strings, presumably there will be path and wpath typedefs, and then Unicode typedefs when they evolve. As far as external encodings go, there will be a program default (which defaults to the platform default, but can be set to a user specified encoding), but individual paths can be constructed using a user-supplied external encoding if desired. Translation issues between encodings are messy, to say the least. Note that there has to be a way to pass strings in the operating system's external encoding on to (at the lowest level) file open functions, and that the current standard does not provide this. Bill Plauger has proposed the addition of this functionality to the standard, so that aspect is moving forward. --Beman

1 0

[filesystem] issue with path::iterator
by Martin Wille 26 Aug '04

26 Aug '04

Hello, a momemnt ago, someone reported a problem on IRC regarding boost::filesystem::path::iterator. He basically has code like this: using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++; That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j: error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested I suspect the change was caused by a recent change to iterator adaptors. Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me. Regards, m

5 15

xtime_get unsafe on Windows for IA64
by Ben Hutchings 26 Aug '04

26 Aug '04

The implementation of the boost::xtime_get() function in libs/thread/src/xtime.cpp includes the following code for Windows: #if defined(BOOST_HAS_FTIME) FILETIME ft; ... const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = ((boost::uint64_t)27111902UL << 32) + (boost::uint64_t)3577643008UL; xtp->sec = (int)((*(__int64*)&ft - TIMESPEC_TO_FILETIME_OFFSET) / 10000000); xtp->nsec = (int)((*(__int64*)&ft - TIMESPEC_TO_FILETIME_OFFSET - ((__int64)xtp->sec * (__int64)10000000)) * 100); return clock_type; #elif ... (This is reformatted slightly so that Outlook doesn't screw it up.) The pointer casts are not safe because although the representations of FILETIME and __int64 are compatible, FILETIME is only 32-bit- aligned whereas __int64 must be 64-bit-aligned on IA64 (in some processor modes). One can instead use union { FILETIME ft; __int64 i64; } and read out i64, though I'm not sure this code should be unconditionally using __int64 anyway. There is a longer explanation at <http://weblogs.asp.net/oldnewthing/archive/2004/08/25/220195.aspx>. Ben.

2 1

[Serialization] question
by Russell Hind 26 Aug '04

26 Aug '04

I have a std::list<ublas::vector<double> > and also a list of iterators in to this list (which basically contain a subset of the initial list e.g. std::list<std::list<ublas::vector<double> >::iterator> Is there a way with serialization library to serialise both lists so that when both lists are re-loaded, the second list contains valid iterators again? Thanks Russell

1 0

[program_options + test] cw 8.3 fails all tests
by Vladimir Prus 26 Aug '04

26 Aug '04

As shown in http://tinyurl.com/3smdm all program_options tests fail on cw 8.3, because boost.test refers to the _errno variable, but that reference is somehow unresolved. Could anybody suggest any solution? TIA, Volodyaya

4 3

Re: [boost] [1.32 Plan] Stalled forever?
by Robert Ramey 26 Aug '04

26 Aug '04

Aleksey Gurtovoy wrote: >JOAQUIN LOPEZ MU?Z writes: >> I don't want to sound harsh or anything, and I truly appreciate the >> effort that's being put in this, but a month has slipped by since the >> first schedule for releasing, and AFAIK we don't even have an agreed >> upon branching date for the near future. >The branching date is pending MPL check-in. The latter has been postponed >several times as the new issues surfaced (in particular, due to better >tests), but it's crucial to ensure that the library is in the predictable >state before the release (remember that it goes on the CD with the TMP >book), so please bear with us. The branch should occur now. MPL update can go into the next release. Or you can see it a slightly different way. Branch and release 1.32 now. Rebranch and release 1.32 when MPL update has been added and any related issues resolved. > There are external constraints for this release's timeframe, > but within those, the release is criteria-driven. One of the > criteria is regression-free codebase, This is criteria for release - not for branching > and another is the new > MPL version. There is no point of releasing "on time" if the > release is useless. Nothing in the current development tree - i.e. the 1.32 release candidate depends on the MPL update that has yet to be integrated. There is no reason to hold up branch/release for new features. > > Shouldn't we settle now on a realistic branching date > and proceed with the release? Or, should I shut my mouth > and let the release manager handle this as he deems > convenient? > > Again, don't get me wrong. I am not willing to push > anybody, but the process looks, well, erratic. > Please don't forget that we are all volunteers here. The best > way to speed up things is to contribute to them. MPL issues > notwithstanding, we still have the regression field to be > cleared -- > http://www.meta-comm.com/engineering/boost-> regression/developer/summary.html. > Turning it green while MPL is in works will make a huge difference. The only way an MPL update can be expected to not create new issues is it makes only small changes. If that's the case its not worth holding things up for. If the changes are not small, it likely will create a slew of new issues. >> If you are willing to take over managing that one >> until the MPL check-in, be my guest. I wish we could all do as well as Joaquin has been doing in clearing issues related to his library. He has been doing an excellent job. When this topic was discussed at the beginning of the release process, it was indicated that subsequent releases would already be scheduled and would be soon after 1.32 . This was to assure developers that if they missed this release, it wouldn't be a big issue as the next one would be soon anyway. This is still a good idea and should be implemented. So Branch now Release branch available only for bug fixes and test clearing Main branch new MPL and what ever else. Robert Ramey

2 1

[filesystem] Status of issues
by Beman Dawes 26 Aug '04

26 Aug '04

For reasons unrelated to Boost, I've been sidelined from most work on filesystem issues since late March and am just now starting to catch up. It will take awhile just to read backed up email. Thanks to John Maddock, Dave Abrahams, and Vladimir Prus for resolving several issues when I wasn't available. As far as the 1.32.0 release goes, I'll try to give priority to bug fixes. But there probably won't be a lot of change compared to the current CVS state, since the library is pretty stable (and has a number on nice fixes and tweaks compared to 1.31.0.) --Beman

5 4

RE: [boost] Re: Java style GUI in C++
by Reece Dunn 26 Aug '04

26 Aug '04

Ralf W. Grosse-Kunstleve wrote: >--- Reece Dunn <msclrhd(a)hotmail.com> wrote: > > Thus, in Java Swing-style C++, you can do something like: > > > > boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); > > frame -> set_pane( new boost::gui::button( "PUSH" )); > > frame -> set_size( 500, 400 ); > > frame -> show(); > > > > boost::gui::message_loop msg; > > return msg.execute(); > >How does main get deallocated here? Oops :) >I am very surprised to see "new" and raw pointers in a library designed >from >scratch. Manual lifetime management is going to lead to a lot of clutter, >memory leaks, and is incompatible with exception handling. A system based >on >smart pointers like boost::shared_ptr and reference-counted container types >is >essential IMO. The library currently uses reference counted types to manage allocated types. I understand the use of smart pointers and agree that it is essential. I was just using this example as a guideline. Regsrds, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0