What is so special about running a c++ program through commnd line?

[dmatador]

I.e., what is beneficial about main(int argc,char *argv[])?

I see a lot of seemingly good programmers write the main like this, but what does it do that int main() cannot do?

 

[D H]

One word: Unix.

 

[davee123]

what does it do that int main() cannot do?

Quite simply, can't it NOT accept command line arguments, ever?

I guess it seems to me like NOT accepting command line arguments sort of the lazy way of approaching the problem. "99% of the time, my users won't want command line options, so I won't include them, because they're just THAT much harder to code." It might make sense when you're writing something that's more-or-less throw away code, or if you REALLY can't be bothered. But any program worth its salt will be versatile and accept command line options.

In the end, I would argue that it's just good practice. Get used to doing it, and you'll be writing better programs. Maybe only 1% better, but hey, you're more likely to be glad that you did it than glad you didn't.

DaveE

 

[TylerH]

Do you know what argc and argv are? Once you do, their use becomes apparent. argc is the number of arguments and argv is an array of char* that are those arguments.

 

[chiro]

I.e., what is beneficial about main(int argc,char *argv[])?

I see a lot of seemingly good programmers write the main like this, but what does it do that int main() cannot do?

Many programs use parameters on the command line to do useful things. If your program needs no other parameters as input, or has other ways of getting input (say using a default config file, through process objects like pipes, network and so on), then that's when you will probably just use int main() instead of the argc/argv vector method.

 

[rcgldr]

I've noticed some PC games use command line parameters to invoke a setup or debug mode.

Another possible use is for a multi-tasking application, because setting up inter task communication is awkward in windows (no shared memory). One method is for one task to pass information via command line parameters when invoking a second task, where the command line parameters are the first task's process handle value and some of that first task's handle values to be used by the second task for DuplicateHandle() to be able to access stuff from the first task (named handles can also be used).

 

[dmatador]

Do you know what argc and argv are? Once you do, their use becomes apparent. argc is the number of arguments and argv is an array of char* that are those arguments.

That part is obvious. I was trying to look for input from people who have strong and founded opinions about using command line.

 

[Grep]

That part is obvious. I was trying to look for input from people who have strong and founded opinions about using command line.

Simply put, command line is more flexible than a GUI for a lot of tasks, and for a fraction of the development work. Let's say you're a system administrator. You have a GUI for it, and only a GUI. You often have to do a series of steps (whatever they may be). It would be much easier if you could write a script to do them, but the program doesn't allow it, and so you end up doing all this repetitive work for nothing.

Instead, you could use command line programs and write a script to do all the steps. Then, you just run this script and there you go. Or you can schedule it to run at certain times. If your GUI doesn't have scheduling and a way of sequencing things, you're reduced to doing it manually every time. And adding those features to a GUI would be a lot of work. With a command line, you get it all for free.

That's without even getting into piping from one program to another to do something the creators of the two programs wouldn't have thought of. The whole becomes more than the sum of the parts.

Unix command line is truly, staggeringly powerful and flexible. I love GUIs and they have their place, but sometimes only the command line will do. It depends on the task. And GUIs usually take a lot more time to develop than a command line driven program. Nor are the two mutually exclusive, of course.

 

[rcgldr]

Simply put, command line is more flexible than a GUI for a lot of tasks, and for a fraction of the development work.

Command line and GUI interface aren't mutually exclusive. As I mentioned before, there may be a set of icons to launch a GUI based program, each with different command line parameters for invoking the GUI based program, such as a debug or setup mode option for an application.

Maybe the question is what is the point of using C++ for a command line program when most of the predefined classes are GUI oriented, so not much is being leveraged by using C++ for a command line program. An example where C++ is still an advantage is the standard template libary, which includes a more generic set of classes and functions (vectors, sorting, ...).

 

[Grep]

Command line and GUI interface aren't mutually exclusive.

Indeed. Pretty much what I said in the last sentence in my last post. I completely agree with your first paragraph.

Maybe the question is what is the point of using C++ for a command line program when most of the predefined classes are GUI oriented, so not much is being leveraged by using C++ for a command line program. An example where C++ is still an advantage is the standard template libary, which includes a more generic set of classes and functions (vectors, sorting, ...).

Don't know that I'd say that, though. In fact, C++ is completely independent from GUI toolkits. There is nothing about GUIs in any part of the C++ standard. Sure, C++ is well suited for GUIs, but there are many, many other tasks where it's just as well suited. C++ is not biased in any way towards GUI programming, really. It's a fully general purpose programming language.

 

[DrGreg]

I don't think anyone has mentioned yet that under Windows Explorer if you drag-and-drop one or more icons for documents onto the icon of an EXE file, all the filenames are passed to the EXE file as its argv list. I suspect this may also happen under other operating systems' GUIs.

It's quite convenient if your application needs to open a user-specified file, but you don't want the hassle of either typing the file name or selecting it through a dialog.

 

[story645]

I don't think anyone has mentioned yet that under Windows Explorer if you drag-and-drop one or more icons for documents onto the icon of an EXE file, all the filenames are passed to the EXE file as its argv list.

That's totally awesome.

It might make sense when you're writing something that's more-or-less throw away code, or if you REALLY can't be bothered.

Or if you really don't need it for whatever reason, like a library-most library code won't need to accept cmd lines args 'cause it's not meant to be accessed that way.

Maybe the question is what is the point of using C++ for a command line program when most of the predefined classes are GUI oriented,...

'cause a GUI is overkill for your needs?

*shrugs* I maintain a cmd line interface to my current python scripts because it's awesome for testing purposes: instead of opening up a script or config file to change some parameter, it's just a switch, which is super useful when I have to fiddle with the parameters a zillion ways to get something just right or if I just want to do something silly like change the file format for the figures I'm generating.

 

[Coin]

Maybe the question is what is the point of using C++ for a command line program when most of the predefined classes are GUI oriented

There are no predefined GUI classes... in fact

Sure, C++ is well suited for GUIs

IMO C++ is not well suited for GUIs. It's not object oriented enough. Notice how many GUI libraries immediately start by trying to break out of the C++ box and into a more dynamic language (Java, .NET, Cocoa, even WxWindows and Qt do crazy preprocessor stuff and are not proper C++).

 

[rcgldr]

There are no predefined GUI classes

For Windows, it's the CWnd class.

http://msdn.microsoft.com/en-us/library/1xb05f0h(v=vs.80).aspx