- Boost - lists.boost.org

[IOStreams] patch for "seek" bug in file descriptor device
by Frank Birbacher 24 Aug '07

24 Aug '07

Hi! I have had a hard time trying to figure out why my windows port of a file transfer program would not write anything to its files. I'm using boost svn, msvc 8 express, platform sdk from msvc 2003, and windows xp (SP2). I discovered that the file_descriptor device of the IOStreams library does not check for SetFilePointer failure as Microsoft recommands. This led to always throwing bad_seek. But the write function on the std::ostream& does neither return with the failbit set nor does it propagate the exception. Anyway the attached patch on the boost svn should fix this problem. I added a second check for failure as the MSDN ( http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp , see "Return Value") suggests. It works for me. Here is where I started: $LC_ALL=C svn info Path: . URL: http://svn.boost.org/svn/boost/trunk Repository Root: http://svn.boost.org/svn/boost Repository UUID: b8fc166d-592f-0410-95f2-cb63ce0dd405 Revision: 38755 Node Kind: directory Schedule: normal Last Changed Author: grafik Last Changed Rev: 38755 Last Changed Date: 2007-08-18 19:11:07 +0200 (Sat, 18 Aug 2007) $LC_ALL=C svn st ? bin.v2 ? stage ? libs/mpi/doc/mpi_autodoc.xml ? libs/intrusive/doc/autodoc.xml ? libs/logic/doc/reference.xml ? libs/program_options/doc/autodoc.xml ? libs/xpressive/doc/autodoc.xml ? libs/interprocess/doc/autodoc.xml ? libs/function/doc/html ? libs/algorithm/string/doc/autodoc.xml M libs/iostreams/src/file_descriptor.cpp "svn diff" in attached file. Frank Index: libs/iostreams/src/file_descriptor.cpp =================================================================== --- libs/iostreams/src/file_descriptor.cpp (revision 38755) +++ libs/iostreams/src/file_descriptor.cpp (working copy) @@ -159,8 +159,10 @@ #ifdef BOOST_IOSTREAMS_WINDOWS if (pimpl_->flags_ & impl::has_handle) { if (pimpl_->flags_ & impl::append) { - ::SetFilePointer(pimpl_->handle_, 0, NULL, FILE_END); - if (::GetLastError() != NO_ERROR) + DWORD const dwResult = + ::SetFilePointer(pimpl_->handle_, 0, NULL, FILE_END); + if (dwResult == INVALID_SET_FILE_POINTER + && ::GetLastError() != NO_ERROR) throw detail::bad_seek(); } DWORD ignore; @@ -192,10 +194,12 @@ way == BOOST_IOS::cur ? FILE_CURRENT : FILE_END ); - if (::GetLastError() != NO_ERROR) { + if (dwResultLow == INVALID_SET_FILE_POINTER + && ::GetLastError() != NO_ERROR) { throw detail::bad_seek(); } else { - return offset_to_position((lDistanceToMoveHigh << 32) + dwResultLow); + return offset_to_position( + (stream_offset(lDistanceToMoveHigh) << 32) + dwResultLow); } } #endif // #ifdef BOOST_IOSTREAMS_WINDOWS

3 5

Re: [boost] ScopeExit Review ends tomorrow
by Tom Brinkman 24 Aug '07

24 Aug '07

>> Give macros libraries a closer look, before dismissing them out of hand. Ok. Noted. Just thought I'd mention another issue, sorry to ramble. Some of the libraries on boost have been terrific learning tools for me to develop a strong sense of what a well written functional/generic library should look like. Many hundreds of hours went into some of them, I'm shur. Theyre are so many hidden nuggets in boost, that one could spend a lifetime trying to search them out. There are many subtle concepts but important concepts in functional/generic programming. In my estimation, it takes an intermediate c++ programmer probably an additional 2-3 years to really begin to appreciate the truely incredible power that functional/generic programming offers. Studying a well written boost library is a terrific way to learn how its done. Its a shame that some of them are incredibly hard to study, without substantial effort. In my case, I attribute that difficulty to macros -- so yes, I have developed a strong disliking for macros.

1 0

Boost::archive::basic_streambuf_locale_saver problem
by Shirley.Wu＠wrsa.com.au 24 Aug '07

24 Aug '07

Hi Boost developers, I'm one of the developer who is using boost library. I don't know whether anybody raised this problem before or not. I noticed that there's a problem in boost/archive/basic_streambuf_locale_saver.hpp. The compiler was complaining about the missing braces of namespace boost::archive. The problem is the #endif for BOOST_NO_STD_LOCALE is outside of the namespace boost::archive close braces. Should I just fix the close braces or should I find some other way to fix it? Once I just fix the close braces, other classes complain about the code (e.g. basic_binary_iprimitive.hpp which is using basic_streambuf_locale_saver class) .. more fixes involved. Could you professionals please give me some suggestions to fix the problem? or you already have patches for this problem? Thank you very much Shirley This email and any attachments are confidential and may be commercially sensitive. They are strictly for the use of the intended addressee only. If you have any reason to believe you are not an intended addressee then do not disseminate the information it contains in any form. Please immediately inform the sender of the error and destroy this email, including any copies of its contents. Please Note: Due to our recent legal name change, our previous @INVENSYS.COM email addresses will shortly cease to function, please ensure to update your records to firstname.lastname(a)WRSA.COM.AU This email and any attachments are confidential and may be commercially sensitive. They are strictly for the use of the intended addressee only. If you have any reason to believe you are not an intended addressee then do not disseminate the information it contains in any form. Please immediately inform the sender of the error and destroy this email, including any copies of its contents. Please Note: Due to our recent legal name change, our previous @INVENSYS.COM email addresses will shortly cease to function, please ensure to update your records to firstname.lastname(a)WRSA.COM.AU

1 0

Re: [boost] ScopeExit Review ends tomorrow
by Tom Brinkman 24 Aug '07

24 Aug '07

>> What can I learn from your criticism? What is it based on other than >> the fact that you don't like macros? By what standard shall we decide >> that use is "overuse?" I'm not shur that you can learn much from that criticism. Other than that I like to examine the libraries source code to help me learn about how it works. If the library is full of macros, or complicated templates for that matter, I often will just give up, and rely soley on the documentation. >> Well, let's be clear. We've been "warm" in the sense that we're >> willing to use macros when they are the best solution to a problem. I'm shur thats the case. >> One could say that for any programming paradigm that isn't "in the >> mainstream," which is an entirely relative judgement. Certainly >> Boost's "dependence on and overuse of templates" is often cited by >> those unfamiliar with certain programming styles as presenting exactly >> the same danger. At Oracle, they use C and ban C++ for the same >> reasons. Good points. Boost should or could be considered a centralized repository where promising experimental libraries can get additional scrutiny for evenutal standarization. >> Well, please study it in depth before leveling such a charge publicly >> based on your suspicions. I qualified my statement by saying that I "suspected" that it was the case, not that it necessarily was a factual statment. >> The macro generates all the boilerplate of forwarding >> functions, handles the "forwarding problem" for the user, evaluates >> defaults in exactly the lazy way one would like without requiring >> lambdas or other function objects, avoids exposing ArgumentPacks, >> ... I think that those are pretty creative uses of internal macros and I have no problems with those uses. I just hope that I'm never tasked with their maintenance.

2 2

Logging Library - WIP
by Tom Brinkman 23 Aug '07

23 Aug '07

Looks good. This is a much needed library.

1 0

Proposed library
by Jake hall 23 Aug '07

23 Aug '07

On Wednesday 22 August 2007 21:18, Jake hall wrote: > I would like to hear peoples thought on a library i uploaded to the > vault and maybe get it submitted for review. > the libraries name is the EventHandler library, it can be found in the > vault under home / Generic Programming / EventHandler.zip > > i find it simple to use (well i wrote it so i should) but effective at > adding almost .net style events to classes > I've never used .net events/delegates, but from a google search and a > subsequent 60 second review of an article on them, they seem to cover the > same ground as signals/slots. Am I way off base here? I quickly googled signals/slots and found a website called http://doc.trolltech.com/3.3/signalsandslots.html which talkes about a class called "QObject", at the begining of the page they state there reasons for using signals/slots, which are ; doc.trolltech.com wrote: >Callbacks have two fundamental flaws. Firstly they are not type safe. We can never be certain that the processing >function will call the callback with the correct arguments. Secondly the callback is strongly coupled to the processing >function since the processing function must know which callback to call. The EventHandler library enforces a type safety in the callback function pointers and you can also clone EventHandlers simply by event_handler<> * event = &anotherevent; so althout you need to know the function to call it doesnt have to be specified each time. these features minic (and in areas improve on) the .net feel of events.

3 3

Re: [boost] ScopeExit review
by Maxim Yanchenko 23 Aug '07

23 Aug '07

I vote to accept the library into Boost. * What is your evaluation of the design? * What is your evaluation of the implementation? The design and implementation is clear and straightforward. Of course we'd like to have such a library with better syntax, but current C++ doesn't allow to make it better. * What is your evaluation of the documentation? Clear and understandable. * What is your evaluation of the potential usefulness of the library? I believe the library is very useful, I will use it in my work. It helps to avoid writing complex rollback code clean and in-place. Another nice feature comparing to using lambdas is the ability to place breakpoints inside the rollback code. Without ScopeExit you can only achieve this by using manually-written scope guard class from scratch * Did you try to use the library? With what compiler? Did you have any problems? Yes, played with the examples from documentation, GCC 3.4, no problems noted. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Compiled, played with examples, looked into the implementation. * Are you knowledgeable about the problem domain? I'm sure everyone is :) * Do you think the library should be accepted as a Boost library? Yes. A couple of general comments after reading other reviews. 1. The fact that the library takes all arguments by reference looks unavoidable. If it allowed passing by value (i.e. making copies) - the copy constructors can throw, and this exception will be thrown after you made the change to your container/whatever you'd like to rollback, and before you setup the rollback action. So you can't guarantee that your rollback action will be executed. So, in case you need a copy - it's much safer to create this copy before making the change to your container/whatever. It will also express your intention more clearly. 2. Of course it would be great to have a full-featured scope guard library in Boost, but its absense is not an excuse to reject ScopeExit, otherwise we need to reject scoped_ptr/scoped_array etc, as they are forms of scope guard. In general, I believe we can't reject a library A just because Boost misses a library B. Thanks, Maxim

5 10

Re: [boost] [Boost-users] [ScopeExit/Typeof] Can't build simple test in debugmode (MSVC 7.1 and 8.0)
by Christian Larsen 23 Aug '07

23 Aug '07

It applies to ScopeExit I see. It seems to be caused by the use of __LINE__, (see http://article.gmane.org/gmane.comp.lib.boost.user/17341/match=boost+edit+co ntinue). This makes sense as edit & continue would probably get a hard time with changing line numbers. But still it produces nonsense error messages. Best regards, Christian Larsen Christian Larsen wrote: > I've moved this to the dev list, because it should probably be mentioned > in the documentation somewhere. I'm not sure whether it belongs in Typeof > or ScopeExit. > > I've tried building the hello.cpp example that comes with ScopeExit with > the same results (as in my original message). I think I have narrowed down > the cause. Building fails whenever "Program Database for Edit & Continue > (/ZI)" is set in the project properties. Changing this to "Program > Database (/Zi)" or any other fixes the problem. Is this a compiler bug? > > I never use Edit & Continue anyway, but I thought it might be helpful to > others to mention this problem somewhere. > > Best regards, > Christian Larsen > > > Christian Larsen wrote: > > I'm trying build a very simple test program using ScopeExit (just > > downloaded > > from the link in the review notice: > > http://boost- > > consulting.com/vault/index.php?action=downloadfile&filename=sco > > pe_exit-0.04.tar.gz&directory=& ). I'm using a brand new download of > Boost > > 1.34.1 with it. The following code builds and runs fine in release mode > in > > both VC7.1 and 8.0, but fails to build in debug mode in both versions. I > > also tried specifying the BOOST_TYPEOF_COMPLIANT in MSVC7.1 debug but to > > no > > avail - I just get some other errors. I couldn't find any indication of > > what > > would cause this difference between debug/release builds. I tried > > disabling > > optimizations in release mode to check whether this would cause release > > mode > > to fail, too, but it didn't. Any help would be appreciated. [SNIP]

2 2

Re: [boost] ScopeExit review
by Yanchenko Maxim 23 Aug '07

23 Aug '07

I agree with Steven, This syntax looks same as the new Boost.Parameter syntax, and this is good for the Boost as a whole. Thanks, Maxim 23.08.07, 20:03, Steven Watanabe: > I prefer BOOST_SCOPE_EXIT((cref c)(ref r)(val v)) > for two reasons. > 1) It makes it clear that they are /not/ function > calls > 2) It's slightly easier to implement because you > can use BOOST_PP_SEQ_FOR_EACH. > In Christ, > Steven Watanabe

2 1

[admin] Release schedule proposal
by Beman Dawes 23 Aug '07

23 Aug '07

Proposal -------- * Quarterly release schedule, with the target release date the 15th of the first month of each quarter. * If a release is late, that does not slip the date of the next quarter's release. * If something isn't ready for the current release, it is simply held until the next release. The current release is not delayed. * Being ready means being ready by the cutoff date set by the release manager. That will be relative early in the release cycle. Rationale --------- Regular releases that occur on a predictable schedule have many benefits: * Developers know far in advance when library updates must be ready, and that's both an aid to planning and a motivation to get stuff done. * Users know far in advance when library updates will be ready, and that helps their planning and reassures them of continuing support. * Regularity creates a sense of quality and trust in Boost for both developers and users. Quarterly releases seem about right: * It's often enough that the process will become smooth. * It's often enough that developers won't feel pressure to release immature updates. * It's often enough that users will feel bug fixes and new libraries are being released on a timely basis. * It isn't so often that users will view Boost as unstable, particularly given the predictable schedule. * It isn't so often that developers and release managers will become fatigued. * A quarterly (or similar) schedule has been very successful for both open source and commercial projects. Comments? The rationale depends a lot on my personal experiences, but I don't see that as a bad thing. --Beman

2 1