|
If you are using Generic-Text Mappings, learn all the conventions and stick to the rules. Don't mix and match TCHAR with char.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
DealFunc is thirdparty code, can't modify it!
So I ask the wired question!
|
|
|
|
|
VC++6.0
When I call function lstrlenA in kernel32.dll error.
------------------------------------------
typedef long(*Myfun)(long);
Myfun pfun;
HMODULE hMod;
BOOL bRes;
hMod = LoadLibrary("kernel32.dll");
pfun = (Myfun)GetProcAddress(hMod,"lstrlenA");
long t1 = 3434;//example
long t2 = (pfun)(t1);//this is Error !!!
getch();
bRes = FreeLibrary(hMod);
-------------------------------------------
thanks very much.
modified on Friday, August 15, 2008 12:40 AM
|
|
|
|
|
Here is the prototype of lstrlen,
int lstrlen( LPCTSTR lpString
);
Implemented as ANSI and Unicode versions
And lstrlenA can be
int lstrlenA( LPCSTR lpString
);
You should use a string ptr not a long number to use lstrlen!
try this:
CHAR buf[MAX_PATH] = "hello";
lstrlenA(buf);
|
|
|
|
|
phan xuan nguyen wrote: typedef long(*Myfun)(long);
What's this nonsense? You can't just make up you own function prototype and call a function with a different one through it. The prototype for lstrlenA looks as follows (found by searching SDK header files):
int
WINAPI
lstrlenA(
LPCSTR lpString
);
The macro WINAPI specifies the calling convention (on x86 machines this will be __stdcall).
Code like this works fine:
typedef int (WINAPI *p_lstrlenA_t)(LPCSTR lpString);
HMODULE hMod = LoadLibrary("Kernel32.dll");
p_lstrlenA_t pFun = (p_lstrlenA_t)GetProcAddress(hMod, "lstrlenA");
int Length = (*pFun)("Measure me!");
FreeLibrary(hMod);
Steve
|
|
|
|
|
This isnt the normal way to use this function. Include the Header and lib!!! 
Why arent you read the help for lstrlen and think about it instead asking these very primitive questions. 
Greetings from Germany
|
|
|
|
|
Woa! Easy tiger..
How do you
(a) Insert code into a code cave, that calls functions from libraries not used by the original program?
(b) Use code from inside a .dll file that has a different file extension?
(c) Hide the loaded dll from the imports table of an exe file?
(d) Create an exe file protector?
Answer: By using the LoadLibrary & GetProcAddress functions, amongst others.
The point is: None of these are primitive subjects, nor is your post particularly helpful.
If you'd wondered, It was indeed I that gifted you that 1 vote.
|
|
|
|
|
KarstenK wrote: This isnt the normal way to use this function.
True, but that doesn't mean it can't be done. Maybe the OP was just playing around with a concept and this was his attempt at it. Sometimes our examples are not truly indicative of the actual problem.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
|
Considering that the pointer p is NULL sometimes,
which is more efficient:
1. delete p;
2. if (p) delete p;
system
|
|
|
|
|
Test it! 
I'm voting for the second method - slightly more efficient in CPU,
less efficient in code size...just a guess.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Deleting null ptr is legal in C++. The delete operator already does the null checking. Check here - http://www.devx.com/tips/Tip/14443[^]
So the null checking in "if (p) delete p;" is not necessary and obviously its a few clock cycles less efficient than "delete p;".
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
Jijo raj wrote: and obviously its a few clock cycles less efficient than "delete p;".
At first I thought that but upon further thought I've become more cautious about jumping to that conclusion. The if case will generate code something like this:
004010FA 85 C0 test eax,eax
004010FC 74 07 je main+15h (00401105)
004010FE 50 push eax
004010FF E8 A4 20 00 00 call operator delete (004031a8)
00401104 59 pop ecx
In the case where the pointer is NULL the branch at 0x004010FC jumps over the function call and thus avoids its overhead, which could well include growing the stack, cache misses, function prolog and epilogs, etc.
In the case where no explicit if is used the function call is always taken and the if is inside there somewhere.
Depending on how likely it is that the pointer is NULL the version with the if might well be faster; if the pointer is never NULL, or at least unlikely to be NULL, then the version without the if will be faster. Like many things it's not as simple as it first appears.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Depending on how likely it is that the pointer is NULL the version with the if might well be faster.
I agree with that.
Since it's possible to call the delete operator with a NULL pointer I would expect some kind of test on the pointer somewhere down the call chain of the delete operator. Otherwise an access violation would be generated.
This means that if all calls were made with a NULL pointer, the code with the test on the pointer prior to the call would be more efficient since it skips an unnecessary call. And consequently if all calls were made with a valid pointer, the code without the test on the pointer prior to the call would be more efficient since it skips an unnecessary test.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
|
Stephen Hewitt wrote:
Depending on how likely it is that the pointer is NULL the version with the if might well be faster;
You are right. I didn't think about the function calling overheads.  Thanks for the info. Well, now the answer for main question is - "It depends". Isn't it?
Stephen Hewitt wrote: Like many things it's not as simple as it first appears.
Very true!
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
Hi Steve,
I saw your reply to me. My thinking was that doing the
test for null yourself would avoid the function call to the
delete operator. That was the basis of my guess.
The machine code above is for the "if (p) delete p;" case, yes?
Or does the compiler build it that way with just "delete p"?
Sure I can look myself, but you already have
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Read Steve's reply again more carefully Mark. 
You'll find that it's the machine code and assembler for the explicit if-case.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Oh....you mean the "The if case will generate code something like this" part? 
need...more...coffee...
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You've made me think more carefully about this again: the compiler could comply with the standard by generating code for the NULL check at the site of the delete call and not in the function itself. In fact this seems like a good strategy. MSVC6 at least doesn’t (delete without an if check):
004010F7 50 push eax
004010F8 E8 AB 20 00 00 call operator delete (004031a8)
004010FD 83 C4 08 add esp,8
Clearly you were correct when you suggest that the OP should stop guessing and measure.
Steve
|
|
|
|
|
I have installed apache on my home computer
managed to get a connection , works fine with putfile
the following statement:
CInternetFile* pFile = (CInternetFile *)m_pFtpConnection->OpenFile("simon.txt", GENERIC_WRITE, FTP_TRANSFER_TYPE_ASCII);
char buffer [15] = "hello";
char* p = buffer;
pFile->WriteString(p);
/////////////////////////////////
debuged pointed at
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
{
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}
has anybody any idea whats going on?
Thanks Simon
|
|
|
|
|
I have a Wizard created class (CSheet1) for a Excel Database. The class is inserted in the project's View class(CDispatcherView) in CDispatcherView.h this is declared: CSheet1* m_pSheet. In debug m_pSheet has this memory address = 0x00000000 which means it is not available due to no memory assignment(I think). How do I get it to be assigned a memory address. Let me explain something. When I created the project I did so with a MS Access database object which is named CDispatcherSet class and in CDispatcherView.h it is also declared as: CDispatcherSet* m_pSet. It always has a menmory address assigned to it. Why doesn't m_pSheet? They both were created by the wizard to install the databases but only the MS Access database has a "live" database pointer!
A C++ programming language novice, but striving to learn
|
|
|
|
|
I'm no expert  , but you may have to declare it like you would for any new object:
CSheet1* m_pSheet = new CSheet1();
John P.
|
|
|
|
|
Since m_pSheet is a Recordset varable I would have to include a database in the constructor under the CSheet1* m_pSheet = new CSheet1(database); and if that worked I'd now have **m_pSheet(since it is already established as a pointer.Right?
I really don't understand why this happens. The m_pSet has given me no trouble and I loaded the MS Access database with it. Now I want to take the data from m_pSet and put it into the Excel database which m_pSheet is supposed to hold that recordset. I had to do nothing to the m_pSet varable, just use it to load the database. It would seem m_pSheet would act the same since both varables were created with the wizard and I changed nothing.
A C++ programming language novice, but striving to learn
|
|
|
|
|
I have noticed that when a vista theme is active the month calender control always displays in the Segoe font irrelevant of what the dialog font is set to. My program uses Tahoma for all dialogs and I want it to stay that way. If I use a classic theme the theme font is Tahoma and the control displays fine. Using the Aero font it displays with the Segoe font even though the dialog is set to Tahoma! Any ideas on how to force it to the correct font and not the one it feels like?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
