RE: Regarding Windows Runtime Libraries, Memory Management, and ICU

[Robert B. <rb...@ma...>]

Great, that's what I was hoping for, and sort of exptected. Thanks for
the info.

Bob

> -----Original Message-----
> From: icu...@ww... 
> [mailto:icu...@ww...] On 
> Behalf Of George Rhoten
> Sent: Tuesday, October 29, 2002 4:50 PM
> To: Robert Buck
> Cc: 'icu4c-support list'
> Subject: Re: Regarding Windows Runtime Libraries, Memory 
> Management, and ICU
> 
> 
> Robert,
> 
> ICU does not use the global new/delete and it uses uprv_malloc in 
> cmemory.c to allocate all memory in ICU.  If you want ICU to use a 
> different memory allocator/deallocator, you can override the 
> functions in 
> cmemory.c.  You may want to take a look at the "Customizable memory 
> management" of the readme.html for more information 
> (http://oss.software.ibm.com/cvs/icu/~checkout~/icu/readme.htm
> l#News). 
> Yes, you should _normally_ be able to use different heaps, if 
> you want to 
> do that.
> 
> Here is an example. You can do this and it will use the ICU new and 
> delete:
> 
> Locale *loc = new Locale("en");
> delete loc;
> 
> or you can use the C style of allocation and free.
> 
> UConverter *ucnv = ucnv_open("UTF-8", &err)
> ucnv_close(ucnv);
> 
> It's usually a good idea to use the provided close functions on 
> non-primitave types instead of free.  For example, you should use 
> ucnv_close, col_close, ubrk_close and other similar close 
> functions to 
> properly clean up the allocated memory from the *_open functions.
> 
> After saying that, I should mention that there are a couple 
> of bugs that 
> prevent you from doing it this way sometimes.  I think 
> TimeZone::createAvailableIDs() is one that is buggy, which 
> requires the 
> private uprv_free() function, but free() should work just as 
> well when 
> you're using the shared C library (not static C library). 
> TimeZone::createAvailableIDs() returns an array of primative 
> types.  I 
> think it's normally okay to mix C runtime libraries, except for those 
> couple of functions, which should be fixed in ICU 2.4 (not 
> released yet).
> 
> I'm not sure which FAQ you are talking about.  Could you tell 
> me where 
> this "Memory Allocation" FAQ is located?
> 
> George Rhoten
> IBM Globalization Center of Competency/ICU  San Jose, CA, USA
> 
> 
> 
> 
> "Robert Buck" <rb...@ma...>
> Sent by: icu...@os...
> 10/29/2002 12:14 PM
> 
>  
>         To:     "'icu4c-support list'" 
> <icu...@os...>
>         cc: 
>         Subject:        Regarding Windows Runtime Libraries, 
> Memory Management, and ICU
> 
>  
> 
> 
> I have a question that regards memory management on Windows.
> 
> In Windows each run-time library has its own allocation 
> routines (malloc, operator new) and deallocation routines 
> (free, operator delete). You cannot call an allocator from 
> one library (for example,
> msvcrt) and deallocate that object in any other library (for 
> example, LIBC.LIB or LIBCMT.LIB).
> 
> Does ICU itself ever 'new' or 'malloc' memory that in some 
> way may be freed by a user directly? Or must the user use the 
> provided cleanup routines in the public API's?
> 
> What I am driving at is this: if ICU does not alloc and leave 
> it up to the users runtime library to delete it, I may safely 
> mix runtime libraries (I can link a debug version of MATLAB 
> against a release version of ICU). I think this is the case 
> with ICU, and just wanted to validate this.
> 
> FYI:
> 
> The section in the FAQ on "Memory Allocation" contains 
> gramatical errors. I have no clue what it is trying to say. 
> Could someone correct it?
> 
> Thanks
> 
> Bob
> 
> _______________________________________________
> icu...@os... - icu4c-support mailing 
> list To Un/Subscribe: 
> http://oss.software.ibm.com/developerworks/oss/mailman/listinf
o/icu4c-support


_______________________________________________
icu...@os... - icu4c-support mailing list To
Un/Subscribe:
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu4c-su
pport