lots of structs

[ecube]

the code below is my attempt at using an array of structs for a mini chat server i'm writing. I want szUsers to point to a USER struct filled with info for each user, the only problem is if I have it say point to 1000 user structs ml.exe 100% cpu during build for about 2-3 mins then finally builds it. My question is how do I go about do this a better way? I thought about heapalloc but that seems really unpractical as it allocates just 1 lump of memory.

Code Select Expand


.data?
USER struct
  szName                  byte 64 dup (?)
  szEhand                  byte 64 dup (?)
  szStatus                  byte 64 dup (?)
USER ends



szUSERS      USER <>
                  USER <>
                  USER <> ;this continued 1000 times or so


[ramguru]

Why not use it in this form?

Code Select Expand


USER struct
  szName   byte 64 dup (?)
  szEhand  byte 64 dup (?)
  szStatus byte 64 dup (?)
USER ends

.data?
szUser USER 1000 dup (<>)



[ecube]

Why not use it in this form?

Code Select Expand


USER struct
  szName   byte 64 dup (?)
  szEhand  byte 64 dup (?)
  szStatus byte 64 dup (?)
USER ends

.data?
szUser USER 1000 dup (<>)



Thanks that is a lot more efficient but whats your thoughts on ml maxing out cpu and the long time to build? Nevermind I think during testing i'll set the user count to a small number and once I feel it's time to test with more users i'll just increase it, thanks for your help ramguru

[ramguru]

Thanks that is a lot more efficient but whats your thoughts on ml maxing out cpu and the long time to build?

I think 1000 lines of code just in .data section should require a much longer compilation time than one, though not that long as 2-3 minutes.
P.S. BTW I had also written chat_server+client, very basic one  :bg .

[u]

I thought about heapalloc but that seems really unpractical as it allocates just 1 lump of memory.

Impractical?? Dynamic allocation and keeping pointers into a vector (resizable array) is the way to go.
ml.exe has practically screamed to you that the approach you tried is bad  :naughty: . What happens if you make 1000 USER vars, and the 1001st user comes :) ?

[Tedd]

..... I thought about heapalloc but that seems really unpractical as it allocates just 1 lump of memory.

Code Select Expand


.data?
szUSERS      USER <>
                  USER <>
                  USER <> ;this continued 1000 times or so


But that's exactly what you're doing anyway! Placing all of these structures in the data? section just causes the whole 'lump' to be allocated on the stack when your program is loaded.
For any structure larger than, say, 512 bytes, I would definitely suggest dynamically allocating it, rather than placing it in a data/data? section.
This also gives you the option of only allocating half (or even a quarter) that amount, and then you can re-allocate if the need arises (which will be unlikely - you're only allocating 1000 as a maximum possible number of users, so it's a limit you never expect to use.)
Decide on what will be a realistic average number of users, add another 50% just to be sure, and then use that number as the first allocation. If you do reach that limit at some point, simply double the size and re-allocate (this also means that if you do also reach THAT limit, you're already set up to double and re-allocate again, so you don't actually have a limit problem.)

[ecube]

I thought about heapalloc but that seems really unpractical as it allocates just 1 lump of memory.

Impractical?? Dynamic allocation and keeping pointers into a vector (resizable array) is the way to go.
ml.exe has practically screamed to you that the approach you tried is bad  :naughty: . What happens if you make 1000 USER vars, and the 1001st user comes :) ?

heh I suppose so  :bg for users though I would have limited connections so it wouldn't of gone over 1000. In any case since you and Tedd both agree dynamic memory allocation is the way to go, I'll try it out. My original reasoning for not using heapalloc was I thought it'd be difficult to work with structs in 1 block of memory but I found some code Donkey wrote that does similiar, and realized how silly my approach was after you guys explained why  :U so thanks gentlemen.