We are more than willing to help those that are stuck: but that doesn't mean that we are here to do it all for you! We can't do all the work, you are either getting paid for this, or it's part of your grades and it wouldn't be at all fair for us to do it all for you.
So we need you to do the work, and we will help you when you get stuck. That doesn't mean we will give you a step by step solution you can hand in!
Start by explaining where you are at the moment, and what the next step in the process is. Then tell us what you have tried to get that next step working, and what happened when you did.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
It sure may be homework, but then again: If different phrasings are both accepted by the compiler, it is legitimate to ask if they are identical, even if it is not homework .
If "const int *ptr" is identical to "int const *ptr", is it then identical to "int *const ptr" as well? If you can shift the "const" keyword one position, why not two? There are several cases (in various languages) of modifiers that can be written in any order (when there are more than one). Knowing when order/position is significant and when it isn't (and which orders/positions are illegal) can be quite confusing until you have built expertise in the language!
They are equivalent. The int value is constant, cannot be modified. Now that you decalre a pointer to this type, this pointer can be set to any constant int value, but the pointer itself may be moved around freely among several constant integer values.
The difference comes when you move 'const' to the right of the asterisk:
int *const ptr = &xxx;
Now the xxx value may change, but ptr will always point to xxx. You are not allowed to move ptr to &yyy. You can consider *ptr as another way of writing xxx. Or ptr is another way of writing &xxx. You can't move xxx to refer to another variable either, so *ptr and xxx, or ptr and &xxx work the same way. You rarely need constant pointers; the address it is initialized with will serve the same purpose. But if the address expression is complex, and it is used many times, setting up a constant pointer may save both typing and improve readability (as long as a more descriptive name than "ptr" is chosen ).
Context: I have some applications that were originally written for Xp. This is important, because we're running into issues with security changes from Xp -> Windows 10. Some of the code in the application makes assumptions for Xp that are evil for Windows 10. So, I'm migrating these apps from VS 2008 to VS 2017 and maybe later.
So, firing up VS2017 and attempting to build some demo projects, I'm prompted to re-target the application. Visual Studio offers me 3 different SDKs. I've dealt with mfc over the years, but the mfc dlls seem to be always included everywhere.
Should I be concerned about which sdk I build for?
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I have done this when moving from VS2015 to 2017, and recently when moving to 2019. I always choose the one with the highest number. Alternatively, create a quick minimal Windows app in VS 2017 and check its properties to see which version it sets as default.
You might want to consider moving directly to VS2019. Differences are quite small but one important factor that made me upgrade is that, in VS2019, you can set the target platform to "10.0 (latest installed version)". That saves you a lot of headaches when changing development machines or when you have different developers.
Again from my experience, you can safely assume that a Windows 10 machine will have the runtime already installed.
Last Visit: 31-Dec-99 19:00 Last Update: 27-Jan-21 10:34