[Bf-committers] Proposal: rationalize string-length #defines

Brecht Van Lommel brechtvanlommel at pandora.be
Thu Dec 15 12:55:58 CET 2011


I think such defines should be used ideally, but the reason they are
not used in DNA_* structs is that makesdna can't parse them.

Brecht.

On Thu, Dec 15, 2011 at 12:27 PM, Bastien Montagne
<montagne29 at wanadoo.fr> wrote:
> Hi devs!
>
> While working on some improvements to WeightVG modifiers, I stumbled
> upon that: in DNA def of modifier structs, all vgroup and uvmap name
> lengths are literal (32)… Imho, a define would be much better (and much
> easier in case we decide to change it one day). We do have a
> MAX_VGROUP_NAME defined in DNA_object_types.h – but I guess including
> that file into DNA_modifier_types.h just for that wouldn’t be wise.
> Also, the FILE_MAX & co are defined twice, once in BKE, once in DNA…
>
> So here is my proposition: why not gather all those string-length
> defines in one place (e.g. the recent DNA_defs.h, which seems to be
> safely includeable every where) ? After a quick search, this would
> concern at least:
> * FILE_MAX and co
> * MAX_VGROUP_NAME, MAX_STYLE_NAME, MAX_FONT_NAME (and others, like [new]
> MAX_OBJ_NAME, MAX_UVMAP_NAME, etc.)
> * MAX_ID_NAME and MAX_IDPROP_NAME
>
> Also, would we need a MAX_VGROUP_NAME, MAX_OBJ_NAME, MAX_UVMAP_NAME,
> etc., or just define a common MAX_BLDEF_NAME (e.g.), as they all seem
> set to 32 currently?
>
> I’m well aware that this involves many parts of Blender code, and as
> such might need a much deeper knowledge of that code than I currently
> have (even though changes could be made progressively, as values would
> remain the same) – but I really think this should be addressed, for
> sanity of code.
>
> Best regards,
> Bastien.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list