- Boost - lists.boost.org

Status of clone_ptr?
by Mathias Gaunard 24 Aug '07

24 Aug '07

There was once a proposal for the addition of a clone_ptr, and eventually poly_obj (same without pointer interface) to the boost smart pointers. I would have liked to know what the status of this is.

1 1

[property tree] status?
by Jeff Flinn 24 Aug '07

24 Aug '07

What is the status of the property tree library? There is just an "under construction" entry for the docs in svn trunk AFAICT. Thanks, Jeff

1 0

[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