[Bf-committers] Proposal: rationalize string-length #defines
montagne29 at wanadoo.fr
Thu Dec 15 16:39:06 CET 2011
Ah, so this is the why of this situation… I see the situation is even
more complex than what I thought. Ugly dummy DNA! :P
Le jeudi 15 décembre 2011 14:20:58, Christian Monfort a écrit :
> 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":
> 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.
>> 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,
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers