Talk:Main function

Languages that don't use main

Why on earth are Ruby and other languages that don't use "main" listed on this page? All their descriptions say is "this language doesn't use main". That's like writing a page about wheels, and having huge sections of the page devoted to fish because "fish don't have wheels". It makes no sense.

If Ruby were somehow unique in it's non-use of main, it might make sense to include it here. But it's not. There are literally hundreds of other languages that don't use main that aren't listed here. How about Rexx, for instance?

This smacks of favoritism. There is no other logical reason to include these languages on this page--and certainly not a whole section to themselves! If it were a single sentences like "Some languages, such as Ruby, do not use a main section." that might be acceptable. But devoting a whole section to a language that has NOTHING to do with the topic of the page is blatant promotionism.

Computer languages not relevant to the use of "main" should be removed from this page. Alternatively if this is not possible for some reason, a less-biased and more inclusive listing of languages that do not use main should be supplied instead. —Preceding unsigned comment added by 68.14.228.19 (talk) 04:32, 2 July 2008 (UTC)

I'm going to have to agree with you on this one. Very odd to have those on this page. I propose these languages lacking Main be removed from the page as well. Barring any valid suggestion contrary to this I'll do it here in the next few days when I have a few minutes.BcRIPster (talk) 05:26, 8 July 2008 (UTC)

args, argc, argv

Java uses the space character as a delimiter for separate elements in the args array. Are there any other characters that act as delimiters (such as "-" or "/")? What about other programming languages? --Abdull 18:29, 16 April 2007 (UTC)

I don't think this is strictly defined anywhere in the standard - it's OS-specific. -- int19h 06:02, 18 April 2007 (UTC)

Correct. The language defines the interface that the O/S should use to pass command line arguments to the program. It is the O/S that determines the format of those arguments on the command line. wrp103 (Bill Pringle) ^(Talk) 14:23, 18 April 2007 (UTC)

On the other hand, IIRC DOS (and Windows) doesn't parse the command line into arguments and passes a single string to the executable, which then has to parse it itself. Might this differ between Windows-hosted environments? –EdC 05:53, 19 April 2007 (UTC)

Yes, it might be that. In case of Windows, it provides the GetCommandLine API function which returns the entire command line as a single string, and it's up to the C library to parse it correctly. Nonetheless, I am not aware of any DOS/Windows C compilers which do not adhere to the standard DOS/Windows conventions in that regard (in particular, that '/' is also a separator). -- int19h 07:16, 19 April 2007 (UTC)

I infer from your username that you know more about DOS than I do, but to avoid misleading readers of this page in the future... '/' (forward slash) is not an argument separator on any system I know. No modern Windows programs treat / as a separator in argument lists, because if they did, you wouldn't be able to specify paths in Unix style: "foo/bar/baz" must be treated as one argument, not three (or five?). However, DOS and Windows do assume that '/' won't appear in command names, so "hello.exe/foo/bar baz" will try to execute "hello.exe" with arguments "/foo/bar" and "baz", rather than executing "hello.exe/foo/bar" with the single argument "baz". --Quuxplusone 01:02, 19 May 2007 (UTC)

DOS and Windows do assume that '/' is an argument separator. For example, dir c:/w will not do a listing of directory C:\W - it will treat /w as a switch, with the end result the same as for dir /w c: (try it!). Similarly, your example with hello.exe/foo/bar baz would be treated as hello.exe /foo /bar baz - this is commonly used in DOS to shorten commands by cramping the switches together with no whitespace, for example: dir /enwiki/w/b/on C:\ (wide listing, lowercase names, order by name). On the other hand, dir "c:/w" treats the entire quoted string as a Unix-style path. To sum it up: Unix style paths are allowed in DOS/Win world, but slash in command line is treated as an argument separator where possible (i.e., in any case except when it's a non-first character in a quoted string). At least that's how it works for built-in and standard commands, third-party ones can be different - I've seen quite a few which allow for switches to begin with slash, do not treat slash by itself as a separator. -- int19h 08:52, 19 May 2007 (UTC)

As far as I know, that is specific to the built-in commands like dir, cd, copy, ren, del, etc. and doesn't apply to external .exe's 201.212.126.164 22:01, 5 September 2007 (UTC)

For the record, under unix the argument parsing is done by a shell, which means it is neither apart of the language nor the operating system. 23:25, 26 June 2007 (UTC)

"It is guaranteed that argc is non-negative and that argv[argc] is not a null pointer" AFAIK is wrong. argv[argc] is guaranteed to be NULL in ANSI C. Historically, it used to be -1 up to Unix V6. —Preceding unsigned comment added by 79.124.84.16 (talk) 18:40, 12 October 2010 (UTC)

apple vector

According tho this article: http://unixjunkie.blogspot.com/2006/02/char-apple-argument-vector.html There is a 4th argument passed to main in both the Mac OSX and darwin OS. —Preceding unsigned comment added by 76.169.2.116 (talk) 10:24, 4 March 2008 (UTC)

Nice. Added. EdC (talk) 13:17, 8 March 2008 (UTC)

Isn't it 'where execution begins' but also

'ultimately ends'? --Leladax (talk) 19:11, 27 July 2008 (UTC)

Not if you program concurrently.188.57.17.168 (talk) 19:41, 25 April 2013 (UTC)

Reference is just text?

How is reference 1 valid? It doesn't cite any source and tries to validate itself because "that's the way it is" apparently. 66.72.215.225 (talk) 19:53, 31 August 2009 (UTC)

Needs more details

It would be helpful to add more details of how the main method is used in various programming languages, including some of the more important commands that are called within "main." --AFriedman (talk) 20:32, 10 December 2009 (UTC)

C/C++ Main Function

int main() means the same thing as int main(void) and is valid in both c/c++. I realize the standards documents for c and c++ are inconsistent in how they show this particular case.  snaphat ► 01:18, 10 August 2011 (UTC)

For C++, Section 8.3.5 Functions of the Working Draft, Standard for Programming Language C++ states "The parameter list (void) is equivalent to the empty parameter list."  snaphat ► 01:30, 10 August 2011 (UTC)

For C, Section 6.7.5.3 Function declarators of (including prototypes) of the ISO/IEC 9899:TC3 (Final Draft of C99 including revisions) states "The special case of an unnamed parameter of type void as the only item in the list specifies that the function has no parameters."  snaphat ► 01:32, 10 August 2011 (UTC)

int main() means the same thing as int main(void) in C++, but not in C, as you've quoted. --Cubbi (talk) 05:15, 10 August 2011 (UTC)

That is correct if you are referring to non-prototype declarations in C. However, we are only talking about prototype declarations and definitions. Specifically, I will use an example (which is assuming C):

//Non-prototype declaration.
void foo();

//prototype declaration.
void bar(void);

//Prototype declaration and definition.
void foo(void) {}

//prototype declaration and definition.
void bar() {}

Since the article is specifically referring to function prototypes, the cases we are talking about are the 2nd through 4th declarations. The 1st isn't a prototype declaration; ergo, what I stated is true.  snaphat ► 17:18, 10 August 2011 (UTC)

Oh, I should have stated that this section is in regard to an edit that added both int main() and int main(void) prototype variants for main and confused the issue by specifying one as from c++ and the other as c based on specific examples found in the corresponding standards documents.  snaphat ► 21:15, 10 August 2011 (UTC)

How are function prototypes even relevant given that "The implementation declares no prototype for this function." (9899:1999 5.1.2.2.1/1)? Anyway, I do agree that mixing up C and C++ in the same chapter of this page is terribly confusing, if that's what you're getting at. --Cubbi (talk) 04:22, 11 August 2011 (UTC)

The point of that statement is simply to say the user is responsible for declaring function mains prototype- not the implementation. It is worded as such so that implementations themselves do not attempt to declare a function prototype for main. It is not saying that main doesn't have a prototype. By definition main has one of the two prototypes written in 9899:1999.  snaphat ► 12:45, 11 August 2011 (UTC)

Suppose, I should have said that it can have any number of prototypes, those are just the ones defined by the standard.  snaphat ► 13:45, 11 August 2011 (UTC)