Event handler in c++

Discussion in 'C++' started by pratik lala, Jan 22, 2012.

  1. pratik lala

    pratik lala Guest

    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?
    pratik lala, Jan 22, 2012
    #1
    1. Advertising

  2. 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
    Alf P. Steinbach, Jan 22, 2012
    #2
    1. Advertising

  3. pratik lala

    osmium Guest

    "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.
    osmium, Jan 22, 2012
    #3
  4. pratik lala

    pratik lala Guest

    On Jan 22, 9:11 am, "Alf P. Steinbach" <alf.p.steinbach
    > 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
    pratik lala, Jan 23, 2012
    #4
  5. On 23.01.2012 01:14, pratik lala wrote:
    > On Jan 22, 9:11 am, "Alf P. Steinbach"<alf.p.steinbach
    > > 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
    Alf P. Steinbach, Jan 23, 2012
    #5
  6. pratik lala

    Christopher Guest

    On Jan 22, 10:56 am, "osmium" <> 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 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.
    Christopher, Jan 24, 2012
    #6
  7. pratik lala

    Robin Tucker Guest

    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.
    Robin Tucker, Feb 13, 2012
    #7
  8. 在 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..
    88888 Dihedral, Feb 14, 2012
    #8
  9. pratik lala

    Ian Collins Guest

    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
    Ian Collins, Feb 14, 2012
    #9
  10. 在 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
    88888 Dihedral, Feb 14, 2012
    #10
  11. pratik lala

    Ian Collins Guest

    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
    Ian Collins, Feb 15, 2012
    #11
  12. pratik lala

    MiB Guest

    On Feb 14, 8:51 pm, 88888 Dihedral <>
    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.
    MiB, Feb 15, 2012
    #12
  13. pratik lala

    Ian Collins Guest

    On 02/15/12 11:11 PM, MiB wrote:
    > On Feb 14, 8:51 pm, 88888 Dihedral<>
    > 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
    Ian Collins, Feb 15, 2012
    #13
  14. pratik lala

    Rui Maciel Guest

    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
    Rui Maciel, Feb 15, 2012
    #14
  15. pratik lala

    MiB Guest

    On Feb 15, 10:32 pm, Robert Wessel <> wrote:
    > On Wed, 15 Feb 2012 02:11:25 -0800 (PST), MiB
    > <> 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
    MiB, Feb 17, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sonic
    Replies:
    1
    Views:
    535
    John Saunders
    Jan 7, 2005
  2. Replies:
    1
    Views:
    695
    Damien
    Feb 22, 2007
  3. RC

    How to recall add event from an Event handler??

    RC, Jan 6, 2005, in forum: ASP .Net Web Controls
    Replies:
    1
    Views:
    260
    John Saunders
    Jan 6, 2005
  4. Adi
    Replies:
    2
    Views:
    192
  5. Replies:
    0
    Views:
    143
Loading...

Share This Page