[interfacekit] Re: Submitted for your approval: the PortLink module

>Doh. I see now what you were talking about, Cedric. That's inexperience 

>talking for me. <sheepish grin> Back to the drawing board to fix, but 
the API 
>shouldn't change.

Glad you saw the error of your wicked ways. ;)  Something I'd like to 
propose (since you're working on a rewrite anyway) is to make Attach() a 
generic data writing function a la:

        void Attach(void* data, size_t size);

Initially, this might seem like a painful way to deal with data, since 
for an int you'd be doing something like:

        int myInt = 5;
        MyPortLink.Attach(&myInt, sizeof (int));

But what this will allow us to do is easily extend the types which 
PortLink handles by overloading the put-to operator:

        PortLink& operator<<(PortLink& Link, int i)
        {
                Link.Attach(&i, sizeof (int));
                return Link;
        }

Now usage is as simple as:

        int myInt = 5;
        int yourInt = 10;
        MyPortLink << myInt << yourInt;

In fact, now that I think about it, you could templatize the put-to 
operator:

        template<class T>
        PortLink& operator<<(PortLink& Link, T data)
        {
                Link.Attach(&data, sizeof (data));
                return Link;
        }

With that alone, we can do all manner of nifty stuff right out of the 
box:

        int myInt = 5;
        BPoint pt(0, 15);
        uint64 myBigInt = 1234567890;
        MyPortLink << myInt << pt << myBigInt;

Now we only have to overload for types that have more complex messaging 
needs.  Beauty is, we don't have to ever extend PortLink itself, just 
add overloaded operators!  Caveat emptor:  haven't even tried to compile 
this code, but with a little tweaking it should do the trick.  Man, I 
love C++! 8)

It would also be nice to see the class be bi-directional; I can see some 
instances where we would want to block waiting for some data -- for 
instance, after we've communicated our port to the app_server, we'll 
want to block on getting a response back with the port the app_server 
has set up just for us.  I suppose we could just loop on a port_read, 
but how much nicer to have it all encapsulated! ;)

        MyPortLink.SetOpCode(CREATE_APP);
        MyPortLink << fAppPort;
        MyPortLink.Flush();
        MyPortLink >> fServerPort;

OK, I'd better stop myself.  See, this is what happens when a programmer 
spends all his time doing administrivia. ;P

e

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: