text input and key down events |
Rainer Deyke
Guest
|
I have a GUI program that listens for both key down and text input
events. The intended behavior is that each key is processed exactly once, by exactly one GUI widget. However, when the user presses the the '1' key (or any other text input key), it can be processed twice: once as a text input event by a text input widget and once as a shortcut key by another widget. The text input widget cannot consume the key down event because it can't match the key down event to the corresponding text input event. What is the recommended way to handle this? Is there a way to detect if a particular key down event is used for text input so that I can suppress these events while listening for text input? -- Rainer Deyke - _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
text input and key down events |
Rainer Deyke
Guest
|
On 2/20/2011 00:42, Rainer Deyke wrote:
As a temporary hack, I am setting the text input widget to consume all key down events where the keysym is in unicode range (i.e. 30th bit not set), unless either ctrl or alt is pressed. This seems to work. -- Rainer Deyke - _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Jeff Post
Guest
|
On Monday 21 February 2011 12:15, Rainer Deyke wrote:
Why is that a hack? The way I handle it is to define a general widget type (structure or class, depending on language). Then each widget (text input, text output, file selector, etc) attaches callbacks for the types of events they need to handle. Events are processed by passing them to a processCallBack function which runs through the widget list and passes the event to the callback function for the topmost widget in the list that has registered a callback function for that type of event. The widget that processes the event then becomes the topmost widget. The one exception is for an alert or error widget. If one is active, it is the topmost widget and all events except for SDLQuit are passed to it. That just means that nothing else will get done until the user responds to the error widget. If you think that might be useful for your application, contact me off list and I'll send you the code (specify whether you prefer .zip or .tar.gz format). Jeff _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
text input and key down events |
john skaller
Guest
|
On 22/02/2011, at 8:38 AM, Jeff Post wrote:
That's quite a sane algorithm, although it has one problem: callbacks. Hard to avoid in C. Callbacks suck because you lose the stack: your per-widget code becomes a slave of the event loop. There are two ways around this. One is to use threads. This also sucks because it is overkill (consumes resources). The other is to use a better language I think (not sure) Go has channels and fibres but allow me to show you the code I use in Felix: proc dispatch_event( keyboard:schannel[SDL_keysym], active:schannel[SDL_ActiveEvent], resize:schannel[SDL_ResizeEvent] ) { whilst true do var e : SDL_Event; poll_event(&e); match get_type e with | ?et when et == SDL_ACTIVEEVENT=> { write (active, e.active); } | ?et when et == SDL_VIDEORESIZE=> { write (resize, e.resize); } | ?et when et == SDL_KEYDOWN=> { write (keyboard, e.key.keysym); } | ?et when et == SDL_QUIT=> { Quit 0; } | _ => {} endmatch; done; } Notice that this code does not **seem** to be invoking a callback. It calls a routine to get an event and dispatches the event down one of two channels. Here's is the resizing code: proc resizechan(x:schannel[SDL_ResizeEvent]) { whilst true do handle_resize$ read x; done; } The program units are modular, they all have a stack with local variables (or so it seems ..). They have the look and feel of threads. But they're not. The execution model of the underlying code is callbacks. (Actually C++ classes with resume() method). The compiler control-inverts the code, that is it turns it inside out: it takes code that "thinks" it is the master and turns it into slave code. It's a great pity some of the API's SDL uses are forced to be callback driven (Audio I believe). The really big advantage of SDL is that it is a library NOT a framework that forces you to do everything with callbacks. BTW: to understand how important control inversion is, think about parsing a file with a subroutine called with a single character at a time, as opposed to reading the data. When you read, you're the master. When you're called with the data you're a slave. When you write C you're using most important control-inversion function on your computer: the operating system. Actual data from your disk drive or network is delivered asynchronously and the OS control inverts so the client application reads it under application control: the application *thinks* it is the master. -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Kenneth Bull
Guest
|
On 21 February 2011 20:37, john skaller wrote:
application controlled rather than like threads which are OS scheduler controlled. http://golang.org/doc/go_spec.html#Go_statements A channel is like a typed pipe. It can be used to send and receive data between goroutines. http://golang.org/doc/go_spec.html#Channel_types You can find more documentation for Go here: http://golang.org/doc/docs.html _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Rainer Deyke
Guest
|
On 2/21/2011 14:38, Jeff Post wrote:
It's a hack because I have no way to tell if I'm inadvertently consuming key down events that are not used for text input, or if I'm inadvertently failing to consume key down events that /are/ used for text input. My algorithm for detecting if a key is used for text input is based on guesswork and intuition, not actual knowledge. In fact, I'm pretty sure that my algorithm is incorrect in some corner cases. For example, it fails to consume the key down events for modifier keys that are used for text input. Even if my algorithm were correct, it would belong in SDL, not in user code. -- Rainer Deyke - _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
text input and key down events |
Jeff Post
Guest
|
On Monday 21 February 2011 17:37, john skaller wrote:
Not a problem in the applications I write. Don't know about games though since I don't write games.
Since I don't know Felix I can't comment on your code (to me, Felix is a cat -- ouch! I guess I'm showing my age Thanks anyway for providing the example.
Uh, okay. Then I fail to see the difference.
That's one of many things I like about SDL.
Funny you should mention that. My latest application does read a file one character at a time because it needs to parse files written on Linux (LF only newline), Windows (CR/LF newline), and Mac (CR only newline). Whether it does so as master or slave is not relevant to the application. Jeff _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
text input and key down events |
Jeff Post
Guest
|
On Monday 21 February 2011 19:11, Rainer Deyke wrote:
Okay. Without seeing your code I have no way of knowing if my code would be of use to you. Thought it would be nice to offer you my code though, in case you might find it useful.
You might be right, but the biggest advantage I see in SDL is that it doesn't force any particular methodology on developers. It merely provides a platform independent way to access low-level functions. My offer still stands. Use what might be of use to you and disregard the rest. Jeff _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
text input and key down events |
Rainer Deyke
Guest
|
On 2/21/2011 21:02, Jeff Post wrote:
Here is the code I'm talking about: if (!(key & 0x20000000) && !(mod & (KMOD_CTRL | KMOD_ALT))) { return true; }
Detecting if a given keyboard input event is linked to text input is basic, low-level stuff. There is way to clean way to implement it on top of the API SDL provides. -- Rainer Deyke - _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
text input and key down events |
john skaller
Guest
|
On 22/02/2011, at 2:51 PM, Jeff Post wrote:
i don't mean to be offensive but .. "I am fine with assembler I don't need high level languages" "I think gotos are just fine, I don't need block structured programming languages" "Procedural code is fine, I don't need functional programming" "I am happy with object orientation". "I am fine with callbacks" Its all the same. You don't understand why what you're doing is bad, you're used to it and you think it is ok. It isn't OK.
Felix is indeed a cat. -- ouch I guess I'm showing mine [If Guido can name his language after a snake I can use a cat :]
You can't see the difference between C and machine code? It's called automation: the compiler (in both cases) does a lot of tedious housework for you and gets it right every time (hopefully :)
The issue isn't whether you read the file one character at a time, but whether you read the character or are called with it. The differences is very relevant to the complexity of the code you write. For example analysing expressions requires recursion. To do recursion you must have a stack. You can either use the machine stack, or you can EMULATE a stack, but you can't do it without a stack. Emulating a stack is more work, and therefore more error prone, than using one integrated into the programming language. But you can't use the machine stack if your code is a slave because the only way to get the next character is to return control. If your code is a master you can read the next character anywhere in the code, even inside a deeply nested recursive context. -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||
|
text input and key down events |
Jonny D
|
I'm not sure if I totally get your problem, but I'll tell you my
approach to shortcuts. The gui system keeps a list of the registered shortcuts. When a key is pressed, the event is checked against these shortcuts. If it matches one, then the event stops there and the shortcut is activated. Otherwise it goes on to be processed by the widget which currently has keyboard focus. Jonny D On Tue, Feb 22, 2011 at 1:56 AM, Rainer Deyke wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
text input and key down events |
Mason Wheeler
Guest
|
OK, this isn't really my thread, but I've been watching it, and the more you
say, the more confused I become. And this last post seems to have devolved into pure gibberish.
So then, if I'm parsing your viewpoint correctly, "OOP = bad, functional programming = good, callbacks = bad"? ...huh? You do know that callbacks (AKA the use of higher-order functions) are one of the most fundamental aspects of functional programming, don't you?
That depends entirely on the complexity of the grammar you're using. For a lexer (tokenizer,) being called one character at a time is perfectly reasonable, if a bit slower than optimal, and no stack is required. For a parser, yes, you're right, you should have a stream of tokens available that you can ask for the next token when you need it, but it doesn't sound like he's actually describing a recursive parser. There's nothing inherently bad about callbacks. For a lot of things, they greatly simplify the work you need to do. For others, they're not appropriate for the task, so you use some other technique instead. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||||||||||
|
text input and key down events |
john skaller
Guest
|
On 23/02/2011, at 1:02 AM, Mason Wheeler wrote:
Yes, and often it sucks. There is a difference or two though.. in most FPLs callbacks have a context so its a bit better: the callback is a closure, not just a context-less function (as in C).
It's only reasonable if the lexer is *generated* by a tool, which builds a finite state automaton, or at least an NFA.
No, of course not, I just gave that as an example.
There's nothing inherently bad about assembler or using gotos either. It's only bad if you this kind of technology when there's something better.
I agree. Callbacks are only useful if the state machine they can conveniently implement via a single client data object are simple. The problem isn't callbacks (Felix has callbacks! and as you point out HOF's often use callbacks). The problem is when you're forced to use them by a framework and your problem is complex enough you demand the tools of higher level systems: modularity, integrated data and control flow using a stack, and if you go even higher level you need things like garbage collection for memory management. Obviously for simple jobs assembler is just fine. Most (non-arcade) games and GUI applications are complex enough that callbacks alone just won't do. My point is not that assembler, gotos, procedural code, or OO are bad: my point is that they're limited. And a second point needs to be made: better technology like fibres can't be implemented without compiler support. You can't do block structured programming in assembler even though you can emulate the principles. You can't do OO in C, even though you can emulate it. You can't do real functional programming in C++. And you can't do coroutines without language support either. Game programmers are the worst hit by bad technology because games are the most sophisticated and difficult application around. Which is why most games are so deficient in many ways .. most "so called" strategy games have hardly any strategy in them, their unit routing algorithms are non-existent or suck totally -- even though good algorithms exist -- because the programmers spend most of their time struggling to implement basic stuff without error, because the tools they're using aren't up to the job. -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
text input and key down events |
Mason Wheeler
Guest
|
Good point. I'm used to using Delphi, where callbacks are usually implemented as method pointers, which are basically simple closures that provide an object for context. SDL uses a similar principle for its callbacks, putting a user-defined data pointer as part of the signature for a callback.
OK, you lost me again. Parser generation I can understand, but a lexer is dead simple to hand-roll. I wrote a lexer just a few weeks ago. It took a couple hours to write and about 10 minutes to debug. Weighs in at a bit under 400 lines of code for the business logic, plus a keyword table. Child's play.
I assume you're still talking about C callbacks with no context here? Also, why do you keep ragging on ASM? The structured programming theorems prove that you can write any program without gotos, but there are some things that simply can't be done without the use of inline assembly, and IMO any language with no support for it is crippled.
Any examples? I've never run across a scenario where a framework forces you to use a callback for a situation that's not appropriate for one and it ends up getting in the way. Also, WRT garbage collection, I've never encountered any programming problem, no matter how "high-level," that required it. I consider garbage collection one of the worst misfeatures of all time. It's only "necessary" in functional languages because they're designed very poorly, based on fundamental principles such as "let's pretend we're not *really* running on a Turing machine." The problem with GC is that it eliminates the perception of the need to think about memory management, without eliminating the actual need to think about memory management, thus eliminating quite a bit of *thinking* that is still necessary. (See http://tinyurl.com/9ngt74 and http://tinyurl.com/4pxr822 )
I don't know. At work I work on the most complex GUI application I've ever seen. It weighs in at around 3.5 million lines of Delphi code, and if you live in the USA and watch TV or listen to the radio, chances are it's running your station. And, being a GUI application, everything that happens gets kicked off by an event handler, which is a callback with a method pointer.
And functional programming isn't? It's difficult to even look at a serious functional language like Lisp or Haskell without saying "this entire thing is one big abstraction inversion!"
Sure it can. I just call the CreateFiber function and I'm good. http://msdn.microsoft.com/en-us/library/ms682402%28v=vs.85%29.aspx
You know what the difference between doing something the "real" way, with language support, and emulating the principles is? When it's not built into the language as a fundamental abstraction, you can debug it, examine it, and find ways to improve it. When the language abstracts all that away, you lose that ability. That's part of the reason why I like Delphi. You can do extremely high-level stuff in it, including functional programming with real, language-supported closures, but you can also go as low as you need to, all the way down to inline ASM if necessary.
Most of that can be laid at the feet of C++. If game programmers were smart, they'd use a language with a real object model and decent OO semantics, and half their trouble would vanish. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||||||||||||||
|
text input and key down events |
Jjgod Jiang
Guest
|
On Tue, Feb 22, 2011 at 7:56 AM, Rainer Deyke wrote:
Since I am the one implemented text input events for SDL/Cocoa, here is my comment about this issue: I have definitely thought about this when I designed the API, however, SDL on Mac works by intercepting key events in the lowest level (app event dispatch queue) and send it to the application directly, while text input events are somehow at a higher level, provided by NSView NSTextInput protocol. So basically when we intercepting all the key events, we don't know which one of them is going to trigger text input events, so we can't selectively send or drop any one of them. My suggestion is that you should disable text input events when you don't need them (like in a typical GUI toolkit, it will only accept text input when the text cursor is focused in a certain text box), and when you do need them, ignore most of the key events except the ones you can tell that's not going to be a text input (functional keys, ctrl/option key combination, etc.) - Jiang _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
text input and key down events |
Jeff Post
Guest
|
On Tuesday 22 February 2011 05:41, john skaller wrote:
that aren't valid. Jeff _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Jeff Post
Guest
|
On Tuesday 22 February 2011 06:02, Mason Wheeler wrote:
parsing is. In this application the "parsing" consists simply of separating a text input line into specific fields, But it must do so in an OS independent way. I really don't understand why John thinks master/slave is relevant here. The user presses a key when he's darned well and ready. Of course the application is driven by the data--it can't be otherwise. I think this conversation has devolved into silliness. Jeff _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
jon
Guest
|
On 02/21/2011 06:37 PM, john skaller wrote:
You might be interested in Tame, which I think accomplishes something close to your goal. http://pdos.csail.mit.edu/papers/tame-usenix07.pdf Which is part of the webserver that runs okcupid.com: http://okws.org/doku.php?id=okws _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
text input and key down events |
john skaller
Guest
|
On 23/02/2011, at 3:55 AM, jon wrote:
However it seems Tame is used to manage real concurrency? -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
text input and key down events |
Rainer Deyke
Guest
|
On 2/22/2011 06:42, Jonathan Dearborn wrote:
My problem is simple. When I press the 'a' key I get two events from SDL: a key down event (SDLK_a) and a text input event ("a"). Widget A listens for text input events; widget B listens for key down events. Widget A has priority over widget B. I need to get widget A to consume all key down events that are used for text input to prevent the same key from being processed twice, once as a key down event and once as a text input event. The problem is accurately identifying the key down events that are used for text input. My current strategy is for widget A to consume all key down events where the keysym is in the unicode range and neither ctrl nor alt is pressed. This is a heuristic that /seems/ to work, but is probably inaccurate. What I want is simple and accurate way to identify key down events that are used for text input. Actually dispatching the events to the widgets is trivial. The only difficulty is identifying which events should be dispatched and which should be consumed. -- Rainer Deyke - _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Rainer Deyke
Guest
|
On 2/22/2011 09:14, Jjgod Jiang wrote:
I see. That makes things more difficult. However, if I'm going to rely on guesswork to identify key down events that are used for text input /anyway/, then I still think it makes more sense to put this guesswork in SDL than in user code. That way the same functionality can be used and tested by many people instead of just one. The change could be as simple as adding an additional field to SDL_KeyboardEvent: Uint8 text; // Non-zero if SDL thinks that this // keyboard event may be used for text input. -- Rainer Deyke - _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Sam Lantinga
|
This is actually a decent assumption. The keycodes which generate
printable characters have a printable value by design. As Jiang mentioned, it's often not possible to tell in advance whether keyboard input is going to be used to compose text input. On Mon, Feb 21, 2011 at 12:15 PM, Rainer Deyke wrote:
-- -Sam Lantinga, Founder and CEO, Galaxy Gameworks _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
text input and key down events |
Jared Maddox
Guest
|
Sorry about the huge message, I hadn't checked email in a few days.
Date: Tue, 22 Feb 2011 12:37:18 +1100 From: john skaller To: SDL Development List Subject: Re: [SDL] text input and key down events Message-ID: Content-Type: text/plain; charset=us-ascii
to give C callbacks closure: a void pointer. Example function prototype: int accumulate( void *closure, int value ); If you need to dynamically resize the closure, and you don't want to have another pointer inside of the closure, then you'd do this: int accumulate( void **closure, int value ); I won't claim to be a big fan of C's pointer syntax (though the syntax itself is my only real problem with pointers), but it works, it reflects the way things really work (which is good for a 'portable assembly language' like C), and it's a simple way to enable reentrancy.
typedef struct SDL_AudioSpec { int freq; /**< DSP frequency -- samples per second */ SDL_AudioFormat format; /**< Audio data format */ Uint8 channels; /**< Number of channels: 1 mono, 2 stereo */ Uint8 silence; /**< Audio buffer silence value (calculated) */ Uint16 samples; /**< Audio buffer size in samples (power of 2) */ Uint16 padding; /**< Necessary for some compile environments */ Uint32 size; /**< Audio buffer size in bytes (calculated) */ SDL_AudioCallback callback; void *userdata; } SDL_AudioSpec; It's in include/SDL_audio.h. I've separated out the two relevant data members: callback and userdata. You get to supply both, and userdata is used as one of the arguments when callback is called. You then cast it in the function to whatever type you want. For example, if you were writing in C++, you would probably cast it to an object, and then call a member function of that object. A binding for another language (for example, a functional language) would likely do the same. ------------------------------ Date: Wed, 23 Feb 2011 00:41:58 +1100 From: john skaller To: SDL Development List Subject: Re: [SDL] text input and key down events Message-ID: Content-Type: text/plain; charset=us-ascii
language that supports operator-overloading for objects to ANYTHING that doesn't is a genuine downgrade (No, I'm not a fan of Java, though I do UNDERSTAND why they didn't include this particular feature).
assembly language known to man. Certain dialects of Forth might rival it, but I'm not certain that even those do, and Forth is barely structured (in fact, does it actually count as structured?).
are appropriate for the language that the bound code interfaces through, but either not appropriate or needlessly inconvenient in another language that uses said interface.
callback with void pointer) is very useful, because I'm parsing character-by-character anyways. However, in other situations I've preferred the 'master' model. It depends on the situation, and preferring one or the other will just cause you grief. ------------------------------ Date: Wed, 23 Feb 2011 01:50:15 +1100 From: john skaller To: SDL Development List Subject: Re: [SDL] text input and key down events Message-ID: Content-Type: text/plain; charset=us-ascii
better string functions the only really annoying thing would be the initial comment/string parsing. Everything else is decently simple so far, you just need to know when to do what step (note: I'm not trying to parse C itself, it has some quirks that I disagree with, some of which complicate parsing ).
portable, and thus a highly portable language is the appropriate one to have the interface in. Bindings for other languages can then be written to provide a behaviorally equivalent interface in the targeted language.
other than C some time ago. C++ (an obese, soul-sucking monstrosity, sure, but fast, and when using a small enough subset of it's features understandable), Lua, Objective-C, etc. all offer feature improvements over C, and thus have supplanted it's use in various areas.
cause your hair to fall out, BUT an extension of the C language's setjump/longjmp facility is sufficient to implement continuations, and therefor sufficient for both fibers that don't use globals (and technically those too, with entrance/exit functions) and coroutines. You have some reasonable ideas, but this bit is totally off-base. ------------------------------ Date: Tue, 22 Feb 2011 07:51:41 -0800 (PST) From: Mason Wheeler To: SDL Development List Subject: Re: [SDL] text input and key down events Message-ID: Content-Type: text/plain; charset=us-ascii
<snip>
would never make it in the marketplace, but I'm not certain whether that's a mark in the 'for' column or one in the 'against' column.
encompase the entirety of AMM) is fairly intrinsic to declarative languages, since you aren't supposed to ACTUALLY know how your code works, but you're right in that attention needs to be paid to memory during coding, since there's no guarantee that the compiler will go with a memory-lean alternative to your memory-hungry algorithm (or even recognize the algorithm as you wrote it!).
initial) bad implementations (e.g. VC++6), and poor libraries. Seriously, auto_ptr was the best they could agree on? He even mentions graphics at one point in TC++PL 2nd ed, which has never been part of the standard. As for the object model, what do you want, prototypes? Maybe quajects? While C++ classes may have a few bugs in their design (I would have preferred that classes NOT just be structs that default to private), classes in general are appropriate for close-to-the-metal languages like C++, dynamically extended prototype objects like in JavaScript & co. aren't. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
text input and key down events |
Mason Wheeler
Guest
|
Well, I'd put "facilitates the writing of bad code by incompetent programmers" squarely in the "against" column.
First and most obvious, the whole point of object-oriented programming is inheritance and polymorphism. These concepts do not mix with the use of objects as value types. For example, what's the output of this simple C++ program? #include <iostream> class Parent { public: int a; int b; int c; Parent(int ia, int ib, int ic) { a = ia; b = ib; c = ic; }; virtual void doSomething(void) { std::cout << "Parent doSomething" << std::endl; } }; class Child : public Parent { public: int d; int e; Child(int id, int ie) : Parent(1,2,3) { d = id; e = ie; }; virtual void doSomething(void) { std::cout << "Child doSomething : D = " << d << std::endl; } }; void foo(Parent a) { a.doSomething(); } int main(void) { Child c(4, 5); foo(c); return 0; } Second, with no base object class, there's no way to create a function that takes an object of any type as a parameter, which is incredibly limiting. I could go on, but you get the general idea. C++'s object model is completely broken on several fundamental levels. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
text input and key down events |
Jonny D
|
What can you do with a plain Object other than store it? C++ uses
generics for this, not polymorphism. How does Delphi do objects differently? Jonny D On Wed, Feb 23, 2011 at 9:14 AM, Mason Wheeler wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||
|
text input and key down events |
Jonny D
|
Oh, and this should probably move to a new thread... Probably on the
gameprogrammer list... Jonny D On Wed, Feb 23, 2011 at 11:35 AM, Jonathan Dearborn wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||
|
text input and key down events |
Jared Maddox
Guest
|
include inheritance in a modern OO language. Interfaces, coercion and composition provide the same advantages as inheritance, with better behavior in various cases.
called in that code, you'd need quajects, prototypes, or references, one of which C++ actually has. Seriously, it's a horribly obese language (Turing-complete twice? By accident? Seriously?), but for when it was first designed, the object support is pretty good.
it easy to wrap an identifier object around any type. Example: class GenericIdentifier { public: /* intptr_t isn't part of the standard, but it's easy to provide, often present anyways, and is expected to be part of the next standard. */ template< class T > static intptr_t defineType() { T *id; return( reinterpret_cast< intptr_t >( &id ) ); }; virtual intptr_t identifyThisType() { return( defineType< void >() ); }; }; template< class T > class Identifier : public GenericIdentifier { public: T &data; virtual intptr_t identifyThisType() { return( defineType< T >() ); }; }; You then just define two versions of your function: A template version that wraps arguments in an Identifier instance, and a version that takes Identifier instances. This is an easy thing to deal with.
'class' keyword) is always dynamically allocated, and doesn't use a pointer syntax, like in Java. However, it isn't garbage collected, so you wind up with inconsistent code appearances. Fortunately, Delphi classes do seem to include destructors (though I didn't read much on them last night), so that's a definite improvement over Java. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||||
|
text input and key down events |
Mason Wheeler
Guest
|
Well, I've heard "inheritance is bad" repeated as an article of faith by a handful of coders in the last few months, especially since Go started gaining popularity, but I've never heard any actual justification for it. And your proposed alternatives are all a lot more work to implement than simple inheritance, so what are the benefits that make it worth the extra work?
Yep. The parent version gets called, after a hidden copy constructor call to an auto-generated copy constructor. In every other OO language I'm familiar with, all objects are reference types and all value types cannot be extended through inheritance, and there's a good reason for that.
I'd hardly call duplicating all your functions and building wrapper objects for everything "an easy thing to deal with." More like, "a big, bloated hack to work around a missing language feature."
That's correct.
What do you mean by that?
Destructors are pretty straightforward. They work more or less like they do in C++, except that raising an exception when inside a destructor doesn't kill your program. As for the original question:
A handful of different uses come to mind immediately, but they could probably all be classified broadly as some variant of "storing". But there's also serialization. I can use reflection to turn any Delphi object into a string, and then take that string and turn it back into an object of arbitrary type. (Assuming the object's class is registered with the serializer, of course.) Accomplishing this in C++ is far more difficult, with no base object type, no reflection and no class references. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||||||||||||
|
text input and key down events |
Kenneth Bull
Guest
|
On 23 February 2011 13:18, Mason Wheeler wrote:
Interfaces at least would not require extra memory when implemented, and as defined in Go, I expect they are actually quite a bit simpler to implement. Not that I don't like inheritance, mind you. Conceptually at least. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
text input and key down events |
Paulo Pinto
Guest
|
The main issue with interfaces in C++ is called the diamond problem.
Conceptually abstract classes can be used in C++ as interfaces are used in other languages. The problem is that it requires the use of multiple inheritance and that opens the door to quite a few issues, one of them being the diamond problem. To solve it, you need to have access to the full source code of your class hierarchy and apply virtual inheritance in the right places. This is why the use of interfaces does not work that well in C++, when compared with other languages. -- Paulo On Wed, Feb 23, 2011 at 7:59 PM, Kenneth Bull wrote:
|
|||||||||||||||
|
text input and key down events |
Mason Wheeler
Guest
|
I don't follow. As long as you're using single inheritance (not gonna touch MI with a 10-foot pole) the vtable pointer adds sizeof(pointer) to each object instance. That's not much, unless you're working with a bunch of really tiny objects. The vtables themselves can grow large if you have a lot of virtual methods, but they're static data; they exist per class, not per instance. And what do you mean that "inheritance is not simple"? If your objects are all reference types, I don't see anything complicated about it. (Now when your objects are value types and you have to worry about copy constructors, that's a different matter, but that brings me back to my original point that C++'s object model is fundamentally broken.) _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
text input and key down events |
Sam Lantinga
|
Yes please :)
On Wed, Feb 23, 2011 at 8:35 AM, Jonathan Dearborn wrote:
-- -Sam Lantinga, Founder and CEO, Galaxy Gameworks _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||||||
|