|
Why would somebody want to do this
typedef string AddressLines[4];
It seems logical to do something like
typedef int xint;
|
|
|
|
|
Because this is the syntax for defining a type that is a table.
|
|
|
|
|
tom groezer wrote: Why would somebody want to do this
Because it's Friday.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
my project - a plugin dll.
but i not have master exe source code.
which can tell me how to get which address call my export function, in this way, i can debug easy and catch exception.
Thanks.
|
|
|
|
|
I think if there's no input,you can make a own input,just as the master exe.
Later buggers harm more.
|
|
|
|
|
|
Yes, but if the EXE that loaded your DLL has no associated debug information, you're not going to see anything useful in the call stack window.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
Does anyone have any good examples of C++ code that will sign an XML document without having to use any third party libraries? If so could you please let me know the URL or let me see a copy of the code.
Thanks very much.
|
|
|
|
|
If you are developing on .NET platfrom:
http://msdn2.microsoft.com/en-us/library/system.security.cryptography.xml.signedxml(vs.71).aspx
-- Soyuz
|
|
|
|
|
Hi All,
I have a Multithreaded MFC application having some 210000+ lines of code. The applications works fine almost all the time but I do see rare crashes 
And it occurs only when I am running the application through the IDE or through WinDbg. (The application has been complied using VC++ 2005). The crash has never happened in a Release version, but I am afraid that someday the application will bomb at the critical time.
When the crash happens, the call stack shows that the pointer has corrupted. I am unable to find when and why that pointer has got corrupted. If I insert the breakpoints in the code, the crash never happens, so it is a very dicey situation.
All the thread in the application are created using _beingthreadex API.
Can someone please give me some pointers on how should I detect crash reason?
Please note that since it a proprietary application I will not be able to share the code.
And I am sorry if someone feels that my query is irrelevant, but this issue is really bugging me.
Thanks in Advance
Regards
|
|
|
|
|
|
well said, i agree with you that logging will definitely help thing down...also I assumed our friend is using thread synchronization properly, but it's good you pointed this out....it could be a consumer/produce problem or thread starvation racing issue for all I know!!!
i am sure when our friend get done with this he will be a better analyst for it 
Yours Truly, The One and Only!
|
|
|
|
|
your description of the bug is full of puns like 'give me some pointers' and 'really bugging me' ....lol 
anyways, it sounds like you have a memory corruption problem, there is no easy way to debug this as you said it can happen anytime.
So your first tasks should be to identify reproducible steps,
once you have this you can set your break points at the places where this pointer is getting referenced and see who is doing what.....maybe someone is deleting the memory to the pointer you are trying to access
also does it always crash at the same place, because this will be helpful!
there is nothing wrong with using _beingthreadex infact it's better to use this over the win32 API as _beingthreadex does some extra initialization with the c runtime lib that is not done with the Win32 API
also is your code checking to see that the pointer is not null before using it, etc are you practicing defensive programming techniques thoughout the code or blindly using a passed pointer etc that would result in an access violation and crash your app soon or later!
Yours Truly, The One and Only!
|
|
|
|
|
If he's using a VS debugger it could be that which is causing it to crash... i dont know how debuggers work  but i don't usually trust MS software...
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
no it's not the debugger and it's not MS! I work with both all the time and i can tell you 99.99% of the time it's the code and the developer's fault!
pick up a book or "debugging application" by john robbins if you want to know a bit more about debugging and now debuggers work, rather than perpetuate the misconceptions why not empower yourself???;P
Yours Truly, The One and Only!
|
|
|
|
|
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the number 3
|
|
|
|
|
Crashes in MT apps can be nasty. Check this out: http://www.codeproject.com/debug/XCrashReportPt1.asp. One of the easiest ways to debug this might be to instrument your threads with logging - the thread id, module name, line number, etc. - using __FILE__ and __LINE__.
|
|
|
|
|
Hi All,
Thanks for your valuable inputs. I will follow the suggestions given.
Hopefully I should be able to nail down the crashing issue now.
Regards
|
|
|
|
|
Maybe someone mentioned this, but if you can get it to crash fairly easy, you can then attach the
debugger to the process and work your way back through the call stack (on any thread).
You don't need to be running in the debugger or have breaakpoints set.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the number 3
|
|
|
|
|
good point!
heck even a crash dump will help learn how to take a dump....lol it's potty training time!!! ...brings tears to my eyes, lil-jr is growing up 
you can always load the dump into your debugger of choice and work backward that way too!
Yours Truly, The One and Only!
|
|
|
|
|
I have created a small program that creates a 5 byte TCP packet to a server then the server sends it back. I'm unsure of how the wisock send and recv functions work exactly, does it just poll the connection until there is something in the buffer or is there an interrupt. I'm suppost to setup an interrupt, so any info you know or a good place I could find this info would be great!
Thanks
Simon
|
|
|
|
|
Interrupt handling will happen in the device driver level, not in Winsock or in the transport service provider that implements the TCP/IP protocol.
|
|
|
|
|
Default behavior of send(...) & recv(...) is blocking on the call till requested operation is finished.
Not aware of how this wait is internally implemented.
As an application programmer, I assume that you want to model your application so that it doesn't block on such calls and utilize the CPU cpu cycles for other tasks. If that is correct, you need to explore which I/O strategy we want to use:
http://tangentsoft.net/wskfaq/articles/io-strategies.html
Translating the "interrupt" to be the case where instead of blocking you want the program to be notified when data is there to read,
WSAAsyncSelect() can be an easy path to go as your app/window is notified through message loop.
-- Soyuz
|
|
|
|
|
Thanks for the information helped me alot!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
