[Bf-committers] char* or char[MAX_FILE] in DNA?

[André Susano Pinto]

I think a solution where each time a person adds a "char*" he/she also needs
to change readers/writters is not acceptable.
The idea is that DNA makes it easy to change data structures and that you
won't need to write specialized code for loading/saving.
Each time you a person needs a specific writer/reader they are pretty much
throwing away the reason for having DNA.

The main problem is that a string concept is too common and DNA is
not natively designed to support it (i think).
Though I am not that much inside blender DNA internals (last time I looked
at it was nearly 2 years ago)

So I can see 3 solutions:
1 ) Use [MAX_FILE]
Blender already uses that limit in many other places, so you might as well
be fine using it.
Theres no point in having that limit in all filepaths and being unlimited on
your shader paths.
If someone needs to fix that limit string size, then it should be done
properly and not hacking code for each instance of the problem.

2) Modify DNA so that char* works all the time without needing to
create specific reader/writers.
And be careful with previous code that used "char*", as fair as I know
before "char*" fields where considered to not be saved
and always reseted to NULL after a load. (Eg: Modifier field "char *error;")
Or careful if someone else has specific code for this type of fields.

3) Define a DNA struct for strings, that has specific code for loading and
saving.
and then anyone can use: "String name" if they want their field to be saved
but the specific code is only in 1 place.
This may actually introduce some problems on code that handles DNA structs
and now have to consider a special "string case", but I am not that much
into details on how DNA works.

So since you are not addressing the max-path-limit problem in blender, i
would suggest you stick with 1.
Thats my humble opinion,

André

On 12 May 2010 08:37, Mitchell Stokes <mogurijin at gmail.com> wrote:

> I've written the readers and writers for the situation in which I use the
> pointers. As I said, I have the pointers working correctly, and I can
> easily
> get the fixed arrays working with some commenting. So, implementation isn't
> much of a problem.
>
> Thanks,
> Mitchell Stokes (Moguri)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>