🚀 go-pugleaf

>> "ian" == "ian (i ) willmott" <willmott@bnr.ca> writes:

 ian> The point is that the "driver" shouldn't have to know the type
 ian> of the object the callback is directed at. This is particularly
 ian> important when the "driver" issuing the callback is a library
 ian> API, such as Motif; you do not want the library to have to know
 ian> about application data types and you do not want to constrain
 ian> the application to use a single callback object type that is
 ian> defined by the library. The point of the proposal is that there
 ian> is a simple extension to the language which would accomplish
 ian> this in a type-safe way.

I don't understand why the example in the C++ Report is not sufficient
for you. Any way if you want a simpler (i.e. less sophisticated
version, here it is and please, no more extension !!!!

//
// library side ===========================================
//
class Callback
{
public:
  virtual void call() = 0;
};

void foo(Callback& cb)
{
  cb.call();			// callback
}

template<class ClientInfo>
class GenCallback : public Callback
{
public:
  ClientInfo client;
  
  virtual void call()
  {
    ((client.object)->*(client.method))(client.data);
  }
};

//
// application side ===========================================
//

class MyObject			// your object here
{
public:
  struct arg { int i; double f; };
  virtual void bar(arg&);
};

typedef void (MyObject::*MyObjectMethod)(MyObject::arg&);

struct MyCBInfo
{
  MyObject* object;
  MyObjectMethod method;
  MyObject::arg data;
};

main()
{
  MyObject o;
  GenCallback<MyCBInfo>* p = new GenCallback<MyCBInfo>;
  p->client.object = &o;
  p->client.method = MyObject::bar;
  p->client.data.i = 1;
  p->client.data.f = 0.1;
  foo(*p);
  return 0;
}



--------------
L.D.
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

In article <4h5j7b$1ur@bcarh8ab.bnr.ca>, "ian (i.) willmott" <willmott@bnr.ca> 
wrote:

>The point is that the "driver" shouldn't have to know the type of the object 
the
>callback is directed at. This is particularly important when the "driver" 
issuing
>the callback is a library API, such as Motif; you do not want the library to 
have
>to know about application data types and you do not want to constrain the 
application
>to use a single callback object type that is defined by the library. The 
point of the
>proposal is that there is a simple extension to the language which would 
accomplish
>this in a type-safe way.

I agree, the orginator of an event should not know about the destination of 
the message.  Also, it should not care how many destinations it has.  In this 
way, you are involving loose couling and the "observer" pattern combined.  
There is a simple way to ensure type safe, loosely coupled callbacks.  

Using a stand alone object to represent the event, that contains a polymorphic 
list of callback "nodes", you can acheive the desired result.  Each node of 
the list could be a templated sub-class that only takes qualified types and 
redefines a virtual to make the call to the specified type.  Once the event 
object has been "invoked", it will cycle through the list and call the virtual 
function to invoke each message.  The message could be a pointer to a C 
function, a static member function, or a public member function for a specific 
instance of a class. 

Doing it this way will ensure you type safety, and flexibility for attaching 
to objects that are from an otherwise unknown class hierarchy.


>The real problem is that it's difficult to write an object-oriented API for a
>system like X because C++ as currently defined doesn't provide 
type-independent
>object callbacks. The proposed language extension would greatly facilitate 
the
>creation of object-oriented, event-driven API's.

No necessarily the case.  Developing a stand-alone object would allow you to 
"attach" an event to any object.  This would allow for an int to emit a 
value-change event or a system file to emit a file-change event or whatever.

If anyone would like further information and/or and example, please eMail me 
and I'd be glad to give you a demonstration.

My thought is that the STL should contain such an object so as to allow 
developers a standardized way of approaching system coordination problems.  I 
also beleive that the base types should have this capability, so I can hook 
into an int's value-change callback.  I have redefined a set of classes to do 
this on my own, but it would be nice it the committees put it in the 
standards.

Rob

-----------------------------------------------------------------------
Robert McInnis
9th Bit Software
(eMail)  rmcinnis@gate.net
(pager)  813/216-8329

- These ramblings have come from a loosely coupled mind
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]