Re: Complexity of new hardware
Alen Ladavac <[email protected]>
| Newsgroups | gmane.games.devel.algorithms |
|---|---|
| Organization | Croteam |
| Message-ID | <[email protected]> |
Adrian wrote at 4/20/2009: >> IME for serialization compatibility in 99% cases you need member >> removing/adding/retyping members, and changing base classes. > Not sure if this was clear, but we don't need the multiple field shenanigans > in the simple cases either. Removing a field without preserving the data is > just a matter of deleting it. Yes, I understood it that way. The comment was aimed at "[Prop::SaveLoad()]", but I covered that better later, so it has become redundant. > forgetting to NOT serialize a field is a silent error that causes no harm > other than inefficiency and consequently will never be caught. I wouldn't consider it a potential to cause any significant inefficiency. In our codebase the temporary (non-serialized) fields are <1% in declarations and even way less in byte count. Btw, there is a large amount of classes that carry reflection info just for convenience of using it for dynamic type handling in the UI (windows, dialogs, etc.), but they are not serialized anyway, so we don't care what's the serialization flag on their members. IME, the largest percentage of file size (across all files in a project) is taken by POD arrays like textures, vertex arrays, etc. YMMV. Alen ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ GDAlgorithms-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list