|
I am not a super-expert with macros (in my C# programming I have never used it). I do not immediately see how I can write a macro so that I can write file names in their 'true' form, without any escaping of backslashes (or for that sake, spaces, different quotes and other other characters requiring quoting in a *nix file system context.
If you can show me how a macro to achieve that might look like, I would be grateful.
|
|
|
|
|
The problem goes back to the first days of MS-DOS, when they chose the backslash for the path separator, rather than the forward slash used by UNIX. Microsoft could have addressed this when they created the first version of Windows, but obviously no one thought it important.
|
|
|
|
|
Richard MacCutchan wrote: The problem goes back to the first days of MS-DOS, when they chose the backslash for the path separator,
Apparently IBM is responsible for that decision. But there are other factors. The following is surprisingly detailed. Even comments at end are interesting. Goes sideways with charset discussion but that also is historically interesting.
Why Does Windows Really Use Backslash as Path Separator? | OS/2 Museum[^]
Richard MacCutchan wrote: Microsoft could have addressed this when they created the first version of Windows, but obviously no one thought it important.
Huh? There were quite a few versions of windows which ran on DOS. Not with it or instead of it. DOS provided the file system not Windows. DOS was directly accessible. So they would have needed to change DOS.
If they had changed it with Win 95 (perhaps the first possible) it would have made it incompatible with a lot of third party software that ran fine on Win 95.
|
|
|
|
|
I always was happy that DOS/Windows chose the backwards slash. Ideally, the separator should be a character that is never used in plain text so it could be used in a file name. Forward slash is often used in text, in several different ways: As an either/or. For fractions, 1/2. At least in Norwegian (but I believe it holds for a number of other languages as well) in commonly used abbreviations, A/S is an 'Ltd.' company. (Today some companies have dropped the slash, but several thousand A/S-es still have 'A/S' in their official name.)
The same goes for the full stop between the file name and the extension. Lunix handles this by not splitting into name.ext. DOS/Windows mostly determines or identifies the extension from context, but there are still cases of ambiguity where a non-overloaded character code was used as a separator.
The problem with both \ and . is significantly reduced in a GUI environment where you point and select, rather that typing the full path. A file name being edited in an entry file dedicated to a file name also handles spaces without requiring quoting\escaping.
Holding up *nix file naming rules as some sort of ideal, "Why would anyone ever dream of doing anything differently??", is in my eyes rather crazy. It satisfied engineers of the 1960s and 70s, by not everyday, non-technical users of the 2020s. Not by far!
|
|
|
|
|
|
|
|
|
No. Nobody here is going to do your homework for you. No matter how many times you repost it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Since this is a standard class project one would expect the teacher to cover all of this.
First step.
1. Learn basics of C (or C++)
2. Learn basics of compiling C.
3. Write a hello world program.
4. Learn how methods work. Write methods that add, subtract, etc, and nothing else.
Next steps depends on how the calculator works.
If a console
1. Learn about stdin and stdout
2. Learn how to run application to read keyboard input and output response
If a UI. This is MUCH harder than above.
1. Find a C UI library
2. Learn basics of that
3. Design calculator UI look.
4. Implement UI look
5. Learn how to tie the UI into C method calls.
Final step - Put all of the above together to build your app.
|
|
|
|
|
Do you realize your post is nearly useless?
We need far more details in order to help you.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I would have said completely useless.
|
|
|
|
|
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
CP could make it a requirement that with any request for having someone doing your homework for you, the name and email of the professor must be specified, so we know where to go to obtain more details about the task.
|
|
|
|
|
Hi,
Is this how it should be done?
int Strawberry = 10;
int * PointerInd0 = &Strawberry;
int ** PointerInd1 = &PointerInd0;
// I’m not sure what comes next
int *** PointerInd2 = &PointerInd1;
Sorry I’m not enclosing the source code in code tags, I don’t have edit options on mobile.
modified 14-Sep-23 9:15am.
|
|
|
|
|
Calin Negru wrote:
int *** PointerLvl3 = &PointerLvl2;
Yes, indeed. You can continue with as many levels of indirection as you wish (although I don't remember needing more than two).
Mircea
modified 14-Sep-23 9:29am.
|
|
|
|
|
If that is true then this simple assign address to is a bit deceiving because you still have to remember what PointerInd2 is, you need special syntax to access Strawberry from PointerInd2
***PointerInd2 = 31; // just a guess
|
|
|
|
|
Calin Negru wrote: ***PointerInd2 = 31; // just a guess
Yes, nothing wrong with that. I don't see why you see it as deceiving. If you miss one of the indirection operators and you write:
**PointerInd2 = 31; compiler will flag it with an error like "cannot assign 'int' to 'int*' ".
But, again, cases where you need more than two level on indirection are exceedingly rare. Probably because we humans aren't great at keeping track of stack levels.
Mircea
|
|
|
|
|
>I don’t see why you see it as deceiving
It’s just a single &sign one that could make you believe it’s a typical pointer you’re dealing with. You need to be in a high alert so to speak and always have in mind what you have declared.
modified 14-Sep-23 16:05pm.
|
|
|
|
|
Calin Negru wrote: you believe it’s a typical pointer you’re dealing with.
The developer should of course be aware of the code they are writing/modifying.
And this should not be something that is used very often.
|
|
|
|
|
>The developer should of course be aware
I know. If you look at the address assignation alone you don’t have a clue what that is (Something = &SomethingElse) you have look at the declaration to figure it out. Sorry if that sounds like repeating the same thing. What I’m saying is that it’s not your C# fire and forget.
modified 15-Sep-23 3:36am.
|
|
|
|
|
Correct, I think. A simple test program would confirm that, but I'm not feeling the urge.
But if you need more than two or three levels of indirection, then the problem space should lead to sensible variable naming. That and intelligent comments should make your intent clear. And, of course, you've got typedefs or C++ using statements to help reduce the brain cramp that I find multiple indirection sometimes brings. If you're using C++, you also have references which might help reduce the (apparent) levels of indirection going on.
Keep Calm and Carry On
|
|
|
|
|
int Strawberry = 10;
int * PointerInd0 = &Strawberry;
std::cout << "*PointerInd0: " << *PointerInd0 << std::endl;
int ** PointerInd1 = &PointerInd0;
std::cout << "**PointerInd1: " << **PointerInd1 << std::endl;
int *** PointerInd2 = &PointerInd1;
std::cout << "***PointerInd2: " << ***PointerInd2 << std::endl;
int **** PointerInd3 = &PointerInd2;
std::cout << "****PointerInd3: " << ****PointerInd3 << std::endl;
Results:
*PointerInd0: 10
**PointerInd1: 10
***PointerInd2: 10
****PointerInd3: 10
And so until the compiler or the application gives up. If you are really interested then get an assembly listing and see what the machine code is doing.
|
|
|
|
|
Thank you Richard, you make it clear.
modified 14-Sep-23 16:02pm.
|
|
|
|
|
You're welcome. It always helps to look at actual code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
