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

Christian Monfort monfort.c at gmail.com
Thu Dec 15 14:20:58 CET 2011


Hi,

I don't know if Joshua is talking about the patch I made some years ago for
Blender 2.45...
Anyway, it is now in the "Todo":
http://projects.blender.org/tracker/?group_id=9&atid=264&func=detail&aid=7889

Christian

Le 15 décembre 2011 12:55, Brecht Van Lommel <brechtvanlommel at pandora.be> a
écrit :

> 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
> _______________________________________________
> 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