I've write :
string.find("\\") to locate the 'folder'character (windows style) separator but without success.
Any idea ?
mmm
The problem was I'm passing the string so :
MY_function ("d:\my_folder\my_subfolder");
And the string received was strange (I suposse because I can not write d:\my_folder\my_subfolder, I have to write d:\\my_folder\\my_subfolder.
Is there any way to say my ide + compiler that "d:\my_folder\my_subfolder" is valid ?
Thanks
-1 to use "/" without discrimination. While you can input a filename using the slash (/), the Windows API will output filenames with backslah (\). If you need to break the path into folder names + file name, suggesting the slash is a mistake.
GetModuleFileName() returns a path + filename. If you were to parse that for folder names, you must find backslashes, not slashes.
EDIT: This is probably the reason why the .Net framework includes System.IO.Path: So managed code can be written in a portable manner when manipulating filenames.
How come both? I have never seen a filename output from a Windows API function call that includes both. Or do you mean that you need to find both if you want the code to remain portable. Is that it?
No, this isn't about portability. In Windows, both / and \ are valid path separators, so if you're breaking up a path into its components, you must account for both.
Under windows you can use the splitpath() function.
string.find("\\") to locate the 'folder'character (windows style) separator but without success.
Do you know what's the string is when you're trying to find the backslash? If the string is really this "d:\my_folder\my_subfolder" you cannot find the backslash since it's not there.
I understand that you can input string literals that represent a filename and path to Windows using either the backslash or the slash. That is not under discussion. The problem that I point out is to think you can expect slashes from calls to functions that return file names, like GetModuleFileName(). Those will always return backslashes.
No, this isn't about portability. In Windows, both / and \ are valid path separators, so if you're breaking up a path into its components, you must account for both.
For input to the API, yes, but I'm pretty sure no API function will return a forward slash in the middle of a path, unless the string comes from the registry or something like that.
The WinAPI needs to pick a default when constructing paths and this default is the backslash.
I don't know where you see a problem. If you're worried about someone adding parts containing slashes to a path returned by the WinAPI: you can safely mix slashes and backslashes in the same path.
the Windows API will output filenames with backslah (\).
I would wrap those calls and convert the output strings to use forward slash.
Nearly every other directory tree in the world uses /. It's pretty much universal except for Windows. But even other trees that you might use on Windows use it (like file archives.. such as .zip, etc)