Why is the application entry point a static method?


A method declared static means that it belongs to the type rather than the instance of an object.

In a C # console application, the entry point is static:

static void Main(string[] args) { ...  }

This is not just C #, in Java it's the same concept:

public static void main(String[] args) { ... }

It is also not limited to console applications. A WPF project has a static entry point.

In questions that already exist on the subject does not explain about static beyond its obligation without justification and definition:

Why are application entry points static?

The application itself, initially, is not an object instance of type Application or ConsoleApplication (ie the name I gave to the class containing the input method), for example?

asked by anonymous 19.10.2017 / 12:12

1 answer


Initially the application is not an instance of anything. And in a way this explains why the method is static.

It could be an instance method, there is nothing technically that prevents doing it this way, that's just how they chose, perhaps because it has always been like that in other languages before C #, most of which do not even have the concept of classes and instantiation of objects.

It could be more, could leave another method, perhaps even with another signature, leaving even other arguments. Remember that you need to tell which type to use as entry point . And it can have Main() in any type without it being an entry point.

Android instantiates objects and does what it needs. For the operating system model is more interesting. But traditional operating systems have always had a unique way of starting an application. So I would say they chose it so even for historical reasons, everyone was accustomed to do so.

In non-object-oriented languages a function is used as an entry point, and the static method is the same as a function.

I think understanding using the static method helps you understand this decision. Contrary to OOP ideologues, a static method is always simpler to deal with, and should always be preferred where it fits (it does not fit into a lot of situation). Main() is a case that fits like a glove.

I do not see as much of a problem as they said in the comments, but it does make sense. Simplification seems to me the best argument to avoid this feature that would bring little or no advantage. Language developers are pragmatic and analyze the costs of implementing something, complicating the language and the benefits it will bring.

One point I think you can take into consideration is that you may want to call this Main() within your application. You then need to instantiate another object, because the object that started the application is owned by CLR (unless you are passing it back and forth in the application). If it is another instance, although it will physically call the same method, you are accessing another object, with possibly different data, it may not be what you want.

In C # you can use 4 different signatures (not simultaneously):

static void Main();
static void Main(string[] args);
static int Main();
static int Main(string[] args);

In C # 7.1 it can even be more because Main() can be asynchronous.

19.10.2017 / 14:36