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

[Christian Monfort]

+1

That was my 1st idea, but keep in mind that preprocessing does not solve
all cases:

#define STR_SIZE 32
char* s1[STR_SIZE];
char* s2[STR_SIZE*2];
char *s3[STR_SIZE+2];

will preprocess to:

char* s1[32];
char* s2[32*2];
char *s3[32 +2];

which was not handled by makesdna (at least the last time I worked on this,
that is Blender 2.4x) for s2 and s3.


Le 17 décembre 2011 20:16, Bastien Montagne <montagne29 at wanadoo.fr> a écrit
:

> I just made some (really quick) tests with cpp (gcc's preprocessor),
> and with the -P -D DNA_DEPRECATED_ALLOW options, generated files seem
> to work just fine with makesdna.
>
> The drawback of preprocessing is that it does the includes, so a few
> structs are defined in every DNA_foo.h preprocessed file – but I don't
> think this is a real problem, it just adds a (really small) overhead to
> the building process.
>
> So if we can get a similar result with msvc, we could just add an
> additional build step to generate those preprocessed DNA files, before
> running makesdna – and enjoy a full preprocessing for dna files…
>
> Le samedi 17 décembre 2011 18:18:56, Bastien Montagne a écrit :
> > About makesdna not being able of interpreting #defines, why not simply
> > use a C preprocessor over all DNA_foo.h files, before giving them to
> > makesdna ? GCC, MSVC, etc. already have coded that, why trying to
> > re-implement a (highly limited) version for makesdna…
> >
> > Just an idea, maybe I’m again missing something important! ;)
> >
> > Le jeudi 15 décembre 2011 16:39:06, Bastien Montagne a écrit :
> >> 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 :
> >>> 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
> >>>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > 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
>