Your memory will obvouisly grow when working with data since all this memory is most likely read into the memory, so nothing strange there in my opinion. However you are loading 50.000! items in a list and that is a bad practise for several reasons:
1) Performance, it slows down the application because it has to load 50000 items at once
2) Usability, A user will not be happy scrolling through 50.000 items. Give them filtering and paging
3) Memory, 50.000 items can consume a lot of memory.
So my suggestion: Limit the amount of data by implementing paging (somewhere between 20 and 50 items each time) and filtering.
Your argument is valid in principle, but you shouldn't base your it on the assumption that this list is actually being displayed to a user - there is no mention of such a thing. In fact there may be no UI involved at all.
The only issue we know of so far is memory consumption. Paging is a solution, but whether a page should hold 20 or 20000 items depends on the actual problem.
If you are using your own implementation of a list then we obviously cannot say what it does. I will therefore assume that you are using an existing implementation, such as std::list (you didn't say!).
Every time you insert an item into a list, a new list node will be allocated. This node - depending on te actual implementation - will at least contain one or, more likely, two pointers that are required to maintain the links to the remainder of the list, and the actual data. So, even if your list only holds short values, each node might in fact take 10 bytes (2*sizeof (pointer_type) + 2) to allocate 50 thousand items thus will require half a million bytes of memory.
If your list items are large, requiring 1000 bytes each to store, then each node will be 1000+2*sizeof(pointer_type) in size, and the whole list will require 500 MB of storage.
If your list maintains large objects and you've decided to store them elsewhere you might want to only stor epointers to these items in your list, but even then each list node will store three pointers: two to maintain the list, and one to point to the actual data. On a 32 bit system that would be 12 bytes, or 600 thousand bytes for a list of 50 thousand items.
In short, you're storing information in memory, a lot of it - why are you surprised this takes up memory?
P.S.: according to your question the list takes up more memory than you are comfortable with. This begs some questions:
1. How much memory do you have available (i. e. what does the target system provide)?
2. How large is each indivuidual item?
3. Are these items stored redundantly, i. e. are they being held in several lists at once, or in other sorts of containers?
4. Where do you get the data from (files, media streams, internet, other applications)?
5. Would it be possible to store just one or a few items, process them and store away the results?
6. Have you considered compressing the data - either each node individually, or by storing only the differences to previous items?
I have just tested this and it works OK. You need to ensure that your bitmap is the same size or smaller than your button. Also if you need to show both bitmap and text, then you must ensure that your bitmap is small enough to leave space for the text.
I've been working with some code that uses a TCP connection for the past few weeks. I have a socket class derived from CAsyncSocket.
Everything works fine initially. I instantiate my manager class which wraps around the socket class and calls connect (via a member pointer to the socket class). I am then able to send a receive data. The problem comes when there is a socket error. For a currently unknown reason, part of my code is causing a socket error. I have yet to find where this is happening but the problem forced me to test out the part of my code which shoudl attempt to recover the connection. It doesn't work, and I can't get things going.
I have overriden OnClose, which calls a method on the manager class (its parent) called OnSocketClose. This calls socket.shutdown(), socket.close() and 'delete socket'. It then sets the pointer to 0. From here, the next time I attempt to send anything down the socket it looks for the socket pointer == 0, to indicate that it should create a pointer to a new socket.
This new socket is created but fails to connect. I have got it to appear connected on a couple of occasions by moving things around but OnConnect doesn't seem to get called and I am unable to send data. The returned value from socket.connect however reports that the socket is already connected if I call socket.connect again, after a short period of time from the first call to connect (socket error 10056).
Apologies if this sounds a little confusing, but I think I have managed to confuse myself... massively
If it will help, I can post code? Just let me know which parts you need to see.
Thankfully, I have managed to solve this issue so thought I would post the solution in the hope that it might help someone else with the same problem.
The problem (rather annoyingly) came because the socket was being created initially on the main thread, but was later being created again (after the socket was destroyed because of a connection error) on a worker thread. This meant that the On* callbacks weren't being implemented, and so I got no feedback from OnConnect and didn't receive any data because OnReceive was never being called.
As soon as I managed the socket entirely from the main thread, everything was fixed