|
Is your code compiling?? and put a debug point at
Flaviu2 wrote: lpszString = lpszStringInit;
and see if the value is getting pased
Every new day is another chance to change your life.
|
|
|
|
|
In most of cases, but I meet a situation that in lpszString I have bugs ...
|
|
|
|
|
|
|
|
Syntactically it's correct. Semantically however... only you can say if it is.
What you are doing there is take a pointer to a string and copy it to another pointer. Now both pointers point to the same string. This may be ok, but what if the argument passed to this function was a temporary object and is deleted later? In that case the pointer lpszString in your class will be invalid! Or, even worse, if the string later gets changed somewhere, this will effect your ItemData struct as well! Do you want that?
Advice: Unless you are totally certain no one else but you will ever use this struct ItemData and potentially use it in the way described above, you should take precautions against that: instead of just copying the pointers, you should copy the entire string! Of course, if you do that you should also delete that string in your destructor. It should be roughly like this (didn't actually try it out):
CMyControl::ItemData::ItemData(LPCTSTR lpszStringInit)
{
if (lpszStringInit != 0 {
std::size_t length = _tcslen(lpszStringInit);
lpszString = new TCHAR[length+1];
_tcscpy(lpszString, lpszStringInit);
}
else {
lpszString = 0;
}
}
CMyControl::ItemData::~ItemData() {
delete [] lpszString;
}
Now you're sure your ItemData object contains it's own copy that cannot be changed or deleted from the outside, no matter who uses this struct. And you know this copy will be deleted exactly when the ItemData object gets deleted. so there will be no memory leaks caused by your struct.
|
|
|
|
|
Thank you all. But what it would be if I use an CString variable instead of LPSTR lpszString ? It would more easy ?
|
|
|
|
|
Yes, if your internal variable is of type CString, then, assigning another CString value to it (or even a LPCTSTR) will automatically do the copying of the string for you, and you don't need to take extra care for releasing it either. That is what string classes are good for.
|
|
|
|
|
I searched for hours, but everything was C# or C++ mfc.
I created a button, using CreateWindow, I found it on a tutorial site on how to make window controls, but there no example on how to handle the click.
So I wrote this, am I missing something like a SendMessage to register the button?
HWND bt_IIS_Install;
bt_IIS_Exit = CreateWindow(L"button", L"Exit", WS_CHILD,
winWidth / 2 - 200,
winHeight - 90,
180, 32, h_IIS_Install_Client, NULL, GetModuleHandle(NULL), 0
);
ShowWindow( bt_IIS_Exit, SW_SHOW);
I found this, that handles a dialog response, so I'm guessing that this is how I capture the button clicks, but I need to assign the defintion to the button.
case WM_COMMAND:
if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
{
}
break;
Am I on the right track here?
|
|
|
|
|
You should use the hMenu parameter to specify the control id of your button (IDOK or IDCANCEL in your case)
From MSDN:
hMenu [in, optional]
A handle to a menu, or specifies a child-window identifier depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used. For a child window, hMenu specifies the child-window identifier, an integer value used by a dialog box control to notify its parent about events. The application determines the child-window identifier; it must be unique for all child windows with the same parent window.
|
|
|
|
|
Thanks for the quick response, who works on Sunday.
I understand, I just need to turn the gears awhile to produce something that works.
|
|
|
|
|
Well that took awhile to figure out. I created a menu in my resource file, and assigned the number to it in the other resource file. Then added the single hMenu item to the create window so WM_COMMAND can pick it up as the wParam. Thanks for the pointer to the huge lesson that I really learned from.
HWND bt_IIS_Install;
bt_IIS_Exit = CreateWindow(L"BUTTON", L"Exit", WS_CHILD,
winWidth / 2 - 200,
winHeight - 90,
180, 32, hIIS_Install, (HMENU)IDC_IIS_WS_EXIT, GetModuleHandle(NULL), 0
);
ShowWindow( bt_IIS_Exit, SW_SHOW);
|
|
|
|
|
I did this in one of my articles - Mousey! Roll Over and Park[^]
The settings dialog and all its controls are created using CreateWindow.
|
|
|
|
|
Great article. So does that mean that I created my buttons correctly?
Writing an app in c++ has been my goal for a long time. Finally had a reason to pursue the next step. I don't want to put anymore visual basic programs out there any more, too much trouble to package and deploy them. I've got this nice eCommerce program, but I can't anybody to use it because it's not super easy to setup and deploy. So this program will make it easier to start using it. The goal is to use a windows program install the web server, create the default web site, import database, create email templates and so forth.
Thanks for looking at my post!
jkirkerx
|
|
|
|
|
I deleted and rebuild both CLW and NCB files.
After rebuild , I have CLW but no NCB file and still cannot add variable in Class wizard.
Added manually and get run time error when variable is used.
This is common and usually works, but not this time.
What did I missed?
Please no "upgrade to X " suggestions.
Any constructive help will be appreciated.
Vaclav
|
|
|
|
|
Found it - Class Wizard disables the add because the class in not checked out in Source Safe.
But it is stupid enough not to say anything about it.
So much for products compatibility.
Thanks MS.
|
|
|
|
|
In the VS IDE (C/C++ Optimization), I usually set these optimizations for Release builds:
Optimization: Maximize Speed (/O2)
Inline Function Expansion: Any suitable (/Ob2)
Enable Intrinsic Functions: Yes (/Oi)
Favor Size or Speed: Favor Fast Code (/Ot)
Omit Frame Pointers: No
Enable Fiber-safe Optimizations: No
Whole Program Optimization: No
What settings do you use?
Has anyone had any good/bad experiences with these settings?
Have you found any helpful blogs as to which settings to use?
|
|
|
|
|
Hans Dietrich wrote: Whole Program Optimization: No
Why do you have this option set to "No"?
Steve
|
|
|
|
|
Mainly due to personal experience. I was trying to track down an intermittent crash that seemingly moved from one area of the app to another. A co-worker suggested removing /GL because it had caused him a similar problem. At this point I was grabbing for anything, so I removed /GL, and that was the last I saw of that crash. I wish I had a better justification, but I don't. There didn't seem to be any noticeable speed slowdown when /GL was removed, so I didn't pursue it.
|
|
|
|
|
I would suggest you save the PDB files generated by the compiler and also save the crash dump after the crash.
You could then debug and get to the root cause of the crash.
|
|
|
|
|
In the kernel I like to turn them all off. That way you get exactly the code you wanted. I have had optimisations take out bits of code I intended to be in their (particulary dead loop timing stuff. Yes, the windows timer has NOT got a low enough granularity. 
You have to write tight code, no function calls in conditions in loops for example, but another benefit is that release code looks like your source, so it is easier to debug release build bugs.
==============================
Nothing to say.
|
|
|
|
|
Optimization: Minimize Size
Inline Function Expansion: Only those explicitly marked
Enable Intrinsic Functions: Yes
Favor Size or Speed: Favor small code
Omit Frame Pointers: No
Enable Fiber-safe Optimizations: Yes
Whole Program Optimization: Yes
Favour size or speed is a result of previous issues with speed optimizations causing problems. Also, smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
I had also done a compare of a number of apps compiled both ways. I was rarely able to find significant differences in speed, but often in size - the size opt had more effect.
Inline expansion 'Any' has caused significant module bloating for me before. This usually happens with template code. I like this part to be deterministic.
Fiber/whole optimizations, never had a reason to turn them off.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
cmk wrote: the size opt had more effect
I assume you mean the size opt yielded faster speed than the speed opt?
cmk wrote: smaller code can result in less page swapping, which swamps any benefits from 'faster' code.
What was the exe size in this case?
|
|
|
|
|
Hans Dietrich wrote: What was the exe size in this case?
The total size of the executable is meaningless in relation to the favor small code optimization. What this does is favor optimizing each function/loop with a very small instruction count. Which may actually reduce the overall exectable size but thats not really the goal. The Favor fast code optimization optimizes for instruction execution throughput... and it may even make code larger because aligned instructions generally prefetch/execute faster. I don't want to give any specific numbers because I am not programming in asm as much these days and plus my expertise is mostly with the older Intel Pentium class processors. Some 32 bit generalizations that may still hold true:
Favor small code:
1.) Could result in more branches but possibly fewer instructions.
2.) Makes an extra effort to keep functions/loops as small possible.
3.) May favor single-byte instructions utilizing the accumulator.
4.) May implement some jumps as sign-extended 8-bit shorts jumps resulting in smaller instruction size.
Favor fast code:
1.) Attempts to keep unconditional branches to a minimum resulting in faster execution speed.
2.) May unroll loops resulting in higher instruction count.
3.) May attempt to align the loops to 16/32/64 byte blocks even at the cost of using more instructions. (Possibly even padding with NOPS!)
Anyway what cmk is implying is that favor fast code will sometimes cause the function or loop to be much larger than a cache line resulting in slower execution and possibly a cache miss.
All of the information I just gave you is speculative and relative to the older compiler code generation algorithms. Modern compilers such as VS2010 generate extremely efficient code in nearly all cases. I spent over a decade hand optimizing much of my C++ code sprinkled with with assembler and could nearly always optimize better than the MS compilers. Beginning with VS2005 I noticed that the compiler was optimizing equal or greater to what I could do by hand. To be perfectly honest... it doesn't make much of a difference these days. The Microsoft compiler is smart enough to know when it is generating inefficient code and sometimes will switch between fast/small code generation algorithms regardless of the engineers choice. The same goes for __inline and __forceinline where the compiler will completely ignore what the engineer wants in many cases.
Btw, I would recommend that you start using whole program optimization. I would be willing to bet that the prior experience you mentioned was due to either VC7.0/VC7.1 or VC8. There were some /LTCG problems on those compilers. Also... for some reason all of those compilers would optimize out calls to memset/ZeroMemory on one of my projects causing an access violation. I ended up using the inlined SecureZeroMemory to get around the optimizing bug. When I moved to VC9 the issues went away entirely and holds true for VC10.
P.S. I essentially use the same optimization settings as cmk with the exception of sometimes omitting the frame pointers to free the ESP register if I am not using exception handlers.
Best Wishes,
-David Delaune
|
|
|
|
|
Good summary.
As you mention, the fast code option can can cause a cache miss. Additionally, earlier versions at least, could result in enough bloat to create extra pages. Related code, that under 'small' sits in the same page, could be split into different pages under 'fast'. This can result in more page faults. The performance impact due to page faults can exceed the speed improvements made from 'fast'.
So, based on past experience, and that these days the difference in optimization strategies is generally minor, I still use 'small'.
I haven't experienced the compiler ignoring my inline settings yet, have to check that, thanks.
The memset issue ... I ran into the same things years ago and found the following:
http://msdn2.microsoft.com/en-us/library/ms972826.aspx[^]
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
