- Boost - lists.boost.org

GMane posting slow?
by David Abrahams 04 Apr '05

04 Apr '05

In the past few days I've noticed that most of my posts through GMane incur a long delay before going out. Is anyone else seeing the same symptoms? This wouldn't be a problem for me if posts happened in the background, but since I'm using Emacs message-mode, I can't do much else until the messages get sent. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[Thomas Barket] Bug still in new (1.32.0) version of boost library
by David Abrahams 04 Apr '05

04 Apr '05

FYI -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[errorinfo] A proposal for better error handling
by Don G 04 Apr '05

04 Apr '05

A technique I have used and evolved over the past few years is a more powerful way to handle errors, derived from std::exception. Following are the motivations and some details. I am curious to hear if others find this a useful facility. The current std::exception class suffers from several problems that limit its use: 1. It cannot be polymorphically copied for storage. 2. It has no virtual "rethrow" method. 3. Instances cannot be extended with extra details. 4. Underlying system error codes are lost. Either of the first two problems would prevent effective marshalling of an instance, as would be needed in an asynchronous environment. The 3rd problem greatly reduces the ability to capture pertinent information during the unwinding process. Example 1 - Capturing an error for later use class StateMachine { private: errorinfo::ptr error_; void called_on_error (const errorinfo & err) { error_ = err.clone(); } }; There are two mechanisms for adding error information: Extending and Chaining. The simpler case is extending an errorinfo object. The reason to extend an errorinfo is that the caller will have more details about the context of the failure than the thrower. Typically a lower level method may encounter a problem and throw an exception, but doesn't know _why_ it was called. The caller, however, knows more about the "why" and can add those details before letting the exception unwind further. Example 2 - Extending the description of an error try { do_something(); do_something_else(); do_something_more(); } catch (const error::logic & x) { x.extend("Failed to achieve my goal").raise(); } The idea behind chaining is similar to that of extending. When extending an errorinfo, only the description (reported by the what() method) is changed. The type of errorinfo is unchanged. There are times that what the caller may be doing would change the kind of failure reported upwards. For example, a method that searches for something might throw error_not_found. The caller might decide that this would be an inappropriate type to throw to his caller and so would want to catch error_not_found and throw some other exception. To preserve the original error_not_found, we can chain it with the newly created exception. Example 3 - Chaining errors try { find_something(); } catch (const error::not_found & x) { throw error_whatever(x.clone(), "Failed in some way"); } I have posted errorinfo.zip on the Yahoo files section for those wanting more detail. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

1 0

[signals] Performance
by Jody Hagins 04 Apr '05

04 Apr '05

Are there any docs which describe the performance of the signal/slot library? I was about to embark on a performance study because I want to use it in a very high performance critical code path, but I thought I'd ask if anyone else may have already done some work in this area. Thanks!

12 35

Re: Asynchronicity (long)
by Don G 03 Apr '05

03 Apr '05

Hi Boris, No problem on the delay. I sometimes have long spells of silence due to work/family/church/life-in-general. :) My answers / opinions are below... --- Boris <boris(a)gtemail.net> wrote: > Hi Don, > > sorry for my late answer but work caught me again. At least > it's good to see others jumping in and keeping the > discussion alive. :) > > > [...] > > ------ Sketch -------- > > [...] > > It reminds me of I/O completion ports - several ports each > of them handling several events? Is your idea similar to this? It is similar, but the channel concept has no analogy. Then again, most async mechanisms are similar, it's just in the details that they diverge<g>. QueueUserAPC + SleepEx(ALERTABLE) is also similar, but again lacking the channel notion. The closest analogy in Windows is the USER thread message queue, an HWND and Get/DispatchMessage + PostMessage. I believe one can find nearly a one-to-one correspondence with that model. > > ------ Pseudo-code -------- > > > > class nexus > > The concept of the class really reminds me of a I/O > completion port. The only difference is that there is no > invisible background thread being responsible for a > nexus object - the application has to make sure that > there is one thread controlling a nexus object? Essentially, yes. Nothing is hidden with the possible exception of how does some body of code know the proper nexus object to which a channel should be connected. This can be explicit, but a thread-specific data item is also compelling. > > [...] > > class channel > > AFAICS you use this class to communicate with a nexus object. > The owner thread does the multiplexing (waiting for different > events in a nexus object) and other threads communicate with > this nexus object through channels which are responsible for > synchronizing? Is this correct? If I understand you correctly, Yes. The channel objects are the means by which the user enqueues events to a nexus object and a different piece of user code calls the nexus object to dispatch/dequeue the messages. > So the difference between your approach and I/O completion > ports in Windows is ... hm, I think in Windows a completion > port is a combination of your nexus and channel, isn't it? It is basically that, yes. The channel class, however, I believe to be a very important concept. Merging it with the nexus class would create dangerous situations where one would have to ask at the point a message is enqueued: "will it be OK to deliver this message regardless of what might happen between now and the time of delivery?" The key impulse that can make this answer always NO is "delete foo". The delete operation is synchronous. Without a channel to serve as a way to cancel pending messages to that object, we would have dangling pointers in the queue (a bad thing). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 13

Re: [1.33.0] Release schedule suggestion
by Dave Gomboc 03 Apr '05

03 Apr '05

> I'll agree again. The changes I check in when we are in release mode (have a > release branch active) _always_ go to both the trunk and the branch. The > branch doesn't help me in any way. > > Apr 15: feature freeze > Release "when it's done" If "when it's done" is short enough, e.g. 2-3 weeks, then it's not even worth branching. Better to just concentrate on getting kinks out for the release. Is this at all realistic? Dave

4 7

Re: Proposal: intrusive containers
by Jaap Suter 03 Apr '05

03 Apr '05

> 1. Instead of providing the two options of deriving and embedding, let > the user provide ADL-style 'next' and 'prev' lookup functions that for a > given type provide hooks to the intrusive containers. "I'm not sure about this, most of the difficulty is involved in manipulating the links" Yes, the access provided to the links should obviously be referential so the containers can freely manipulate them. " - iterator adaptor or facade can be used to easily create iterators for types with their own next and prev pointers." It's not the iterators I'm worried about. It's being able to provide uniform STL-ish access to all my current intrusive containes. Inserting and removing elements from such containers becomes a lot more consistent, I believe. "If there was a check that a node wasn't in a container on insertion wouldn't these problems disappear?" Yes, but I don't always want to pay for this check if my own program logic dictates that I cannot possibly be inserting an item that already exists. In my own code, we have an 'insert' and a 'safe_insert'. However, occasional refactoring turns an 'insert' using piece of code into something that should be using 'safe_insert'. I'd like to be able to temporarily turn on invariant checking for a list when I'm working on the code around it, so I can make sure my changes didn't violate any conditions. Regards, Jaap Suter

1 0

Re: [1.33.0] Release schedule suggestion (David Abrahams)
by Dave Gomboc 03 Apr '05

03 Apr '05

> >If "when it's done" is short enough, e.g. 2-3 weeks, then it's not > >even worth branching. Better to just concentrate on getting kinks > >out for the release. Is this at all realistic? > > the reason for the branch is to that those developers who > need to work on > stuff NOT related to the release have someplace to put their > "commits". Yes, I know, but I also speculate that if the feature freeze time is short, then the number of Boost developers who "need" this is approximately zero. It's a plus if all developers are focusing on the actual release, so even if someone would otherwise be working on stuff for 1.34.0, if they are instead helping to clear regressions for 1.33.0, this means the 1.33.0 release will be ready sooner than otherwise. Dave

1 0

RE: [boost] Re: [Filesystem] Feature Request:Onemoreimplementationusing.NET
by Brian Braatz 03 Apr '05

03 Apr '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Holger Grund > Subject: [boost] Re: [Filesystem] Feature > Request:Onemoreimplementationusing.NET > > "Edward Diener" <eddielee(a)tropicsoft.com> wrote > > >>> I believe Microsoft will fix that bug in 2.0. > >>> The only disadvantage that it's not ready yet. > >>> > >>> So, may be we should postpone this question until 2.0 released? > >>> > >>> Anyway I don't think it's bad idea to do it with at least .NET 2.0. > > > > The problem is that the .NET classes themselves do not support templates > > as > > classes or as public or protected member functions. So moving any of > Boost > > to .NET essentially must drop the use of templates for the programmer > > using > > the implementation. > > That's not quite correct. You can have templates of managed types. > The C++ compiler will instantiate these as usual and create mangled > names which many existing languages targetting the CLR can't > access (they can still access methods via a base class). > > BTW: .NET 1.2 has never been released to the public and I think was > the CLR version used for some very early alpha (I think when we first > got the bits in July 2003, it shipped with a 1.2.30703 or something) > > VC++'s implementation of the C++/CLI language will enable you > to compile almost all of your existing C++ code to managed code only. > (the /clr:pure switch) > > That doesn't mean, however, that magically your code can be accessed > from other languages targeting the CLR nor that it will take advantage > of integrity/safety features of the GC memory system. If you want a > verifiable executable you simply need to rewrite your code (and you > can't use certain things in certain contexts like pointer arithmetic or > managed references as members ..) > > The language design is obviously intended to keep our (and oc, MS's > own) C++ assets. Just take your code compile with /clr and add > new managed functionality with the extensions of the C++/CLI > binding. > > So effectively, writing an implementation with the current structure > and using .NET classes for file system access gets you a whole lot > of nothing, I'm afraid. > [Brian Braatz Writes:] Forget Managed C++ Bad idea its going away (ugly too) The new CLI layer lets your code "be" C++ code and run in the dot net environment. You keep all the C++ performance by doing this. Only if you choose to expose something via the CLI mechanisms do you suffer performance issues with managed value\reference types Converesly, though what you gain is the ability to take your cpp code and selectively share out interfaces to it to other dot net libraries. Once you SHARE those things however you lose multiple inheritance and you cannot expose CPP templates. Additionally- the "sharing out" mechanism in CLI is akin to the PIMPL idiom (this is how CLI deals with you hooking the two worlds together) As Stan Lippman has said "C++ is multiparadigm. CLI is just another paradigm" The good news is you can use boost regex all day long. You can remain a CPP app , and you can share out functionality with dot net if you so choose.

1 0

[Boost-bugs] [ boost-Patches-1169756 ] Threads add additional assert to aid in debugging join()
by SourceForge.net 02 Apr '05

02 Apr '05

Patches item #1169756, was opened at 2005-03-24 01:55 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Threads add additional assert to aid in debugging join() Initial Comment: see discussion at http://article.gmane.org/gmane.comp.lib.boost.user/10093 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-02 15:03 Message: Logged In: NO added in Revision: 1.20, Tue Mar 29 16:19:32 2005 UTC by glassfordm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0