Event handler in c++

[pratik lala]

Hey,
I am trying to create a game which requires the use of keyboard.The
game is about falling items and I have to collect the item using the
paddle .So I know that we can make the terminal to operate in raw mode
and make the paddle move using the keyboard input.But i am not sure if
it will work as efficiently as an event handler works in other
languages.
Is there any way that we can make it look like a REAL time event?

 

[Alf P. Steinbach]

I am trying to create a game which requires the use of keyboard.The
game is about falling items and I have to collect the item using the
paddle .So I know that we can make the terminal to operate in raw mode
and make the paddle move using the keyboard input.But i am not sure if
it will work as efficiently as an event handler works in other
languages.

Other languages are generally implemented in either C or C++, or in some
language that ultimately is implemented in C or C++.

That means (logically) that whatever the other language does, you can do
it just as efficiently in C++.

And in general the problem is the opposite: can some other and otherwise
desirable language, do something as efficiently as C++?

It is rare indeed that some high level language beats C++ on efficiency.
When you understand what's going on, what overhead the typical language
implementation adds, then you know that any test putting C++ low on
efficiency must be flawed. Like an observation that claims the moon is
much larger than the sun is necessarily flawed.

The "language efficiency" thing for C++ is more a question of
/productivity/. If it involves much more work to do the thing
efficiently in C++ than to do it efficiently in e.g. C#, then likely
efficiency will suffer for C++. So your concern is not entirely
misplaced on general grounds, but it's based on an incorrect perception
of the issues.

However, be assured that regarding the concrete example, namely keyboard
input, there is no problem.

Keyboard input is so slow a thing, by several orders of magnitude
compared to the execution speed of current computers, that thinking
about efficiency here is meaningless.

Is there any way that we can make it look like a REAL time event?

Yes. First define in more detail what you mean by "REAL time event".
Then make it look like that, or ask here about how to make it look like
that.


Cheers & hth.,

- Alf

 

[osmium]

"Alf P. Steinbach"

Other languages are generally implemented in either C or C++, or in some
language that ultimately is implemented in C or C++.

That means (logically) that whatever the other language does, you can do
it just as efficiently in C++.

And in general the problem is the opposite: can some other and otherwise
desirable language, do something as efficiently as C++?

It is rare indeed that some high level language beats C++ on efficiency.
When you understand what's going on, what overhead the typical language
implementation adds, then you know that any test putting C++ low on
efficiency must be flawed. Like an observation that claims the moon is
much larger than the sun is necessarily flawed.

The "language efficiency" thing for C++ is more a question of
/productivity/. If it involves much more work to do the thing efficiently
in C++ than to do it efficiently in e.g. C#, then likely efficiency will
suffer for C++. So your concern is not entirely misplaced on general
grounds, but it's based on an incorrect perception of the issues.

IMO, the lack of co-routines is a serious impediment for some problems -
such as event simulation - in C++. For example, I don't see any way to
implement an event handler in as neatly and intuitively satisfying a way as
in the first incarnation of Simula.

Does anyone know, does Simula 67 have co-routines? I took a course in it but
the it was very superficial. and directed at the goal of using Simula 67 as
a general purpose language.

 

[pratik lala]

Other languages are generally implemented in either C or C++, or in some
language that ultimately is implemented in C or C++.

That means (logically) that whatever the other language does, you can do
it just as efficiently in C++.

And in general the problem is the opposite: can some other and otherwise
desirable language, do something as efficiently as C++?

It is rare indeed that some high level language beats C++ on efficiency.
When you understand what's going on, what overhead the typical language
implementation adds, then you know that any test putting C++ low on
efficiency must be flawed. Like an observation that claims the moon is
much larger than the sun is necessarily flawed.

The "language efficiency" thing for C++ is more a question of
/productivity/. If it involves much more work to do the thing
efficiently in C++ than to do it efficiently in e.g. C#, then likely
efficiency will suffer for C++. So your concern is not entirely
misplaced on general grounds, but it's based on an incorrect perception
of the issues.

However, be assured that regarding the concrete example, namely keyboard
input, there is no problem.

Keyboard input is so slow a thing, by several orders of magnitude
compared to the execution speed of current computers, that thinking
about efficiency here is meaningless.


Yes. First define in more detail what you mean by "REAL time event".
Then make it look like that, or ask here about how to make it look like
that.

Cheers & hth.,

- Alf

Well, the events are such that,i have to display the falling items
continously and also make the keyboard move.So, To display the matrix
continously, my displaymatrix will have to wait until the user gives
an input. I want to make it such that the items are falling
continously irrespective of the situation that the user is entering or
not entering the input

 

[Alf P. Steinbach]

[snip]
Is there any way that we can make it look like a REAL time event?

Yes. First define in more detail what you mean by "REAL time event".
Then make it look like that, or ask here about how to make it look like
that.

Well, the events are such that,i have to display the falling items
continously and also make the keyboard move.So, To display the matrix
continously, my displaymatrix will have to wait until the user gives
an input. I want to make it such that the items are falling
continously irrespective of the situation that the user is entering or
not entering the input

OK, what you're asking for is simply non-blocking i/o.

In *nix that's part of raw mode. I don't remember the details (I think
last time I used that was in 1986). However, if I recall correctly that
functionality is part of the ncurses library -- check it out.

Anyway, on each timer tick, simply check whether there is any new
keyboard input. You can structure that to look as apparent events, or
whatever. But the crucial functionality at bottom, is non-blocking i/o.

Cheers & hth.,

- Alf

 

[Christopher]

IMO, the lack of co-routines is a serious impediment for some problems -
such as event simulation -  in C++.  For example, I don't see any wayto
implement an event handler in as neatly and intuitively satisfying a way as
in the first incarnation of Simula.

I use boost::asio::io_service and/or boost::bind for events on
occasion. You post some work to be done to the io_service (which runs
on a thread or threads) and it calls back your handler when it
completes. The "work" could be waiting for something to happen, such
as a network recv.

You can also use boost::condition_variable to wait for some state.

You'd need more details about said event and what triggers it.

 

[Robin Tucker]

I'm using a templated method to describe, dispatch and handle events
in an intuitive manner. For example, describing an event can be done
with something like this:

Event<void(std::shared_ptr<Observable>, double, double, double)>
MyEvent;

, for an event that takes 4 parameters (the "sender" and three
doubles). The handler looks like this:

void OnEventHandler(std::shared_ptr<Observable> sender, double x,
double y, double z)
{
// Handle the event.
}

And the event is dispatched in the following intuitive way:

MyEvent(shared_from_this(), 3, 2, 1);

It's type-safe and you can dispatch any number of parameters (up to 9
actually, in the absence of variadic templates in VS2010!). Anyway the
code and blog about it can be found here:

http://drrobsjournal.blogspot.com/

I hope this is useful to someone.

 

[88888 Dihedral]

在 2012å¹´2月13日星期一UTC+8下åˆ7æ—¶52分44秒，Robin Tucker写é“：

I'm using a templated method to describe, dispatch and handle events
in an intuitive manner. For example, describing an event can be done
with something like this:

Event<void(std::shared_ptr<Observable>, double, double, double)>
MyEvent;

, for an event that takes 4 parameters (the "sender" and three
doubles). The handler looks like this:

void OnEventHandler(std::shared_ptr<Observable> sender, double x,
double y, double z)
{
// Handle the event.
}

And the event is dispatched in the following intuitive way:

MyEvent(shared_from_this(), 3, 2, 1);

It's type-safe and you can dispatch any number of parameters (up to 9
actually, in the absence of variadic templates in VS2010!). Anyway the
code and blog about it can be found here:

http://drrobsjournal.blogspot.com/

I hope this is useful to someone.

C++ is not very good to be usd as a language to
write device drives to be called by the OS.

People working on the linux kernal talked about this
problem for so long.

Unless functions in the C++ container and template libraries are incorporated into the OS kernal library
or system shared linked libraries, otherwise C++ compiled programs are too fat in the heap, too.

A device in the OS is an object that responds to messages from the OS or AP..

 

[Ian Collins]

在 2012å¹´2月13日星期一UTC+8下åˆ7æ—¶52分44秒，Robin Tucker写é“：

C++ is not very good to be usd as a language to
write device drives to be called by the OS.

Yes it is, you just have to provide the OS hooks as extern "C" functions.

People working on the linux kernal talked about this
problem for so long.

They are somewhat bigoted.

Unless functions in the C++ container and template libraries are incorporated into the OS kernal library
or system shared linked libraries, otherwise C++ compiled programs are too fat in the heap, too.

"too fat in the heap" ?

In kernel space you have two choices:

1) Use C++ as a better C and avoid the parts that require runtime support.

2) Use a statically linked run time library.

I use one where resources are tight and 2 where they are not.

 

[88888 Dihedral]

在 2012å¹´2月15日星期三UTC+8上åˆ2æ—¶17分43秒，Ian Collins写é“：

Yes it is, you just have to provide the OS hooks as extern "C" functions.


They are somewhat bigoted.


"too fat in the heap" ?

In kernel space you have two choices:

1) Use C++ as a better C and avoid the parts that require runtime support..

2) Use a statically linked run time library.

I use one where resources are tight and 2 where they are not.

在 2012å¹´2月15日星期三UTC+8上åˆ2æ—¶17分43秒，Ian Collins写é“：

Yes it is, you just have to provide the OS hooks as extern "C" functions.


They are somewhat bigoted.

In the kernal space, the hardware supports and assembler
supports are required.

"too fat in the heap" ?

For example, the hash or map library in C++
are unreasably large and some are just faking
to be a hash table not of O(1) when there is no hash collision at all.

A hash can be frozen at the compile time
is not well-distinguished from a map that can
be modified in the run time very often.

This took so long for C++ to implement
a true hash table.

 

[Ian Collins]

在 2012å¹´2月15日星期三UTC+8上åˆ2æ—¶17分43秒，Ian Collins写é“：

In the kernal space, the hardware supports and assembler
supports are required.

Not on any of the platforms I've written drivers for.

For example, the hash or map library in C++
are unreasably large and some are just faking
to be a hash table not of O(1) when there is no hash collision at all.

Well obviously a container such as a map will be heavy on the heap. If
you can't afford the overhead, don't use them. If you want the
convenience, do.

Have you ever written device drivers? If so, for which platform(s)?

 

[MiB]

在 2012å¹´2月15日星期三UTC+8上åˆ2æ—¶17分43秒，Ian Collins写é“： [..]

They are somewhat bigoted.

Actually, one of the dominant goals of GNU/Linux is availability on a
wide range of platforms. To bootstrap the development tool chain, some
core functionality needs to be implemented, i.e. library code, cross
compiling code generators for the target architecture, hardware
drivers, code to load and start the Linux core. A major milestone in
porting an OS to any platform is to get it to compile its own kernel,
the rest is more transpiration than inspiration.

Unfortunately only major platforms offer C++ compilers, and if they
do, there is wide range of language implementation issues that make
writing common source code APITA. Not so long ago, just to pick one
example, the popular Visual C++ Compiler 6 had a very unique
interpretation on the scope of variables declared in the loop control
header of for loops. You CAN write code in a way so it runs unchanged
on other platforms, i.e. by wrapping each and every for loop in an
extra pair of curly braces, but it looks ugly and is easy to forget.
Most of the time, you end up in an orgy of #ifdef's. The latter is
true for the C implementation of Linux, too.

C, however, is more readily available on smaller platforms (embedded
systems, mobile phones, ...) and has less portability problems just
because the language core is so much smaller. I believe this was the
main argument of the C vs. C++ factions in Linux development, not
issues regarding memory consumption (there is, in fact, no such issue)
and not performance worries. I am not aware of any problem solvable in
C, that needs more run time when implemented properly (!) in C++.

If you write an OS for one platform only, or for a very limited set of
related platforms, I see no real issue why C++ should not be used for
writing the majority of OS code.

For example, the hash or map library in C++
are unreasably large and some are just faking
to be a hash table not of O(1) when there is  no hash collision at all.

Even with hash collisions, the amortized run time of hash tables is
O(1). A std::map is usually implemented as some sorted tree structure
with search and insertion costs O( log n ) time, because of the
requirement to get a sorted order traversal in O(n) time. This is not
possible with hash maps.

A hash can be frozen at the compile time
is not well-distinguished from a map that can
be modified in the run time very often.

This took so long for C++ to implement
a true hash table.

Hash maps took so long to get into the standard because the design of
the hash function interface deserves a lot of deliberation - its
already tough to find a hash function for a data type like "subset of
int". You need to know the domain and relative frequency of keys well
to make a good choice. Data types with no or vague identifying key
data are even more difficult. Often the binary representation of a
part of the data structures is used as hash function input in real
world implementations, but for a universal library? - eeks.

The second issue was the uncomfortable decision to use closed
addressing (linear searched chains in hash buckets) for collision
handling. For many years already I use my own hash map implementation
with open addressing (double hashing on *very* carefully chosen hash
table address spaces). It does insertion and look up between two and
three times (!) faster on average than any closed addressing
implementation I've seen. It does not handle arbitrary deletions,
though, only deletion in exact reverse order of insertion is
supported. Not suited for a standard library that emphasizes on
orthogonality - all algorithms should run on all containers.

MiB.

 

[Ian Collins]

在 2012å¹´2月15日星期三UTC+8上åˆ2æ—¶17分43秒，Ian Collins写é“： [..]

On 02/14/12 11:14 PM, 88888 Dihedral wrote:
People working on the linux kernal talked about this
problem for so long.

They are somewhat bigoted.

Actually, one of the dominant goals of GNU/Linux is availability on a
wide range of platforms. To bootstrap the development tool chain, some
core functionality needs to be implemented, i.e. library code, cross
compiling code generators for the target architecture, hardware
drivers, code to load and start the Linux core. A major milestone in
porting an OS to any platform is to get it to compile its own kernel,
the rest is more transpiration than inspiration.

Don't forget the GNU/Linux and gcc are joined at the hip. Anywhere gcc
can go, GNU/Linux in some form can follow.

Unfortunately only major platforms offer C++ compilers, and if they
do, there is wide range of language implementation issues that make
writing common source code APITA.

But the GNU/Linux kernel only builds with gcc, or with a compiler
specifically tailored to build it such as the Intel compiler. So in
this specific context, the ABI incompatibility argument doesn't really
hold water.

C, however, is more readily available on smaller platforms (embedded
systems, mobile phones, ...) and has less portability problems just
because the language core is so much smaller. I believe this was the
main argument of the C vs. C++ factions in Linux development, not
issues regarding memory consumption (there is, in fact, no such issue)
and not performance worries. I am not aware of any problem solvable in
C, that needs more run time when implemented properly (!) in C++.

From what I've heard and read over the years, the objections to C++
from GNU/Linux kernel developers are more philosophical dressed up as
practical than practical.

 

[Rui Maciel]

I'm using a templated method to describe, dispatch and handle events
in an intuitive manner.

<snip/>

It sounds a lot like libsigc++.

http://libsigc.sourceforge.net/


Rui Maciel

 

[MiB]

On Wed, 15 Feb 2012 02:11:25 -0800 (PST), MiB


In MS's defense, MSCV6 (*14* years old at this point, and predating
the final C++ 98 standard), got bitten by a late change in the draft
C++ standard.  They weren't the only ones (at least one of HP's
compilers was as well).  Per MS language policy, which is to avoid
making breaking changes within a version, this was never "fixed" in
MSVC6, but was in MSVC7.

My comment was in no way intended to belittle MS's efforts. I use
VS2010 on an every day basis and I am quite happy with it, and back in
the olden days I liked VS5, too. For a developer interested in source
code compatibility, however, at the end of the day it does not matter
why his programs will not compile and who is to blame for it, only
that they don't.

MiB