windows and linux discrepancy: backslash and forward slash in c++
In windows I have
std::string graphdir = projDir + "graph\";
int mkdirsf=_mkdir(graphdir.c_str());
The above works quite well in windows. But in linux, you know forward slashed / are used. So the above will create a folder with name graph. Is there an universal way to enter the correct folder without worrying about / or ?
c++ linux windows
asked Nov 16 '18 at 8:30
JohnJohn
325
add a comment |
In windows I have
std::string graphdir = projDir + "graph\";
int mkdirsf=_mkdir(graphdir.c_str());
The above works quite well in windows. But in linux, you know forward slashed / are used. So the above will create a folder with name graph. Is there an universal way to enter the correct folder without worrying about / or ?
c++ linux windows
asked Nov 16 '18 at 8:30
JohnJohn
325
4
Within some limits, Windows have supported forward slashes/since the DOS days. Otherwise usestd::filesystem(or Boost filesystem).
– Some programmer dude
Nov 16 '18 at 8:31
2
Indeed, try with/on Windows too, and see if it works. I think it should.
– hyde
Nov 16 '18 at 8:39
1
Your standard library implementation will make sure that/works on Windows.
– molbdnilo
Nov 16 '18 at 8:48
1
Its normally only the command shell (cmd.exe) under windows that does not understand forward slashes, the WinAPI (usually) does.
– Aconcagua
Nov 16 '18 at 8:52
add a comment |
In windows I have
std::string graphdir = projDir + "graph\";
int mkdirsf=_mkdir(graphdir.c_str());
The above works quite well in windows. But in linux, you know forward slashed / are used. So the above will create a folder with name graph. Is there an universal way to enter the correct folder without worrying about / or ?
c++ linux windows
asked Nov 16 '18 at 8:30
JohnJohn
325
In windows I have
std::string graphdir = projDir + "graph\";
int mkdirsf=_mkdir(graphdir.c_str());
The above works quite well in windows. But in linux, you know forward slashed / are used. So the above will create a folder with name graph. Is there an universal way to enter the correct folder without worrying about / or ?
c++ linux windows
c++ linux windows
asked Nov 16 '18 at 8:30
JohnJohn
325
asked Nov 16 '18 at 8:30
JohnJohn
325
edited Nov 16 '18 at 21:14
John
asked Nov 16 '18 at 8:30
JohnJohn
325
asked Nov 16 '18 at 8:30
JohnJohn
325
asked Nov 16 '18 at 8:30
JohnJohn
325
325
4
Within some limits, Windows have supported forward slashes/since the DOS days. Otherwise usestd::filesystem(or Boost filesystem).
– Some programmer dude
Nov 16 '18 at 8:31
2
Indeed, try with/on Windows too, and see if it works. I think it should.
– hyde
Nov 16 '18 at 8:39
1
Your standard library implementation will make sure that/works on Windows.
– molbdnilo
Nov 16 '18 at 8:48
1
Its normally only the command shell (cmd.exe) under windows that does not understand forward slashes, the WinAPI (usually) does.
– Aconcagua
Nov 16 '18 at 8:52
add a comment |
4
Within some limits, Windows have supported forward slashes/since the DOS days. Otherwise usestd::filesystem(or Boost filesystem).
– Some programmer dude
Nov 16 '18 at 8:31
2
Indeed, try with/on Windows too, and see if it works. I think it should.
– hyde
Nov 16 '18 at 8:39
1
Your standard library implementation will make sure that/works on Windows.
– molbdnilo
Nov 16 '18 at 8:48
1
Its normally only the command shell (cmd.exe) under windows that does not understand forward slashes, the WinAPI (usually) does.
– Aconcagua
Nov 16 '18 at 8:52
4
4
Within some limits, Windows have supported forward slashes
/ since the DOS days. Otherwise use std::filesystem (or Boost filesystem).– Some programmer dude
Nov 16 '18 at 8:31
Within some limits, Windows have supported forward slashes
/ since the DOS days. Otherwise use std::filesystem (or Boost filesystem).– Some programmer dude
Nov 16 '18 at 8:31
2
2
Indeed, try with
/ on Windows too, and see if it works. I think it should.– hyde
Nov 16 '18 at 8:39
Indeed, try with
/ on Windows too, and see if it works. I think it should.– hyde
Nov 16 '18 at 8:39
1
1
Your standard library implementation will make sure that
/ works on Windows.– molbdnilo
Nov 16 '18 at 8:48
Your standard library implementation will make sure that
/ works on Windows.– molbdnilo
Nov 16 '18 at 8:48
1
1
Its normally only the command shell (cmd.exe) under windows that does not understand forward slashes, the WinAPI (usually) does.
– Aconcagua
Nov 16 '18 at 8:52
Its normally only the command shell (cmd.exe) under windows that does not understand forward slashes, the WinAPI (usually) does.
– Aconcagua
Nov 16 '18 at 8:52
add a comment |
1 Answer
1
active
oldest
votes
You might consider using forward slashes even on Windows as a directory separator. Most Windows libraries are able to convert them to backward slashes (they actually don't do a conversion, but understand them as wanted; the rest is an implementation detail)
Otherwise, notice that the C++11 (or C++14) standard don't know about "folders" (you actually mean directories; since folders are only a GUI artefact; read e.g. n3337 to check). C++17 has std::filesystem.
Maybe you should consider some other libraries or frameworks: Boost, POCO, Qt all know how to deal with directories on common OSes (Windows, Linux, MacOSX, Android).
A more significant concern is the "drive" letter. For Windows (and even some MS-DOS) C:/FOO/BAR.TXT (or, using backslashes, C:FOOBAR.TXT) and D:/FOO/BAR.TXT refer to different files. There is no real equivalent in Linux or MacOSX. Since mount points are more general.
At last, file hierarchy conventions (and file systems) vary widely from one OS to the other. For Linux, see hier(7) and path_resolution(7). Notice that globbing is also OS specific (and happens differently: in Unix systems, it is often done by shells; on Windows, it might be done, in every application, by some crt0 like thing of the runtime system). For Linux, see also glob(7).
BTW, perhaps you could consider using WSL on your Windows machine. In lucky cases, the same executable could run on Linux and on Windows (under WSL), and that makes your work easier (when it is usable).
Take time to read more about operating systems and file systems. I recommend the Operating System: Three Easy Pieces textbook (freely downloadable).
You could find useful to read more about your OS. For Linux, read ALP (or some newer book) then syscalls(2) and intro(3) etc... For Windows, learn the WinAPI (I don't know it), perhaps by starting here.
On Linux, the API relevant to directories include mkdir(2), chdir(2), rmdir(2), getcwd(2), stat(2), opendir(3) and closedir, readdir(3), nftw(3), etc, etc.... Be aware that a file is on Linux just an i-node (read inode(7) and about hard links) and can be in several directories (or none), see link(2). AFAIU, this makes a huge difference with Windows.
PS. I never used Windows, and never coded for it.
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
1
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
2
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited toMAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.
– eryksun
Nov 16 '18 at 10:56
1
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
1
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53334046%2fwindows-and-linux-discrepancy-backslash-and-forward-slash-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You might consider using forward slashes even on Windows as a directory separator. Most Windows libraries are able to convert them to backward slashes (they actually don't do a conversion, but understand them as wanted; the rest is an implementation detail)
Otherwise, notice that the C++11 (or C++14) standard don't know about "folders" (you actually mean directories; since folders are only a GUI artefact; read e.g. n3337 to check). C++17 has std::filesystem.
Maybe you should consider some other libraries or frameworks: Boost, POCO, Qt all know how to deal with directories on common OSes (Windows, Linux, MacOSX, Android).
A more significant concern is the "drive" letter. For Windows (and even some MS-DOS) C:/FOO/BAR.TXT (or, using backslashes, C:FOOBAR.TXT) and D:/FOO/BAR.TXT refer to different files. There is no real equivalent in Linux or MacOSX. Since mount points are more general.
At last, file hierarchy conventions (and file systems) vary widely from one OS to the other. For Linux, see hier(7) and path_resolution(7). Notice that globbing is also OS specific (and happens differently: in Unix systems, it is often done by shells; on Windows, it might be done, in every application, by some crt0 like thing of the runtime system). For Linux, see also glob(7).
BTW, perhaps you could consider using WSL on your Windows machine. In lucky cases, the same executable could run on Linux and on Windows (under WSL), and that makes your work easier (when it is usable).
Take time to read more about operating systems and file systems. I recommend the Operating System: Three Easy Pieces textbook (freely downloadable).
You could find useful to read more about your OS. For Linux, read ALP (or some newer book) then syscalls(2) and intro(3) etc... For Windows, learn the WinAPI (I don't know it), perhaps by starting here.
On Linux, the API relevant to directories include mkdir(2), chdir(2), rmdir(2), getcwd(2), stat(2), opendir(3) and closedir, readdir(3), nftw(3), etc, etc.... Be aware that a file is on Linux just an i-node (read inode(7) and about hard links) and can be in several directories (or none), see link(2). AFAIU, this makes a huge difference with Windows.
PS. I never used Windows, and never coded for it.
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
1
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
2
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited toMAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.
– eryksun
Nov 16 '18 at 10:56
1
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
1
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
add a comment |
You might consider using forward slashes even on Windows as a directory separator. Most Windows libraries are able to convert them to backward slashes (they actually don't do a conversion, but understand them as wanted; the rest is an implementation detail)
Otherwise, notice that the C++11 (or C++14) standard don't know about "folders" (you actually mean directories; since folders are only a GUI artefact; read e.g. n3337 to check). C++17 has std::filesystem.
Maybe you should consider some other libraries or frameworks: Boost, POCO, Qt all know how to deal with directories on common OSes (Windows, Linux, MacOSX, Android).
A more significant concern is the "drive" letter. For Windows (and even some MS-DOS) C:/FOO/BAR.TXT (or, using backslashes, C:FOOBAR.TXT) and D:/FOO/BAR.TXT refer to different files. There is no real equivalent in Linux or MacOSX. Since mount points are more general.
At last, file hierarchy conventions (and file systems) vary widely from one OS to the other. For Linux, see hier(7) and path_resolution(7). Notice that globbing is also OS specific (and happens differently: in Unix systems, it is often done by shells; on Windows, it might be done, in every application, by some crt0 like thing of the runtime system). For Linux, see also glob(7).
BTW, perhaps you could consider using WSL on your Windows machine. In lucky cases, the same executable could run on Linux and on Windows (under WSL), and that makes your work easier (when it is usable).
Take time to read more about operating systems and file systems. I recommend the Operating System: Three Easy Pieces textbook (freely downloadable).
You could find useful to read more about your OS. For Linux, read ALP (or some newer book) then syscalls(2) and intro(3) etc... For Windows, learn the WinAPI (I don't know it), perhaps by starting here.
On Linux, the API relevant to directories include mkdir(2), chdir(2), rmdir(2), getcwd(2), stat(2), opendir(3) and closedir, readdir(3), nftw(3), etc, etc.... Be aware that a file is on Linux just an i-node (read inode(7) and about hard links) and can be in several directories (or none), see link(2). AFAIU, this makes a huge difference with Windows.
PS. I never used Windows, and never coded for it.
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
1
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
2
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited toMAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.
– eryksun
Nov 16 '18 at 10:56
1
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
1
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
add a comment |
You might consider using forward slashes even on Windows as a directory separator. Most Windows libraries are able to convert them to backward slashes (they actually don't do a conversion, but understand them as wanted; the rest is an implementation detail)
Otherwise, notice that the C++11 (or C++14) standard don't know about "folders" (you actually mean directories; since folders are only a GUI artefact; read e.g. n3337 to check). C++17 has std::filesystem.
Maybe you should consider some other libraries or frameworks: Boost, POCO, Qt all know how to deal with directories on common OSes (Windows, Linux, MacOSX, Android).
A more significant concern is the "drive" letter. For Windows (and even some MS-DOS) C:/FOO/BAR.TXT (or, using backslashes, C:FOOBAR.TXT) and D:/FOO/BAR.TXT refer to different files. There is no real equivalent in Linux or MacOSX. Since mount points are more general.
At last, file hierarchy conventions (and file systems) vary widely from one OS to the other. For Linux, see hier(7) and path_resolution(7). Notice that globbing is also OS specific (and happens differently: in Unix systems, it is often done by shells; on Windows, it might be done, in every application, by some crt0 like thing of the runtime system). For Linux, see also glob(7).
BTW, perhaps you could consider using WSL on your Windows machine. In lucky cases, the same executable could run on Linux and on Windows (under WSL), and that makes your work easier (when it is usable).
Take time to read more about operating systems and file systems. I recommend the Operating System: Three Easy Pieces textbook (freely downloadable).
You could find useful to read more about your OS. For Linux, read ALP (or some newer book) then syscalls(2) and intro(3) etc... For Windows, learn the WinAPI (I don't know it), perhaps by starting here.
On Linux, the API relevant to directories include mkdir(2), chdir(2), rmdir(2), getcwd(2), stat(2), opendir(3) and closedir, readdir(3), nftw(3), etc, etc.... Be aware that a file is on Linux just an i-node (read inode(7) and about hard links) and can be in several directories (or none), see link(2). AFAIU, this makes a huge difference with Windows.
PS. I never used Windows, and never coded for it.
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
You might consider using forward slashes even on Windows as a directory separator. Most Windows libraries are able to convert them to backward slashes (they actually don't do a conversion, but understand them as wanted; the rest is an implementation detail)
Otherwise, notice that the C++11 (or C++14) standard don't know about "folders" (you actually mean directories; since folders are only a GUI artefact; read e.g. n3337 to check). C++17 has std::filesystem.
Maybe you should consider some other libraries or frameworks: Boost, POCO, Qt all know how to deal with directories on common OSes (Windows, Linux, MacOSX, Android).
A more significant concern is the "drive" letter. For Windows (and even some MS-DOS) C:/FOO/BAR.TXT (or, using backslashes, C:FOOBAR.TXT) and D:/FOO/BAR.TXT refer to different files. There is no real equivalent in Linux or MacOSX. Since mount points are more general.
At last, file hierarchy conventions (and file systems) vary widely from one OS to the other. For Linux, see hier(7) and path_resolution(7). Notice that globbing is also OS specific (and happens differently: in Unix systems, it is often done by shells; on Windows, it might be done, in every application, by some crt0 like thing of the runtime system). For Linux, see also glob(7).
BTW, perhaps you could consider using WSL on your Windows machine. In lucky cases, the same executable could run on Linux and on Windows (under WSL), and that makes your work easier (when it is usable).
Take time to read more about operating systems and file systems. I recommend the Operating System: Three Easy Pieces textbook (freely downloadable).
You could find useful to read more about your OS. For Linux, read ALP (or some newer book) then syscalls(2) and intro(3) etc... For Windows, learn the WinAPI (I don't know it), perhaps by starting here.
On Linux, the API relevant to directories include mkdir(2), chdir(2), rmdir(2), getcwd(2), stat(2), opendir(3) and closedir, readdir(3), nftw(3), etc, etc.... Be aware that a file is on Linux just an i-node (read inode(7) and about hard links) and can be in several directories (or none), see link(2). AFAIU, this makes a huge difference with Windows.
PS. I never used Windows, and never coded for it.
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
edited Nov 16 '18 at 13:35
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
answered Nov 16 '18 at 8:33
Basile StarynkevitchBasile Starynkevitch
177k13166363
177k13166363
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
1
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
2
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited toMAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.
– eryksun
Nov 16 '18 at 10:56
1
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
1
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
add a comment |
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
1
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
2
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited toMAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.
– eryksun
Nov 16 '18 at 10:56
1
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
1
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
"Most Windows libraries are able to convert them to backward slashes." I don't think there is a need to convert them in the first place. Even the lowest level functions treat them equally.
– glglgl
Nov 16 '18 at 8:47
1
1
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
DOS and CP/M are happy with forward slashes since the version they introduced subdirectories.
– Swordfish
Nov 16 '18 at 10:11
2
2
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited to
MAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.– eryksun
Nov 16 '18 at 10:56
Unless an app is running in Windows 10 with long-path support enabled both at the system level and in the application manifest, then path normalization in the runtime library is limited to
MAX_PATH. That's 259 characters, or 247 when creating a directory (with space for an 8.3 filename). Another reason to bypass normalization is to avoid quirky rules such as DOS devices in every directory, regardless of extension (e.g. "nul.txt") and to allow names with trailing spaces and dots. Skipping normalization requires a "\?" local-device path, which can only use backslash as the path separator.– eryksun
Nov 16 '18 at 10:56
1
1
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
Also the shell path API, which is widely used, doesn't understand forward slashes at all.
– zett42
Nov 16 '18 at 13:31
1
1
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
One also has to consider, that most Windows programs interpret forward slashes as introduction of command-line arguments. E. g. if you call a child processes like "some.exe /mylocalpath/subdir" it might treat the 2nd argument as a command-line flag named "/mylocalpath/subdir" instead of treating it as a path argument.
– zett42
Nov 16 '18 at 13:37
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53334046%2fwindows-and-linux-discrepancy-backslash-and-forward-slash-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Within some limits, Windows have supported forward slashes
/since the DOS days. Otherwise usestd::filesystem(or Boost filesystem).– Some programmer dude
Nov 16 '18 at 8:31
2
Indeed, try with
/on Windows too, and see if it works. I think it should.– hyde
Nov 16 '18 at 8:39
1
Your standard library implementation will make sure that
/works on Windows.– molbdnilo
Nov 16 '18 at 8:48
1
Its normally only the command shell (cmd.exe) under windows that does not understand forward slashes, the WinAPI (usually) does.
– Aconcagua
Nov 16 '18 at 8:52