| 00:44.49 | *** join/#bzflag hilmy (~hilmy@156.223.127.140) |
| 01:24.32 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 02:23.59 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 02:25.43 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 09:02.20 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 09:03.56 | *** join/#bzflag dngor_ (abuse@c-50-143-65-84.hsd1.fl.comcast.net) |
| 09:05.24 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 10:14.47 | *** join/#bzflag jnoob22 (~jnoob@c-24-8-43-250.hsd1.co.comcast.net) |
| 10:14.47 | *** join/#bzflag jnoob22 (~jnoob@unaffiliated/jnoob22) |
| 13:35.37 | *** join/#bzflag nitroxis (n@6.nxs.re) |
| 16:20.49 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 16:24.49 | Notify | 03BZFlag:Zehra * 9460 /HiddenAdmin: redirected page as plug-in was replaced by putting "hideAdmin" in the group perm files on a config for a server |
| 16:46.21 | Notify | 03BZFlag:Zehra * 9461 /BZFS_2.4_Upgrade: added category |
| 17:25.33 | macsforme | there seem to be many ways to set up objects that need to be accessed by multiple other objects in C++... singletons, globals, storing the object address in a pointer... are there guidelines for which techniques fit certain use cases better than others? |
| 17:28.24 | macsforme | I'm trying to have memory management be as automatic as possible (taken care of by the scope, where possible)... another factor is that since there is a GL context involved, certain initialization/instantiation and destruction has to happen in a certain order |
| 17:35.38 | DTRemenak | we're c++11 now, right? so, avoid globals, and avoid raw pointers. singletons are appropriate when you need exactly one object for the entire system, accessible from multiple objects. otherwise use unique_ptr for single-ownership, shared_ptr/weak_ptr for multiple-ownership. |
| 17:36.15 | macsforme | I know you can do some initialization outside of the constructor, but I'm looking for as clean/automatic of a design as possible... and I know you can use static/class functions as well, but the lack of construction/destruction makes it seem like you have less control over initialization (unless you use other class methods specifically for that) |
| 17:38.52 | DTRemenak | singletons can be lazy-initialized. smart_ptr/unique_ptr initialization is controlled by the calling code, destruction is automatic on scope loss. |
| 17:39.24 | DTRemenak | the only case that you have no control over initialization is globals. and you shouldn't use them. |
| 17:41.36 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 17:45.12 | macsforme | lazy-initialized as in initializing itself the first time it's used? |
| 17:46.21 | blast007 | yeah, your 'getInstance' method would check if it has been initialized yet and if not it does it |
| 18:12.20 | macsforme | so then if there is cleanup that has to occur in a singleton (other than memory release; for example, shader program deletion), it seems that you would have to do that manually since the singleton destructor wouldn't be called until the program exits... at which point the GL context has already been destroyed |
| 18:13.43 | macsforme | I realize that the program exiting will kind of clean things up by force, but I'm trying to write a clean design |
| 20:02.32 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 22:19.48 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 22:39.50 | JeffM | macsforme: yes, you'd want a "dispose" method or something that is called by the context. |
| 23:43.39 | *** join/#bzflag nitroxis (n@6.nxs.re) |
| 23:56.55 | BulletCatcher | We're still limiting ourselves to c++0x rather than full c++11. |
| 23:56.58 | BulletCatcher | I see a hack in src/bzfs/ShotManager.h for shared_ptr support, but other newfangled features may not work everywhere. |
| 23:58.01 | BulletCatcher | I don't recall which system we want(ed) to support that has c++0x but not c++11. |