|
Thanks for the helpful information.
Increasing the hash table size to 5003 was a significant performance improvement over leaving it at the default size of 17 
Any sufficiently gross incompetence is nearly indistinguishable from malice.
|
|
|
|
|
At my work, we have a third party software that we would like to modify to better suit our production needs.
I searched through the third party's DLL and found the function that applies to what we need to modify.
Not sure if its even function hooks I want to deal with...
If it is possible, I would just like to modify the array which the function gets its values from, if not, then I would like to modify a functions parameters.
Anyone know how to do this? or can point me in the right direction? I havent programmed in awhile, but by doing this we can run more efficiently so I think it would be worth it.
Thanks for any help.
|
|
|
|
|
Why the drastic approach of hooking the function calls? Is it not possible to just call the functions differently, or is it not possible for you to recompile the DLL clients? 
--
Based on a True Story
|
|
|
|
|
Sounds like there are 2 things to consider. A) injecting your code into the other process (assuming the 3rd party code is in its own process), and then B) intercepting/hooking the DLL calls.
A) to do this, you can create your own DLL containing the code you want to inject. then set a windows hook, specifying your DLL and the function. windows will then load your DLL into all applicable processes and you can then check to see if its the process of interest, and then proceed to B to intercept the DLL calls
B) intercepting DLL calls in your process is a bit tricky. "Programming Applications for Microsoft Windows" by Jeffrey Richter goes into this in depth and he provides a class which encapsulates all the hard work for you. With his class, its a few lines of code to inject your own function in place of a specified DLL call (could be an OS API, or in your case a 3rd party DLL). your function can do its processing and then call the original using his class as well. I was surprised at how easy it was to do, given his class.
granted, the other option is to go bug the 3rd party and tell them to fix their code  but that wouldn't be nearly as fun!
|
|
|
|
|
I am trying to indicate that class CSentenceAr COULD throw the same object as an exception:
SentenceAr.h
class CSentenceAr
{
...
protected:
bool readFile(char strFileToRead[MAX_SENTENCE_LENGTH + 1]) throw (CSentenceAr);
// #1 (see below)
...
};
SentenceAr.cpp
bool CSentenceAr::readFile(char strFileToRead[MAX_FILENAME_LENGTH])
{
char strLine[MAX_SENTENCE_LENGTH + 1];
fstream fileToRead(strFileToRead,ios::in);
if (ios::good != false)
...
return true;
}
else
{ //Error: file cannot be read
throw (CSentenceAr);
// #2 (see below)
return false;
}
fileToRead.close();
}
#1: \SentenceAr.h(21): warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
#2: \SentenceAr.cpp(43): error C2059: syntax error : ';'
Jon
|
|
|
|
|
jon_80 wrote: bool readFile(char strFileToRead[MAX_SENTENCE_LENGTH + 1]) throw (CSentenceAr);
Shouldn't this be:
bool readFile(char strFileToRead[MAX_SENTENCE_LENGTH + 1]) { throw (CSentenceAr); }
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I meant to declare that the function can throw the exception, doesn't this syntax indicate that this is what the function does?
I tried it anyway just in case and it doesn't compile.
Jon
|
|
|
|
|
jon_80 wrote: I meant to declare that the function can throw the exception, doesn't this syntax indicate that this is what the function does?
Yes, it does. Though, it is not really necessary (it is more for readability than anything else). That said, attaching throw () to the end of a method definition declares that it will NOT throw.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
jon_80 wrote: I meant to declare that the function can throw the exception, doesn't this syntax indicate that this is what the function does?
I've not ever seen throw() used in a class definition like that.
jon_80 wrote: I tried it anyway just in case and it doesn't compile.
My bad. I did not notice that the method already had a body.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: I've not ever seen throw() used in a class definition like that.
You probably have, you just never realized it before. Many of the MFC classes have definitions that use it, but it is hidden behind a #define macro.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: ...but it is hidden behind a #define macro.
I'm looking in afxdb.h at CRecordset::Open() but I don't see any mention of an exception. How is this done?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I'm on a Linux box at the moment, so I can't look it up. However, I do remember CFile having a constructor that throws an exception. If you look at the header file for it, you should see something at the end of the defintion that looks like _THROW() (which is #define'd as throw(...)). There is also a #define for _NOTHROW() (which is #define'd as throw()). The first means the function will throw an exception. The latter means the function cannot throw an exception (you will actually get a compiler error if you throw an exception from a function declared with the throw() directive.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: However, I do remember CFile having a constructor that throws an exception. If you look at the header file for it, you should see something at the end of the defintion that looks like _THROW() (which is #define'd as throw(...)).
From afx.h, I found:
CFile();
CFile(int hFile);
CFile(LPCTSTR lpszFileName, UINT nOpenFlags);
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: CFile(LPCTSTR lpszFileName, UINT nOpenFlags);
That is the one that throws the exception. I thought it had the macro beside it, but it might be on the Open method. Either way, if you search the MFC include directories for _THROW, you should see it.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: That is the one that throws the exception.
True, but I see no way of knowing this without looking at the constructor's implementation.
Zac Howland wrote: I thought it had the macro beside it, but it might be on the Open method.
Neither one. I don't find "throw" in any class definition.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: True, but I see no way of knowing this without looking at the constructor's implementation.
That is in the src directory ... can't remember the filename off the top of my head, but it isn't too difficult to search for.
DavidCrow wrote: Neither one. I don't find "throw" in any class definition.
I know I've seen it in some of the MFC definitions before, but when I do a search on my VS.Net 2003, I find it in the implementation of STL:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(26): #define _THROW0() throw ()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(27): #define _THROW1(x) throw (...)
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(28): #define _THROW(x, y) throw x(y)
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(39): #define _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(40): #define _THROW1(x)
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(41): #define _THROW(x, y) x(y)._Raise()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xtree(592): _THROW(out_of_range, "invalid map/set<T> iterator");
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xtree(913): _THROW(length_error, "map/set<T> too long");
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(866): istreambuf_iterator(streambuf_type *_Sb = 0) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(871): istreambuf_iterator(istream_type& _Istr) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(969): ostreambuf_iterator(streambuf_type *_Sb) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(974): ostreambuf_iterator(ostream_type& _Ostr) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(1003): bool failed() const _THROW0()
Among a host of others.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
jon_80 wrote: bool readFile(char strFileToRead[MAX_SENTENCE_LENGTH + 1]) throw (CSentenceAr);
Microsoft's compiler doesn't distinguish between a specificed throw and a generic one. That is, what you have is equivalent to writing:
bool readFile(char strFileToRead[MAX_SENTENCE_LENTH + 1]) throw (...);
As a side note, you should NOT use the same class you are throwing from as the exception type you are throwing. It would then be possible to end up with an infinite throw problem -- which is very very bad.
Unless you have to define your own exception class for an assignment, you should use the standard exception class, or use MFC's CException class.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Unless you have to define your own exception class for an assignment, you should use the standard exception class, or use MFC's CException class.
Or inherits a class from that. It allows you to add more flexibility.
|
|
|
|
|
True ... forgot to mention that as well. However, you rarely need any more information than what those classes already support, and even the other STL exceptions are mostly just blank classes derived from std::exception.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Oh ic. To be honest I wish I could use MFC, but the syllabus covers basic C++ and we have to abide by it for the major part, because I'm still at the lower end of the learning curve 
MFC has its own exceptions and they resemble so much the exceptions that I'm used to with VB for example.
hehe... I think that if I decide to become a software engineer and use C++, I'll need more than silicone
Jon
|
|
|
|
|
jon_80 wrote: To be honest I wish I could use MFC
Don't be too sure about that. While MFC does have its advantages in the Windows' world, it is virtually useless outside of it. STL is far more portable.
You keep posting code that should be written with STL classes, but you only use part of STL (mainly cin/cout). Don't be afraid of string, vector, and list (along with the rest of the containers and algorithms).
Coming from a VB background will be tough. Basically, try to forget everything VB does for you, because you won't find much of that in C++ -- most of it you will have to do yourself.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
jon_80 wrote:
<code> {
throw (CSentenceAr);
return false;
}</code>
You must throw an instance of class CSentenceAr, not the class name. Change the throw statement to:
throw CSentenceAr();
You must have a working default constructor for this class.
|
|
|
|
|
Would I be throwing a new instance that way? The idea is to throw back the same instance with the invalid data.
Jon
|
|
|
|
|
Dear all,
I have dialog with two buttons(one is for automatic logon and one is for UI logon).
when the user selects the UI logon the new dialog pops up with prompting username and password ,after user enter this data he clicks ok button to enter.
But when press automatic logon ,i modified code to fill the default username and password (in username and password edit box),after this generate IDOK notification ,So that its logs automatically with out UI.
But what i need is to hide this popup dialog(which prompts for username and password ) which comes when user press the automatic logon button( i tried to hide this window by using showwindow(hwnd,SW_HIDE) in WM_INIT notification (case WM_INITIALISE: ) in dialog procedure ,but this window flashs and disappears,Is their any way to HIDE this without showing this dialog to user when he press automatic logon)
Manjunath S
GESL
Bangalore
|
|
|
|
|
It would be cleaner if you could separate the logic of window creation from the logic of user input validation. This way, when automatical logging in, you only call the validation logic, without creating the window.
I assume that you know the difference between instantiating a C++ window object and actually creating a window. If not, I'll explain more.
Best,
Jun
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
