C++ Event Coding Questions

[AzizMandar]

C++ Event Coding Questions

I have done some simple programs in C++ and read a lot of good C++
books (Including The C++ Programing Language, and C++ Primer) I am
trying to understand and implement an Event based program and Message
system. I have a very basic event engine that I'm feeling works a bit
backwards. I'm looking for documents, source code, and books that may
help me better understand how to implement this type of code. I am not
a student and this is not homework, just a hobby at the moment.

I have a few requirements that are making my search difficult.

1. I'm trying to develop some cross platform programming skills so I
want the code to be as generic as possible. (No MFC)

2. I'm happy to use the STL but no other external libraries

3. I am coding this on a Linux Box but that should not matter because
of point 1

4. Simpler is better. I understand and am able to read most code and
have many samples but they are very poorly documented and are so
ingrained with some external framework (like MFC) that I am having a
bear of a time trying to make heads or tails of it.

5. I have a very archaic but working garbage collector and memory
management system. After I get this all figured out I'll be happy to
let you all rip it to shreds and tell me how evil and silly I am. (It's
creative but not necessarily in a good way)

6. I'm not using threads. I hear that they are not dependable for
execution speed and time and can be problematic and in many cases are
unnecessary.

I keep reading about Event handlers and Dispatchers and I don't think
that is what I am doing

My code is a bit long and not commented well so I will spare you all
reading it at this point.

In general I have an Event Controller that all events are sent to.
When it receives an event it determines if it runs now or is on hold.
If it runs now it gets added to the end of the NOW link list. If it
runs later it gets sorted into the HOLD list. Once a cycle the
Controller checks the front of the HOLD lists for things that should
run now (and pulls off the events and pushes them onto the front of the
NOW list) Then it executes every event in the NOW list. Events are
deleted after they return from execution by the Controller.

The Events work by calling a function pointer that points to a static
function of the object or factory that created it. These then do
something and usually generate a new event. The Function Pointers
ActionFunction(Object* Me,int Action) for what the object (Me) is doing
(Action) and InteractFunction(Object* Me,Object* You, int Action) for
Object (Me) doing (Action) to Object(You)

I have some great casting in these functions that just shout out EVIL
and I'm certain I can get rid of them by changing the way either the
function Pointers work or the way the Events work.

Also I think this will need a better State Machine because using an
enumerated Type cast on an int is EVIL and using a raw int and trying
to keep track of what it means is EVIL and making the base objects and
events use a pre-defined enumerated Type is inflexible and therefor
EVIL.

Please help me get rid of the EVIL.

Thanks

 

[F.J.K.]

I have a few requirements that are making my search difficult.

1. I'm trying to develop some cross platform programming skills so I
want the code to be as generic as possible. (No MFC)

2. I'm happy to use the STL but no other external libraries

You are usinllg the word "difficult" in a rather euphemistic way.
Events are neither part of the C++ language, nor of the STL. This means
you'll either grab your events directly from your OS, which is not
portable. Or you are using a portable external framework, which is not
standard sustained any more. There is no such thing as "pure language
cross plattform event programming Skillz" in C++.

Let's face it, the requirements you are describing show one thing very
clearly. You are concerned about productivity, ease of use and
portability, as opposed to MIPS or FLOPS. C++ should not be your weapon
of choice. Consider using a language that actually focusses on things
like portable GUI's, like Tcl/TK, Python/TK, Ruby or even evil Java.
Part of being a good C++ programmer is knowing when NOT to use C++ ;-)

Have fun, FJK

 

[Nick Keighley]

AzizMandar wrote:

**** original post reinserted *********
STL is not an external library. Its a standardised part of a conforming

C++ implementation.

You are usinllg the word "difficult" in a rather euphemistic way.
Events are neither part of the C++ language, nor of the STL. This means
you'll either grab your events directly from your OS, which is not
portable. Or you are using a portable external framework, which is not
standard sustained any more.

or roll your own. An event can simply be a class.

There is no such thing as "pure language
cross plattform event programming Skillz" in C++.

Let's face it, the requirements you are describing show one thing very
clearly. You are concerned about productivity, ease of use and
portability, as opposed to MIPS or FLOPS. C++ should not be your weapon
of choice. Consider using a language that actually focusses on things
like portable GUI's, like Tcl/TK, Python/TK, Ruby or even evil Java.
Part of being a good C++ programmer is knowing when NOT to use C++ ;-)

um. I never saw the word "GUI" in his post. He said he was interested
in
an event or message driven system. That doesn't mean it's a GUI.
eg. telecomms


--
Nick Keighley

As I recall, OSI dealt with TCP/IP by just admitting it into the spec
as a variation of existing levels. This is akin to dealing with an
Alien face hugger by allowing it to implant its embryo in your body.

 

[F.J.K.]

**** original post reinserted *********

STL is not an external library. Its a standardised part of a conforming

C++ implementation.



or roll your own. An event can simply be a class.

Sure. But where's the point? You can define pretty much anything as a
class. But events as general data structures are of rather limited use,
unless you want to respond to external triggers. In this case, you'll
need to interface the external "trigger-giving" software-layer. This
interface is not defined by the C++ language, you'll have to either use
abstraction libraries or use nonstandard constructs. Which is what the
OP wanted to avoid.

IMHO events/messages only make sense in the context of asynchronous
communication. Which again, is not part of the standard (yet, see
boost::asio)."Pure" C++ programs to my knowledge can only communicate
synchronously.

um. I never saw the word "GUI" in his post. He said he was interested
in
an event or message driven system. That doesn't mean it's a GUI.
eg. telecomms

Right. But if you read carefully, I used the words "like portable
GUI's" to give a nonexclusive example of an important, if not the most
important, area of application for event based programming. Your
example "telecomms" is another important area. That doesn't make GUIs
any less valid though ;-)

There's a reason, a std::event does not exist. The current standard
language does not allow you to portably do anything useful with events.
Period. You do have input and output streams, that's it. These can be
handled without events and easier. You need to use external libraries
and/or system specific headers for events to become useful in C++.

If you want the "batteries included" you need to use a different
language. Perl, Python, Java, Tcl/TK all of them are good choices in
that sense. C/C++ needs its external libraries.

Greets, FJK

 

[AzizMandar]

class. But events as general data structures are of rather limited use,
unless you want to respond to external triggers. In this case, you'll
need to interface the external "trigger-giving" software-layer. This
interface is not defined by the C++ language, you'll have to either use
abstraction libraries or use nonstandard constructs. Which is what the
OP wanted to avoid.

IMHO events/messages only make sense in the context of asynchronous
communication. Which again, is not part of the standard (yet, see
boost::asio)."Pure" C++ programs to my knowledge can only communicate
synchronously.






GUI's" to give a nonexclusive example of an important, if not the most
important, area of application for event based programming. Your
example "telecomms" is another important area. That doesn't make GUIs
any less valid though ;-)

There's a reason, a std::event does not exist. The current standard
language does not allow you to portably do anything useful with events.
Period. You do have input and output streams, that's it. These can be
handled without events and easier. You need to use external libraries
and/or system specific headers for events to become useful in C++.

If you want the "batteries included" you need to use a different
language. Perl, Python, Java, Tcl/TK all of them are good choices in
that sense. C/C++ needs its external libraries.

Greets, FJK

If you have a copy of The C++ Programming Language 3rd Edition please
check out Chapter 12 Problem 11 (I think the only dificulty 5 excersise
in the book)

This is what I am looking for more information on. I got the Task.h
from Stroustrup and most of the concept is abstract classes and
containers. I've made some simple working event programs but I know
there is more out there. Event Driven programming is more than
multithreaded MFC and GUI code. I'm not looking for tools or code that
will use events I want to write an event driven engine. The concept of
Event driven code is that the event can interupt the code at any time
and many languages and tools let you program in a seemingly
asynchronous way. However at some level it's all synchronous. I want
to write a Synchronous Event Engine.

My goal is to write an Event/message engine that will be:
1. Easy to document and debug (Primary advantages of OO programing)
2. fast (C/C++ advantages)
3. Platform independant (C/C++ advantages)

Why? Fun and learning

What use would it be? OS design, real time monitoring or
communications , entertainment applications(games).

To get any of these to run at an acceptable speed I will most likely
have to use a lot of non-OO code (abstract classes have a tendency to
slow down the main loop because of the extra pointer calls) but that
again is a great advantage of C++ (You don't have to use OO code when
you don't need it) C++ is not C with OOP.

I have a decent amount of C examples but I know a lot of people use C++
to do this as well. But most of what I have seen is either proprietary
code (MFC) or C with OOP code (someone who added abstract classes to a
C concept but sacrifices type safety, uses 8 tons of Macros, and 2-3
pages of global variables).

one last thing

STL: Standard Template Library. Requires #include statements because
it is EXTERNAL to C++. Therefor an external library. Yes it is a
standardized part of C++ implementation and controlled by a standards
comities but it is not a part of C++ just a very good set of
standardized templates and tools that are cross platform and type safe
for 'GOOD' C++ programming standards. If you don't have STL installed
on your computer you can't use it. But most computers with a C++
compiler have it (either installed by the compiler or the OS)

and no it doesn't have an Event class or GUI elements but it does have
good containers and tools for making the basic elements of these. As I
stated previously I am using an external I/O class and wrapping it into
an external class so I can keep the main engine completely independent
of this. Therefor I don't need any I/O specific code. (One of the
weakest part of C++ is the I/O but wrapped out of the main code I am
free to use the strengths of C++ and use external solutions for the
I/O)