On Wed, 20 Oct 2004 13:57:27 -0400, Hugo Duncan wrote

Would anybody mind if I removed the sandbox version to prevent any more people spending time on that code?

No objection.

I am aiming to make an intial alpha release of giallo in the next couple of weeks.

Sounds great :-) Jeff

On Thu, 21 Oct 2004 Francis ANDRE wrote: Francis,

Would you put pack your Gallio developments into the boost foundry???

The intention has always been to get the library accepted into boost. I have moved it out of the boost-sandbox because my development has been very slow, and I did not want to give the impression of blocking anyone else who had more time from developing a "boost.socket" library. Hugo

Hugo Duncan wrote:

I am aiming to make an intial alpha release of giallo in the next couple of weeks. Following recent discussions I have factored out the demultiplexer code to be completely independent of the socket code, and am in the process of generating some initial documentation. The giallo CVS codebase will be somewhat unstable until then.

I'd just like to point out that I intend to share a prototype design of a demultiplexor. I don't think there will be much overlap, as it is not socket-centric, and perhaps doesn't even need to be part of a socket library, as its just as related to sockets as it is to, say, threads or directories. Furthermore, the code itself is not so important; my primary intent is to share a design for how I think a serious C++ demultiplexor should look. As its entirely flexable, it should be trivial to adapt to Gallio for demonstration purposes. Aaron W. LaFramboise

On Thu, 21 Oct 2004 Aaron W. LaFramboise wrote:

I'd just like to point out that I intend to share a prototype design of a demultiplexor.

Great. Your previous posts and the previous discussion motivated me to take a look at how the demultiplexer was coupled to the socket classes, and prompted me to better define the interface between them. The interface that I have is now: template <typename Impl> class demux { template <typename Arguments> demultiplexer_error add(Arguments&, bool notify=true); template <typename Arguments> bool remove(Arguments&, bool notify=true); bool handle_events(long timeout=-1); // one shot void run(); // until stop() void stop(); void notify(); // eg, new events to handle } The tricky bit seems to be creating concrete Argument classes, which provide the information about the resource the demultiplexer should wait on, possibly the type of event to wait for, and the function it should call if an event occurs. The solution I have implemented uses composition of othogonal classes, with the composition controlled by the concrete type of the demux implementation, the type of resource, and the operation being performed on the resource. An example: A waitable timer needs to provide a handle a callback. A socket wishing to do asynch io with proactor style completion notification using a windows event object demultiplexer needs to provide an OVERLAPPED structure an event object, and a callback. The concrete Arguments type computed in these cases provides what is needed, with the user consistently specifying just the handle and callback in each case. Does that make any sense? Does that compare somewhat to your proposal? Hugo

Hugo Duncan wrote:

On Thu, 21 Oct 2004 Aaron W. LaFramboise wrote:

...

I'd just like to point out that I intend to share a prototype design of a demultiplexor.

The interface that I have is now:

template <typename Impl> class demux { template <typename Arguments> demultiplexer_error add(Arguments&, bool notify=true);

template <typename Arguments> bool remove(Arguments&, bool notify=true);

bool handle_events(long timeout=-1); // one shot void run(); // until stop() void stop(); void notify(); // eg, new events to handle }

The tricky bit seems to be creating concrete Argument classes, which provide the information about the resource the demultiplexer should wait on, possibly the type of event to wait for, and the function it should call if an event occurs.

I also agree that this is a difficult part. However, in the way I've set up my prototype, this itself isn't actually a problem, as the registering of events of organized slightly differently.

Does that make any sense?

Yes.

Does that compare somewhat to your proposal?

Well, I think I've done things a little differently. Allow me to wait until I have something to show, though, before I elaborate. By the way, I've tentatively named my prototype class and the associated components 'notify.' Someone--I don't remember who--pointed out earlier that the name 'demultiplexor' is fairly awful, and suggested that new name instead. I like it. :) Aaron W. LaFramboise

Hi boost users, A friend of mine wants to expose properties in his classes in the form properties exist in other languages such as Delphi or VB or C#. I don't agree with the idea since get and set methods are just fine for me but I thought I would send this question out and see if any of you have a recommendation. The idea would be the following: class CButton { public: void SetColor(const int & nColor) { m_nColor = nColor; } const int & GetColor() const { return m_nColor; } private: int m_nColor; }; So of course we can set and retrieve the color of a CButton instance using the get and set methods in the way: CButton button; button.SetColor(5); int nColor = button.GetColor(); However what my friend wants to do is to expose methods so we can do: button.color = 5; int nColor = button.color; ...and the get and set method would be called internally. He already has a solution for this problem using a template class property<TClass, TType> that overrides operator= and operator value type, and then at runtime he binds the get and set methods to the property object. However, one of the things he would like to do is to not have to pass the class name to property and/or not have to bind the get and set methods at runtime to the property. I guess the functionality he wants is like the property keyword in VC++. Unfortunately this is a Microsoft only extension. Any ideas? Suggestions? Thanks -delfin