Alloc Question

[uosunsetter]

Hello!

I have about 30.000 files and I need to have each file path in memory (something like string array). Since I don't know exact number of files there and how long their paths are, it seems like I will be using GlobalAlloc, VirtualAlloc, HeapAlloc or the other ones that I don't even know...

So my first question is which alloc should I use? I've done some searching and got confused  :toothy

The other question(maybe very noob one) is what should be the logic in my case? My idea is allocating let's say 4kbytes and everytime before I add a file path checking whether the space is enough. If it's not then allocating new space which is n*4kbytes(n is how many times reallocation is done), copy the old array to the new space, free the old one, keep adding.

My last question is about string array. My idea is adding each string to another with null chars between them. Would that cause any problem with StrLen or InString functions included in masm32 lib?

Quick example of that: (Consider # as null char)

abc d#efg hijk#moprs#

If I give address of "a" the StrLen function is going to give me the length from "a" to "d" right? I have checked the StrLen function and it seems to be checking 4 chars at once which made me worry.

Thanks in advance...

[dedndave]

sounds to me like a "dynamic" string array would be a good solution
in the file:
\masm32\help\hlhelp.chm
look in the Macro Catagories section, Dynamic String Arrays

also - use the forum search tool for "arralloc$" to see a few examples

dynamic string arrays are much faster than what it appears you are doing

[jj2007]

This one uses HeapAlloc :wink

include \masm32\MasmBasic\MasmBasic.inc   ; download
   Init
   GetFiles \*.as?
   push eax  ; #files
   SortFiles
   Print Str$("Your puter sorted %i files for you, the latest 5 are:\n", eax)
   For_ ebx=0 To 4
      PrintLine Str$(GfSize(ebx)), Tb$, GfDate$(ebx), Spc2$, GfTime$(ebx), Tb$, Files$(ebx)
   Next
   PrintLine "... and here are the oldest five:"
   pop eax
   lea edx, [eax-5]
   For_ ebx=edx To eax-1
      PrintLine Str$(GfSize(ebx)), Tb$, GfDate$(ebx), Spc2$, GfTime$(ebx), Tb$, Files$(ebx)
   Next
   Exit
end start

Code Select Expand

Your puter sorted 7269 files for you, the latest 5 are:
4377    19.05.2012  20:50:14    \masm32\RichMasm\Ascii2Dword.asm
8515    19.05.2012  20:41:03    \masm32\RichMasm\Ascii2Dword.asc
4067    19.05.2012  20:40:26    \masm32\RichMasm\Res\SkelTimer.asm
8398    19.05.2012  14:12:19    \masm32\MasmBasic\MbHistory.asc
7190    19.05.2012  11:35:47    \ZIP_TEMP\TinyTmp.asm
... and here are the oldest five:
3927    08.09.1992  19:55:36    \masm32\bin\BIN611\MASM611\SAMPLES\WINCLOCK\APPENTRY.ASM
3927    08.09.1992  19:55:36    \masm32\RichMasm\Misc\MASM611\SAMPLES\WINCLOCK\APPENTRY.ASM
3927    08.09.1992  19:55:36    \masm32\bin\BIN611\MASM611\SAMPLES\WINDLL\APPENTRY.ASM
11865   20.11.1987  18:23:48    \WWN\xx_Emu\ST_D\DA_LWU\JAPANPIC.NEU\SHOW_PIC.ASM
9182    20.11.1987  18:23:42    \WWN\xx_Emu\ST_D\DA_LWU\JAPANPIC.NEU\COMPACT.ASM


If you are looking specifically for your sources, modify as follows:

Code Select Expand

GetFiles \*.as?|*.inc|*.rc

[uosunsetter]

Thank you both!! I will try both and test for speed.


PS: jj2007; I really have to say this, great job about MasmBasic! Until now -I dont know why but- I have resisted using MasmBasic. I am convinced now  :toothy It is somehow very fast and very compact yet I have no idea how  :toothy I'm going to check out MasmBasic files to figure out.

[jj2007]

PS: jj2007; I really have to say this, great job about MasmBasic! Until now -I dont know why but- I have resisted using MasmBasic. I am convinced now  :toothy It is somehow very fast and very compact yet I have no idea how  :toothy I'm going to check out MasmBasic files to figure out.

Thanks a lot :thumbu
MB is good because I had many friendly helpers here. For example, the GetFiles macro was very actively discussed in the lowest possible stack address thread. And it certainly has some of the fastest algos that have ever been designed.
There are minor problems, too: First, it is not thread-safe, although there rarely should be problems for typical multi-threaded apps; contact me if you need to know more. Second, it adds about 17k of overhead, mainly for the Dim & strings engine, so you cannot play the classical "I can program a Win32 app in 1024 bytes" game - check the size of this "app":

Code Select Expand

include \masm32\MasmBasic\MasmBasic.inc
Init
Credits
Exit
end start
I haven't updated it for a while, I hope nobody is missing :red

On the other hand, a statement like...
Inkey "The size of ", CL$(0), Str$("\nis only %3f kBytes", Lof(CL$(0))/1024), " and will not change a lot", CrLf$, "if you add more functionality"
... needs 90 bytes of code, for quite a bit of functionality. The editor, RichMasm, is written in MB and has almost 14,000 lines: 83 kBytes, 6 bytes per line, and many of these lines are as complex as the Inkey line above. The overhead quickly loses importance when your apps grow. Just one example:

Print "Line 1", CrLf$, "Line 2"
Print "Line 1", CrLf$, "Line 2"

In "normal" hand-made assembler you would expect six strings in the .data section. See what MasmBasic does:

Code Select Expand

00401063     ³.  68 28704000         push offset ra_lbl2                  ; ASCII "Line 1"
00401068     ³.  6A 01               push 1
0040106A     ³.  68 30704000         push offset ra_lbl3                  ; ASCII "Line 2"
0040106F     ³.  6A 03               push 3
00401071     ³.  E8 04050000         call MbPrint
00401076     ³.  68 28704000         push offset ra_lbl2                  ; ASCII "Line 1"
0040107B     ³.  6A 01               push 1
0040107D     ³.  68 30704000         push offset ra_lbl3                  ; ASCII "Line 2"
00401082     ³.  6A 03               push 3
00401084     ³.  E8 F1040000         call MbPrint

MB reuses the "Line 1" and "Line 2" strings, and instead of a 6-byte push offset TheCrLf it uses a short push 1. Little tricks :wink
Let me know if MB works for you, and PM me if you need help.

[Antariy]

MB is good because I had many friendly helpers here. For example, the GetFiles macro was very actively discussed in the lowest possible stack address thread.

:eek :green2

:U