Hi, all in one ;-).
On Sat, 2007-05-26 at 10:58 -0500, Daniel E. Shipton wrote: > Excuse the top posting.. > > I think that a better option would be to get rid of all the legacy > code for 2.0. Having just finished a big project that was using 2.0 I > can tell you that trying to make your old 1.x code work with 2.0 is a > huge pain...and frankly not worth the hassle. Ideally yes, but it can be a similar pain to track changes on the 1.x branch of an active project while preparing 2.x if the port is more complicated than just switching names. Especially if you want to use this active project to verify 2.x. On Sat, 2007-05-26 at 15:46 +0200, Carsten Neumann wrote: > Hi Gerrit, > So for a user that defines OSG_1_COMPAT there would be no additional > changes required when porting to 2 and performance would be same (poor) > as without the change. not quite. Usually the app is much more limited and targeted in its access patterns. OpenSG internally does access a lot more during the rendering and commit calls. And OpenSG is more likely to access variables that trigger costly operations (e.g recaching of textures or geometry). So getting rid of those is already a big advantage. On Sun, 2007-05-27 at 19:06 -0500, Dirk Reiners wrote: > Hi Gerrit, > Carsten Neumann wrote: > > Hi Gerrit, > > > >Following, yes? > > > > readFoo() const; > > editFoo(); > > > > #ifdef OSG_1_COMPAT > > getFoo() const; > > getFoo(); > > #endif > > ... in addition to > > setFoo(); > > which is why I'm not excited about the change, as it would kill the get/set > parallelism. Besides that, read is longer than get. So an alternative would > be: yup 1 character but the same length as edit ;-) > 3) replace getFoo() with foo() (no verb), which is similar to Performer (just > the other way around) and avoids the length problem. fine with me too. > I've been playing with it a little bit, and it seems at least g++ is not very > smart about picking the right version, unless the object is const it always > picks the non-const method. :( So besides going through the source tree with > a > fine-toothed comb to make sure absolutely everything that can be const is > const > that won't help us. It wouldn't hurt to be more diligent about const in > general, > but I don't know if we want to tackle this right now. I for sure don't want to this ;-). One problem you face is that once you jump pointers it really gets ugly. > The problem arises because by default we return references to everything, to > avoid copying large object types needlessly. However, most of our types are > small enough that it's not a big deal to create copies (mostly built-in types > or > FCPtr). Personally I have never used the ability to change the value using > the > reference passed by get(), so I wouldn't mind going for this one: > > 4) Remove getFoo();, only keep getFoo() const. This would bomb with (some) > old > code. I'm not sure with how much old code, but I think very little. Inside OpenSG no code at all, outside quite some. The main problem is not so much the code change. As said above, tracking diverging 1.x and 2.x branches is the really painful part. I tried that one already on a non trivial code base and it wasn't that much fun ;-). But what I haven't tried is to isolate the getFoo part from the other OSG_1_COMPAT elements. Let me try this and see if the impact of not having a changing get is small enough so we don't need it. That would be the best solution, don't know why I missed it earlier ;-) regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
