I'm updating my C++ application in to multi thread application in VisualStudio 2013.
In main(), thread's was created by CreateThread()and inside the thread's classA ObjA(); was created & called the function.
In the classA it call another dll method.
Dll was include in to the project through properties->Linker.
Problem was when objA called dll method , application throws access violation reading location.
But without multi-thread it works normal.
Accessing dll method from multi-thread is same way as normal or any other things needed for accessing.
Because the math operations performed by your code result in a NaN?
You cast an integer with at least the relevant most signficant bits set to float or double?
You have a buffer overflow writing such a value to the memory of a float or double?
But I "THINK" even if I do a HeapAlloc for 20 byes it really gets 1K
I don't know if this better than using new
There is a very specific reason for using HeapAlloc and nothing you posted suggests you need that.
And not a good idea to attempt to circumvent C++ compiler allocations unless you have identified a specific need and you understand exactly how allocations work.
If you have some limited need or just want to mess around then you can override allocations for a specific class (one class only) and control it in fine detail. And do so knowing that you are not as likely to mess up the rest of the application doing it.
Alternatively find several open source allocators and heaps and examine how they are implemented first to understand what happens with heaps.
Keep in mind that if you do attempt to control your own allocations you can completely destroy the application (runtime) because you can end up overwriting memory that has nothing to do with what you think it should. So do it very carefully.
The run time has it own heap I think the default heap
Modern OSes generally have at least two allocators. So in C++ the OS provides space to the app and then C++ itself manages that heap with its own allocator. Same is true for Java and C#.
When I create my heap I’m segragting the allocations
Not sure that what that means.
An heap already represents a segregation. The C++ heap (every one I have looked at going back decades) dynamically manages blocks that it requested from the OS. Then on top of that it lays down a simple (or even complex) traditional heap. Then when you use 'new' (presuming you do not otherwise provide an allocator) it uses that existing API to request an amount of space appropriate for usage. Generally the allocation is exact to the structure.
The structure might have padding but that is intrinsic to the structure and not the allocation.
New works well when you now Exactly howvmuch storage you want I.e a object or class
That is not true.
For an object in C++ you must ALWAYS allocate at least as much space is needed for the object. You can allocate more but it will be wasted.
One can force C++ to use space that is less but that would be nothing but bad programming.
In my case I am capturing user input and not quite sure thus HeapReAlloc
All that means is that you are dynamically allocating the space. Which is something that C++ allows directly. You do not need to use a system API method to do that.
As I previously pointed out HeapReAlloc has a specific purpose. And what you just described here is an inappropriate use of that. And one that could lead to resource (memory) starvation if you are not careful how you use it.
If the list box has an owner-drawn style but not the LBS_HASSTRINGS style, this parameter is stored as item data instead of a string. You can send the LB_GETITEMDATA and LB_SETITEMDATA messages to retrieve or modify the item data.
Calling AddString() itself should not raise an exception (provided that the list box window exists) because that just sends the LB_ADDSTRING message. I guess it is happening later when other list box operations are performed.