Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13541 > unrolled thread

Event handler in c++

Back to article view | Back to comp.lang.c++

Contents

  Event handler in c++ pratik lala <pratik3558@gmail.com> - 2012-01-22 06:42 -0800
    Re: Event handler in c++ "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-22 16:11 +0100
      Re: Event handler in c++ "osmium" <r124c4u102@comcast.net> - 2012-01-22 10:56 -0600
        Re: Event handler in c++ Robert Wessel <robertwessel2@yahoo.com> - 2012-01-22 21:32 -0600
        Re: Event handler in c++ Christopher <cpisz@austin.rr.com> - 2012-01-24 08:25 -0800
          Re: Event handler in c++ Robin Tucker <robinmjtucker@gmail.com> - 2012-02-13 03:52 -0800
            Re: Event handler in c++ 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-14 02:14 -0800
              Re: Event handler in c++ Ian Collins <ian-news@hotmail.com> - 2012-02-15 07:17 +1300
                Re: Event handler in c++ 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-14 11:51 -0800
                  Re: Event handler in c++ Ian Collins <ian-news@hotmail.com> - 2012-02-15 16:59 +1300
                  Re: Event handler in c++ MiB <michael.boehnisch@gmail.com> - 2012-02-15 02:11 -0800
                    Re: Event handler in c++ Ian Collins <ian-news@hotmail.com> - 2012-02-16 07:46 +1300
                    Re: Event handler in c++ Robert Wessel <robertwessel2@yahoo.com> - 2012-02-15 15:32 -0600
                      Re: Event handler in c++ MiB <michael.boehnisch@gmail.com> - 2012-02-16 17:56 -0800
            Re: Event handler in c++ Rui Maciel <rui.maciel@gmail.com> - 2012-02-15 23:11 +0000
      Re: Event handler in c++ pratik lala <pratik3558@gmail.com> - 2012-01-22 16:14 -0800
        Re: Event handler in c++ "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-23 03:54 +0100

#13541 — Event handler in c++

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?

[toc] | [next] | [standalone]

#13542

On 22.01.2012 15:42, pratik lala wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#13543

"Alf P. Steinbach"

> On 22.01.2012 15:42, pratik lala wrote:
>>
>> 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.

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. 

[toc] | [prev] | [next] | [standalone]

#13551

On Sun, 22 Jan 2012 10:56:47 -0600, "osmium" <r124c4u102@comcast.net>
wrote:

>"Alf P. Steinbach"
>
>> On 22.01.2012 15:42, pratik lala wrote:
>>>
>>> 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.
>
>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. 


Yes, Simula-67 has coroutines.

[toc] | [prev] | [next] | [standalone]

#13561

On Jan 22, 10:56 am, "osmium" <r124c4u...@comcast.net> wrote:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#13972

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.

[toc] | [prev] | [next] | [standalone]

#14032

在 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.

  

[toc] | [prev] | [next] | [standalone]

#14045

On 02/14/12 11:14 PM, 88888 Dihedral wrote:
> 在 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.

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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14049

在 2012年2月15日星期三UTC+8上午2时17分43秒，Ian Collins写道：
> On 02/14/12 11:14 PM, 88888 Dihedral wrote:
> > 在 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.
> 
> 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.
> 
> -- 
> Ian Collins



在 2012年2月15日星期三UTC+8上午2时17分43秒，Ian Collins写道：
> On 02/14/12 11:14 PM, 88888 Dihedral wrote:
> > 在 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.
> 
> 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.
> 

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

> > 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" ?
> 
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.

> 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.
> 
> -- 
> Ian Collins

[toc] | [prev] | [next] | [standalone]

#14062

On 02/15/12 08:51 AM, 88888 Dihedral wrote:
> 在 2012年2月15日星期三UTC+8上午2时17分43秒，Ian Collins写道：
>> On 02/14/12 11:14 PM, 88888 Dihedral wrote:
>>>
>>> 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.
>>
>
> In the kernal space, the hardware supports and assembler
> supports are required.

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

>>> 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" ?
>>
> 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)?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14070

On Feb 14, 8:51 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> 在 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.

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.

[toc] | [prev] | [next] | [standalone]

#14075

On 02/15/12 11:11 PM, MiB wrote:
> On Feb 14, 8:51 pm, 88888 Dihedral<dihedral88...@googlemail.com>
> wrote:
>> 在 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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14076

On Wed, 15 Feb 2012 02:11:25 -0800 (PST), MiB
<michael.boehnisch@gmail.com> wrote:

>On Feb 14, 8:51 pm, 88888 Dihedral <dihedral88...@googlemail.com>
>wrote:
>> ? 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.
>
>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.


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.

[toc] | [prev] | [next] | [standalone]

#14124

On Feb 15, 10:32 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Wed, 15 Feb 2012 02:11:25 -0800 (PST), MiB
> <michael.boehni...@gmail.com> wrote:
[..]
> >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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#14079

Robin Tucker wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#13549

On Jan 22, 9:11 am, "Alf P. Steinbach" <alf.p.steinbach
+use...@gmail.com> wrote:
> On 22.01.2012 15:42, pratik lala wrote:
>
>
>
> > 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

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

[toc] | [prev] | [next] | [standalone]

#13550

On 23.01.2012 01:14, pratik lala wrote:
> On Jan 22, 9:11 am, "Alf P. Steinbach"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> On 22.01.2012 15:42, pratik lala wrote:
>>
>>> [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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web