|
what we use to handle exceptions in Macintosh programming (xcodeproject)
b'se try and catch(...) never work for MAC. They never caught any exception
Manoj Kumar Chauhan
|
|
|
|
|
Exception handling is a cooperative effort between the OS, the C Library, code injected at compile time by the compiler and your code. One of these is not doing its job. Your next step probably needs to be to find out which. Make sure that C++ exception handling or SEH or both are enabled in your project, that should take care of the Compiler. Make sure if you need SEH that your OS supports it. Make sure you're using a C Library like MSVCRT that has the necessary support in it for Exception handling and if necessary rebuild it with different options to support your OS and the exception handling you need. If all this is good you should be able to debug the exception handling process itself, at least at the assembler level and get some idea of what is and isn't working. All sort of things like switching off Thread Local Storage support can break exception handling, even mixing code compiled on different Visual Studio versions. If your stack works differently on the MAC then stack unwinding is different, even processor register map differences could in theory break an implementation. EH is still a black art I'm afraid and you may need to get your hands dirty if your root problem is not straight forward. Good Luck 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hi,
my compiler is gcc and environment is xcode
I have enabled c++ exception, c++ runtime type, objective-c exceptions and statics are thread safe. But still the exception is not catch. What is SEH? I did not find it.
Manoj Kumar Chauhan
|
|
|
|
|
I know very little about gcc or and even less about exception handling with gcc or xcode so my advice may not be good. Still I would stick to strict ANSI C++ exception handling rules as that is what gcc is most likely to support. You can forget about SEH (Structured Exception Handling) it's an Operating System exception mechanism which may not be available on the MAC and almost certainly not under gcc.
What will work under gcc pretty much anywhere are Standard Library exceptions. Have a look at std::exception and derived classes to see if you can get any examples to work. If you can get a std::exeception to work you can debug through what it does and see how it uses primary exception handling internally. This should give you what you need even if you can't use std::exception directly. Good luck.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Ok Thanks for this info. I think there is some problem with gcc compiler or some special setting which i dont know. I create a new program just to handle divide by zero exception. In project setting i enabled c/c++ exception. In prepocessor macro following line was written
_APPLE_C_SOURCE _NO_EXCEPTION
it prevents the exception. So i removed this line. Also in my program i add following
#undef _NO_NAMESPACE
#undef _NO_EXCEPTION
#undef _NO_TEMPLATE
But after this exception is not caught. Program is simple like
int main(void)
{
try{
vector<int> a;
a.push_back(1);
a.push_back(2);
vector<int> b;
b.push_back(0);
b.push_back(0);
for(int i = 0; i <a.size();i++)
{
="" if(a[i]="" b[i])
="" a[i]="b[i];
" }
="" catch(...)
="" printf("exception="" caught");
="" }
}
i="" think="" there="" is="" something="" which="" should="" be="" define="" in="" preprocessor.=""
<div="" class="ForumSig">Manoj Kumar Chauhan
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
