http://blog.gmane.org/gmane.comp.lib.boost.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.boost.user/39515 I use the same compiler and disabled the warning in the project properties. There's some more info here about it http://msdn.microsoft.com/en-us/library/aa984668(VS.71).aspx I see the warning as more of a history lesson telling you that the previous Microsoft C++ compilers didn't implement Koenig lookup. Peter Barker 2008-08-30T10:23:23 http://permalink.gmane.org/gmane.comp.lib.boost.user/39514 I have just downloaded and applied one of the patches. I think the patches are very useful and convenient. (I work for a tiny software company, three full-time employees, one developer (me) and two sales people.) --Johan ' Johan Råde 2008-08-30T10:04:36 http://permalink.gmane.org/gmane.comp.lib.boost.user/39513 Hi raindog< at >macrohmasheen.com Argh... please do not top-post... and if you do then at least do not make your part of the mail long AND not place any quoting characters in front of lines belonging to the original post you are replying to. Reading that mail was a very unpleasant experience. Many thanks. Best regards, Jurko Gospodnetić _______________________________________________ Boost-users mailing list Boost-users< at >lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Jurko Gospodnetić 2008-08-30T08:59:26 http://permalink.gmane.org/gmane.comp.lib.boost.user/39512 I think this part of the library was never released. It is an addition to the integer libryry. You can find it in the vault if I'm right... Best regards Hansjörg Pfligersdorffer, Christian schrieb: Hansi 2008-08-30T05:12:07 http://permalink.gmane.org/gmane.comp.lib.boost.user/39511 My 2 cents: 1. Point releases should never break interfaces ever, they should be for those organizations who need minor bugs fixed but don't have the spare cycles to rework their code due to interface changes. Think of all the test cases, etc that might need rewritten and even the test case code themselves might depend on the same library. Interface changes will reduce the number parties able to even consider taking the release. 2. Organizations like those with the 10 year old tool chains are not going to consume any releases after their already accepted dependancies regardless, due to whatever risks they have whether contrived or not. 3. Major releases will generally be comsumed by organixations starting new projects or major revisions of existing projects because this is when they can afford the risks and at the same time will have spare cycles. 4. Developers or organizations agile enough to take point releases or patches will have no problem using a vcs system to fetch those changes or to apply patches, they should be experts at this. They will probably also be taking all major releases too. 5. My opinion is that for any shop with multiple layers of dependancies, as described below, they should choose a version of the dependancy and upgrade across the site only with major revisions if deemed necessary. For general software development, they will be very few compelling reasons that will warrant a library upgrade. The last thing one would desire is to bore developers with tasks they generally dislike ( library upgrades being one of those ). Josh phillips Virus analyst Microsoft Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Beman Dawes <bdawes< at >acm.org> Date: Fri, 29 Aug 2008 18:01:15 To: <boost-users< at >lists.boost.org> Cc: <boost< at >lists.boost.org> Subject: Re: [Boost-users] [filesystem][xpressive] Hotfix patches available for 1.36.0 Michael Marcin wrote: As far as Boost.Filesystem goes, it is perfectly usable. The fixes are primarily concerned with deprecated names. They only would be considered required if so much existing user code failed to compile that it is easier to apply the fixes than update the existing user code. In that sort of environment it is often best to stick with a particular version of Boost and other libraries until you reach a point in internal development cycles that it is convenient to change over to the newest versions of the libraries. Understood. That's quite a common scenario in mid-size and larger shops. Depends. In the kind of synchronized environment you are talking about, version upgrades do have to be managed carefully. OTOH, independent developers and other small and agile organizations may prefer to have the latest fixes, particularly if they are being impacted by the bugs being fixed. That makes sense in the environment you describe. HTH, --Beman _______________________________________________ Boost-users mailing list Boost-users< at >lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users raindog< at >macrohmasheen.com 2008-08-30T04:46:17 http://permalink.gmane.org/gmane.comp.lib.boost.user/39510 I'm suspecting that there is a confusion about how to seriailzation a pointer to a null terminated string. It's natural to want to do something like char *p; ... p = "jsdkfjads" ... ar & p; because the library syntax encourages one to think that way. But in this case, one would want save(... int i = strlen(p); ar << i; ar << binary_object(i, p); } load(... int i; ar >> i; ar >> binary_object(i,p); } That is, I think the question reflects a mis-conception about the best way to use the library. Robert Ramey Matthias Troyer wrote: Robert Ramey 2008-08-30T05:12:22 http://permalink.gmane.org/gmane.comp.lib.boost.user/39509 Hello, In the documentation at http://www.boost.org/doc/libs/1_36_0/libs/filesystem/doc/index.htm in section named "Using the library" there is a broken link named "example directory" (404 Not Found). Also, the example program http://www.boost.org/doc/libs/1_36_0/libs/filesystem/example/simple_ls.cpp uses dir_itr->filename() but when I do grep -r filename /usr/local/include/boost-1_35/boost/filesystem I get no matches. I ended up using dir_itr->path().leaf() instead. --> Mika Heiskanen / FMI Mika Heiskanen 2008-08-30T04:06:37 http://permalink.gmane.org/gmane.comp.lib.boost.user/39508 How would you serialize pointers as binary objects? On 29 Aug 2008, at 17:13, Robert Ramey wrote: Matthias Troyer 2008-08-30T03:50:47 http://permalink.gmane.org/gmane.comp.lib.boost.user/39507 Hi again, Nobody has a clue on this matter ? Anyone uses Boost 1.36 with multiple files with Visual Studio 2008 ? Matthieu 2008/8/28 Matthieu Brucher <matthieu.brucher< at >gmail.com>: Matthieu Brucher 2008-08-30T00:46:02 http://permalink.gmane.org/gmane.comp.lib.boost.user/39506 Arrange for a way for another thread can call top() on the first thread's io_service object. Jonathan Biggar 2008-08-30T00:01:15 http://permalink.gmane.org/gmane.comp.lib.boost.user/39505 Personally, I have no problems with hotfixes, but for those who prefer point releases, how about this: When a given version of Boost is at the end of its development lifecycle (i.e., when a new version of Boost is ready for release), take all the hotfixes for that version and package them into a point release, then release the point release and the new version at the same time. E.g., when Boost 1.37.0 is done, create a 1.36.1 out of all the available 1.36.0 hotfixes. This shouldn't add a significant resource burden, as the 1.36.1 package should only need a single test run (as opposed to the daily tests the new version would require) -- it's not being actively updated, should have no/minimal interface changes from the base version, and the changeset(s) making up a given hotfix have already received prior testing on trunk. To clarify, I'm advocating that individual hotfixes do not receive any automated testing, other than on trunk, as is currently done; only the point release resulting from all the hotfix changesets would need testing. The one "drawback" that I can think of is that Boost developers as a whole (i.e., more than just Beman and Eric ;-) would need to track/categorize changesets as hotfixes, so it could take a while to get enough momentum going to make it realistic/useful. Just my 2¢. _______________________________________________ Boost-users mailing list Boost-users< at >lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Adam Merz 2008-08-29T23:58:36 http://permalink.gmane.org/gmane.comp.lib.boost.user/39504 Hi. When designing server-client model, one has to use boost::asio::ip::tcp::endpoint and boost::asio::ip::tcp::resolver::query respectively. What I am confused about is that query accepts std::string& service as a parameter whereas endpoint only accepts unsigned short. When writing code, it is really easy to get confused which constructor takes string and which short. I would appreciate is somebody could tell me if there is a way to create a server side component using integer as a service. - V Vjekoslav Brajkovic 2008-08-29T23:48:33 http://permalink.gmane.org/gmane.comp.lib.boost.user/39503 Mat Marcus wrote: That wasn't my answer. See above. 1.36.0 works out of the box. But I get your point. Understood. You want point releases. We don't have the resources right now. We are busy flushing the bugs out of a new release process that should give us quarterly releases. This is in response to feedback such as yours. Beman has said on this list that the issue of point releases will be reconsidered once we are meeting our quarterly release schedule. In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases. In the future, I could imagine staggered releases ... something like a 3 month full release cycle, followed by 1 or 2 months to put out a point release. With extra resources, these two could happen in parallel, of course. Eric Niebler 2008-08-29T22:34:03 http://permalink.gmane.org/gmane.comp.lib.boost.user/39502 Sure, corporate environments often prefer to pretend software has no bugs, and thus rarely needs to be updated. I've got one customer who refuses to upgrade a ten+ year old C++ compiler because the vendor has come out with new releases every few years and management views that as a sign of great instability. Sigh. We took a straw-poll at BoostCon. Quarterly Boost releases were clearly the sweet spot for those present. There have been a number of posting to this list recently from folks who would like point releases in between the regular quarterly releases. We aren't going to do that, so making patches available is an experimental alternative. That's a lot more user friendly that asking people who want fixes to fool with Subversion, which may not be familiar to everyone. --Beman Beman Dawes 2008-08-29T22:18:37 http://permalink.gmane.org/gmane.comp.lib.boost.user/39501 Are you sure really want to do this? look into binary object. Robert Ramey Matthias Troyer wrote: Robert Ramey 2008-08-29T23:13:04 http://permalink.gmane.org/gmane.comp.lib.boost.user/39500 As far as Boost.Filesystem goes, it is perfectly usable. The fixes are primarily concerned with deprecated names. They only would be considered required if so much existing user code failed to compile that it is easier to apply the fixes than update the existing user code. In that sort of environment it is often best to stick with a particular version of Boost and other libraries until you reach a point in internal development cycles that it is convenient to change over to the newest versions of the libraries. Understood. That's quite a common scenario in mid-size and larger shops. Depends. In the kind of synchronized environment you are talking about, version upgrades do have to be managed carefully. OTOH, independent developers and other small and agile organizations may prefer to have the latest fixes, particularly if they are being impacted by the bugs being fixed. That makes sense in the environment you describe. HTH, --Beman Beman Dawes 2008-08-29T22:01:15 http://permalink.gmane.org/gmane.comp.lib.boost.user/39499 For missing C or POSIX features under Windows CE platform, I've developed a small utility library - a compilation enabler :-) http://mateusz.loskot.net/projects/wcelibcex/ I link it statically only, errno is not thread-safe. Best regards, Mateusz Loskot 2008-08-29T21:51:24 http://permalink.gmane.org/gmane.comp.lib.boost.user/39498 _______________________________________________ Boost-users mailing list Boost-users< at >lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Paul Heil 2008-08-29T21:18:30 http://permalink.gmane.org/gmane.comp.lib.boost.user/39497 For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases. - Mat Mat Marcus 2008-08-29T21:23:55 http://permalink.gmane.org/gmane.comp.lib.boost.user/39496 _______________________________________________ Boost-users mailing list Boost-users< at >lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Ramesh 2008-08-29T21:08:02 http://permalink.gmane.org/gmane.comp.lib.boost.user/39495 It is when compared to the overhead of IO (disk or socket, possibly even memory). I think here you are talking about the overhead of a single write operation versus multiple write operations on the underlying stream, correct? It's true that the standard stream operations can be slow, but that is a separate problem from the actual byte shuffling and should be solved separately. Maybe this problem could be avoided by using a std::vector<char> instead of a stream object for the actual serialization and then dumping it all at once. (It is not reasonable to just dump in-memory objects to a stream in any portable format, binary or text.) I though option 3 was to write little-endian archives on little-endian machines and big-endian archives on big-endian machines? If so, the generated archives would /not/ be the same. Hence the potential source of bugs. Rainer Deyke 2008-08-29T20:53:28 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.user