Index
> Windows > An example of adding multiple strings using HeapReAlloc |
| Author |
|
|
JohnFound 13 Dec 2011, 07:08
If you need extensive string processing, you can see StrLib from the package FreshLib
Besides the big set of functions for dynamic string processing, it also provides portability among different OSes (in this moment Win32 and Linux). |
|||
13 Dec 2011, 07:08 |
|
|
bdo1964 13 Dec 2011, 19:47
but this example is for folks who were interested in writing
their own programming language with strings of unlimited length... in this case {s1,s2,s3} would represent: Code: myStr$ = "" myStr$ + "this is line 1" + chr(13) myStr$ + "this is line 2" + chr(13) myStr$ + "this is line 3" + chr(13) _________________ briano |
|||
|
13 Dec 2011, 19:47 |
|
|
JohnFound 13 Dec 2011, 19:56
Yes, I understand it. But building everything from scratch is not the best thing, if you want to build some complex system.
For example, with StrLib, your example will look like: Code: stdcall StrNew ; create the string stdcall StrCat, eax, s1 ; add line1 stdcall StrCat, eax, s2 ; add line2 stdcall StrCat, eax, s3 ; add line3 |
|||
|
13 Dec 2011, 19:56 |
|
|
bdo1964 15 Dec 2011, 06:04
you make a good point...
if i were writing a compiler... with fasm as the backend... the fact that FreshLib is a portable library would come in handy... and i thank you for your post!!! since i was providing the example for the benefit of others... your comments about the existence of FreshLib... will provide folks with additional information... it looks like you have done a lot of work! _________________ briano |
|||
|
15 Dec 2011, 06:04 |
|
|
f0dder 15 Dec 2011, 17:19
1) keep in mind that HeapReAlloc might not always be able to reallocate in place - your code doesn't handle this.
2) memory (re)allocation is expensive, it's much better to over-allocate and avoid calls to the heap manager. 3) NUL terminated strings are, for a lot of use cases, pretty darn slow. |
|||
|
15 Dec 2011, 17:19 |
|
|
AsmGuru62 15 Dec 2011, 17:33
The good way is a string pool, where there is a vector of string pointers and every string is a small structure where the room for string buffer and its real length are stored. Also, as f0dder mentioned reallocate string by chunks of say, 32 characlers in size or even double the room in each reallocation. This will save a lot of CPU cycles during concatenation. Put all the allocations into one heap, so when destroying that whole pool - no need to call HeapFree thousands of times, just call HeapDestroy once. Very fast! I used it for my code parser in IDE. The fact that each string has a length allows for quick searching of needed string, because code skips all strings which are not of the specified length.
|
|||
|
15 Dec 2011, 17:33 |
|
|
revolution 15 Dec 2011, 17:38
f0dder wrote: 2) memory (re)allocation is expensive, it's much better to over-allocate and avoid calls to the heap manager. f0dder wrote: 3) NUL terminated strings are, for a lot of use cases, pretty darn slow. f0dder wrote: 1) keep in mind that HeapReAlloc might not always be able to reallocate in place - your code doesn't handle this. |
|||
|
15 Dec 2011, 17:38 |
|
|
revolution 15 Dec 2011, 17:43
AsmGuru62 wrote: The good way is a string pool, ... AsmGuru62 wrote: ... where there is a vector of string pointers and every string is a small structure where the room for string buffer and its real length are stored. Also, as f0dder mentioned reallocate string by chunks of say, 32 characlers in size or even double the room in each reallocation. This will save a lot of CPU cycles during concatenation. Put all the allocations into one heap, so when destroying that whole pool - no need to call HeapFree thousands of times, just call HeapDestroy once. AsmGuru62 wrote: Very fast! Last edited by revolution on 15 Dec 2011, 17:56; edited 1 time in total |
|||
|
15 Dec 2011, 17:43 |
|
|
AsmGuru62 15 Dec 2011, 17:52
For me speed was the most important.
|
|||
|
15 Dec 2011, 17:52 |
|
|
f0dder 15 Dec 2011, 18:05
revolution: very valid points - the first post does mention simplicity, but the OP's next post also mentions "writing their own programming language", so...
Btw, dynamically reallocating strings isn't always the best solution, either - consider situations with multithreaded code where strings are used from multiple threads... you'll end up needing copy-on-write and performance-killing mutexing. Immutable strings are interesting in those scenarios, but you pretty much need garbage collection for that to work well enough, and that brings in it's own set of problems. There's no silver bullet |
|||
|
15 Dec 2011, 18:05 |
|
|
revolution 15 Dec 2011, 18:33
f0dder wrote: Btw, dynamically reallocating strings isn't always the best solution, either ... f0dder wrote: ... - consider situations with multithreaded code where strings are used from multiple threads... you'll end up needing copy-on-write and performance-killing mutexing. |
|||
|
15 Dec 2011, 18:33 |
|
|
bdo1964 16 Dec 2011, 03:12
i am absolutely blown away by these responses!
thank you all very much! in the case that the parser was to encounter: Code: myStr$ = "" myStr$ + "this is line 1" + chr(13) myStr$ + "this is line 2" + chr(13) myStr$ + "this is line 3" + chr(13) dynamically reallocating strings would not be necessary... Code: s_myStr: db "this is line 1" ,13 db "this is line 2" ,13 db "this is line 3" ,13 db 0 e_myStr: nor would NULL terminated strings be required... Code:
mov ecx,e_myStr-s_myStr
dec ecx
obviously we have no exception handling... STATUS_NO_MEMORY The allocation attempt failed because of a lackof available memory or heap corruption. STATUS_ACCESS_VIOLATION The allocation attempt failed because of heap corruptionor improper function parameters. so how about some input regarding: passing strings in and out of MS COFF object files assembled via fasm???? |
|||
|
16 Dec 2011, 03:12 |
|
< Last Thread | Next Thread > |
Forum Rules:
|