I didn't say there was a reason to use void main(). I was talking about whether to include an arg list/arg count or not while still having the return type of integer which is completely fine. I also didn't say that I don't like C++ (rusty with it maybe, but I have no bitter feelings towards it). Man, the internet sure makes some people feel big.

I was talking to zeronis, not you. He said

what about void main()? Working fine for me...

So please read more carefully next time before making silly accusations!

If you do not want to remove the names of the parameters:

#include <iostream>
    #define UNREFERENCED_PARAMETER(x) x

    int main(int argc, char* argv[])
    {
    UNREFERENCED_PARAMETER(argc);
    UNREFERENCED_PARAMETER(argv);
    std::cout<<"Hello, world!\n";
    }

If you do not want to remove the names of the parameters:

#include <iostream>
    #define UNREFERENCED_PARAMETER(x) x

    int main(int argc, char* argv[])
    {
    UNREFERENCED_PARAMETER(argc);
    UNREFERENCED_PARAMETER(argv);
    std::cout<<"Hello, world!\n";
    }

That's hideous. I fail to see how any of these workarounds are better than simply not defining unused parameters in the first place.

It makes totally no difference in the example above, but let's consider more sophisticated case: MFC's OnSize handler must have the following signature:

void OnSize(UINT nType, int cx, int cy);

Here cx/cy are the window's new width/height and nType is a code like SIZE_MAXIMIZED if the window is being maximized or SIZE_RESTORED for normal sizing. Usually you don't care about nType; you only care about cx and cy. So you need UNREFERENCED_PARAMETER(nType) if you want to compile with /W4. OnSize is just one function among thousands in MFC and Windows. It's hardly possible to write a Windows-based program without unreferenced parameters.
So much for UNREFERENCED_PARAMETER.
Аnother trick C++ programmers often use to achieve the same result is to comment the parameter name out of the function signature:

void CMyWnd::OnSize(UINT /* nType */, 
  int cx, int cy)
{
}

Now nType is an unnamed parameter, the same as if you'd typed OnSize(UINT, int cx, int cy). So now the key question is: which method should you use — unnamed parameters or UNREFERENCED_PARAMETER?
Most of the time it makes no difference, it's purely a style thing.
But I can think of at least one situation where UNREFERENCED_PARAMETER is required. Suppose you've decided to disallow maximizing your window. You disable the Maximize button, remove Maximize from the system menu, and block every other place the user could maximize. Because you're paranoid (and most good programmers are paranoid), you add an ASSERT to ensure that your code is working as you intended:

void CMyWnd::OnSize(UINT nType, int cx, int cy)
{
  ASSERT(nType != SIZE_MAXIMIZE);
  ...   // use cx, cy
}

The QA team runs your program 87 ways and the ASSERT never bombs, so you figure it's safe to compile a Release build. But now without _DEBUG defined, ASSERT(nType != SIZE_MAXIMIZE) expands to ((void)0) and suddenly nType becomes an unreferenced parameter! There goes your clean compile. You can't comment nType out of the parameter list because you need it for the ASSERT. So in this situation—where the only place you use a parameter is within an ASSERT or other _DEBUG-conditional code—only UNREFERENCED_PARAMETER will keep the compiler happy in both Debug and Release builds. Understood?

commented: We're talking about main(), not any function with a fixed signature -4

It's worse to use "int main(int argv, char** args)" because you loose two variable names if you won't use command line arguements or if the system does not support it .)

Wow are we really having a 4 page long thread about this. I don't get whats the problem. You guys/girls/its needs to get some fresh air and forget this thread ever happened

commented: Especially since the OP has made 1 single post. +16

@Tellalca,

Your logic is terrible.

It's worse to use "int main(int argv, char** args)" because you loose two variable names if you won't use command line arguements or if the system does not support it .)

Luckily there's literally 1.1478385914378332077745140144861e+457 other variable names to choose from.

I was talking to zeronis, not you. He said...

Funny how you quoted my post while saying that.....

If you do not want to remove the names of the parameters:
C++ Syntax (Toggle Plain Text)
#include <iostream>
#define UNREFERENCED_PARAMETER(x) x

int main(int argc, char* argv[])
{
UNREFERENCED_PARAMETER(argc);
UNREFERENCED_PARAMETER(argv);
std::cout<<"Hello, world!\n";
}

Waste of 2 lines of code, decreases code readability, in that case why wouldn't you just use normal int main().

Funny how you quoted my post while saying that.....

Don't see anything funny

Don't see anything funny

Funny as in unusual, not funny as in ha-ha. The suggestion is that by using a quote without specifying whom you're addressing, you're replying to the person being quoted. So it's not unreasonable for that person to assume you're referring to them. However, it is unreasonable to get your panties in a twist when that person further replies to you as if you were referring to them, which you apparently did here:

So please read more carefully next time before making silly accusations!

Just FYI.

It seems that int main(void) is unnecessary as the "void" here is implied. Thanks guys, I will keep this info in mind.

Waste of 2 lines of code, decreases code readability, in that case why wouldn't you just use normal int main().

I have explained why use those macro in details in my previous post already.

What is the difference between "int main(void)" and simply "int main()"? Is "int main()" acceptable?

In the int main(void)You are saying system that no parameters are there as well as ur second argument is same only the difference is first argument is saying computer there are no parameter and in second the system is automatically able to check that no parameters are there.

i think this may help you.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.