|
#include <atlconv.h>
TCHAR szBuf[MAX_PATH] = _T("buf");
USES_CONVERSION;
DealFunc( T2A( szBuf ));
T2A/W2A converts from unicode to ansi and T2W/A2W converts from ansi to unicode.
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
modified on Friday, August 15, 2008 2:25 AM
|
|
|
|
|
You would really recommend him to do something like that? I thought one must either stick to generic text mappings, or NOT. But that's my opinion. 
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
Rajesh R Subramanian wrote: You would really recommend him to do something like that?
Reason being that it might be a external library API which he cannot modify and just in case if he can modify the prototype of this function then the parameter should be changed to TCHAR form.
Nibu babu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http://nibuthomas.wordpress.com
|
|
|
|
|
Nibu babu thomas wrote: just in case if he can modify the prototype of this function then the parameter should be changed to TCHAR form.
Exactly!
But I agree, it has happened to me more than once that I have to write sub standard code, only because then it would work with some existing component or framework, whose source is closed to me. I hate it. 
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
The right way is to make your DealFunc(TCHAR *pStr);
so you are independent to what TCHAR expands. Everything else is a bad barter.
Believe me: I am actually changing a lot of my code because I need it to be Unicode compatible.
Greetings from Germany
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
