From alex at neisis.net Fri Dec 1 00:12:37 2006 From: alex at neisis.net (Alex Norman) Date: Fri Dec 1 00:12:44 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> Message-ID: <20061201081237.GM6029@silverninja.net> > A registration function seems like a good solution (though I'm still > not convinced there's really a problem). I would prefer it however > if the registration of all events happens as part of the library > initialization, not incrementally during execution (removes the need > for a flag, and a lot of if()s and f()s for the price of a tiny > memory increase). I certainly want to minimize the number of > function calls (esp. virtual function calls) in the normal execution > of the event handling. I was thinking about this too.. init functions, basically this means you create a class method "init" for each class, you could have a midievent::init() which would call all the inits in the midievent namespace (or whatever).. etc. these inits could be included in the subsystem inits. so if you include the device subsystem you'd have to call mintdevices::init() or some b.s. it would make it so you wouldn't have to check, but leads to the possibility of missing some inits and fucking shit up. Basically every method leads to different areas things that we might mess up, and we know we're going to mess them up, there is no way around it, it always happens. The question is, what is the easiest to understand now. What is going to be the easiest to debug. What makes sense to an average programmer. Again, I really think that if we over optimize from the beginning we're going to have bugs that are more difficult to locate than if we make things more elegant and encapsulated. -Alex From rch at umail.ucsb.edu Fri Dec 1 02:04:41 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Dec 1 02:04:48 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061201081237.GM6029@silverninja.net> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> Message-ID: <456FFE39.1000105@umail.ucsb.edu> >I was thinking about this too.. init functions, basically this means you create >a class method "init" for each class, you could have a midievent::init() which >would call all the inits in the midievent namespace (or whatever).. etc. these >inits could be included in the subsystem inits. so if you include the device >subsystem you'd have to call mintdevices::init() or some b.s. >it would make it so you wouldn't have to check, but leads to the possibility of >missing some inits and fucking shit up. > Not necessarily. The only reason to 'register' events with the core event handler is so they get dispatched back to the correct sub-system. There is no reason for a cascade of init calls as the events should not register themselves. (Why should an event actually 'do' anything anyway? The subsystem should 'respond' to events. It is the system that does the thing.) I would think, instead, there could be a centralized location in each sub-system that would register its events with the core. class MidiSystem { RegisterSystemEvents () { .. register currently available events with core ... } } This list could even be loaded from a file, since it just consists of event ids. To add a new event to a sub-system, you do the following: 1. Add the event class & code itself to the sub-system, which includes a virtual member function that returns the event id. 2. Add a single line to the register list for that sub-system, with the event id. For user code, you could add the event any time you wanted: 1. Write the user event 2. Put the user event dispatch in the user event handler 3. Call app.SetupUserHandler ( userEventHandler ); 4. Call app.RegisterUserEvent ( 'eventid' ) to tell the core to dispatch this event id to the user-event handler. In general, I like Graham's current solution because it is simple and works. I agree on: - event objects that encapsulate many events - memory pooling Memory pooling events is not that difficult to implement, but it will effect the structure of the event handler significantly - so it would be easier to code now rather than later. The ideal system would handle events of many different sizes: 1. Events with no data need no storage. Just send the event id... E.g.: leftmouseclick. 2. Events with small amounts of data would get it from a memory pool allocated by the core (receiving) thread, fill it, and send it. When the core actually gets around to handling the event, the data is already there for it. E.g. mousemove (x/y), midinote (note, freq, amp) 3. Events with large amounts of data would either a) copy it, b) lock it until it is handled, or c) just send pointer to most recent data. Which one is used depends on the circumstances for safety and performance. I can think of examples where all three behaviors are desirable. It is easy to get carried away with event objects. Mainly I think event objects should not actually 'do' anything. They carry messages, they don't act on them. >Basically every method leads to >different areas things that we might mess up, and we know we're going to mess >them up, there is no way around it, it always happens. The question is, what is >the easiest to understand now. What is going to be the easiest to debug. What >makes sense to an average programmer. > >Again, I really think that if we over optimize from the beginning we're going to >have bugs that are more difficult to locate than if we make things more elegant >and encapsulated. > I think we're all in agreement on the goals of elegant, bug-free code in as much as its possible. Yet there is a difference between efficient design and optimization. Efficient design comes before coding (where structure of the system is affected), optimization after. R From alex at neisis.net Fri Dec 1 07:47:49 2006 From: alex at neisis.net (Alex Norman) Date: Fri Dec 1 07:47:57 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <456FFE39.1000105@umail.ucsb.edu> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> Message-ID: <20061201154748.GN6029@silverninja.net> > > > Not necessarily. The only reason to 'register' events with the core > event handler is so they get dispatched back to the correct sub-system. > There is no reason for a cascade of init calls as the events should not > register themselves. (Why should an event actually 'do' anything anyway? > The subsystem should 'respond' to events. It is the system that does the > thing.) I would think, instead, there could be a centralized location in > each sub-system that would register its events with the core. This registration we're talking about is simply a way to give each event type a unique id. The safest way to do this is to have each event type "registered" in some way so that our core system assigns it a unique id. By cascading I'm just meaning that a subsystem would have a function that inits all its events, in the subsystem init function. There are a number of ways to do this, one would be do have some function like: eventtype.setid(getuniqueid()) but that means that a user might call that setid and mess everything up. A safer thing would be to have this unique id method as a static method within our base class [or our base event class]. class baseclass { private: static unsigned int ids = 1; static unsigned int getUniqueId(){ return ids++; } then in a event you'd have something like static bool inited=false; static unsigned int typeid = 0; //0 could be an invalid id static void init(){ if (!inited) typeid = getUniqueId(); } This minimizes function calls per Grahams request because the default id is 0, and you can just put a test for 0 in your event handler, if that ever happens you can notify the user that there is an unregistered event and you can give its name if we provide introspection, if we provide full class names in our introspection methods we'll make it easier on ourselves and users to find these. > > class MidiSystem { > RegisterSystemEvents () { .. register currently available events > with core ... } > } > This list could even be loaded from a file, since it just consists of > event ids. > To add a new event to a sub-system, you do the following: > 1. Add the event class & code itself to the sub-system, which includes a > virtual member function that returns the event id. > 2. Add a single line to the register list for that sub-system, with the > event id. Loading from a file could lead to duplicate ids for unique events. > > - memory pooling > Memory pooling events is not that difficult to implement, but it will > effect the structure of the event handler significantly - so it would be > easier to code now rather than later. Memory pooling might possibly be implemented more elegantly by overloading new and delete: http://www.softwareacademy.de/cpplernen/?cpp=Overloading&ziel=Overloading%20new%20and%20delete > > It is easy to get carried away with event objects. Mainly I think event > objects should not actually 'do' anything. > They carry messages, they don't act on them. Yes, they don't act on messages, but they should have methods for which to easily set and get their data. > > >Again, I really think that if we over optimize from the beginning we're > >going to have bugs that are more difficult to locate than if we make > >things more elegant > >and encapsulated. > > > I think we're all in agreement on the goals of elegant, bug-free code in as > much as its possible. Yet there is a difference between efficient design > and optimization. Efficient design comes before coding (where structure of > the system is affected), optimization after. > R > -Alex From alex at neisis.net Fri Dec 1 07:51:27 2006 From: alex at neisis.net (Alex Norman) Date: Fri Dec 1 07:51:34 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061201154748.GN6029@silverninja.net> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> Message-ID: <20061201155127.GP6029@silverninja.net> I guess this should be protected not private, but you get the point.. -Alex > > class baseclass { > private: > static unsigned int ids = 1; > static unsigned int getUniqueId(){ > return ids++; > } > > then in a event you'd have something like > static bool inited=false; > static unsigned int typeid = 0; //0 could be an invalid id > static void init(){ > if (!inited) > typeid = getUniqueId(); > } > > This minimizes function calls per Grahams request because the default id is 0, > and you can just put a test for 0 in your event handler, if that ever happens > you can notify the user that there is an unregistered event and you can give > its name if we provide introspection, if we provide full class names in our > introspection methods we'll make it easier on ourselves and users to find these. > From jcastellanos at umail.ucsb.edu Fri Dec 1 09:42:09 2006 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Fri Dec 1 09:42:22 2006 Subject: [Tdg] Core folder structure In-Reply-To: <456F5E31.7050603@umail.ucsb.edu> References: <456F5E31.7050603@umail.ucsb.edu> Message-ID: <07069661-81BA-4A80-9EC7-C4B38A398770@umail.ucsb.edu> Are we sure we want the Docs and Bin directories in the repository? j On Nov 30, 2006, at 5:41 PM, Rama Hoetzlein wrote: So, I started core coding for MINT. Basically, I have just been working on proper linkage for multiple sub-libraries. That is, a single solution with multiple projects, each of which builds static libraries. There is a TestApp that links these libraries with a sample entry point. The app runs, but does nothing more than debug output to a file. Here is what was built: Mint complete solution (root of repository) Bin folder for all executables and static libraries (output path) Docs folder for critical docs (proposals, specs, etc.) Include folder for external linkage to MINT (mint.h, mint- graphics.h, etc.) Output folder for obj files, symbol tables, debug databases Source folder for all actual code Core project code for Core (this folder builds mint-core.lib) Application application class. primary control point for MINT EventHandler our fancy new Event-Handler code EventPlatforms main event loops for various OS platforms (WinMain, etc.) Generic basic supporting classes. Debug class. Error handling class. Subsystem base class for a subsystem. used to derive sub-systems. AudioSystem project code for Audio (this folder builds mint-audio.lib) ConsoleSystem project code for Consoles (this folder builds mint-cons.lib) DisplaySystem project code for Displays (this folder builds mint-displays.lib) GraphicsSystem project code for Graphics (this folder builds mint-graphics.lib) NetworkSystem project code for Networking (this folder build mint-network.lib) TestApp project code to build and link actual test app with MINT (main.cpp) I just want to make sure we're all on the same page with folder structure. These would be initial repository folders. Rama _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From jcastellanos at umail.ucsb.edu Fri Dec 1 09:48:46 2006 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Fri Dec 1 09:48:58 2006 Subject: [Tdg] Core folder structure In-Reply-To: <07069661-81BA-4A80-9EC7-C4B38A398770@umail.ucsb.edu> References: <456F5E31.7050603@umail.ucsb.edu> <07069661-81BA-4A80-9EC7-C4B38A398770@umail.ucsb.edu> Message-ID: <16B2CB22-3670-4D7C-AF65-E89CE533609B@umail.ucsb.edu> What I mean is that some of those files can be regenerated and it might make more sense to keep them out of the versioning system. Any thoughts? j On Dec 1, 2006, at 12:42 PM, Jorge Castellanos wrote: Are we sure we want the Docs and Bin directories in the repository? j On Nov 30, 2006, at 5:41 PM, Rama Hoetzlein wrote: So, I started core coding for MINT. Basically, I have just been working on proper linkage for multiple sub-libraries. That is, a single solution with multiple projects, each of which builds static libraries. There is a TestApp that links these libraries with a sample entry point. The app runs, but does nothing more than debug output to a file. Here is what was built: Mint complete solution (root of repository) Bin folder for all executables and static libraries (output path) Docs folder for critical docs (proposals, specs, etc.) Include folder for external linkage to MINT (mint.h, mint- graphics.h, etc.) Output folder for obj files, symbol tables, debug databases Source folder for all actual code Core project code for Core (this folder builds mint-core.lib) Application application class. primary control point for MINT EventHandler our fancy new Event-Handler code EventPlatforms main event loops for various OS platforms (WinMain, etc.) Generic basic supporting classes. Debug class. Error handling class. Subsystem base class for a subsystem. used to derive sub-systems. AudioSystem project code for Audio (this folder builds mint-audio.lib) ConsoleSystem project code for Consoles (this folder builds mint-cons.lib) DisplaySystem project code for Displays (this folder builds mint-displays.lib) GraphicsSystem project code for Graphics (this folder builds mint-graphics.lib) NetworkSystem project code for Networking (this folder build mint-network.lib) TestApp project code to build and link actual test app with MINT (main.cpp) I just want to make sure we're all on the same page with folder structure. These would be initial repository folders. Rama _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Fri Dec 1 09:58:49 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Dec 1 09:58:57 2006 Subject: [Tdg] Core folder structure In-Reply-To: <16B2CB22-3670-4D7C-AF65-E89CE533609B@umail.ucsb.edu> References: <456F5E31.7050603@umail.ucsb.edu> <07069661-81BA-4A80-9EC7-C4B38A398770@umail.ucsb.edu> <16B2CB22-3670-4D7C-AF65-E89CE533609B@umail.ucsb.edu> Message-ID: <1079b050612010958k18fd926ep9618a77be5077b8c@mail.gmail.com> I think it's nice to have that because you can then tag the docs for a particular version of the repository. wes On 12/1/06, Jorge Castellanos wrote: > What I mean is that some of those files can be regenerated and it > might make more sense to keep them out of the versioning system. > > Any thoughts? > > j > > > On Dec 1, 2006, at 12:42 PM, Jorge Castellanos wrote: > > > Are we sure we want the Docs and Bin directories in the repository? > > j > > > On Nov 30, 2006, at 5:41 PM, Rama Hoetzlein wrote: > > So, I started core coding for MINT. > > Basically, I have just been working on proper linkage for multiple > sub-libraries. That is, a single solution with multiple projects, > each of which builds static libraries. There is a TestApp that links > these libraries with a sample entry point. The app runs, but does > nothing more than debug output to a file. > > Here is what was built: > > Mint complete solution (root of repository) > Bin folder for all executables and static libraries > (output path) > Docs folder for critical docs (proposals, specs, etc.) > Include folder for external linkage to MINT (mint.h, mint- > graphics.h, etc.) > Output folder for obj files, symbol tables, debug databases > Source folder for all actual code > Core project code for Core (this folder > builds mint-core.lib) > Application application class. primary control > point for MINT > EventHandler our fancy new Event-Handler code > EventPlatforms main event loops for various OS > platforms (WinMain, etc.) > Generic basic supporting classes. Debug > class. Error handling class. > Subsystem base class for a subsystem. used to > derive sub-systems. > AudioSystem project code for Audio (this folder builds > mint-audio.lib) > ConsoleSystem project code for Consoles (this folder builds > mint-cons.lib) > DisplaySystem project code for Displays (this folder > builds mint-displays.lib) > GraphicsSystem project code for Graphics (this folder builds > mint-graphics.lib) > NetworkSystem project code for Networking (this folder build > mint-network.lib) > TestApp project code to build and link actual test > app with MINT (main.cpp) > > I just want to make sure we're all on the same page with folder > structure. > These would be initial repository folders. > > Rama > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From alex at neisis.net Fri Dec 1 11:02:03 2006 From: alex at neisis.net (Alex Norman) Date: Fri Dec 1 11:02:12 2006 Subject: [Tdg] Core folder structure In-Reply-To: <1079b050612010958k18fd926ep9618a77be5077b8c@mail.gmail.com> References: <456F5E31.7050603@umail.ucsb.edu> <07069661-81BA-4A80-9EC7-C4B38A398770@umail.ucsb.edu> <16B2CB22-3670-4D7C-AF65-E89CE533609B@umail.ucsb.edu> <1079b050612010958k18fd926ep9618a77be5077b8c@mail.gmail.com> Message-ID: <20061201190203.GS6029@silverninja.net> I think putting docs in a repo is a good idea but I don't think we should put binaries in there. btw, I personally get quite annoyed by folders/files with: spaces capitol letters special characters (ie anything other than [a-zA-Z0-9_-.]) If we could avoid that I'd really appreciate it. -Alex On 0, Wesley Smith wrote: > I think it's nice to have that because you can then tag the docs for a > particular version of the repository. > > wes > > On 12/1/06, Jorge Castellanos wrote: > >What I mean is that some of those files can be regenerated and it > >might make more sense to keep them out of the versioning system. > > > >Any thoughts? > > > >j > > > > > >On Dec 1, 2006, at 12:42 PM, Jorge Castellanos wrote: > > > > > >Are we sure we want the Docs and Bin directories in the repository? > > > >j > > > > > >On Nov 30, 2006, at 5:41 PM, Rama Hoetzlein wrote: > > > >So, I started core coding for MINT. > > > >Basically, I have just been working on proper linkage for multiple > >sub-libraries. That is, a single solution with multiple projects, > >each of which builds static libraries. There is a TestApp that links > >these libraries with a sample entry point. The app runs, but does > >nothing more than debug output to a file. > > > >Here is what was built: > > > >Mint complete solution (root of repository) > > Bin folder for all executables and static libraries > >(output path) > > Docs folder for critical docs (proposals, specs, etc.) > > Include folder for external linkage to MINT (mint.h, mint- > >graphics.h, etc.) > > Output folder for obj files, symbol tables, debug databases > > Source folder for all actual code > > Core project code for Core (this folder > >builds mint-core.lib) > > Application application class. primary control > >point for MINT > > EventHandler our fancy new Event-Handler code > > EventPlatforms main event loops for various OS > >platforms (WinMain, etc.) > > Generic basic supporting classes. Debug > >class. Error handling class. > > Subsystem base class for a subsystem. used to > >derive sub-systems. > > AudioSystem project code for Audio (this folder builds > >mint-audio.lib) > > ConsoleSystem project code for Consoles (this folder builds > >mint-cons.lib) > > DisplaySystem project code for Displays (this folder > >builds mint-displays.lib) > > GraphicsSystem project code for Graphics (this folder builds > >mint-graphics.lib) > > NetworkSystem project code for Networking (this folder build > >mint-network.lib) > > TestApp project code to build and link actual test > >app with MINT (main.cpp) > > > >I just want to make sure we're all on the same page with folder > >structure. > >These would be initial repository folders. > > > >Rama > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Fri Dec 1 11:58:08 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Fri Dec 1 11:58:15 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061201154748.GN6029@silverninja.net> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> Message-ID: <45708950.90000@umail.ucsb.edu> I'm confused. Did we agree on event ids being numbers? I thought we were considering them to be 4-byte strings? >This minimizes function calls per Grahams request because the default id is 0, >and you can just put a test for 0 in your event handler, if that ever happens >you can notify the user that there is an unregistered event and you can give >its name if we provide introspection, if we provide full class names in our >introspection methods we'll make it easier on ourselves and users to find these. > > Are we talking about >generating< event ids to build our list of registered events? OR, are we talking about generating ids to keep track of different actual >instantiated< events? I still don't think we should be >generating< event ids to register events. In this case of event >definition<, we explicitly specify what each event type is. So, for event registration, generating them seems unnecessary. (Event types: A, B, C, etc.). If the same event id is registered twice, the event handler can still tell us. I don't think events should have an 'init' function, or should generate unique ids... After all, we want to assign the events ids anyway (ie. each event has a specific meaning). I thought we were considering them to be 4-byte strings? The other problem with numbers for event ids is on different runs of the program ids might shift if the user defines them in a different order. -- I really think event ids should be fixed 4 or 8-byte strings. Really, i would call this "event type". IF we are talking about event ids to keep track of actual >instantiated< events, this seems a better place to use them. The event handler can then distinguish two different events of the same type within the same time stamp (for example - two left mouse clicks that happen in the same time stamp: A1, A2, ...). But still there would be no 'init' function in the event to generate ids. The id would be set by the event handler -after- the event is received. The creator of the event doesn't care what id it has, so long as the handler keeps track of them... I really don't think that events should actual 'do' anything, such as generate ids via 'init'. They should just carry messages. Maybe it would be better to talk about this stuff in person sometime... > > >>class MidiSystem { >> RegisterSystemEvents () { .. register currently available events >>with core ... } >>} >>This list could even be loaded from a file, since it just consists of >>event ids. >>To add a new event to a sub-system, you do the following: >>1. Add the event class & code itself to the sub-system, which includes a >>virtual member function that returns the event id. >>2. Add a single line to the register list for that sub-system, with the >>event id. >> >> > >Loading from a file could lead to duplicate ids for unique events. > > Why? If our ids are four-byte strings, then we will have a map of ids. The event handler can easily check if an id already exists as it reads the file. > > >Memory pooling might possibly be implemented more elegantly by overloading new >and delete: >http://www.softwareacademy.de/cpplernen/?cpp=Overloading&ziel=Overloading%20new%20and%20delete > > > I disagree. Then new and delete don't behave as expected in other sub-systems. >>It is easy to get carried away with event objects. Mainly I think event >>objects should not actually 'do' anything. >>They carry messages, they don't act on them. >> >> > >Yes, they don't act on messages, but they should have methods for which to >easily set and get their data. > > Agreed. From wakefield at mat.ucsb.edu Fri Dec 1 12:16:23 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Fri Dec 1 12:16:31 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <45708950.90000@umail.ucsb.edu> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> Message-ID: On Dec 1, 2006, at 11:58 AM, Rama Hoetzlein wrote: > > I'm confused. Did we agree on event ids being numbers? > I thought we were considering them to be 4-byte strings? So far I like Lance's proposal best: union{ char c[4]; unsigned long i; } EventType; >> Memory pooling might possibly be implemented more elegantly by >> overloading new >> and delete: >> http://www.softwareacademy.de/cpplernen/? >> cpp=Overloading&ziel=Overloading%20new%20and%20delete >> >> > I disagree. Then new and delete don't behave as expected in other > sub-systems. I concur. New programmers should expect new and delete to do what they always do, but when learning the MINT/TDG API, they should learn that they call different methods to generate different events, but that the events will be freed automatically by the event handling system. From wesley.hoke at gmail.com Fri Dec 1 12:55:08 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Dec 1 12:55:17 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> Message-ID: <1079b050612011255u24ea27b3jc86b6a2f15788b3d@mail.gmail.com> > I concur. New programmers should expect new and delete to do what > they always do, but when learning the MINT/TDG API, they should learn > that they call different methods to generate different events, but > that the events will be freed automatically by the event handling > system. Why do you have to have different methods to create different events? Can't there be a base class virtual function that gets called so that the interface is generic yet creates specific events? wes From wakefield at mat.ucsb.edu Fri Dec 1 13:07:35 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Fri Dec 1 13:07:45 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1079b050612011255u24ea27b3jc86b6a2f15788b3d@mail.gmail.com> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <1079b050612011255u24ea27b3jc86b6a2f15788b3d@mail.gmail.com> Message-ID: Helper methods for people who appreciate help. On Dec 1, 2006, at 12:55 PM, Wesley Smith wrote: >> I concur. New programmers should expect new and delete to do what >> they always do, but when learning the MINT/TDG API, they should learn >> that they call different methods to generate different events, but >> that the events will be freed automatically by the event handling >> system. > > Why do you have to have different methods to create different events? > Can't there be a base class virtual function that gets called so that > the interface is generic yet creates specific events? > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From jcastellanos at umail.ucsb.edu Fri Dec 1 14:04:09 2006 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Fri Dec 1 14:04:25 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> Message-ID: <3E91B0D9-4951-4B00-8F7D-ABC411DBA6A2@umail.ucsb.edu> > >> >> I'm confused. Did we agree on event ids being numbers? >> I thought we were considering them to be 4-byte strings? >> > > So far I like Lance's proposal best: > > union{ > char c[4]; > unsigned long i; > } EventType; > What was wrong with Wes' proposal (hash)? j On Dec 1, 2006, at 3:16 PM, Graham Wakefield wrote: On Dec 1, 2006, at 11:58 AM, Rama Hoetzlein wrote: > > I'm confused. Did we agree on event ids being numbers? > I thought we were considering them to be 4-byte strings? So far I like Lance's proposal best: union{ char c[4]; unsigned long i; } EventType; >> Memory pooling might possibly be implemented more elegantly by >> overloading new >> and delete: >> http://www.softwareacademy.de/cpplernen/? >> cpp=Overloading&ziel=Overloading%20new%20and%20delete >> >> > I disagree. Then new and delete don't behave as expected in other > sub-systems. I concur. New programmers should expect new and delete to do what they always do, but when learning the MINT/TDG API, they should learn that they call different methods to generate different events, but that the events will be freed automatically by the event handling system. _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Fri Dec 1 14:11:08 2006 From: alex at neisis.net (Alex Norman) Date: Fri Dec 1 14:11:19 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> Message-ID: <20061201221108.GT6029@silverninja.net> > >>Memory pooling might possibly be implemented more elegantly by > >>overloading new > >>and delete: > >>http://www.softwareacademy.de/cpplernen/? > >>cpp=Overloading&ziel=Overloading%20new%20and%20delete > >> > >> > >I disagree. Then new and delete don't behave as expected in other > >sub-systems. > > I concur. New programmers should expect new and delete to do what > they always do, but when learning the MINT/TDG API, they should learn > that they call different methods to generate different events, but > that the events will be freed automatically by the event handling > system. new/delete only act differently behind the scenes in this case, it doesn't look any different to the user (afaik). This is just a suggestion, something to think about, I'm not sure if it is a good idea or not yet. -Alex > > > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Fri Dec 1 15:05:04 2006 From: alex at neisis.net (Alex Norman) Date: Fri Dec 1 15:05:13 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <45708950.90000@umail.ucsb.edu> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> Message-ID: <20061201230504.GU6029@silverninja.net> On 0, Rama Hoetzlein wrote: > > I'm confused. Did we agree on event ids being numbers? > I thought we were considering them to be 4-byte strings? > I wasn't aware of any final conclusion :) Just that Graham is already working on something, but not that we've come to a consensus about anything. I totally understand the need for Graham to get something going... so whatever if it works it works. > > >This minimizes function calls per Grahams request because the default id > >is 0, > >and you can just put a test for 0 in your event handler, if that ever > >happens > >you can notify the user that there is an unregistered event and you can > >give > >its name if we provide introspection, if we provide full class names in our > >introspection methods we'll make it easier on ourselves and users to find > >these. > > > > > Are we talking about >generating< event ids to build our list of > registered events? OR, are we talking about generating ids to keep track > of different actual >instantiated< events? > Yes, I am talking about generating event type ids. This is similar to hashing, giving each event type a guaranteed unique id at run time. I agree, this isn't 100% necessary, but it provides some safety from accidentally conflicting event type ids and with no run time cost (after initial initialization, which is trivial). > I still don't think we should be >generating< event ids to register > events. In this case of event >definition<, we explicitly specify what > each event type is. So, for event registration, generating them seems > unnecessary. (Event types: A, B, C, etc.). If the same event id is > registered twice, the event handler can still tell us. I don't think > events should have an 'init' function, or should generate unique ids... > After all, we want to assign the events ids anyway (ie. each event has a > specific meaning). I thought we were considering them to be 4-byte > strings? The other problem with numbers for event ids is on different > runs of the program ids might shift if the user defines them in a > different order. -- I really think event ids should be fixed 4 or 8-byte > strings. Really, i would call this "event type". Well, we have a lot of opinions. I think events should have: A static/class eventClassName String [any length] (ie "midi") A static/class eventClassID (unsigned int) A static/class eventTypeName String [any length] (ie "noteon") A static/class eventTypeID (unsigned int) obviously I am in the minority... oh well :) > > > > >Loading from a file could lead to duplicate ids for unique events. > > > > > Why? If our ids are four-byte strings, then we will have a map of ids. > The event handler can easily check if an id already exists as it reads > the file. > You are talking about event type registration here, almost exactly what you said we shouldn't do above. In this case instead of registering an event with our system using unique ids it is registering the event type with the handler, either way this is registration. -Alex From wakefield at mat.ucsb.edu Fri Dec 1 15:30:59 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Fri Dec 1 15:31:08 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061201221108.GT6029@silverninja.net> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201221108.GT6029@silverninja.net> Message-ID: > > new/delete only act differently behind the scenes in this case, it > doesn't look > any different to the user (afaik). > > This is just a suggestion, something to think about, I'm not sure > if it is a > good idea or not yet. Fair enough! Definitely we should get as many suggestions as possible before making any commitments! I'm just in a situation where I need something up and running ASAP (codename 'MintyG') so I'm running with what I've got for now. Anything useful that comes out of it we can use in Mint; anything that turns out to have been a bad idea will be scrapped. From ljputnam at umail.ucsb.edu Fri Dec 1 16:57:15 2006 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Dec 1 16:57:30 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <3E91B0D9-4951-4B00-8F7D-ABC411DBA6A2@umail.ucsb.edu> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <3E91B0D9-4951-4B00-8F7D-ABC411DBA6A2@umail.ucsb.edu> Message-ID: <20061201165715.kw4leygefwg00wcw@webaccess.umail.ucsb.edu> Jorge Castellanos wrote: > >> >>> >>> I'm confused. Did we agree on event ids being numbers? >>> I thought we were considering them to be 4-byte strings? >>> >> >> So far I like Lance's proposal best: >> >> union{ >> char c[4]; >> unsigned long i; >> } EventType; >> > > What was wrong with Wes' proposal (hash)? > > j > I have little experience with hash tables, so I don't know what the advantages/disadvantages are. Both methods will still be prone to having duplicate names/values, i.e. collisions, so hashing seems unneccesarily complex. Someone please explain why we would want to do hashing. Also, if you want a string for pretty printing we can have a virtual 'asString()' method. Lance -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From wesley.hoke at gmail.com Fri Dec 1 17:01:11 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri Dec 1 17:01:20 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061201165715.kw4leygefwg00wcw@webaccess.umail.ucsb.edu> References: <20061130173823.GA6029@silverninja.net> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <3E91B0D9-4951-4B00-8F7D-ABC411DBA6A2@umail.ucsb.edu> <20061201165715.kw4leygefwg00wcw@webaccess.umail.ucsb.edu> Message-ID: <1079b050612011701q6da6a23fp682f9c94208b7642@mail.gmail.com> The way a hash would work is that you set a variable in the event like name="myevent" and use this and potentially some other distinguishing data on a class level and run it through a hashing function that will return a unique number based on the contents of the inputs. If the inputs are the same, the result is the same. The reason to do this is that the data that is set is human readable like a string but the data used to compare class types is the hashed result i.e. an int that is computed and is fast to compare with. wes PS you fag On 12/1/06, Lance J. Putnam wrote: > Jorge Castellanos wrote: > > > > >> > >>> > >>> I'm confused. Did we agree on event ids being numbers? > >>> I thought we were considering them to be 4-byte strings? > >>> > >> > >> So far I like Lance's proposal best: > >> > >> union{ > >> char c[4]; > >> unsigned long i; > >> } EventType; > >> > > > > What was wrong with Wes' proposal (hash)? > > > > j > > > > I have little experience with hash tables, so I don't know what the > advantages/disadvantages are. Both methods will still be prone to > having duplicate names/values, i.e. collisions, so hashing seems > unneccesarily complex. Someone please explain why we would want to do > hashing. Also, if you want a string for pretty printing we can have a > virtual 'asString()' method. > > Lance > > -- > Lance Putnam > Graduate Student > Electronic Music and Sound Design > Media Arts and Technology / UCSB > ljputnam@umail.ucsb.edu > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From ljputnam at umail.ucsb.edu Fri Dec 1 17:14:36 2006 From: ljputnam at umail.ucsb.edu (Lance J. Putnam) Date: Fri Dec 1 17:14:52 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1079b050612011701q6da6a23fp682f9c94208b7642@mail.gmail.com> References: <20061130173823.GA6029@silverninja.net> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <3E91B0D9-4951-4B00-8F7D-ABC411DBA6A2@umail.ucsb.edu> <20061201165715.kw4leygefwg00wcw@webaccess.umail.ucsb.edu> <1079b050612011701q6da6a23fp682f9c94208b7642@mail.gmail.com> Message-ID: <20061201171436.qwaj8qmdkwwoo8k4@webaccess.umail.ucsb.edu> Yes, I understand you want both fast comparison and human-readable identifiers for each event. With either approach, this requirement is satisfied. The problem I see is that your comparisons will no longer be human-readable or maybe less readable. On the flip-side, now I'm not sure writing char[4]'s like 'abcd' is cross-platform. Anyone tested this on Windows or Linux? Lance P.S. You smoke hash. Wesley Smith wrote: > The way a hash would work is that you set a variable in the event like > name="myevent" and use this and potentially some other distinguishing > data on a class level and run it through a hashing function that will > return a unique number based on the contents of the inputs. If the > inputs are the same, the result is the same. The reason to do this is > that the data that is set is human readable like a string but the data > used to compare class types is the hashed result i.e. an int that is > computed and is fast to compare with. > > wes > > PS you fag > > On 12/1/06, Lance J. Putnam wrote: >> Jorge Castellanos wrote: >> >>> >>>> >>>>> >>>>> I'm confused. Did we agree on event ids being numbers? >>>>> I thought we were considering them to be 4-byte strings? >>>>> >>>> >>>> So far I like Lance's proposal best: >>>> >>>> union{ >>>> char c[4]; >>>> unsigned long i; >>>> } EventType; >>>> >>> >>> What was wrong with Wes' proposal (hash)? >>> >>> j >>> >> >> I have little experience with hash tables, so I don't know what the >> advantages/disadvantages are. Both methods will still be prone to >> having duplicate names/values, i.e. collisions, so hashing seems >> unneccesarily complex. Someone please explain why we would want to do >> hashing. Also, if you want a string for pretty printing we can have a >> virtual 'asString()' method. >> >> Lance >> >> -- >> Lance Putnam >> Graduate Student >> Electronic Music and Sound Design >> Media Arts and Technology / UCSB >> ljputnam@umail.ucsb.edu >> >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg >> > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -- Lance Putnam Graduate Student Electronic Music and Sound Design Media Arts and Technology / UCSB ljputnam@umail.ucsb.edu From rch at umail.ucsb.edu Sat Dec 2 02:13:55 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sat Dec 2 02:14:01 2006 Subject: [Tdg] Style Message-ID: <457151E3.6080408@umail.ucsb.edu> > Alex Norman wrote: > btw, I personally get quite annoyed by folders/files with: > spaces > capitol letters > special characters (ie anything other than [a-zA-Z0-9_-.]) Maybe we can take a general consensus on style. - What are your preferences for folders? (capitalization, hyphens, spaces, etc.) - What are your preferences for files? (capitalization, hyphens, spaces, etc.) - What are your preferences for member variables? (hungarian m_, other..) - What are your preferences for class names? (Event, CEvent, etc.) My own responses would be: - Capitols on folders. No spaces. Like: DisplaySystem - No caps on files. Hyphens for seperation. Like: display-file.cpp - Hungarian notation for member vars, but only for these cases: m_Variable always m_ for member vars m_strFilename for strings m_bCheck for bools m_iInt for ints m_fFloat for floats m_Variable for anything else - C preceding class names. Prevents name conflicts with Visual Studio. E.g. CEvent I suspect there will be a lot of argument on style. Plus, style tends to make people pretty emotional (since you use it everywhere). So I highly recommend you all just submit your preferences for now and we will wade through them together later. R From rch at umail.ucsb.edu Sat Dec 2 02:21:11 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sat Dec 2 02:21:16 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061201230504.GU6029@silverninja.net> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> Message-ID: <45715397.60207@umail.ucsb.edu> >You are talking about event type registration here, almost exactly what you said >we shouldn't do above. In this case instead of registering an event with our >system using unique ids it is registering the event type with the handler, >either way this is registration. > > Right. I am not against registering ids. I'm advocating it. And I was suggesting perhaps a map could facilitate this. I'm just arguing against generating id numbers. I like the strategy of using a union. You said: A static/class eventClassName A static/class eventClassID (unsigned int) A static/class eventTypeName String [any length] (ie "noteon") A static/class eventTypeID (unsigned int) Why do you want both a name and an id anyway? R From alex at neisis.net Sat Dec 2 10:42:55 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 10:43:03 2006 Subject: [Tdg] Style In-Reply-To: <457151E3.6080408@umail.ucsb.edu> References: <457151E3.6080408@umail.ucsb.edu> Message-ID: <20061202184255.GW6029@silverninja.net> My style prefs: NO CAPS in file or folder names. files and folders: only a-z,-,_ files can include . this makes it SO much nicer to move around the file tree on the command line using tab completion. [at least for me, and for those who use some gui b.s. (I assume everyone besides me), well.. it makes no difference] ClassNames Start with Caps and use "CamelCase" member vars start with m, the next letter is capitalized, also use CamelCase, [i am fine with an underscore if that is the way it has to be] including a type identifier doesn't seem like a bad idea either [ie m_strBlah] class vars start with c I like the constants start with k thing too.. so basically, I almost agree with Rama -Alex On 0, Rama Hoetzlein wrote: > >Alex Norman wrote: > >btw, I personally get quite annoyed by folders/files with: > >spaces > >capitol letters > >special characters (ie anything other than [a-zA-Z0-9_-.]) > > Maybe we can take a general consensus on style. > - What are your preferences for folders? (capitalization, hyphens, > spaces, etc.) > - What are your preferences for files? (capitalization, hyphens, spaces, > etc.) > - What are your preferences for member variables? (hungarian m_, other..) > - What are your preferences for class names? (Event, CEvent, etc.) > > My own responses would be: > - Capitols on folders. No spaces. Like: DisplaySystem > - No caps on files. Hyphens for seperation. Like: display-file.cpp > - Hungarian notation for member vars, but only for these cases: > m_Variable always m_ for member vars > m_strFilename for strings > m_bCheck for bools > m_iInt for ints > m_fFloat for floats > m_Variable for anything else > - C preceding class names. Prevents name conflicts with Visual Studio. > E.g. CEvent > > I suspect there will be a lot of argument on style. Plus, style tends to > make people pretty emotional (since you use it everywhere). So I highly > recommend you all just submit your preferences for now and we will wade > through them together later. > > R > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sat Dec 2 10:47:29 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 10:47:37 2006 Subject: [Tdg] Style In-Reply-To: <20061202184255.GW6029@silverninja.net> References: <457151E3.6080408@umail.ucsb.edu> <20061202184255.GW6029@silverninja.net> Message-ID: <1079b050612021047l7d605711p202abe2cdf0daa4d@mail.gmail.com> On 12/2/06, Alex Norman wrote: > My style prefs: > NO CAPS in file or folder names. > files and folders: only a-z,-,_ > files can include . > this makes it SO much nicer to move around the file tree on the command line > using tab completion. [at least for me, and for those who use some gui b.s. (I > assume everyone besides me), well.. it makes no difference] > > ClassNames Start with Caps and use "CamelCase" > member vars start with m, the next letter is capitalized, also use CamelCase, > [i am fine with an underscore if that is the way it has to be] > including a type identifier doesn't seem like a bad idea either [ie m_strBlah] > class vars start with c > I like the constants start with k thing too.. > I'm cool with all of this. wes From alex at neisis.net Sat Dec 2 11:08:47 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 11:08:56 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <45715397.60207@umail.ucsb.edu> References: <20061130173823.GA6029@silverninja.net> <20061130133024.lhr0kqb4iooock8k@webaccess.umail.ucsb.edu> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> Message-ID: <20061202190847.GX6029@silverninja.net> Basically I'm talking about the same thing Wes is talking about, hashing a name, but instead of hashing on the name in the foreground and having to create a hash function that is guaranteed to give a unique id for each name, we just give each class a unique id from the start, it is easier for us, you don't have to do any real computation based on the name. Having both a name and an id is nice because the class retains its name in full [for printing etc], and you don't have to do any look up in order to find its id [no hash table, ie map]. so instead of doing this: if(hash(e->getEventName()) == hash(Midi::NoteOn::EventName) or whatever you just do: if(e->getEventId() == Midi::NoteOn::EventId) all of the id b.s. is done behind the scenes requires less overhead when you're actually doing comparisons [which is where it counts], doing "registration" in a class constructor requires ONE more if statement [negligible] and ONE function call the first time a class of that type is allocated. it also requires about one more boolean class variable per class [again negligible]. -Alex p.s. who's got hash? On 0, Rama Hoetzlein wrote: > > >You are talking about event type registration here, almost exactly what > >you said > >we shouldn't do above. In this case instead of registering an event with > >our > >system using unique ids it is registering the event type with the handler, > >either way this is registration. > > > > > Right. I am not against registering ids. I'm advocating it. And I was > suggesting perhaps a map could facilitate this. > I'm just arguing against generating id numbers. I like the strategy of > using a union. > > You said: > A static/class eventClassName > A static/class eventClassID (unsigned int) > A static/class eventTypeName String [any length] (ie "noteon") > A static/class eventTypeID (unsigned int) > > Why do you want both a name and an id anyway? > > R > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sat Dec 2 11:13:42 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 11:13:50 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202190847.GX6029@silverninja.net> References: <20061130173823.GA6029@silverninja.net> <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> Message-ID: <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> Exactly! I was also thinking on hit of hash when the class was created. I bet there's something in Boost we can snag to do this. > -Alex > p.s. who's got hash? > I used to, but my source in Oakland moved to the Right Coast. From wakefield at mat.ucsb.edu Sat Dec 2 11:36:24 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 11:36:35 2006 Subject: [Tdg] Style In-Reply-To: <1079b050612021047l7d605711p202abe2cdf0daa4d@mail.gmail.com> References: <457151E3.6080408@umail.ucsb.edu> <20061202184255.GW6029@silverninja.net> <1079b050612021047l7d605711p202abe2cdf0daa4d@mail.gmail.com> Message-ID: Generally I prefer mVariable over m_variable, for the sake of RSI-by- underscore I wouldn't want to enforce adding a type prefix to every variable either. Perhaps for the ambiguous ones only. Also, I tend to use much shorter names for very frequently used variables (sometimes even single letters). Any distinction between public and private/protected variables/methods? How about getters & setters? We had a lot of this kind of discussion with GLV. I guess in this case we have a distinction to make between the public API and our internal engine; public API should be more explicit (but not so explicit as Apple's 20-odd character classnames!). Oh, class names: yes we had a similar problem in GLV (GLV Rect clashing with Carbon Rect) until we used a namespace, then all was (mostly) well. Can't we do the same in VS? mint::Event shouldn't clash with VS's Event. On Dec 2, 2006, at 10:47 AM, Wesley Smith wrote: > On 12/2/06, Alex Norman wrote: >> My style prefs: >> NO CAPS in file or folder names. >> files and folders: only a-z,-,_ >> files can include . >> this makes it SO much nicer to move around the file tree on the >> command line >> using tab completion. [at least for me, and for those who use some >> gui b.s. (I >> assume everyone besides me), well.. it makes no difference] >> >> ClassNames Start with Caps and use "CamelCase" >> member vars start with m, the next letter is capitalized, also use >> CamelCase, >> [i am fine with an underscore if that is the way it has to be] >> including a type identifier doesn't seem like a bad idea either >> [ie m_strBlah] >> class vars start with c >> I like the constants start with k thing too.. >> > > > I'm cool with all of this. > > wes > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 12:04:24 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 12:04:32 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> References: <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> Message-ID: <20061202200424.GY6029@silverninja.net> I don't think there is any need to use boost for this, we don't need to hash, we just assign a unique id via a baseclass that has a static var that is incremented and assigned to a class variable when a class is first created. ie: class BaseClass { private: static unsigned int cEventTypeIdCnt; protected: unsigned int getUniqueTypeId(){return cEventTypeIdCnt++;} public: virtual unsigned int getEventTypeId(){ return cEventTypeId; } } unsigned int BaseClass::cEventTypeIdCnt = 1; then each subclass does this: class SubClass : public BaseClass { private: static unsigned int cEventTypeId; static bool cEventTypeInited; public: SubClass(){ if(!cEventTypeInited){ cEventTypeInited = true; cEventTypeId = getUniqueTypeId(); } } virtual unsigned int getEventTypeId(){ return cEventTypeId; } } bool SubClass::cEventTypeInited = false; unsigned int SubClass::cEventTypeId = 0; Since each class is overriding the cEventTypeId and cEventTypeInited variables they have to define this virtual method, but most of this can be done behind the scene. Since the default eventtypeid is 0, we can test that first in the event processor, then we know that the thing wasn't inited and we can note that or throw an error or whatever we decide to do. Since every class would need to do this we could make a MACRO so we don't have to type so much. This way we're just doing integer comparison to get at the class type. SubClass::cEventTypeId == e->getEventTypeId() the lame part about this is we still cannot use this in a switch statement because cEventTypeId changes at one point during the execution of the app. -Alex On 0, Wesley Smith wrote: > Exactly! I was also thinking on hit of hash when the class was > created. I bet there's something in Boost we can snag to do this. > > > >-Alex > >p.s. who's got hash? > > > > I used to, but my source in Oakland moved to the Right Coast. > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sat Dec 2 12:08:58 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 12:09:06 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202200424.GY6029@silverninja.net> References: <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> Message-ID: <1079b050612021208i2fa98497ie9037fdb7959a147@mail.gmail.com> We can just borrow from the Hash implementation from Boost. We don't have to use the entire Boost library. That would suck. The reason to use a hash as opposed to a counter is that there is a one-to-one mapping between string data and a resulting integer which could potentially be rigged into a case statement. wes On 12/2/06, Alex Norman wrote: > I don't think there is any need to use boost for this, we don't need to hash, we > just assign a unique id via a baseclass that has a static var that is > incremented and assigned to a class variable when a class is first created. > > ie: > class BaseClass { > private: > static unsigned int cEventTypeIdCnt; > protected: > unsigned int getUniqueTypeId(){return cEventTypeIdCnt++;} > public: > virtual unsigned int getEventTypeId(){ > return cEventTypeId; > } > } > unsigned int BaseClass::cEventTypeIdCnt = 1; > > then each subclass does this: > > class SubClass : public BaseClass { > private: > static unsigned int cEventTypeId; > static bool cEventTypeInited; > public: > SubClass(){ > if(!cEventTypeInited){ > cEventTypeInited = true; > cEventTypeId = getUniqueTypeId(); > } > } > virtual unsigned int getEventTypeId(){ > return cEventTypeId; > } > } > > bool SubClass::cEventTypeInited = false; > unsigned int SubClass::cEventTypeId = 0; > > Since each class is overriding the cEventTypeId and cEventTypeInited variables > they have to define this virtual method, but most of this can be done behind the > scene. Since the default eventtypeid is 0, we can test that first in the event > processor, then we know that the thing wasn't inited and we can note that or > throw an error or whatever we decide to do. Since every class would need to do > this we could make a MACRO so we don't have to type so much. > > This way we're just doing integer comparison to get at the class type. > SubClass::cEventTypeId == e->getEventTypeId() > > the lame part about this is we still cannot use this in a switch statement > because cEventTypeId changes at one point during the execution of the app. > > -Alex > > On 0, Wesley Smith wrote: > > Exactly! I was also thinking on hit of hash when the class was > > created. I bet there's something in Boost we can snag to do this. > > > > > > >-Alex > > >p.s. who's got hash? > > > > > > > I used to, but my source in Oakland moved to the Right Coast. > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From wakefield at mat.ucsb.edu Sat Dec 2 12:59:16 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 12:59:26 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202200424.GY6029@silverninja.net> References: <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> Message-ID: Why is getEventTypeId() virtual? It is the same in every class, it should just be a normal (and inlined) method. On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > I don't think there is any need to use boost for this, we don't > need to hash, we > just assign a unique id via a baseclass that has a static var that is > incremented and assigned to a class variable when a class is first > created. > > ie: > class BaseClass { > private: > static unsigned int cEventTypeIdCnt; > protected: > unsigned int getUniqueTypeId(){return cEventTypeIdCnt++;} > public: > virtual unsigned int getEventTypeId(){ > return cEventTypeId; > } > } > unsigned int BaseClass::cEventTypeIdCnt = 1; > > then each subclass does this: > > class SubClass : public BaseClass { > private: > static unsigned int cEventTypeId; > static bool cEventTypeInited; > public: > SubClass(){ > if(!cEventTypeInited){ > cEventTypeInited = true; > cEventTypeId = getUniqueTypeId(); > } > } > virtual unsigned int getEventTypeId(){ > return cEventTypeId; > } > } > > bool SubClass::cEventTypeInited = false; > unsigned int SubClass::cEventTypeId = 0; > > Since each class is overriding the cEventTypeId and > cEventTypeInited variables > they have to define this virtual method, but most of this can be > done behind the > scene. Since the default eventtypeid is 0, we can test that first > in the event > processor, then we know that the thing wasn't inited and we can > note that or > throw an error or whatever we decide to do. Since every class > would need to do > this we could make a MACRO so we don't have to type so much. > > This way we're just doing integer comparison to get at the class type. > SubClass::cEventTypeId == e->getEventTypeId() > > the lame part about this is we still cannot use this in a switch > statement > because cEventTypeId changes at one point during the execution of > the app. > > -Alex > > On 0, Wesley Smith wrote: >> Exactly! I was also thinking on hit of hash when the class was >> created. I bet there's something in Boost we can snag to do this. >> >> >>> -Alex >>> p.s. who's got hash? >>> >> >> I used to, but my source in Oakland moved to the Right Coast. >> _______________________________________________ >> Tdg mailing list >> Tdg@mat.ucsb.edu >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wakefield at mat.ucsb.edu Sat Dec 2 13:08:01 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 13:08:09 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202200424.GY6029@silverninja.net> References: <20061201004729.GG6029@silverninja.net> <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> Message-ID: On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > > > the lame part about this is we still cannot use this in a switch > statement > because cEventTypeId changes at one point during the execution of > the app. Why? So long as we have already called SubClass() once, or some kind of SubClass::register() function, at startup, this will work fine: switch(e->getEventTypeId()) { case SubClass::cEventTypeId: //... break; } I do think that a SubClass::register() is preferable to putting things into a SubClass() constructor; in fact, I'm in favor of not having SubClass() constructors at all (equal footprint and ease of casting to event types from the base class). In any case I still think the probability of having an event ID clash is very low, whether using four-char-codes or hashed strings. I have no strong opinions either way. From alex at neisis.net Sat Dec 2 13:13:18 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 13:13:27 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> Message-ID: <20061202211318.GZ6029@silverninja.net> getEventTypeId needs to be virtual because each "class variable" is unique.. ex: BaseEvent{ private: static unsigned int cEventTypeId; } SubEvent{ private: static unsigned int cEventTypeId; } even though they both have a cEventTypeId they actually refer to different data because each class needs their own static "class" member to store the event. If we didn't override the static member we wouldn't have a unique id for each class, ALL the classes would share the same static member [afaik]. there is no way for a baseclass event to access this new static member, so you need to create a virtual method to return this value. this way even if we put a SubEvent in a list of type BaseEvent, the getEventTypeId() function will return the correct value. Since every class would need to define the same thing, I think it is a valid place to use a Macro like I showed at the beginning of this discussion. this does bring up an issue, should the static member be public or private? if it is public then it can be changed by the user, if it is private we need to create an additional "class method" that returns the value, it does the same thing as getEventTypeId() but since that is a virtual method there is no way to call like Midi::NoteOn::getEventTypeId() -Alex On 0, Graham Wakefield wrote: > Why is getEventTypeId() virtual? It is the same in every class, it > should just be a normal (and inlined) method. > > On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > > >I don't think there is any need to use boost for this, we don't > >need to hash, we > >just assign a unique id via a baseclass that has a static var that is > >incremented and assigned to a class variable when a class is first > >created. > > > >ie: > >class BaseClass { > > private: > > static unsigned int cEventTypeIdCnt; > > protected: > > unsigned int getUniqueTypeId(){return cEventTypeIdCnt++;} > > public: > > virtual unsigned int getEventTypeId(){ > > return cEventTypeId; > > } > >} > >unsigned int BaseClass::cEventTypeIdCnt = 1; > > > >then each subclass does this: > > > >class SubClass : public BaseClass { > > private: > > static unsigned int cEventTypeId; > > static bool cEventTypeInited; > > public: > > SubClass(){ > > if(!cEventTypeInited){ > > cEventTypeInited = true; > > cEventTypeId = getUniqueTypeId(); > > } > > } > > virtual unsigned int getEventTypeId(){ > > return cEventTypeId; > > } > >} > > > >bool SubClass::cEventTypeInited = false; > >unsigned int SubClass::cEventTypeId = 0; > > > >Since each class is overriding the cEventTypeId and > >cEventTypeInited variables > >they have to define this virtual method, but most of this can be > >done behind the > >scene. Since the default eventtypeid is 0, we can test that first > >in the event > >processor, then we know that the thing wasn't inited and we can > >note that or > >throw an error or whatever we decide to do. Since every class > >would need to do > >this we could make a MACRO so we don't have to type so much. > > > >This way we're just doing integer comparison to get at the class type. > >SubClass::cEventTypeId == e->getEventTypeId() > > > >the lame part about this is we still cannot use this in a switch > >statement > >because cEventTypeId changes at one point during the execution of > >the app. > > > >-Alex > > > >On 0, Wesley Smith wrote: > >>Exactly! I was also thinking on hit of hash when the class was > >>created. I bet there's something in Boost we can snag to do this. > >> > >> > >>>-Alex > >>>p.s. who's got hash? > >>> > >> > >>I used to, but my source in Oakland moved to the Right Coast. > >>_______________________________________________ > >>Tdg mailing list > >>Tdg@mat.ucsb.edu > >>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sat Dec 2 13:15:12 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 13:15:23 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061201004729.GG6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> Message-ID: <1079b050612021315w518fa35bp82d97ae5f6104e70@mail.gmail.com> If we go with the ID counter like Alex suggested, we never have to worry about clashes. The only thing you'll have to be careful of is hardcoding the relationship between the ID# and the string name, but if we are smart about it, we will never have to hard code it. We can just use functions to get the approporate values at runtime. This is probably the easiest thing to do. Hashing is nice, but it will be more work. wes On 12/2/06, Graham Wakefield wrote: > > On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > > > > > > > the lame part about this is we still cannot use this in a switch > > statement > > because cEventTypeId changes at one point during the execution of > > the app. > > Why? So long as we have already called SubClass() once, or some kind > of SubClass::register() function, at startup, this will work fine: > > switch(e->getEventTypeId()) > { > case SubClass::cEventTypeId: > //... > break; > } > > I do think that a SubClass::register() is preferable to putting > things into a SubClass() constructor; in fact, I'm in favor of not > having SubClass() constructors at all (equal footprint and ease of > casting to event types from the base class). > > In any case I still think the probability of having an event ID clash > is very low, whether using four-char-codes or hashed strings. > > I have no strong opinions either way. > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From alex at neisis.net Sat Dec 2 13:17:38 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 13:17:46 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> Message-ID: <20061202211738.GA6029@silverninja.net> A constructor is created for you if you don't create [afaik], and it is always called so why not just register in there? it requires 1 more bit and that is about it. Worrying about 1 if statement is totally overkill in my eyes. you can always do both, but if you do it in the constructor you don't have to worry about explicitly registering, or forgetting to register. Well, I tried to do this type of switch statement. it didn't work for me, the compiler said you have to have a constant value in the the case part of a switch statement, since the cEventTypeId does change during execution, that is a problem. That is a case for having pre-defined, const, ids. though maybe there is some compiler option to allow for it?? -Alex On 0, Graham Wakefield wrote: > > On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > > > > > > >the lame part about this is we still cannot use this in a switch > >statement > >because cEventTypeId changes at one point during the execution of > >the app. > > Why? So long as we have already called SubClass() once, or some kind > of SubClass::register() function, at startup, this will work fine: > > switch(e->getEventTypeId()) > { > case SubClass::cEventTypeId: > //... > break; > } > > I do think that a SubClass::register() is preferable to putting > things into a SubClass() constructor; in fact, I'm in favor of not > having SubClass() constructors at all (equal footprint and ease of > casting to event types from the base class). > > In any case I still think the probability of having an event ID clash > is very low, whether using four-char-codes or hashed strings. > > I have no strong opinions either way. > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 13:23:15 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 13:23:22 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1079b050612021315w518fa35bp82d97ae5f6104e70@mail.gmail.com> References: <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <1079b050612021315w518fa35bp82d97ae5f6104e70@mail.gmail.com> Message-ID: <20061202212315.GB6029@silverninja.net> Yeah, I don't think hashing really gives us anything anyways, afaik we still cannot use it in a switch statement, because a hash has to do some computation, unless it is some "macro" hash function that actually does the hashing before compilation. Once we have ids/names we can easily print out super classes of a class, can easily make an "isA" methods to return if foo is a subclass of bar, etc. I'm not sure if this is really necessary for this application, but it is a nice side effect. -Alex On 0, Wesley Smith wrote: > If we go with the ID counter like Alex suggested, we never have to > worry about clashes. The only thing you'll have to be careful of is > hardcoding the relationship between the ID# and the string name, but > if we are smart about it, we will never have to hard code it. We can > just use functions to get the approporate values at runtime. This is > probably the easiest thing to do. Hashing is nice, but it will be > more work. > > wes > > On 12/2/06, Graham Wakefield wrote: > > > >On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > > > >> > >> > >> the lame part about this is we still cannot use this in a switch > >> statement > >> because cEventTypeId changes at one point during the execution of > >> the app. > > > >Why? So long as we have already called SubClass() once, or some kind > >of SubClass::register() function, at startup, this will work fine: > > > >switch(e->getEventTypeId()) > >{ > > case SubClass::cEventTypeId: > > //... > > break; > >} > > > >I do think that a SubClass::register() is preferable to putting > >things into a SubClass() constructor; in fact, I'm in favor of not > >having SubClass() constructors at all (equal footprint and ease of > >casting to event types from the base class). > > > >In any case I still think the probability of having an event ID clash > >is very low, whether using four-char-codes or hashed strings. > > > >I have no strong opinions either way. > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 13:31:07 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 13:31:15 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202211738.GA6029@silverninja.net> References: <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211738.GA6029@silverninja.net> Message-ID: <20061202213107.GC6029@silverninja.net> Here is a test: ----- class A { public: static unsigned int cId; }; unsigned int A::cId = 0; int main(){ unsigned int i = 0; switch(i){ case A::cId: break; } return 0; } ---- when i compile this i get: test.cpp:14: error: 'A::cId' cannot appear in a constant-expression if you make cId const then it works. Again, this is a valid reason to use const ids instead of registration, but that gives the possibility of clashes, which could easily happen, especially with users who are novice programmers. making it not const and registering it gives us the benefit of compiler checking because the compiler won't allow for classes of the same name within the same namespace and all the user has to do is provide a classname, the ids are done for them. all kinds of trade offs.. -Alex On 0, Alex Norman wrote: > A constructor is created for you if you don't create [afaik], and it is always > called so why not just register in there? it requires 1 more bit and that is > about it. Worrying about 1 if statement is totally overkill in my eyes. > > you can always do both, but if you do it in the constructor you don't have to > worry about explicitly registering, or forgetting to register. > > Well, I tried to do this type of switch statement. it didn't work for me, the > compiler said you have to have a constant value in the the case part of a switch > statement, since the cEventTypeId does change during execution, that is a > problem. That is a case for having pre-defined, const, ids. though maybe there > is some compiler option to allow for it?? > > -Alex > > On 0, Graham Wakefield wrote: > > > > On Dec 2, 2006, at 12:04 PM, Alex Norman wrote: > > > > > > > > > > >the lame part about this is we still cannot use this in a switch > > >statement > > >because cEventTypeId changes at one point during the execution of > > >the app. > > > > Why? So long as we have already called SubClass() once, or some kind > > of SubClass::register() function, at startup, this will work fine: > > > > switch(e->getEventTypeId()) > > { > > case SubClass::cEventTypeId: > > //... > > break; > > } > > > > I do think that a SubClass::register() is preferable to putting > > things into a SubClass() constructor; in fact, I'm in favor of not > > having SubClass() constructors at all (equal footprint and ease of > > casting to event types from the base class). > > > > In any case I still think the probability of having an event ID clash > > is very low, whether using four-char-codes or hashed strings. > > > > I have no strong opinions either way. > > > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Sat Dec 2 13:38:40 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sat Dec 2 13:38:46 2006 Subject: [Tdg] fake introspection/event classes Message-ID: <4571F260.6060602@umail.ucsb.edu> I guess we can provide both ways to compare events, although I still think its redundant. You can always just do: if ( e->eventType == 'midion' ) ... If we use the union structure and hash, there are actually four ways to compare events: - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very slow - if ( e->eventId == EventID::MidiOn ) // fast - if ( e->eventType.str == 'midion' ) // kind of fast - if ( e->eventType.val == (int) 'midion' ) // fast I am suggestng the use of a hash function to register events and check for duplicates, but not to do the actual comparison. I would really prefer to use the last two comparisons above, but I suppose we could provide all of them. I see you are still thinking of putting the id generation in the event classes. If you do this, you need a global variable for event id counter. From your example: unsigned int BaseClass::cEventTypeIdCnt = 1; I think its much better to assign the unique ids from event handler. Such as: class EventHandler { public: void RegisterEvent ( Event* e ); int eventIdCnt; } void EventHandler::RegisterEvent ( Event* e ) { e->SetID ( eventIdCnt ); eventIdCnt++; } This way, we can stick to the idea that events just carry messages. Incrementing the id inside events makes them into functional parts of the program again (while they should just carry messages). Using the code above, the event handler is now in charge of the id counter as it should be (not a global var). It tells events what their id is, and would make the assignment of ids more flexible (ie. would be easy to change) Wes, why not use std::map instead of boost? Here are all the argument so far as I can tell: - Storage of event ids: a) Use a union of 4-byte and int b) Use a full std::string and another int - Enforcing unique events a) Use a hash on event string, b) Use an id generator (no hash needed) - Generation of unique ids (only applied to b. in previous) a) Generate ids from inside the event, using constructor/init. Global id counter to increment ids. b) Generate ids from the EventHandler. Id values are assigned to the event from the handler. EventHandler maintains the counter. - Comparison of event ids: a) Compare the 4-bytes in the union b) Compare the int in the union c) Compare the hash of the full event string d) Compare the int id of the event (not in a union) Alex, using an id generator to "enforce unique events" does not guarantee that the event type strings will be unique. The user could still create two event types and accidentally give them the same event string. - MidiOnEvent: eventType = 'myevent', eventId = 0 - MidiOffEvent: eventType = 'myevent', eventId = 1 The id generator would assign unique id values to both, but they would still carry the same event string. This is the reason for the hash. -R From wesley.hoke at gmail.com Sat Dec 2 13:42:53 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 13:43:01 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <4571F260.6060602@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> Message-ID: <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very slow I think this is backwards. I would do: if ( (e->hashedEventType) == (EventType::MidiOn::hashedEventType) ) // very fast wes From rch at umail.ucsb.edu Sat Dec 2 13:47:01 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sat Dec 2 13:47:05 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> Message-ID: <4571F455.3000802@umail.ucsb.edu> I am >not< suggesting to actual use: - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very slow A hash resolves to an int. So what is the difference between these two? - if ( (e->hashedEventType) == (EventType::MidiOn::hashedEventType) ) // very fast - if ( e->eventId == EventID::MidiOn ) // very fast hash ( e->eventType ) == e->eventId From wakefield at mat.ucsb.edu Sat Dec 2 13:50:44 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 13:50:51 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202211318.GZ6029@silverninja.net> References: <20061201081237.GM6029@silverninja.net> <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211318.GZ6029@silverninja.net> Message-ID: Oh I see, of course, because the class id is static. If id wasn't static, but instead set when the event is generated, there would be no need for a virtual. Calls for unit tests I suppose. Ugh. On Dec 2, 2006, at 1:13 PM, Alex Norman wrote: > getEventTypeId needs to be virtual because each "class variable" is > unique.. From wesley.hoke at gmail.com Sat Dec 2 13:50:59 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 13:51:06 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <4571F455.3000802@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> Message-ID: <1079b050612021350k4743452eq46523b3cf73ec355@mail.gmail.com> Potentially nothing is e->eventId is the result of the hashed string value. What I was proposing with the hashing was the following Event :: Event(const char *name) { //std::string m_name = name m_eventID = hash(name) } The code above would be no different and we wouldn't have to figure out a counting system for eventIDs. It would come naturally from the string name. wes On 12/2/06, Rama Hoetzlein wrote: > > I am >not< suggesting to actual use: > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very slow > > A hash resolves to an int. > So what is the difference between these two? > > - if ( (e->hashedEventType) == (EventType::MidiOn::hashedEventType) ) > // very fast > - if ( e->eventId == EventID::MidiOn ) // very fast > > hash ( e->eventType ) == e->eventId > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From wakefield at mat.ucsb.edu Sat Dec 2 13:53:29 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 13:53:40 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202213107.GC6029@silverninja.net> References: <456FFE39.1000105@umail.ucsb.edu> <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211738.GA6029@silverninja.net> <20061202213107.GC6029@silverninja.net> Message-ID: <6AE1BB58-D5FD-4576-B792-50F12F287F53@mat.ucsb.edu> On Dec 2, 2006, at 1:31 PM, Alex Norman wrote: > Again, this is a valid reason to use > const ids instead of registration, but that gives the possibility > of clashes, > which could easily happen, especially with users who are novice > programmers. This is the part that I don't really agree with. A very large operating system used by many thousands of developers uses unsigned ints for event class and type. From jcastellanos at umail.ucsb.edu Sat Dec 2 13:54:26 2006 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Sat Dec 2 13:54:41 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <4571F455.3000802@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> Message-ID: <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> If we only need the type (and not "full" introspection), then it's easy to get by using the typeid operator. In C++ there's no need to add any static stuff and complicate subclassing.... by calling typeid(*ptr).name you get back the name of the Class. Again, this only works for simple introspection where just basic type info is needed. But it seems that's what we've been talking about. ahh... and it's very fast! j On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: I am >not< suggesting to actual use: - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very slow A hash resolves to an int. So what is the difference between these two? - if ( (e->hashedEventType) == (EventType::MidiOn::hashedEventType) ) // very fast - if ( e->eventId == EventID::MidiOn ) // very fast hash ( e->eventType ) == e->eventId _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20061202/8b80c721/attachment.html From alex at neisis.net Sat Dec 2 13:55:39 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 13:55:47 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <4571F260.6060602@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> Message-ID: <20061202215539.GE6029@silverninja.net> On 0, Rama Hoetzlein wrote: > I guess we can provide both ways to compare events, although I still > think its redundant. > You can always just do: > > if ( e->eventType == 'midion' ) ... > > If we use the union structure and hash, there are actually four ways to > compare events: > > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very slow > - if ( e->eventId == EventID::MidiOn ) // fast > - if ( e->eventType.str == 'midion' ) // kind of fast > - if ( e->eventType.val == (int) 'midion' ) // fast once you provide a union I think you're supposed to only access it in one way, like the int type, or the string type, so you wouldn't want to mix eventType.str and eventType.val once you assign to eventType.str eventType.val is totally bogus and there is on way to a know if type eventTypes with unique str values will have unique .val values. I really think using unions is unnecessary and a bad idea. ..... > This way, we can stick to the idea that events just carry messages. > Incrementing the id inside events makes them into functional parts of > the program again (while they should just carry messages). Using the > code above, the event handler is now in charge of the id counter as it > should be (not a global var). It tells events what their id is, and > would make the assignment of ids more flexible (ie. would be easy to > change) I disagree. This isn't making the events a "functional" part of the program, it is simply making a baseclass insure unique ids in a very clean way. Putting that into the event handler unnecessarily makes the EventHandler define aspects of internals of eventtypes. > Alex, using an id generator to "enforce unique events" does not > guarantee that the event type strings will be unique. > The user could still create two event types and accidentally give them > the same event string. > - MidiOnEvent: eventType = 'myevent', eventId = 0 > - MidiOffEvent: eventType = 'myevent', eventId = 1 > The id generator would assign unique id values to both, but they would > still carry the same event string. > This is the reason for the hash. True, it depends on how you assign event types. If you make the event type the same as the classname then you do get this.. #define BLAH(ClassName) ClassName::cEventTypeName = #ClassName the compiler will then complain if you do that twice. -Alex > > -R > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 14:15:10 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 14:15:18 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> Message-ID: <20061202221510.GF6029@silverninja.net> I'm not sure of the rtti stuff test: -- #include #include #include using namespace std; class X { }; class Y : public X { }; int main(){ cout << "class X\n"; cout << "class Y : public X\n"; cout << "list l;\n"; list l; cout << "Y * b = new Y;\n"; Y * b = new Y; cout << "typeid(b).name(): "; cout << typeid(b).name() << '\n'; cout << "typeid(*b).name(): "; cout << typeid(*b).name() << '\n'; cout << "l.push_back(b);\n"; l.push_back(b); cout << "typeid(l.back()).name(): "; cout << typeid(l.back()).name() << "\n"; cout << "typeid(*l.back()).name(): "; cout << typeid(*l.back()).name() << "\n"; return 0; } -- this gives me the output: class X class Y : public X list l; Y * b = new Y; typeid(b).name(): P1Y typeid(*b).name(): 1Y l.push_back(b); typeid(l.back()).name(): P1X typeid(*l.back()).name(): 1X so, b is a pointer to a Y, but once i put it on the list and then I try to see the type of it on the list it says it is a pointer to an X, and when I deref it I see it is of type X, but this is not true, it is of type Y. Am I not doing this correctly? -Alex On 0, Jorge Castellanos wrote: > > If we only need the type (and not "full" introspection), then it's > easy to get by using the typeid operator. In C++ there's no need to > add any static stuff and complicate subclassing.... > > by calling typeid(*ptr).name you get back the name of the Class. > > Again, this only works for simple introspection where just basic type > info is needed. But it seems that's what we've been talking about. > > ahh... and it's very fast! > > j > > > On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: > > > I am >not< suggesting to actual use: > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very > slow > > A hash resolves to an int. > So what is the difference between these two? > > - if ( (e->hashedEventType) == > (EventType::MidiOn::hashedEventType) ) // very fast > - if ( e->eventId == EventID::MidiOn ) // very fast > hash ( e->eventType ) == e->eventId > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wesley.hoke at gmail.com Sat Dec 2 14:18:43 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 14:18:51 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202221510.GF6029@silverninja.net> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> <20061202221510.GF6029@silverninja.net> Message-ID: <1079b050612021418t7715924bg1bc418bed9919dd1@mail.gmail.com> You have to cast it in order to make it a Y. For example: *(l.back()).name() wes On 12/2/06, Alex Norman wrote: > I'm not sure of the rtti stuff > > test: > -- > > #include > #include > #include > using namespace std; > > class X { > }; > > class Y : public X { > }; > > int main(){ > cout << "class X\n"; > cout << "class Y : public X\n"; > > cout << "list l;\n"; > list l; > > cout << "Y * b = new Y;\n"; > Y * b = new Y; > > cout << "typeid(b).name(): "; > cout << typeid(b).name() << '\n'; > > cout << "typeid(*b).name(): "; > cout << typeid(*b).name() << '\n'; > > cout << "l.push_back(b);\n"; > l.push_back(b); > > cout << "typeid(l.back()).name(): "; > cout << typeid(l.back()).name() << "\n"; > > cout << "typeid(*l.back()).name(): "; > cout << typeid(*l.back()).name() << "\n"; > > return 0; > } > > -- > > this gives me the output: > class X > class Y : public X > list l; > Y * b = new Y; > typeid(b).name(): P1Y > typeid(*b).name(): 1Y > l.push_back(b); > typeid(l.back()).name(): P1X > typeid(*l.back()).name(): 1X > > so, b is a pointer to a Y, but once i put it on the list and then I try to see > the type of it on the list it says it is a pointer to an X, and when I deref it > I see it is of type X, but this is not true, it is of type Y. > > Am I not doing this correctly? > > -Alex > > On 0, Jorge Castellanos wrote: > > > > If we only need the type (and not "full" introspection), then it's > > easy to get by using the typeid operator. In C++ there's no need to > > add any static stuff and complicate subclassing.... > > > > by calling typeid(*ptr).name you get back the name of the Class. > > > > Again, this only works for simple introspection where just basic type > > info is needed. But it seems that's what we've been talking about. > > > > ahh... and it's very fast! > > > > j > > > > > > On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: > > > > > > I am >not< suggesting to actual use: > > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very > > slow > > > > A hash resolves to an int. > > So what is the difference between these two? > > > > - if ( (e->hashedEventType) == > > (EventType::MidiOn::hashedEventType) ) // very fast > > - if ( e->eventId == EventID::MidiOn ) // very fast > > hash ( e->eventType ) == e->eventId > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > From jcastellanos at umail.ucsb.edu Sat Dec 2 14:19:25 2006 From: jcastellanos at umail.ucsb.edu (Jorge Castellanos) Date: Sat Dec 2 14:19:42 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202221510.GF6029@silverninja.net> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> <20061202221510.GF6029@silverninja.net> Message-ID: <1F934F84-DC74-4324-B22C-A9DFAFC70C10@umail.ucsb.edu> You need to add a virtual destructor for the polymorphic behavior to work. I think. Additionally, all this can be hidden in the base class by adding a method called "isOfClass()" or something like that. j On Dec 2, 2006, at 5:15 PM, Alex Norman wrote: I'm not sure of the rtti stuff test: -- #include #include #include using namespace std; class X { }; class Y : public X { }; int main(){ cout << "class X\n"; cout << "class Y : public X\n"; cout << "list l;\n"; list l; cout << "Y * b = new Y;\n"; Y * b = new Y; cout << "typeid(b).name(): "; cout << typeid(b).name() << '\n'; cout << "typeid(*b).name(): "; cout << typeid(*b).name() << '\n'; cout << "l.push_back(b);\n"; l.push_back(b); cout << "typeid(l.back()).name(): "; cout << typeid(l.back()).name() << "\n"; cout << "typeid(*l.back()).name(): "; cout << typeid(*l.back()).name() << "\n"; return 0; } -- this gives me the output: class X class Y : public X list l; Y * b = new Y; typeid(b).name(): P1Y typeid(*b).name(): 1Y l.push_back(b); typeid(l.back()).name(): P1X typeid(*l.back()).name(): 1X so, b is a pointer to a Y, but once i put it on the list and then I try to see the type of it on the list it says it is a pointer to an X, and when I deref it I see it is of type X, but this is not true, it is of type Y. Am I not doing this correctly? -Alex On 0, Jorge Castellanos wrote: > > If we only need the type (and not "full" introspection), then it's > easy to get by using the typeid operator. In C++ there's no need to > add any static stuff and complicate subclassing.... > > by calling typeid(*ptr).name you get back the name of the Class. > > Again, this only works for simple introspection where just basic type > info is needed. But it seems that's what we've been talking about. > > ahh... and it's very fast! > > j > > > On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: > > > I am >not< suggesting to actual use: > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very > slow > > A hash resolves to an int. > So what is the difference between these two? > > - if ( (e->hashedEventType) == > (EventType::MidiOn::hashedEventType) ) // very fast > - if ( e->eventId == EventID::MidiOn ) // very fast > hash ( e->eventType ) == e->eventId > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg _______________________________________________ Tdg mailing list Tdg@mat.ucsb.edu http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 14:20:23 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 14:20:32 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1079b050612021418t7715924bg1bc418bed9919dd1@mail.gmail.com> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> <20061202221510.GF6029@silverninja.net> <1079b050612021418t7715924bg1bc418bed9919dd1@mail.gmail.com> Message-ID: <20061202222023.GH6029@silverninja.net> I know the speed gurus aren't going to like a dynamic cast though we could use this rtti stuff inside the classes to create their id numbers. -alex On 0, Wesley Smith wrote: > You have to cast it in order to make it a Y. For example: > > *(l.back()).name() > > > wes > > > On 12/2/06, Alex Norman wrote: > >I'm not sure of the rtti stuff > > > >test: > >-- > > > >#include > >#include > >#include > >using namespace std; > > > >class X { > >}; > > > >class Y : public X { > >}; > > > >int main(){ > > cout << "class X\n"; > > cout << "class Y : public X\n"; > > > > cout << "list l;\n"; > > list l; > > > > cout << "Y * b = new Y;\n"; > > Y * b = new Y; > > > > cout << "typeid(b).name(): "; > > cout << typeid(b).name() << '\n'; > > > > cout << "typeid(*b).name(): "; > > cout << typeid(*b).name() << '\n'; > > > > cout << "l.push_back(b);\n"; > > l.push_back(b); > > > > cout << "typeid(l.back()).name(): "; > > cout << typeid(l.back()).name() << "\n"; > > > > cout << "typeid(*l.back()).name(): "; > > cout << typeid(*l.back()).name() << "\n"; > > > > return 0; > >} > > > >-- > > > >this gives me the output: > >class X > >class Y : public X > >list l; > >Y * b = new Y; > >typeid(b).name(): P1Y > >typeid(*b).name(): 1Y > >l.push_back(b); > >typeid(l.back()).name(): P1X > >typeid(*l.back()).name(): 1X > > > >so, b is a pointer to a Y, but once i put it on the list and then I try to > >see > >the type of it on the list it says it is a pointer to an X, and when I > >deref it > >I see it is of type X, but this is not true, it is of type Y. > > > >Am I not doing this correctly? > > > >-Alex > > > >On 0, Jorge Castellanos wrote: > >> > >> If we only need the type (and not "full" introspection), then it's > >> easy to get by using the typeid operator. In C++ there's no need to > >> add any static stuff and complicate subclassing.... > >> > >> by calling typeid(*ptr).name you get back the name of the Class. > >> > >> Again, this only works for simple introspection where just basic type > >> info is needed. But it seems that's what we've been talking about. > >> > >> ahh... and it's very fast! > >> > >> j > >> > >> > >> On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: > >> > >> > >> I am >not< suggesting to actual use: > >> - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very > >> slow > >> > >> A hash resolves to an int. > >> So what is the difference between these two? > >> > >> - if ( (e->hashedEventType) == > >> (EventType::MidiOn::hashedEventType) ) // very fast > >> - if ( e->eventId == EventID::MidiOn ) // very fast > >> hash ( e->eventType ) == e->eventId > >> _______________________________________________ > >> Tdg mailing list > >> Tdg@mat.ucsb.edu > >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > >> > > > >> _______________________________________________ > >> Tdg mailing list > >> Tdg@mat.ucsb.edu > >> http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 14:22:12 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 14:22:19 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <1F934F84-DC74-4324-B22C-A9DFAFC70C10@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> <20061202221510.GF6029@silverninja.net> <1F934F84-DC74-4324-B22C-A9DFAFC70C10@umail.ucsb.edu> Message-ID: <20061202222212.GI6029@silverninja.net> Ahh, yes, once I add a virtual destructor the: typeid(*l.back()).name(); correctly gives 1Y -Alex On 0, Jorge Castellanos wrote: > You need to add a virtual destructor for the polymorphic behavior to > work. I think. > > Additionally, all this can be hidden in the base class by adding a > method called "isOfClass()" or something like that. > > j > > > On Dec 2, 2006, at 5:15 PM, Alex Norman wrote: > > I'm not sure of the rtti stuff > > test: > -- > > #include > #include > #include > using namespace std; > > class X { > }; > > class Y : public X { > }; > > int main(){ > cout << "class X\n"; > cout << "class Y : public X\n"; > > cout << "list l;\n"; > list l; > > cout << "Y * b = new Y;\n"; > Y * b = new Y; > > cout << "typeid(b).name(): "; > cout << typeid(b).name() << '\n'; > > cout << "typeid(*b).name(): "; > cout << typeid(*b).name() << '\n'; > > cout << "l.push_back(b);\n"; > l.push_back(b); > > cout << "typeid(l.back()).name(): "; > cout << typeid(l.back()).name() << "\n"; > > cout << "typeid(*l.back()).name(): "; > cout << typeid(*l.back()).name() << "\n"; > > return 0; > } > > -- > > this gives me the output: > class X > class Y : public X > list l; > Y * b = new Y; > typeid(b).name(): P1Y > typeid(*b).name(): 1Y > l.push_back(b); > typeid(l.back()).name(): P1X > typeid(*l.back()).name(): 1X > > so, b is a pointer to a Y, but once i put it on the list and then I > try to see > the type of it on the list it says it is a pointer to an X, and when > I deref it > I see it is of type X, but this is not true, it is of type Y. > > Am I not doing this correctly? > > -Alex > > On 0, Jorge Castellanos wrote: > > > >If we only need the type (and not "full" introspection), then it's > >easy to get by using the typeid operator. In C++ there's no need to > >add any static stuff and complicate subclassing.... > > > >by calling typeid(*ptr).name you get back the name of the Class. > > > >Again, this only works for simple introspection where just basic type > >info is needed. But it seems that's what we've been talking about. > > > >ahh... and it's very fast! > > > >j > > > > > >On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: > > > > > >I am >not< suggesting to actual use: > > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // very > >slow > > > >A hash resolves to an int. > >So what is the difference between these two? > > > >- if ( (e->hashedEventType) == > >(EventType::MidiOn::hashedEventType) ) // very fast > >- if ( e->eventId == EventID::MidiOn ) // very fast > >hash ( e->eventType ) == e->eventId > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > > > >_______________________________________________ > >Tdg mailing list > >Tdg@mat.ucsb.edu > >http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From rch at umail.ucsb.edu Sat Dec 2 14:22:40 2006 From: rch at umail.ucsb.edu (Rama Hoetzlein) Date: Sat Dec 2 14:22:44 2006 Subject: [Tdg] (no subject) Message-ID: <4571FCB0.4060205@umail.ucsb.edu> All I have to say is --- ugh.. I need to get some other work done for a little while, R From alex at neisis.net Sat Dec 2 14:27:59 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 14:28:07 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: References: <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211318.GZ6029@silverninja.net> Message-ID: <20061202222759.GK6029@silverninja.net> if the class id isn't static then you'd have to have an id for each event type which would mean there would have to be a look up every time you create an event. it would also mean that there wouldn't be a way to compare against a class variable because there wouldn't be one :) I think that e->getTypeId() == Midi::NoteOn::cTypeId is quite nice and easy to understand. but there are all kinds of trade offs to think about. -Alex On 0, Graham Wakefield wrote: > Oh I see, of course, because the class id is static. > > If id wasn't static, but instead set when the event is generated, > there would be no need for a virtual. > > Calls for unit tests I suppose. Ugh. > > On Dec 2, 2006, at 1:13 PM, Alex Norman wrote: > > >getEventTypeId needs to be virtual because each "class variable" is > >unique.. > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From alex at neisis.net Sat Dec 2 14:30:56 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 14:31:10 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202222759.GK6029@silverninja.net> References: <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211318.GZ6029@silverninja.net> <20061202222759.GK6029@silverninja.net> Message-ID: <20061202223056.GL6029@silverninja.net> yeah, well I guess you could have both a class type id and an object type id, so you could have a non virtual: getTypeId() and do that thing I keep talking about (that I like) > e->getTypeId() == Midi::NoteOn::cTypeId it just requires an additional variable: mTypeId -Alex On 0, Alex Norman wrote: > if the class id isn't static then you'd have to have an id for each event type > which would mean there would have to be a look up every time you create an > event. it would also mean that there wouldn't be a way to compare against a > class variable because there wouldn't be one :) > > I think that > e->getTypeId() == Midi::NoteOn::cTypeId > is quite nice and easy to understand. > > but there are all kinds of trade offs to think about. > > -Alex > > On 0, Graham Wakefield wrote: > > Oh I see, of course, because the class id is static. > > > > If id wasn't static, but instead set when the event is generated, > > there would be no need for a virtual. > > > > Calls for unit tests I suppose. Ugh. > > > > On Dec 2, 2006, at 1:13 PM, Alex Norman wrote: > > > > >getEventTypeId needs to be virtual because each "class variable" is > > >unique.. > > > > _______________________________________________ > > Tdg mailing list > > Tdg@mat.ucsb.edu > > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg From wakefield at mat.ucsb.edu Sat Dec 2 14:56:50 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 14:57:02 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> Message-ID: <7A114E44-BC4F-43C1-A8BA-E2A080092807@mat.ucsb.edu> I think it's nice for debugging, but not for general use: MidiIn * midiin = new MidiIn(); printf("type of MidiIn: %s\n", typeid(*midiin).name()); --> type of MidiIn: 6MidiIn Where does the 6 come from? How does this help? Also, if we use generic classes and cast to specific classes for functionality, we'll always return the base type using typeid. On Dec 2, 2006, at 1:54 PM, Jorge Castellanos wrote: > > If we only need the type (and not "full" introspection), then it's > easy to get by using the typeid operator. In C++ there's no need to > add any static stuff and complicate subclassing.... > > by calling typeid(*ptr).name you get back the name of the Class. > > Again, this only works for simple introspection where just basic > type info is needed. But it seems that's what we've been talking > about. > > ahh... and it's very fast! > > j > > > On Dec 2, 2006, at 4:47 PM, Rama Hoetzlein wrote: > > > I am >not< suggesting to actual use: > - if ( hash(e->eventType) == hash(EventType::MidiOn) ) // > very slow > > A hash resolves to an int. > So what is the difference between these two? > > - if ( (e->hashedEventType) == > (EventType::MidiOn::hashedEventType) ) // very fast > - if ( e->eventId == EventID::MidiOn ) // very fast > hash ( e->eventType ) == e->eventId > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg > > _______________________________________________ > Tdg mailing list > Tdg@mat.ucsb.edu > http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zydeco.mat.ucsb.edu/pipermail/tdg/attachments/20061202/49cf4d4d/attachment.html From wakefield at mat.ucsb.edu Sat Dec 2 14:59:08 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 14:59:16 2006 Subject: [Tdg] fake introspection/event classes In-Reply-To: <20061202222023.GH6029@silverninja.net> References: <4571F260.6060602@umail.ucsb.edu> <1079b050612021342n3e837f77o22e37f4a2ffce0c5@mail.gmail.com> <4571F455.3000802@umail.ucsb.edu> <6822C309-DDAA-4DB8-BDCB-D4F9C8DEC499@umail.ucsb.edu> <20061202221510.GF6029@silverninja.net> <1079b050612021418t7715924bg1bc418bed9919dd1@mail.gmail.com> <20061202222023.GH6029@silverninja.net> Message-ID: <4D0E8347-F792-405D-A0F9-E45A506D2DD4@mat.ucsb.edu> Yep. On Dec 2, 2006, at 2:20 PM, Alex Norman wrote: > I know the speed gurus aren't going to like a dynamic cast > though we could use this rtti stuff inside the classes to create > their id > numbers. > > -alex From wakefield at mat.ucsb.edu Sat Dec 2 15:11:54 2006 From: wakefield at mat.ucsb.edu (Graham Wakefield) Date: Sat Dec 2 15:12:02 2006 Subject: [Tdg] Ugh In-Reply-To: <20061202222759.GK6029@silverninja.net> References: <20061201154748.GN6029@silverninja.net> <45708950.90000@umail.ucsb.edu> <20061201230504.GU6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211318.GZ6029@silverninja.net> <20061202222759.GK6029@silverninja.net> Message-ID: <664EB5A9-5CCF-4CC6-8EA4-288C98EED503@mat.ucsb.edu> OK, for the sake of Rama's *Ugh*, here's my summary: I prefer to keep runtime efficient (I want to write real-world software using this stuff, and I want it fast). I expect the flow of events to be potentially very high. Core programming style for the Mint user should be our decision, should be relatively simple but should not bend over backwards to the novice. Slower but simpler helper methods for the novice could easily be written over our lower level API if desired. I think potential event class / type clashes are incredibly unlikely; but anyway they should become apparent to the developer as they are writing & testing their app. Extra development time in this rare situation seems far preferable compared to slower runtime. I favor equal structure/memory footprint for events, since it can make memory pools, serialization, remote control etc. a lot simpler. I have no strong opinions at all whether to use fixed array strings, ints, enums, four-char-codes etc. etc. They'll be hidden anyway. I have no particularly strong opinions about coding style (just bear in mind RSI). Oh, and I probably need hash. From wesley.hoke at gmail.com Sat Dec 2 15:17:23 2006 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat Dec 2 15:17:31 2006 Subject: [Tdg] Ugh In-Reply-To: <664EB5A9-5CCF-4CC6-8EA4-288C98EED503@mat.ucsb.edu> References: <20061201154748.GN6029@silverninja.net> <45715397.60207@umail.ucsb.edu> <20061202190847.GX6029@silverninja.net> <1079b050612021113p32aa6e2x1ea446663b5b66f5@mail.gmail.com> <20061202200424.GY6029@silverninja.net> <20061202211318.GZ6029@silverninja.net> <20061202222759.GK6029@silverninja.net> <664EB5A9-5CCF-4CC6-8EA4-288C98EED503@mat.ucsb.edu> Message-ID: <1079b050612021517x13aa525ex9b0cf77178d4b93e@mail.gmail.com> WTF is RSI? wes From alex at neisis.net Sat Dec 2 16:08:50 2006 From: alex at neisis.net (Alex Norman) Date: Sat Dec 2 16:08:59 2006 Subject: [Tdg] Ugh In-Reply-To: <664EB5A9-5CCF-4CC6-8EA4-288C98EED503@mat.ucsb.edu> References: <20061