|
But when I enter a valid weight and hit enter, the program moves on to the next feature (it doesnt go through the if branch).
|
|
|
|
|
I think I get what you are saying, but I just ran the program again and if I enter a valid weight (positive number) everything runs normally and at the end it displays the number I entered.
|
|
|
|
|
Sure, but if you do this
if(weight != "\n")
{
pigs[i].SetPigWeight(pigWeight);
}
else
pigs[i].SetPigWeight(100.0);
Now, when you hit enter, you would expect that the default weight would be used (i.e. set to 100.0), if the comparison is working as you expect. But it won't be, it will be set to zero. Believe me when I tell you that
if (weight != "\n")
does not compare objects of type char* (ie c-style strings). You must use strcmp() to compare c-style strings. Better than using iostream::getline, take a look at std::getline. Your code might then look something like
#include <string>
string input_string;
getline(cin, input_string);
if(input_string.length() != 0) {
}
Furthermore, what happens if you enter one hundred for the weight? It doesn't get set to 100, but zero, since atof("one hundred") == 0.0. A good solution should check that the input is a number. At the very least that the input string contains only the characters "0123456789.". Ideally you would check that there was only one decimal point, too.
|
|
|
|
|
You're right, I copied and pasted that code to try it and it set the pig weight to the default of 0 instead of 100. I understand what you are saying now. Thank you so much for taking out the time to explain this to me in detail. This thing was really frustrating me and you really cleared it up for me, I really appreciate this!
|
|
|
|
|
You're very welcome.
String comparisons can be tricky in C/C++. I have over 30 years experience with C and it took me a couple of readings of your code to realize
if(weight != "\n") did not do what it looks like it should! I'm sure I'm not the only one who looked at that and didn't twig right away that the string comparisons were incorrect.
|
|
|
|
|
k5054 already said it all.
But I'd like to add the general advice that you read up on the description of all I/O functions rather than making assumptions about what they return. Especially input functions.
Also, it is usually easier to read std::string objects rather than reading input of unknown length into limited size buffers. You can use the function getline(istream&, string) for that. See getline (string) - C++ Reference[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: Also, it is usually easier to read std::string objects rather than reading input of unknown length into limited size buffers. You can use the function getline(istream&, string) for
Additionally, you should expect your Teacher/TA/Assignment-marker to be an "evil knave of the worst kind", looking to find ways to make your program crash. For any input she/he might choose to cut/paste something like: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. If you use std::getline(), rather than iostream::getline(), you should be able to handle any reasonable input sent your way.
|
|
|
|
|
k5054 wrote: Additionally, you should expect your Teacher/TA/Assignment-marker to be an "evil knave of the worst kind", looking to find ways to make your program crash
I've found I learned more from the 'evil knave' types than those who were 'playing nice'. Nothing prepares you better for the real world than nasty traps! 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I wrote a small utility tool with MFC (for user interface) and purely C++ code.
on Windows 10 and in Visual Studio 2017 IDE, I compiled this program into .exe file (i.e. HelloX.exe) in MFC dynamic DLL option.
So I put vcruntime140.dll and mfc140u.dll at the same folder.
I test my program on Windows Vista, it works well. I just tested this program on Windows XP and it did not work(few minutes ago).
Any suggestion or comments to share? thanks a million.
diligent hands rule....
modified 8-Mar-20 22:14pm.
|
|
|
|
|
|
thanks
diligent hands rule....
|
|
|
|
|
Deploy as in creating an installer ?
For small packages like yours, I would use inno setup to package your software.
I'd rather be phishing!
|
|
|
|
|
not using installer. just xcopy command etc.
diligent hands rule....
|
|
|
|
|
To deploy without having to install the VC++ dlls.
Linking to C runtime statically (Multithreaded (/MT) for Release build)
http://imageshack.com/a/img923/6600/ifeLcs.png
If you are using MFC, linking to MFC runtime statically.
http://imageshack.com/a/img921/1331/7eBoZW.png
The downside to linking statically is your executable size will be bigger but it only links the classes and functions your executable calls whereas, in the dynamically linkage case, the VC++ dlls have to contains all the code regardless your executable calls them or not.
|
|
|
|
|
I plan to use MFC DLL dynamically linked option. I have several utilities to distribute in one bundle...
diligent hands rule....
|
|
|
|
|
|
thank you! first to know VS 2015, VS 2017,and VS2019 have the same redistribute.
diligent hands rule....
|
|
|
|
|
Yes, this is the future direction going forward because MS does not want the user to install many VC++ redistributables on their machine.
|
|
|
|
|
your screenshots are very helpful. thanks.
diligent hands rule....
|
|
|
|
|
hi
I am trying to add a MENU bar to my Dialog when I look at this link seems I should be able to
DIALOG resource - Win32 apps | Microsoft Docs[^]
however after I add it
IDD_DIALOG21 DIALOGEX 0, 0, 790, 321
MENU IDR_MAINFRAME
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Dialog"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
CONTROL "",IDC_RICHEDIT21,"RichEdit20A",ES_MULTILINE | WS_BORDER | WS_TABSTOP,27,7,780,273
LTEXT "Static",IDC_STATIC15,7,7,20,273,WS_CLIPSIBLINGS
END
and open up the dialog in the resource editor it doesn't display
I tried creating a new project "Dialog Based" and the menu (control to add it ) in the wizard was grayed out
thanks
|
|
|
|
|
I don't have a VS version that includes the resource editor, so I have to do things manually. However, I can confirm that dialog boxes work fine with menus.
|
|
|
|
|
ok maybe it only display them when you do a SHowWindow
|
|
|
|
|
I thought you were talking about a modal dialog.
|
|
|
|
|
Easy to do it manually .. inside WM_INITDIALOG assuming the dialog window handle is hWnd
Try this
HMENU hMenubar;
HMENU hMenu;
hMenubar = CreateMenu();
hMenu = CreateMenu();
AppendMenuW(hMenu, MF_STRING, 10000, "&New");
AppendMenuW(hMenu, MF_STRING, 10001, "&Open");
AppendMenuW(hMenu, MF_SEPARATOR, 0, NULL);
AppendMenuW(hMenu, MF_STRING, WM_QUIT, "&Quit");
AppendMenuW(hMenubar, MF_POPUP, (UINT_PTR)hMenu, "&File");
SetMenu(hWnd, hMenubar);
In vino veritas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
