Prev: "Problems"
Next: How well can TextOut() handle Unicode?
From: Joseph M. Newcomer on 13 Feb 2010 11:56
On Sat, 13 Feb 2010 00:47:21 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>Joseph M. Newcomer wrote:
>
>> ****
>>> I have found out that it is related with the event I am using for telling
>>> thread A to execute the optional callback. If I simply put the SetEvent()
>>> in comment, the problem never occurs.
>> ****
>> Callbacks are dangerous as a way of life, especially in C++. Try to avoid ever using
>> them. The are an old C hack, rarely, if ever, valid in C++.
>
>-1.
****
However, if you examine the use of most callbacks, they are just C hacks transformed to
C++, usually badly. For example, how many callbacks really carry a "user-defined" value
with them? Even Microsoft totally screwed this up, and in 20+ years, has not fixed it
with some of the enum callbacks, making them impossible to use in C++. I did not say
"avoid them", I said "try to avoid ever using them". That's because there are often much
better approaches to the problem than a callback. It was reflexive for C programmers to
toss a callback into the mix whenever they felt like it; it is less neccessary in C++, and
is often best handled by passing in an object of an abstract superclass with a pure
virtual method defined by the DLL interface, except what is passed in is actually an
instance of the derived class whose virtual method is specified. While this
sort-of-looks-like a callback, it is philosophically quite different from the C hack, and
is a cleaner solution in the C++ world.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Giovanni Dicanio on 13 Feb 2010 13:13
I agree with Joe: I mean, if I had to provide an API with a pure C interface
(like Win32 does), then I think using callbacks (with the additional "void *
context" parameter) is a must have .
But if I had to build something in C++ without a need to be compatible with
C, I think that using interface classes is better design, IMHO.

Giovanni



"Joseph M. Newcomer" <newcomer(a)flounder.com> ha scritto nel messaggio
news:65mdn51ti6sm1k2vf93fnhijt27mcbqi9e(a)4ax.com...
> On Sat, 13 Feb 2010 00:47:21 -0500, Hector Santos
> <sant9442(a)nospam.gmail.com> wrote:
>
>>Joseph M. Newcomer wrote:
>>
>>> ****
>>>> I have found out that it is related with the event I am using for
>>>> telling
>>>> thread A to execute the optional callback. If I simply put the
>>>> SetEvent()
>>>> in comment, the problem never occurs.
>>> ****
>>> Callbacks are dangerous as a way of life, especially in C++. Try to
>>> avoid ever using
>>> them. The are an old C hack, rarely, if ever, valid in C++.
>>
>>-1.
> ****
> However, if you examine the use of most callbacks, they are just C hacks
> transformed to
> C++, usually badly. For example, how many callbacks really carry a
> "user-defined" value
> with them? Even Microsoft totally screwed this up, and in 20+ years, has
> not fixed it
> with some of the enum callbacks, making them impossible to use in C++. I
> did not say
> "avoid them", I said "try to avoid ever using them". That's because there
> are often much
> better approaches to the problem than a callback. It was reflexive for C
> programmers to
> toss a callback into the mix whenever they felt like it; it is less
> neccessary in C++, and
> is often best handled by passing in an object of an abstract superclass
> with a pure
> virtual method defined by the DLL interface, except what is passed in is
> actually an
> instance of the derived class whose virtual method is specified. While
> this
> sort-of-looks-like a callback, it is philosophically quite different from
> the C hack, and
> is a cleaner solution in the C++ world.
> joe
> ****
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Hector Santos on 13 Feb 2010 13:23
Joseph M. Newcomer wrote:

> On Sat, 13 Feb 2010 00:47:21 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>
>> Joseph M. Newcomer wrote:
>>
>>> ****
>>>> I have found out that it is related with the event I am using for telling
>>>> thread A to execute the optional callback. If I simply put the SetEvent()
>>>> in comment, the problem never occurs.
>>> ****
>>> Callbacks are dangerous as a way of life, especially in C++. Try to avoid ever using
>>> them. The are an old C hack, rarely, if ever, valid in C++.
>> -1.
> ****
> However, if you examine the use of most callbacks, they are just C hacks transformed to
> C++, usually badly. For example, how many callbacks really carry a "user-defined" value
> with them? Even Microsoft totally screwed this up, and in 20+ years, has not fixed it
> with some of the enum callbacks, making them impossible to use in C++. I did not say
> "avoid them", I said "try to avoid ever using them". That's because there are often much
> better approaches to the problem than a callback. It was reflexive for C programmers to
> toss a callback into the mix whenever they felt like it; it is less neccessary in C++, and
> is often best handled by passing in an object of an abstract superclass with a pure
> virtual method defined by the DLL interface, except what is passed in is actually an
> instance of the derived class whose virtual method is specified. While this
> sort-of-looks-like a callback, it is philosophically quite different from the C hack, and
> is a cleaner solution in the C++ world.
> joe

-1 :)

In general, IPC DESIGN is independent of language, although some
language lend themselves to IPC designs.

If you look at most communications applications, its all callbacks at
the lowest levels. I don't care if you wrap it with a class, events,
messages, yada, yada, yada, it generally begins with callbacks. You
might not have to do it yourself at the layman application level, but
there is a CALLBACK in there somewhere prepared for you. We do this
for our developers, we have a low level call back RPC Client/server
framework. The RPC clients prepare the callback and they receive RPC
server event signals. We also prepared Message and Event based layers
for those who want to use this. For these developers, it looks like
its not a callback, but a "OnXXXXX" event. We even use interfaces and
properties, so that we you drop the control on your form, you have
your property window showing all the OnXXXXX events so that the GUI
automatically create the stub code when you click it, so on and so on.
But even with all this, its all callbacks, and most IPC begin with
callbacks in the same manner, including sockets, MFC as well!

I beg you not to begin arguing this. Not necessary. I only will
agree that for the layman programmers, today, they are most use to
seeing OnXXXXX and messaging style development. Using callbacks are
generally at the system level or layer below messaging.

--
HLS
From: Hector Santos on 13 Feb 2010 13:25
Thats different Giovanni, and if stated that way, from an application
standpoint, I agree it is easily to use interfaces, but its still
callbacks at some level. It was just done for you.

But to get into the theory of callbacks and whether its bad or good,
well, thats a waste of time to be discussing.

So -1 from that standpoint. :)

--

Giovanni Dicanio wrote:

> I agree with Joe: I mean, if I had to provide an API with a pure C
> interface (like Win32 does), then I think using callbacks (with the
> additional "void * context" parameter) is a must have .
> But if I had to build something in C++ without a need to be compatible
> with C, I think that using interface classes is better design, IMHO.
>
> Giovanni
>
>
>
> "Joseph M. Newcomer" <newcomer(a)flounder.com> ha scritto nel messaggio
> news:65mdn51ti6sm1k2vf93fnhijt27mcbqi9e(a)4ax.com...
>> On Sat, 13 Feb 2010 00:47:21 -0500, Hector Santos
>> <sant9442(a)nospam.gmail.com> wrote:
>>
>>> Joseph M. Newcomer wrote:
>>>
>>>> ****
>>>>> I have found out that it is related with the event I am using for
>>>>> telling
>>>>> thread A to execute the optional callback. If I simply put the
>>>>> SetEvent()
>>>>> in comment, the problem never occurs.
>>>> ****
>>>> Callbacks are dangerous as a way of life, especially in C++. Try to
>>>> avoid ever using
>>>> them. The are an old C hack, rarely, if ever, valid in C++.
>>>
>>> -1.
>> ****
>> However, if you examine the use of most callbacks, they are just C
>> hacks transformed to
>> C++, usually badly. For example, how many callbacks really carry a
>> "user-defined" value
>> with them? Even Microsoft totally screwed this up, and in 20+ years,
>> has not fixed it
>> with some of the enum callbacks, making them impossible to use in
>> C++. I did not say
>> "avoid them", I said "try to avoid ever using them". That's because
>> there are often much
>> better approaches to the problem than a callback. It was reflexive
>> for C programmers to
>> toss a callback into the mix whenever they felt like it; it is less
>> neccessary in C++, and
>> is often best handled by passing in an object of an abstract
>> superclass with a pure
>> virtual method defined by the DLL interface, except what is passed in
>> is actually an
>> instance of the derived class whose virtual method is specified.
>> While this
>> sort-of-looks-like a callback, it is philosophically quite different
>> from the C hack, and
>> is a cleaner solution in the C++ world.
>> joe
>> ****
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>



--
HLS
From: Joseph M. Newcomer on 13 Feb 2010 17:40
See below...
On Sat, 13 Feb 2010 13:23:07 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>Joseph M. Newcomer wrote:
>
>> On Sat, 13 Feb 2010 00:47:21 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>>
>>> Joseph M. Newcomer wrote:
>>>
>>>> ****
>>>>> I have found out that it is related with the event I am using for telling
>>>>> thread A to execute the optional callback. If I simply put the SetEvent()
>>>>> in comment, the problem never occurs.
>>>> ****
>>>> Callbacks are dangerous as a way of life, especially in C++. Try to avoid ever using
>>>> them. The are an old C hack, rarely, if ever, valid in C++.
>>> -1.
>> ****
>> However, if you examine the use of most callbacks, they are just C hacks transformed to
>> C++, usually badly. For example, how many callbacks really carry a "user-defined" value
>> with them? Even Microsoft totally screwed this up, and in 20+ years, has not fixed it
>> with some of the enum callbacks, making them impossible to use in C++. I did not say
>> "avoid them", I said "try to avoid ever using them". That's because there are often much
>> better approaches to the problem than a callback. It was reflexive for C programmers to
>> toss a callback into the mix whenever they felt like it; it is less neccessary in C++, and
>> is often best handled by passing in an object of an abstract superclass with a pure
>> virtual method defined by the DLL interface, except what is passed in is actually an
>> instance of the derived class whose virtual method is specified. While this
>> sort-of-looks-like a callback, it is philosophically quite different from the C hack, and
>> is a cleaner solution in the C++ world.
>> joe
>
>-1 :)
>
>In general, IPC DESIGN is independent of language, although some
>language lend themselves to IPC designs.
****
IPC == Inter-Process Communication. I see no IPC here; I see subroutine calls, within a
single thread, to a library component. So don't divert the discussion by bringing in an
unrelated topic.
****
>
>If you look at most communications applications, its all callbacks at
>the lowest levels. I don't care if you wrap it with a class, events,
>messages, yada, yada, yada, it generally begins with callbacks. You
>might not have to do it yourself at the layman application level, but
>there is a CALLBACK in there somewhere prepared for you.
****
But with the right layering, it can be clean and elegant, instead of the hack of passing
in a function pointer in the C sense.

Did you know that languages like Ada forbade passing function pointers, and instead
provided cleaner mechanisms for achieving the same goal?

Just because something is possible, or because there is a low-level implementation detail
that makes something work, does not mean that doing it is good, or exposing that low-level
detail as a first-class concept in the language is good design.
****
>We do this
>for our developers, we have a low level call back RPC Client/server
>framework. The RPC clients prepare the callback and they receive RPC
>server event signals. We also prepared Message and Event based layers
>for those who want to use this. For these developers, it looks like
>its not a callback, but a "OnXXXXX" event. We even use interfaces and
>properties, so that we you drop the control on your form, you have
>your property window showing all the OnXXXXX events so that the GUI
>automatically create the stub code when you click it, so on and so on.
>But even with all this, its all callbacks, and most IPC begin with
>callbacks in the same manner, including sockets, MFC as well!
****
Note that MFC does it by calling virtual methods of a superclass (CAsyncSocket), so there
is no visible "callback" mechanism involved. MFC message maps are another interesting
layer on what is the callback concept, somewhat less clean than virtual methods, but not
as ugly as passing function pointers to subroutines.

Note that the class "callback" isn't very clean in a lot of ways; for example, some
subroutine libraries store the callback address in a static variable inside the code, so
if you need to have multiple callbacks, possibly in multiple threads, you get into deep
trouble. The abstraction of the virtual method on an object instance allows the
capability of the callback without the unfortunate static binding that too often happens.

Callbacks can be packaged up into elegant abstractions, but to just pass a function
pointer in represents an assembly-code approach to the problem, when you want a high-level
abstraction (remember, C is the language which gives you the power of writing in assembly
code with all the expressive elegance of writing in assembly code).

Again, you are dragging IPC into a discussion where IPC was not involved. You can do
callbacks such as event sinks without exposing the ugliness of the raw callback mechanism.
****
>
>I beg you not to begin arguing this. Not necessary. I only will
>agree that for the layman programmers, today, they are most use to
>seeing OnXXXXX and messaging style development. Using callbacks are
>generally at the system level or layer below messaging.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: "Problems"
Next: How well can TextOut() handle Unicode?