Getting argv[] command line arguments.

[KazenoZ]

Hello,

Simple question this time, I hope, I have a program that collects an argument from execution on another program, the argument is the path to a file.

Now, the problem is that when I try to read the argument to a string using argv[1], it'll only get the first character of the string. Thing is, trying to do the same on argv[0], which, to my best understanding, is supposed to contain the name of the program, it also only gets the first letter of it, so I'm thinking that my method for doing this is not correct, although everywhere I looked online I was told that it's done just by any of the various methods of assigning to a string.

Can anyone just show me how it's done please?

Thanks alot.

[gerard4143]

Can we see an example of the string?

[Narue]

Why don't you post the code you've tried that doesn't work? We can show you where the problem is.

[KazenoZ]

Because it was a general question, I tried various ways and couldn't really decide what to show =\

This is a copy of an example from learncpp.com's tutorial's:

int main(int argc, char *argv[])  

02 {  

03     using namespace std;  

04     // If the user didn't provide a filename command line argument,  

05     // print an error and exit.  

06     if (argc <= 1)  

07     {  

08         cout << "Usage: " << argv[0] << " <Filename>" << endl;  

09         exit(1);  

10     }  

11    

12     char *pFilename = argv[1];  

13    

14     // open file and process it  

15 }

When I try to implement the same code, I will only get the letter 'C' from the path that I need, same thing would happen if I tried storing into a string instead.

[jonsca]

Because argv is a C-string, you have to use the methods in <cstring> (such as strcpy, strcmp)

char * pFilename = new char[strlen(argv[1])+1]; //room for null terminus '\0'
strcpy(pFilename,argv[1]);
//accomplishes what line 23 does

[KazenoZ]

No, it still only gets the first letter...

What exactly is that supposed to do though?

[jonsca]

Allocates room for a C-string in pFilename that's the length of argv[1] and room for the null character. Then it copies argv[1] to pFilename.

Is the above the exact code that you are using. If it isn't post exactly what you are running now.

[KazenoZ]

Yes, exactly the same:

int _tmain(int argc, char *argv[])
{
	char* location = new char[strlen(argv[1])+1];
	strcpy(location, argv[1]);
	cout << location;
}

Unless something is wrong with using just cout?

[jonsca]

No, cout can handle C-strings okay. Hmm, when I compiled and ran it, it had no problem (though I didn't try it in Visual C++). What parameters are you giving your executable, and are you putting them in at the command line directly or via the arguments option in VC++?

[Kanoisa]

Hi, i just thought id try with visual studio for you and it works just fine.

my code is as follows

#include <cstdlib>
#include <iostream>

using std::cout; using std::endl; using std::cin;

int main(int argc, char** argv)
{
    if(argc<2)
    {
        cout<<"Usage: "<<argv[0]<<" string"<<endl;
        return -1;
    }
    char* location = new char[strlen(argv[1])+1];
    strcpy(location, argv[1]);
    cout <<"Argv[1] = "<< location<<endl;

    cin.get();

	return 0;
}

my Terminal output

testArgv.exe "this is a test string"
Argv[1] = this is a test string

I am using visual studio 2008 express sp1 so i can confirm this code in the environment ,.. The only thing i am unsure about is that you use _tmain() and i am unsure how this affects arguments.

[KazenoZ]

Seems like that was it =\
I removed _t and it just worked, though stopped at space, is there a way to read it including spaces? And what exactly IS _tmain that it functions so differently?

Also, Jonsca, the argument is "C:\\Documents and Settings\\User\\My Documents\\Test\\data.gpj", and currently I'm entering it via the arguments option in VS, but evantually, it's supposed to be driven from another program that will start this one.

[Kanoisa]

Spaces act as a delimiter in the arguments to a program so to handle spaces your string must be enclosed with "" as the one i passed in had done. _tmain is a microsoft version of main to allow for wchar and unicode as far as im aware but from what little i understand of it it changes characters from being 8 bits to 16 bits. this i think throw off strcpy() and strlen() I hope this clears things up for you

[KazenoZ]

It kind of did.

Thanks alot for the help, both of you =)

[KazenoZ]

I'm sorry to be a bother again, but I'm running into a new problem as a result of changing to main now...

1>MSVCRTD.lib(crtexe.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

If I change back to _tmain, the linker error would go away and compile fine, but then I won't be able to get the whole string again...

[Kanoisa]

ok just to check a few things then, are you using a console project? what includes have you included in main, and are you using precompiled headers?

[KazenoZ]

Yes, it's a console project, I'm including stdafx.h, fstream, iostream, and string, as well as 3 headers I made myself.

#include "stdafx.h"
#include <fstream>
#include <iostream>
#include <string>
#ifndef MAP
#define MAP
#include "Map.h"
#endif
#ifndef PROJECT
#define PROJECT
#include "Project.h"
#endif
#ifndef CHARA
#define CHARA
#include "Char.h"
#endif

And the option for precompiled headers is set to using(/Yu), and the value is $(IntDir)\$(TargetName).pch, just what VS creates by itself.

[Kanoisa]

Ok i tried adding the tchar and stdio includes to my project to see if it made any difference and as i suspected it did not produce the warning you are seeing,... it is possible something in the precompiled herader is causing this issue have you tried doing a project clean and a rebuild as well as swapping your main function to change to the normal definition of main. I think there may be something lingering from a previous build

If this fails you then im afraid without being able to access your project i cant think of what the issue is sorry.

[jonsca]

i suspected it did not produce the warning you are seeing,...

I would say try starting a new project and copy your files into it (or you could try turning off multibyte characters under Project/<Projectname> Properties/Configuration Properties/Character Set and setting it back to Unicode, but I'm not sure if that will work).

[KazenoZ]

I just tried creating the project anew and adding the files into it, it works and compiles fine, until I put the command argument again, then it gives the same error.

Which is weird, because if I take the argument out of the previous, existing, project, it would still produce that same error.

Also, clean and rebuild didn't work, and I wasn't really sure about what you meant by the normal definition of main.

[jonsca]

I'm not sure what to tell you, this is one of those things that is difficult to diagnose, as it's some setting that you are selecting. Zip up and attach the directory of the project to your post.

[WaltP]

Try running the program from the command line and add your parameters there. See what happens.

[KazenoZ]

It can't run from the command line, it's not compiled yet, I have no .exe to run.

Either way, this is the folder of the project.

[jonsca]

I don't have SDL so I can't compile it readily.

Try putting the argument in quotes and/or eliminating the double backslashes -- you should only need those when writing strings in your code, not when entering them in.

[KazenoZ]

It already had quotes, and removing the doubles didn't work, but I don't find it much of a surprise when even removing the whole argument all together, didn't work either =\

Got any other suggestions?

Edit: Just a heads up, another Google search with some new input from this thread had turned my attention to that I would also need to include SDLmain.lib, I didn't think of it, since it was never really neccassery for any of my projects so far, apparently it has something to do with the conversion from _tmain to main, as it fixes it.

However, it now produces the Linker warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

Which, if I do use the /NODEFAULTLIB, would cause about a million other errors, however, upon some further reading, it says that this warning doesn't really have much affect on SDL programs, so, I guess that for now atleast, I would stick with that.

Unless you might know something about it too, that would really help.

[jonsca]

I'm getting a bit confused because it sounds like part of the time you are having problems once you've entered the command and it sometimes sounds like you can't compile the project. You also gave an example program that in no way represented what was really going on...that's forgiven, but it's good to know the whole story.

You also say that this program is being started by another program. Is it possible there's a problem with the other program? If you have to, for the time being, write out the path into a text file and read that into this program to get the filename.

Edit: I had failed to connect you were the one doing .net stuff in your other program, sorry, lol

[KazenoZ]

lol, it's ok, no worries.

Also, I don't really know, I don't see how these contradict eachother; the program used to compile, until I don't know what changed really, then it started giving out these errors and wouldn't compile anymore, the new project, having the files pasted into it, would only compile while it had no command arguments to take, and would give the same error, if it had.
Then, adding SDLmain.dll to the dependencies, would solve those errors, but would give a warning instead, a warning doesn't stop you from compiling after all.

Either way, the other program is fine, since the failure is in compilation, which doesn't rely on the program that launches it, after it's compiled.

[Fbody]

lol, it's ok, no worries.

Also, I don't really know, I don't see how these contradict eachother; the program used to compile, until I don't know what changed really, then it started giving out these errors and wouldn't compile anymore, the new project, having the files pasted into it, would only compile while it had no command arguments to take, and would give the same error, if it had.
Then, adding SDLmain.dll to the dependencies, would solve those errors, but would give a warning instead, a warning doesn't stop you from compiling after all.

Either way, the other program is fine, since the failure is in compilation, which doesn't rely on the program that launches it, after it's compiled.

You've marked the thread solved, but it doesn't sound like it is. Did you figure it out?

[KazenoZ]

Well, yea, the program compiles and runs fine now, regardless of the warning I get, I don't think it really matters much, would be nice to know the answer to that, but I don't think it's much reason to prevent the people who helped me here from getting their solved thread count higher.

[jonsca]

it's much reason to prevent the people who helped me here from getting their solved thread count higher.

Hehe, it is how I make my commission to feed my 10 children. Only kidding -- we'd be happy to keep helping you, it's just it's one of those quirky bugs that seems to pop up intermittently (as your command line parameters shouldn't bring anything to bear on the compilation). Definitely keep it open and see if someone who does SDL on a regular basis has run into this before.

[Fbody]

I'm wondering if it has something to do with the character type being used. I've been looking for documentation on them, but I can't find the "wide" versions of strcpy(), strcmp() etc... I know I've read about them...

I think they're called wstrcpy() and/or similar, but I must be mistaken.

EDIT:
Found it. Schildt, C++ The Complete Reference, Fourth Edition; Chapter 31: The Wide-Character Functions. Do some research on the <cwchar> and <cwctype> headers. They contain a lot of stuff for manipulating "wide" character strings. Maybe there is something in there, like wcsncpy(), that may be useful.