Re: [boost] Determining interest in combining_iterator
<[EMAIL PROTECTED]> wrote: > FWIW, I've extended my pair iterator to be a tuple > iterator for > input/forward/bidirectional/random-access iterator > categories, which was > relatively painless. I will boostify it, add output > iterator support back in, > and test it with VC7.1 as well as g++ 3.2.2, if you > (or anyone else) are > interested. Well, this combining iterator thing is the first time I'm ever submitting anything to boost, so I don't know if I should give advice, but what I did was to click on "Submissions" at www.boost.org and it said that Step 1 was to post a description of the proposed submission to the boost mailing list to determine interest. So that's what I did, and I suppose that's what you should do too. In my case, the response was not overwhelming, but it wasn't devastating either, and I got a positive from David Abrahams. So what I'll do next is to check out their new iterator adaptor stuff in the sandbox and see how my stuff fits in there or can be made to fit in. Since my combining iterator would have to be part of the iterator adaptor library, it will then ultimately be David's, Jeremy's and Thomas' decision whether they want it in there or not. Thanks a bunch for yall's feedback so far. It has certainly helped me sort things out. Finally, Anthony: As I look at the new iterator adaptor in the sandbox, I will of course keep an eye on whether their changes have any bearing on the relationship between what you have and what I have. Under the current boost iterator adaptor, I think it is clear that yours and mine are at least as different from each other as the transform iterator is different from the projection iterator, and hence they are two separate things. It may be a while until I get around to working on all this again, so let me know if you have any new insights in this regard. Thomas Becker Zephyr Associates, Inc. Zephyr Cove, NV [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] How do I install boost::filesystem?
I am trying to use the boost::filesystem library, but when I follow the instructions in the documentation to the best of my ability, the linker does not seem to find the components that it needs. I am using MSVC6 under Windows XP, and after downloading version 1.30.0, I typed bjam "-sTOOLS=msvc" in the boost directory, as described in the documentation. This seemed to build a lot of things, and scatter the results in various deep subdirectories. When I then try to link my own test program, which uses the constructor boost::filesystem::path(const char*), the linker complains that it cannot find this symbol in any library. I would assume that this is because the filesystem library has not been installed in the library path, but there is no mention that I can find in the documentation of any further actions I should perform after I have run bjam. Copying the file \boost_1_30_0\libs\filesystem\build\bin\libboost_filesystem.lib\msvc\debug\runtime-link-dynamic\libboost_filesystem.lib by hand to the default MSVC library directory does not seem to have any effect at all, and explicitly adding it to the cl command line only results in the linker complaining about a lot of multiply defined symbols. In any case neither of these actions is suggested in the documentation. What is it that I am supposed to do? I am quite sure that the answer is something quite trivial, because I am by no means any expert on the MSVC environment, but I do think that the Boost documentation should explicitly mention all the steps that are required to use any of the libraries. I have previously beed successful in installing the regex package by just following the intstructions in the documentation, so for that library, the build and install information was evidently sufficient for someone like me. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression logs
Beman Dawes <[EMAIL PROTECTED]> writes: > I think Alisdair's raised some good points. While I'm not sure > regression testers will want to put a lot of effort into back tests, I > think it would be good if from here on out we segregated current from > past tests. > > So I'd say give it a bit more thought and see what you can come up > with. It will probably be easier to leave everything in one directory, > but have the script display each release separately. Maybe default to > current state, but with an option to look at past tests. > > Keep in mind the number of test platforms is likely to increase as > time goes on. That also argues for better separation between releases > and the current CVS state. I just returned from PyConDC 2003, where a system was described which will watch a CVS repository for checkins, launch new remote tests on any number of platforms, collect the results, and notify people of failures (e.g. via mail or even IRC chat). It can be set up to bother the person at fault first, and then bother a different group, for example. http://buildbot.sourceforge.net/. It looks like it could be really useful for us. Brian Warner expressed interest in helping us get that BuildBot up for Boost if we want to use it. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
"William E. Kempf" <[EMAIL PROTECTED]> writes: > Russell Hind said: >> I'd been wondering this, and heard about TLS issues. The issues are >> only on Windows it appears. Search for the thread >> >> "Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on >> 18/02/2003 >> >> Specifically, the many posts by William Kempf and Edward Diener discuss >> the problems on windows with TLS cleanup. >> >> I do have a question on this issue: If this problem is only to do with >> TLS cleanup when a thread exits, then if all threads are created when >> the program starts and only destroyed when the program exited, then, in >> practice, could this really be an issue? I.e. if we only work like >> this, could building thread as a static lib cause problems providing >> that we don't let threads exit in the middle of the program? We're >> currently really trying to stay clear of any DLLs. > > Theoretically at least, I don't see why this would cause a problem. You > intentionally leak, but the leak is benign since it occurs only right > before the application exits. But most users won't code this way, nor do > I want to have to deal with the support requests/questions this would > cause. So, unless you have some suggestion as to how I can enable this > usage with out causing confusion, I'm not sure I'd care to re-enable > static builds. But you could probably fairly easily hack things to build > that way yourself. I don't really understand the issues here, but I was wondering if you could reclaim "leaked" TLS resources lazily somehow, by looking for unused TLS the next time new TLS is requested. Just a thought... -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Thread Lib and DLL
Yes, cleanup could be solved this way (or with other approaches, daemon thread, periodic timers, etc). However, I don't see cleanup as the core issue with making TLS work without a DLL under Win-32. Currently, boost.threads supports (uses/specifies) the POSIX style cleanup model where the cleanup function is called on the thread that is closing. This cleanup function can also set/get/clear TLS values (which should continue to be valid for the "closing" thread until it exits [read: right after the cleanup func finishes]). Boost.threads TLS/DLL approach is used to fire off the cleanup function on the closing thread. There are also issues with this [DllMain single-dispatch rules, someone waiting in a cleanup handler, and others], but this approach at least allows boost.threads under Win32 to conform to it's own specification. [ Note: Windows internally seems to have been fixed by MS at some point to dispatch DLL_THREAD_DETACH in a "reverse-dependency" order, which makes sure that the DLL that was most recently loaded is the first to receive DLL_THREAD_DETATCH messages. Without this behavior, DLL TLS support would have serious issues in even working out of the box. The reason this seems to be a fix by MS at some point, is that the DLL_THREAD_ATTACH order is *NOT* in dependency order, but in what appears to be link order. Perhaps someone from MS can comment on the implementation, and how it came to follow these [undocumented] rules. ] For boost.threads stand-alone lib, the only solution I currently see is: - Relaxation of the cleanup function handler requirement from "WILL BE CALLED", to "MAY BE CALLED" from the closing thread. If this was done, then Unix implementations would continue working as is (call from cleanup func in closing thread), and windows implementation would have a worker thread(s) dispatch the cleanup handler functions when threads were shutdown (this thread would wait on the thread object when TLS values were in use on a particular thread). Note, the calls to the win32 boost TLS functions can be made to "work" correctly if dispatched from a cleanup-handler, which is what we want. However, OS level functions, [GetCurrentThread() and friends] would yield the thread of the "cleanup dispatcher" thread which is indeed incorrect. Since *few* people do "fancy" things in TLS [usually they deallocate/free resources], and *even less* people call other TLS functions from cleanup handlers, and *even less* people call OS-thread functions inside their TLS cleanup handlers, I see the change in the specifications to be reasonable. With something like this I see a valid (if complex in implementation) way to support boost.threads as a static lib. Willam Kempf has be gracious enough to discuss many of the issues at length with me and has examined various approaches to solving the TLS / DLL dependency issues. At first I thought it should be possible to solve, but I now feel that solving it within the scope of the current TLS-cleanup handler specification is impossible without modifying the specification (from WILL to MAY "call from the closing thread"). Here Bill and I disagree :-). Bill feels that the specification should not be changed, since this is an OS-brokenness issue that can be corrected by MS at some point in the future. I feel, that the boost thread specification should be modified for this (very rare) corner case, in order to support Win-32 static lib builds of boost.threads. I don't see any right or wrong here, as it is fundamentally a matter of specification. - Steve PS I also share Bill's desire to find a workable solution to this problem. However, I am pessimistic that there exist solutions that work under Win-32 and conform to the boost thread TLS spec rules for cleanup handlers. -Original Message- From: David Abrahams Sent: Saturday, March 29, 2003 10:16 AM > I don't really understand the issues here, but I was > wondering if you could reclaim "leaked" TLS resources > lazily somehow, by looking for unused TLS the next time > new TLS is requested. Just a thought... -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Thread Lib and DLL
David Abrahams wrote: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >> Russell Hind said: >>> I'd been wondering this, and heard about TLS issues. The issues are >>> only on Windows it appears. Search for the thread >>> >>> "Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on >>> 18/02/2003 >>> >>> Specifically, the many posts by William Kempf and Edward Diener >>> discuss the problems on windows with TLS cleanup. >>> >>> I do have a question on this issue: If this problem is only to do >>> with TLS cleanup when a thread exits, then if all threads are >>> created when the program starts and only destroyed when the program >>> exited, then, in practice, could this really be an issue? I.e. if >>> we only work like this, could building thread as a static lib cause >>> problems providing that we don't let threads exit in the middle of >>> the program? We're currently really trying to stay clear of any >>> DLLs. >> >> Theoretically at least, I don't see why this would cause a problem. >> You intentionally leak, but the leak is benign since it occurs only >> right before the application exits. But most users won't code this >> way, nor do I want to have to deal with the support >> requests/questions this would cause. So, unless you have some >> suggestion as to how I can enable this usage with out causing >> confusion, I'm not sure I'd care to re-enable static builds. But >> you could probably fairly easily hack things to build that way >> yourself. > > I don't really understand the issues here, but I was wondering if you > could reclaim "leaked" TLS resources lazily somehow, by looking for > unused TLS the next time new TLS is requested. Just a thought... The problem lies in the fact that the TLS API only gives one access to the storage slot for the thread which is being executed. One does not use any "tag", or identify the thread in any way, when gaining access to a storage slot for a particular thread. Therefore it is not possible using the Windows TLS API to gain access to the storage slot for another thread other than the one currently executing. Of course one might be able to roll's one own thread local storage implementation, probably using std::map<> to map a thread-id against storage areas for a particular thread, etc. etc. which would allow one to gain access to another thread's storage areas for thread specific data in order to do lazy reclamation, but one would have to do a good bit of work in order to accomplish what TLS automatically gives you. Also, of course, one's own implementation of TLS would not be compatible with the end-user's normal thread-local storage if that matters. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Thread Lib and DLL
I believe you still have the problem of cleanup handlers needing to execute within the closing thread (before the thread exits). One can call WaitForMultipleObjects() with a cleanup-worker thread whenever TLS is used, but you would only be able to execute the cleanup handler function (for the closing thread) within the cleanup-worker's context. This would allow the cleanup handler to execute from a cleanup-worker thread, before the thread object was actually closed. If the boost TLS specification were relaxed to allow for cleanup handlers to execute from a different thread (with boost.thread's Get/Set TLS methods working), I see the possibility for a boost.threads static-lib solution. The previous email about the current boost specification gets into more detail about possible options in this space. - Steve -Original Message- From: Edward Diener Sent: Saturday, March 29, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: [boost] Re: Re: Thread Lib and DLL > Of course one might be able to roll's one own > thread local storage implementation, probably > using std::map<> to map a thread-id against storage > areas for a particular thread, etc. etc. which would > allow one to gain access to another thread's storage > areas for thread specific data in order to do lazy > reclamation, but one would have to do a good bit of > work in order to accomplish what TLS automatically > gives you. Also, of course, one's own implementation > of TLS would not be compatible with the end-user's > normal thread-local storage if that matters. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Variant Library Review
Quoting Gennadiy Rozental: > Here is my a bit late review for the variant library. In spite of > several > concerns that I have, I incline to vote to ACCEPT this submission. Hi Gennadiy, thanks for the comments. I apologize for my late response. [snip] > Design > _ > > In most part design of the library looks solid and well thought-out( > I think we definitely ought to give Andrei credits for this also). As has been discussed since your posting, Andrei will receive credit for his OOPSLA 2001 paper and his C/C++ User Journal insofar as those works inspired the design of Boost.Variant. > There are several things that bother me though. > > 1. Two types requirement > It's unreasonable. ! or even zero sized variants should be allowed. I know you had not followed the review discussion closely, but we decided similarly as you did. There was once justification for this design decision, but it no longer applies. Accordingly, the requirement will be removed, with variant<> simply as shorthand for variant. > 2. Top level const requirement on bounded types. > It's unreasonable. I should be able to define variant with const > types. It will be as usable as usual constant types are. The only > requirements that we may incur is that if one types is const, > rest should be also. It's actually not unreasonable: one of the primary goals of variant is to match the semantics of its bounded types as closely as possible. The prohibition on top-level const types, then, is quite reasonable. To see, consider the following: const int i = 3; i = 4; // error variant v; v = 4; // error? If top-level const types *were* allowed, then the assignment would succeed. Itay and I decided such was highly undesirable. Let me know if you disagree with the above reasoning. > 3. Copy Constructible/Assignable requirements on bounded types > This only need to be required if variant should have appropriate > feature. I disagree. As-is, every variant object requires CopyConstructible bounded types, as it is the only way to construct its content. Some notes, however. I may be able to eliminate the Assignable requirement altogether by modifying the implementation of variant::swap. As well, there has been some discussion about in-place construction, which could eliminate the CopyConstructible requirement except in cases of actual variant copying. (This conversation occurred with regard to optional, but could work with equal applicability to variant.) > 4. DefaultConstructible requirements on first bounded types > This only need to be required if variant need to be default > constructible. Agreed. > 5. Usage std::type_info for reflection > I don't think we should enforce RTTI for the variant users. We should > be able to postpone the decision on what kind of reflection > information user want till instantiation time. Please elaborate on this point. FYI, the current variant::type method is provided so as to mirror boost::any. > 6. extract > I not like this name. It does not reflect the essence of the > operation it performs. It does not extract juice from orange. It > provides an access to the varant value. It basically external > access method. So the name get, get_value would be more > appropriate. This issue was extensively discussed during the review, but I am not sure it came to any definite resolution. I am currently looking into the proposal by Joel de Guzman's to provide a 'get' function such as used by the tuple library. > Also I think we need free function form of value > extraction. In other case it would be difficult to place extract > in context where template parameter is deduced. And check function > is not that important in most cases. While I am again considering a free function, I'm not sure what difference it makes. Please elaborate. Also, I think the functionality offered in extract::check is quite important. Unlike visitation, extract (or get, or whatever) handles only one of several possible states of the given variant object. > 7. Variant size > Unfortunately I was not able to follow exact logic behind usage of 2 > different storages. But one thing I know: > sizeof(boost::variant) could not be 28. > >From what I view it seems that types that are used to construct > storage2 also used when constructed storage1. So we definitely have > size duplication here. The two storages implement Anthony William's "double storage" technique. (See http://aspn.activestate.com/ASPN/Mail/Message/boost/1314807 for an overview.) This technique is necessary to provide a general guarantee of strong exception-safety, which in turn is necessary to maintain a "never empty" invariant for variant. In regard to the particularly large size you report, I believe it results from a problem either with boost::type_with_alignment itself or with my understanding of it. Thus, I am aware of the problem, but I am still determining how best to a
