#### Archived

This topic is now archived and is closed to further replies.

# Switching \ to / in strings?

This topic is 6933 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello, got (yet) another question, In my world builder program, there are places where the user has to enter a filename. The problem is, Windows (and XWindows) have made it so that filenames are usually given with ''\'' as the directory marker instead of ''/''. The obvious problem is that in C++ ''\'' is interpreted as a command marker, comepletely screwing up my string! How do I go through and replace all the ''\''s with ''/''s? Will MFC do it for me? ~noxa~

##### Share on other sites
Have you tried using ''/''?

I believe it will work.
Ex:

FILE *myFile;
myFile=fopen("c:/mydir/subdir/foo.txt", "r");

Is that what you meant?

Jesse Chounard

##### Share on other sites
Untested code:
// Replace all occurences of ''\'' with ''/''// NB: theString is your char* filename. Should be non-const.for (char* iter = theString; *iter != 0; ++iter){    if (*iter == ''\'')        *iter = ''/'';}

There may be an MFC command for this, but I don''t recommend using something so unportable, especially since you mention XWindows. (Not that I think anyone using XWindows would use a backslash in a pathname, but I digress.)

##### Share on other sites
What I''m confused about is this. When you put "c:\\test.txt" in your code, \\ is translated into the ASCII value associated with "\"... Anyhow, it''s translated by the ***compiler***.

When a user enters a string it''s sent to you already translated. So if a user enters "c:\test", you won''t receive "c: est" (spaces supposed to indicate a tab), you''ll actually receive "c:\test"...

So, unless your #include''ing your world data files into your C++ source, then it _shouldn''t_ be a problem.

Anyways, the previous posting had it right (''cept a typo in his for loop... the backslash wasn''t doubled up).

##### Share on other sites
The \ - commands are interpreted by the compiler and only valid in the source code, if you read a string from somewhere you don't need to care about this because only the C compiler interprets the commands and your program doesn't.

GA

Edited by - ga on 4/23/00 1:12:30 PM

##### Share on other sites
Why does it seem everyone either does conversions manually (not that that''s bad, I often do), or wants a big API to do it for them. There ARE lots of string manipulation functions in ANSI C.

char * ptr = stringToConvert;
while(ptr = strchr(ptr, ''\''))
*ptr = ''/'';

Rock

##### Share on other sites
Oh my god ppl, i learned this one in first grade!!
use "\\" which tells compiler you want a normal \.

##### Share on other sites
quote:
Original post by Rock2000

Why does it seem everyone either does conversions manually (not that that''s bad, I often do), or wants a big API to do it for them. There ARE lots of string manipulation functions in ANSI C.

char * ptr = stringToConvert;
while(ptr = strchr(ptr, ''\''))
*ptr = ''/'';

Well, if this was an API function that replaced the characters for you, I''d agree. But strchr doesn''t do much more than find the next character, and still has to iterate through the lot, so except for possible assembly optimisations, it''s unlikely to be faster than my method, especially if you have extra function call overhead.

Not that it makes much difference if you''re just doing it to the occasional filename, but I like to be picky

ga, Zipster... I see what you''re saying, but I believe there are certain functions which do actually act on those character sequences just like they were embedded into a string literal. Shame I can''t find any proof to back that up right now Besides, I''d have throught Noxa wouldn''t post about a problem he or she hadn''t actually had yet But it is possible.

##### Share on other sites
Yeah Kylotan, I was using this thread more to make a general comment about the seeming lack of use of the ANSI string functions. This was not the best example of using them. It should still be able to easily beat a for loop for anything but very small strings if speed is a concern (which I assume it isn''t here), but its more a matter of getting into the habit of using the plentiful string functions already available, which few people seem to ever use.

Rock

• 10
• 13
• 52
• 11
• 15