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

Campbell Barton ideasman42 at gmail.com
Thu May 13 13:13:10 CEST 2010


On Thu, May 13, 2010 at 12:34 PM, André Susano Pinto
<andresusanopinto at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

best just use...
 char path[MAX_FILE];

Solving the problem in one place only isn't that great IMHO, people
use images (for eg) many more times then they would use shader files
so if the problem is to be solved it should be done in a way we can
migrate common use cases too.

-- 
- Campbell


More information about the Bf-committers mailing list