|
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?
|
|
|
|
|
this is my repeter code
<asp:Repeater ID="rptrr" runat="server">
<HeaderTemplate>
<table>
<tr>
<th>
Language</th>
<th>
Description</th><th>Title</th>
</tr>
</HeaderTemplate>
<ItemTemplate>
<tr>
<td>
<asp:Label runat="server" ID="Label1" Text='<%#DataBinder.Eval(Container, "DataItem.res_Language").ToString() %>' />
</td>
<td>
<asp:Label runat="server" ID="Label2" Text='<%#DataBinder.Eval(Container, "DataItem.res_Description").ToString() %>' />
</td>
<td>
<asp:Label runat="server" ID="Label5" Text='<%#DataBinder.Eval(Container, "DataItem.res_Title").ToString() %>' />
</td>
<td >
<a href="EditResources.aspx?id=<%#DataBinder.Eval(Container, "DataItem.res_ID").ToString() %>">
<asp:Image ID="Image1" runat="server" ImageUrl="~/Images/icon_edit.gif" /></a>
</td>
<td >
<asp:Image ID="Image2" runat="server" ImageUrl="~/Images/icon_delete.gif" />
</td>
</tr>
</ItemTemplate>
<FooterTemplate>
</table>
</FooterTemplate>
</asp:Repeater>
please let me know the code to delete a row from the repeater whn im clicking on the image button "delete"
|
|
|
|
|
That has to be the WORST C++ code I've ever seen.
Oh, wait....maybe you wanted the ASP.NET board[^].
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: That has to be the WORST C++ code I've ever seen.
lol 
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
Hi, In some MFC projects I spend quite a lot of time designing a dialog box and I need it in another project I can copy paste class codes but I have to redesign the dialog resource. I tried to copy a text segment that seemed was about the dialog I was interested in(there were a few lines of empty space then IDD_MY_DIALOG_OF_INTEREST and some text and again some lines of empty space) from .rc file of another project to another project but after that the latter project couldn't load any of its resources until I deleted the inserted segment. Is there any way?
regards ,
|
|
|
|
|
I do it this way
1. Copy the RC file from which you want to reuse the dialog to new Project folder
2. Add the copied rc file to your new project.
3. It will show you warning that there can be only one rc active but just say "ok" on it.
4. Now I just open the resource view and drag the dialogs or resources that you want from copied rc file to the new projects file.
5. After you are done just remove the copied rc file from the project.
I hope it helps. I do this way because i don't have to bother about the formatting in rc file.
Regards,
Sandip.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
