Re: [Algorithms] Complexity of new hardware

[Alen L. <ale...@cr...>]

Monday, April 20, 2009, 10:13:12 PM, Adrian wrote:
> Would you mind sharing a field definition that contains that level of
> annotation?  You can see how cluttered our definitions get in my article,
> but I'm having a hard time envisioning it in your syntax.

Here are some examples (from different classes):

  _(1) Ptr<CFlareConfiguration> ep_pfcConfig; _("Flare")  flags(SMF_NONE|SMF_BROWSE|SMF_NEW)
 ....
  _(3) CEditMesh         *msh_pemEdit;       flags(SMF_OWNED|SMF_EDIT|SMF_CLIPBOARDBARRIER)
 ....
  _(6) FLOAT pwp_fMinimumWoundEffectStrength; _("Minimum wound effect strength" min="0.0f" max="1.0f")
...
 _(211) net QuatVect en_qvNetPlacement; context(CTX_ABS_PLACEMENT)
 _(212) net Vector3f en_vNetVelocity; context(CTX_VELOCITY)
...
  meta unreliable compacted client virtual void SetDriveSteerRatioAndLookDir(Vector3f vDriveSteer, Vector3f vLookDirEul);
...
  meta saved cvar ENGINE_API extern FLOAT efx_fFixedEV; _(renoption perdocument version="2")
...
  meta cvar ENGINE_API extern BOOL ren_bDynamicShadows; _("D&ynamic Shadows" renoption)

Note that most members need only some part of the specs, because the
assumed defaults are set to the common denominator. Also, as you can
see, there are different types of tags ranging from keywords, through
preset flags, to completely flexible hint strings.

> The situation I'm trying to describe is this: someone writes a class that
> holds an angle in degrees.  Later they decide it would be more prudent to
> store the value in radians.  They aren't just removing a field, they're
> converting it.

That's an interesting approach. We have very rarely observed this in
practice, so when it happens, we just keep the old field, hide it from
user, and convert in PostRead() meta-function. This means some extra
memory and disk space until we can trim, as you noted below. We could
save disk space by tagging it as load-only-no-saving. But I do like
the idea that this could be removed from memory immediately.

IME for serialization compatibility in 99% cases you need member
removing/adding/retyping members, and changing base classes. So I
stick to the adage: "Simple things should be simple, complex things
should be possible", and in that spirit don't want to write long
declarations for all members just because 1% will need some special
handling. YMMV.

> .field("angle", &MyClass:m_angle)
> [
>         Prop::SaveLoad()
> ]

This reminds me of one thing I was meaning to comment earlier... I
prefer opposite logic to this. If I don't specify anything, I'd
assume save+load would be the default as that's most often used. But
again, some like it terse, some don't. :)

Alen