|
MKUser wrote: I think there is something which should be define in preprocessor.
You may well be right. I would be interested to know what it is. It is also worth noting that on some system math exceptions are handled separately. A 'divide by zero' exception may be considered a special floating point exception and be handled by the math library. Check this out if you are using glibc or stdlibc. It's possible that your exception is being handled somewhere but being filtered out before reaching your handler code.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I'm not using stdlib or glib. If if i use them then how should i catch the exception. The problem is i have tried everything to catch the exception but it's not catch.
I also tried to use ObjC/ObjC++ exception and synchronization support but i got error to use them.
Manoj Kumar Chauhan
|
|
|
|
|
MKUser wrote: I'm not using stdlib or glib
That could be the issue. If you use stdlib youd write catch( std::exception ){} and that would catch all the standard library exceptions because they all derive from std::exception. glibc might actually be required for exception handling with GCC C++ compiler to work and this could be the problem. In this case standard C++ exception handling is all you'd need catch(...) syntax might work and I think finally is supported you'd need to check the glibc and GCC docs. ObjC/C++ is an entirely different animal about which I know almost nothing so I won't comment on that except to say that it isn't needed fro C++ exception handling. GCC switches and make settings is where I'd look to enable it but I don't the details on either. I'm just starting to try to get into that myself.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hello,
I am making an application in which i want buffer to store data.
But i dont know what will be the size of the data at run time.
so how can i initialize that buffer?
Right now i am using HeapAlloc, it works fine but the problem is that when i am destroying the Object then also it is not freeing up the memory. It frees memory when i am closing the application.
So, anybody know how can i solve this problem?
Manish Patel
|
|
|
|
|
use the std::string if u r size not defined
|
|
|
|
|
But std::string will end with NULL, but i want NULL as a char in buffer.
Thanks
Manish Patel
|
|
|
|
|
WTF are you talking about ? where have you heard it was about strings ?
|
|
|
|
|
Which kind of objects are you allocating ? Why don't you simply use new and delete ?? That's the most obvious way to go in C++.
|
|
|
|
|
No you understood wrongly.
I am clearing to you.
In my class i am making one buffer and size of that buffer in not known at the time of initialization.
For that i got one solution as a HeapAlloc but now new problem arise is that it will not freeing memory of that buffer even i destroy that object.
It will free it when i am closing the whole Appliaction.
So let me know what is the next Solution from you.
Manish Patel
|
|
|
|
|
Manish_mnp wrote: No you understood wrongly.
No, I think I perfectly understood your question  . But still new and delete is the way to go:
int Size = 10;<br />
char* pBuffer = new char[Size];<br />
<br />
delete[] pBuffer;
Of course, you can change the value of Size at runtime.
EDIT: this works also with datatypes other than char (like int, TCHAR, ...). And you don't have to care about the size of the datatype (e.g. a long is 4 bytes), new will allocate an array large enough to contain the requested number of data, no matter their size.
|
|
|
|
|
Ya i also know it.
Mow im am telling you briefly.
I am developing Server Application.
in this i am acceppting multiple client connections.
I had created one class Client. Whenever new Client arrives one object of client class is created.
Now two more classes are there Input -> Storing Data comes from Client
Output -> Storing Data for sending to Client.
Now in Output, when i am initializing this class i do't have size of the buffer and after that one by one bytes are placed on this buffer so the size is not sure at beginig. It may grows accordingly.
Now tell me how can i do this thing?
Already i am having solution with HeapAlloc but as i said it is not feasible.
Thanks
Manish Patel
|
|
|
|
|
Ok, but there is a difference between a buffer that you know its size only at runtime and a buffer that can grow  .
For your problem, I think the best solution is to include the size of each packet just before sending the data. For example, suppose that you need to send 10 bytes from the client to the server, you first send an integer containing the size of the data (10) and then you send the data. On the other side (server), you first wait for an integer (the size of the packet), then you create your buffer of that size (using new) and you store your data in the buffer and process it. Once it is finished, you destroy the buffer.
I think it is the most 'simple' efficient way (using a container class like a std::string will probably add too much overhead).
|
|
|
|
|
In the class initialization you declare the buffer, WHEN YOU KNOW how large it should be, then use new.
If you need it to grow up, you delete it and use new another time with another size.
Or just use a "LIST" and it will give most of the grow at the fly performance for your self. If you are using MFC take a look into articles SmartList (Simon Huge) and SmartList II (mine).
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Why arent you calling HeapFree, on the pointer that HeapAlloc allocates, in the objects destructor?
|
|
|
|
|
Manish_mnp wrote: But i dont know what will be the size of the data at run time.
Then when do you know the size, after the program exits? 
Manish_mnp wrote: Right now i am using HeapAlloc, it works fine but the problem is that when i am destroying the Object then also it is not freeing up the memory. It frees memory when i am closing the application.
Why are you not using an STL container instead? At this rate, you'll spend a month of Sundays messing around with HeapAlloc(), new, etc, and will likely still have a mess to maintain.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
If the Size of the Data is never known, or unknowable, the problem is unsolvable.
So, assuming that the size of the data is known at some stage, I would work with malloc, realloc and free. If needed, start with a very big buffer. Most protocols have a way of communicating the available buffer size, and give something like ERR_MOREDATA in case of overflow. It will take a littlebit of ingenuity but in principle should not be too difficult to write.
Bram van Kampen
|
|
|
|
|
When does this message get posted is it every time the process that load it the DLL creates a thread or when the thread invokes a fucntions in the DLL
Thankx
|
|
|
|
|
It's not strictly a message but a parameterised call to a DLL entry point. Anyway this is what the docs say.
"The current process is creating a new thread. When this occurs, the system calls the entry-point function of all DLLs currently attached to the process. The call is made in the context of the new thread. DLLs can use this opportunity to initialize a TLS slot for the thread. A thread calling the DLL entry-point function with DLL_PROCESS_ATTACH does not call the DLL entry-point function with DLL_THREAD_ATTACH.
Note that a DLL's entry-point function is called with this value only by threads created after the DLL is loaded by the process. When a DLL is loaded using LoadLibrary, existing threads do not call the entry-point function of the newly loaded DLL."
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
is there any way I can interogate some info regarding the thread that is being created via
DLL_ATTACH_PROCESS
I have many types of threads being created in My process and only want to do processing for
certian types of threads
Would lpreserved parm on DLLMAIN point to on a structure with info about the
newly created thread
Thankx
|
|
|
|
|
When your DLL_ATTACH_PROCESS handler is hit it will always be from the primary application thread so there is no issue there. To get thread info in your DllMain DLL_ATTACH_THREAD handler I'd start with the DWORD GetCurrentThreadId(void); API. Then either use the thread ID to index your own shared data structure (remember to lock it ) or use a well known variable to access the user data passed into your thread function. Most people use this one parameter which gets passed through to a thread start point to pass a data structure for identifying and controlling the thread.
<br />
HANDLE CreateThread(<br />
LPSECURITY_ATTRIBUTES lpThreadAttributes,<br />
SIZE_T dwStackSize,<br />
LPTHREAD_START_ROUTINE lpStartAddress,<br />
LPVOID lpParameter,<br />
DWORD dwCreationFlags,<br />
LPDWORD lpThreadId<br />
);<br />
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
My next question what gets control first the starting function of the createthread API or DLL_ATTACH_THREAD message
I would some how like to intilize/create a control block/structure that the DLL_ATTACH_THREAD message
can introgate and do certin processing based on the value of this structure
|
|
|
|
|
Interesting question, I'm not sure but I guess the DLL Entry point may be called with DLL_ATTACH_THREAD first which will make it difficult to use your thread creation parameter. I suggest you use the C Runtime thread spawning commands documented here[^] and include the C Runtime source in the include directories of your project. Then you can debug the thread startup process and see if there's somewhere you can attached your control object. You may be able to access your thread parameter through the C Runtime before your thread start function is called.
The alternative is to use structures shared between threads, set up the data for the new thread in this structure (list, array or whatever ) before you launch the thread and use synchronisation objects to safely access the shared data from your secondary thread. This kind of arrangement would probably require a singleton thread factory to ensure that only one thread is created and handed off its data at a time. I have seen arrangements like this working in the past in distributed applications.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
And If I have quad core CPU it makes hairer as I need another levle of syncronazation
Thnakx
|
|
|
|
|
I work on some software which needs to be low CPU usage and high performance.. But I find it hard and annoying to use perfmon to find what I need.
I was wondering what tools people use for profiling their applications?
I'd love to find something like "Super Perfmon". Something that let's me watch things, add events to the record, record system events, reporting, etc...
Any clues for some must-have debug tools?
P.S. I heart Process Explorer!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>
|
|
|
|
|
I found one article in the website "optimization your worst enemy", take a look, at the bottom are links to other related articles, they maybe help you.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
