# How does c++ differentiate between "path\filename.txt" and filename.txt on CLI?

This is a discussion on How does c++ differentiate between "path\filename.txt" and filename.txt on CLI? within the C++ Programming forums, part of the General Programming Boards category; I am -trying- to teach myself C++ and in that process I'm trying to make an application that will take ...

1. ## How does c++ differentiate between "path\filename.txt" and filename.txt on CLI?

I am -trying- to teach myself C++ and in that process I'm trying to make an application that will take a command line parameter and then generate a result. I managed to find out what needs to be done to get the parameters initially (putting the argc/argv stuff in main()), but I need to expand on that..

For example,

urlmaker "c:\directory\to\filename"

Does c++ have a way of knowing *just* the filename out of this or do I have to make a function to parse the filename out of it? I'd also like to be able to just do: urlmaker filename, but I can't figure out how to tell which type of argument urlmaker has been passed.

Code:
#include <iostream>
#include <string>

using namespace std;

int main(int argc, char *argv[], char **envp)
{
string image = argv[1];

cout << image << endl;
return 0;

}

2. >> do I have to make a function to parse the filename out of it?
You have to make a function or use an existing one that does it for you. I don't believe there are any standard ones, but some libraries certainly have functions that do this.

To do it yourself, you can find_last_of("/\\") and if one is found get all the text in the string after that point.

3. If you are using Microsofts C Runtime library, the function _splitpath will split a filename into portions for you.

--
Mats

4. Originally Posted by Isolder
Does c++ have a way of knowing *just* the filename out of this or do I have to make a function to parse the filename out of it? I'd also like to be able to just do: urlmaker filename, but I can't figure out how to tell which type of argument urlmaker has been passed.
I'm not sure why you feel you need to care. Just use the filename exactly as passed. If it's a naked filename, it will work. If it's a relative or absolute path, it will work. There is absolutely no reason for you to even LOOK at the filename.

5. The program name suggests that the thing translates paths to file: URLs. So yes, there is reason to look at the filename.

6. Thanks everyone for your replies. The program does indeed require the filename specifically. I have someone else's software that downloads photos from flickr and stores them with a naming scheme that makes it possible to tell what the image's url was in flickr. Sometimes the downloaded file is 'empty' and so I wanted to make something that could open the image in Flickr in order to see what the image was.

Anyway, my first cpp application, albeit very simple:

Code:
#include <iostream>
#include <string>
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

using namespace std;

int main(int argc, char *argv[], char **envp)
{
string flickbase = "http://www.flickr.com/photos/";
const char* c_str();

if (argc == 1) {

cout << "No file specified." << endl;

} else {

char drive[_MAX_DRIVE];
char dir[_MAX_DIR];
char fname[_MAX_FNAME];
char ext[_MAX_EXT];

_splitpath(argv[1], drive, dir, fname, ext);

string filename(fname);
string first_half = filename.substr(0, filename.find("-", 0));
string second_half = filename.substr(filename.find("-", 0)+1, filename.length());
string fullurl = flickbase + first_half + "/" + second_half;

cout << "Opening.." << fname << endl;
ShellExecute(NULL, "open", fullurl.c_str(), NULL, NULL, SW_SHOWNORMAL);

}

return 0;
}
I could have done this in perl, but I'm not trying to learn perl.

7. Originally Posted by Isolder
Code:
	string flickbase = "http://www.flickr.com/photos/";
const char* c_str();
I don't even know what to say about this, but why is it there? I wouldn't think this would even compile o_O;

Edit: using namespace std; is generally bad practice aswell.

8. Originally Posted by Okiesmokie
I don't even know what to say about this, but why is it there? I wouldn't think this would even compile o_O;
I took it out and it still compiled. Originally I put it in there because I thought it would be necessary to make my string work in the ShellExecute along with the fullurl.c_str(). I can't reference what I looked at that made me think such a thing. Maybe someone can shed light on why or why not the code still compiles with that "const char* c_str();"

Edit: using namespace std; is generally bad practice aswell.
I removed the using namespace std; and have since add std:: to everything. Thanks.

9. It's a declaration for a global function by the name of c_str that takes no arguments and returns a const char *. It's duly noted by the compiler, but since you never actually call a global function by this name, it's not used further.

10. Originally Posted by matsp
If you are using Microsofts C Runtime library, the function _splitpath will split a filename into portions for you.

--
Mats
I need a little clarification on this -- as I said already it did help me make my application work (thanks), but I want to know a little more.

As I understand it, being part of Microsoft's C Runtime library, this function is for Windows only. However, this isn't a 'win32 api' function? My original understanding was that in Windows, the basic breakdown was "c++ stl > win32 api [ mfc | atl | wxWidgets | QT ] and so on."

I'm not opposed to using a Windows only function to accomplish my goals since this is my current development environment, but is there code that can do the same thing and stay platform independent?

Perhaps that is what boost is. The way I've understood platform independence based on other posts is that I could write console application code that would compile under Mac/Windows/Linux without any code adjustments.

11. You can see what Boost.Filesystem offers you. The Boost libraries are generally written to be platform-independent or at least cross-platform.

_splitpath is not a Win32 API function. It is, as you say, part of MS's CRT. It's a utility function found useful, but not so essential that it was given Win32 API status, which is a very high status that carries a larger testing and general maintenance penalty for the dev teams than a CRT extension. Also, the dev teams of the API (in fact, of many different parts of the API) and the CRT aren't the same.

12. Originally Posted by CornedBee
_splitpath is not a Win32 API function. It is, as you say, part of MS's CRT. It's a utility function found useful, but not so essential that it was given Win32 API status, which is a very high status that carries a larger testing and general maintenance penalty for the dev teams than a CRT extension. Also, the dev teams of the API (in fact, of many different parts of the API) and the CRT aren't the same.
Because a function which splits pathnames is SO hard to test for correctness? Hell, it's probably so simple you could PROVE it to be correct. Hah.

I'm not poking at you, I'm poking at MS

13. WinAPI functions must work from many different languages, not just C and C++, whereas the CRT is only guaranteed to work for these two. That's quite the difference right there.