[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/src header_info.c usiblender.c

[Ed Halley]

To add to Ton's brief blurb, to explain the diff between python and C...

That's because Python does all of the memory management for you.

In C, you have to do the memory management yourself.  You must give a 
size, either for those bytes allocated within a structure, or the size 
sent to allocator routines like malloc(). When you call free(), it has 
kept an internal record of how big that allocated block was.  There are 
re-allocating systems, but it's usually a little cumbersome to write the 
extra calls required to allocate a bigger block.  And those structure 
definitions can't be changed after the code is compiled.

By convention and with a little support from the compiler, C strings end 
with a zero byte.  To find the current length of such a string, you call 
something like strlen() but that actually requires scanning every byte 
in the string to find that terminator.   Your actual strings can be 
shorter than the memory you allocated for those strings.

A length like "160" was common for a maximum path length in Windows in 
the old days, but not for multi-byte characters and complicated mount 
points and modern fifteen-directory-deep source code trees.  Now you 
should probably allow for path strings that are 1000 bytes or even 
longer.  However, when putting those constraints into fixed structures, 
you're now wasting the unused space.  Better to have a pointer in the 
structure which refers to dynamically allocated memory, and then write 
that dynamic block out when saving the structure to disk (sdna, etc.).

In scripting languages like Python, strings have no particular 
terminating character, so the engine must keep the length internally, 
and adjust it on every operation that changes the string, and does all 
the re-allocation stuff for you when you need more space.  Unlike most 
usages of C, that means that the string length and the allocation length 
are kept in sync.  (As an aside, strings don't end with "\n" characters 
in either language.)

Toni Alatalo wrote:
> On Tuesday 30 May 2006 15:22, Ton Roosendaal wrote:
> 
>>I meant *maximum* space for strings... that's the whole problem you
>>know!
> 
> 
> (and here a c-ignorant coder wonders why strings must have a defined max 
> length .. is it because how malloc / sdna / something works - i thought they 
> could just end to \n when they feel like it?, but guess that something needs 
> to know the size
> 
> this seems to work ok in python: 
> In [58]: longstr = 'I am a long string - ' * 1000000
> In [59]: len(longstr)
> Out[59]: 21000000
> 
> but that is of course irrelevant and you can just happily ignore me :)
> 
> 
>>-Ton-
> 
> 
> ~Toni
> 
> 
>>On 30 May, 2006, at 13:38, Jiří Hnídek wrote:
>>
>>>Hi Ton,
>>>why need I store length of string? I can use function strlen(string),
>>>can't I. What should do generic string manipulation library? I guess,
>>>I could write one.
>>>
>>>Jiri
>>>
>>>Ton Roosendaal wrote:
>>>
>>>>Hi,
>>>>
>>>>
>>>>>I'm just rewriting recent open as ListBase and I would like to
>>>>>replace sce[160], lib[160], ima[160] with pointers at char in the
>>>>>future too.
>>>>
>>>>A nice generic string manipulation lib would help too :)
>>>>Using our secured malloc, any malloc can always be verified to return
>>>>the data allocation size, with this call;
>>>>MEM_allocN_len();
>>>>So you don't need to store string lengths.
>>>>-Ton-
>>>
>>>_______________________________________________
>>>Bf-committers mailing list
>>>Bf-committers at projects.blender.org
>>>http://projects.blender.org/mailman/listinfo/bf-committers
>>
>>------------------------------------------------------------------------
>>--
>>Ton Roosendaal  Blender Foundation ton at blender.org
>>http://www.blender.org
>>
>>_______________________________________________
>>Bf-committers mailing list
>>Bf-committers at projects.blender.org
>>http://projects.blender.org/mailman/listinfo/bf-committers
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
> 
> 
> 

-- 
[ e d @ h a l l e y . c c ]