Discussion :

[Davidbrcz]

Un tableau n'est jamais copié par une fonction

C'est plutôt faux. Par défaut, tu vas passer un pointeur sur le premier élément tu tableau. Pointeur qui va être passé par copie. Si tu veux agrandir le tableau dans la fonction tel qu'elles sont définies, tu vas avoir des fuites de mémoire.

[Melem]

J'ai dit un tableau n'est jamais copié par une fonction. Pas un pointeur vers un élément d'un tableau n'est jamais copié par une fonction. Pour ajouter de la précision, le nom d'un tableau lorsqu'il n'est pas utilisé seul en argument de sizeof est toujours converti par le compilateur en l'adresse de son premier élément (c'est dans les textes des normes du C et du C++, et aussi dans la FAQ C), donc impossible qu'un tableau sera passé par valeur (par valeur = par copie) à une fonction.

[JolyLoic]

Pour ajouter de la précision, le nom d'un tableau lorsqu'il n'est pas utilisé seul en argument de sizeof est toujours converti par le compilateur en l'adresse de son premier élément (c'est dans les textes des normes du C et du C++, et aussi dans la FAQ C),

Le sizeof n'est pas le seul contexte. typeid non plus, ou passer un tableau par référence à une fonction (le fameux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
template<class T, std::size_t N>
std::size_t size(T (&array)[N])
{
    return N;
}

)

donc impossible qu'un tableau sera passé par valeur (par valeur = par copie) à une fonction.

Ça, d'accord.

[Jean-Marc.Bourguet]

Ce n'est pas le nom d'un tableau qui est important, c'est le fait que ce soit une valeur de type tableau. Que le tableau soit nomme ou non (dans le cas des tableaux multidimentionnels et des pointeurs vers tableau, il n'y a pas de nom pour ces objets, pourtant la conversion a lieu).

En C, il y a deux contextes ou la conversion n'a pas lieu: argument de sizeof et argument de &.

En C++, il y a en plus le passage d'arguments quand la fonction est capable de prendre une reference vers le tableau (que la fonction soit template ou pas). Les regles de gestion des ambiguites pour raison de surcharges et de deduction des arguments templates sont complexes et avec des effets parfois surprenants.

En prime, si un objet est passe par valeur et qu'il a un membre tableau, celui-ci est naturellement copie.

[Melem]

Le sizeof n'est pas le seul contexte.

C'est vrai. Même dans un forum C++, j'ai toujours la tête "C" .

En C, il y a deux contextes ou la conversion n'a pas lieu: argument de sizeof et argument de &

En effet, je l'ai oubliée mais elle est bien présente dans la FAQ.

Ce n'est pas le nom d'un tableau qui est important, c'est le fait que ce soit une valeur de type tableau (...) (dans le cas des tableaux multidimentionnels et des pointeurs vers tableau, il n'y a pas de nom pour ces objets, pourtant la conversion a lieu).

Waw, il y a de la rigueur dans l'air ... et aussi de quoi mettre à jour la FAQ .

[ptyxs]

A propos du titre de ce fil : main() n'est pas une 'méthode' mais une fonction, à ce qu'il me semble...

(Du reste, par parenthèses, j'ai l'impression qu'en C++ le terme 'méthode', employé pour désigner une fonction définie dans une classe (donc pas main()), tombe en désuétude : dans les bouquins de Stroustrup, Meyers etc. ce terme est inexistant ou très rare, du moins d'après mes souvenirs...)

[guendalf]

Pendant qu'on y est avec les réponses expertes sur les formes autorisées du main... quelqu'un pourrait m'expliquer pourquoi on ne peut pas faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int main(int argc, std::string argv[])

Parce qu'être encore obligé de manipuler des char* en C++ en 2009, c'est dommage je trouve, non ?

[Médinoc]

Parce que ça n'est pas binairement compatible, peut-être?

Encore qu'avec la surcharge de fonction, on devrait pouvoir faire des chaînes de compilation qui acceptent ça. .Net et Java suivent cette voie, après tout.

[koala01]

Salut,

A propos du titre de ce fil : main() n'est pas une 'méthode' mais une fonction, à ce qu'il me semble...

(Du reste, par parenthèses, j'ai l'impression qu'en C++ le terme 'méthode', employé pour désigner une fonction définie dans une classe (donc pas main()), tombe en désuétude : dans les bouquins de Stroustrup, Meyers etc. ce terme est inexistant ou très rare, du moins d'après mes souvenirs...)

Typiquement, on accorde au terme méthode le fait de représenter une fonction membre ayant un comportement polymorphe (le fait que la fonction soit déclarée "virtual" pour faire simple) alors que pour tout autre type de fonction (libre ou membre et non polymorphe) on utilisera de préférence le terme fonction.

Mais tout cela n'est que du à la sensibilité des gens

Pendant qu'on y est avec les réponses expertes sur les formes autorisées du main... quelqu'un pourrait m'expliquer pourquoi on ne peut pas faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int main(int argc, std::string argv[])

Parce qu'être encore obligé de manipuler des char* en C++ en 2009, c'est dommage je trouve, non ?

Je vois plusieurs raisons à cela, mais peut-être fais-je tout à fait fausse route...

En premier lieu, nous pourrions nous appesantir sur le poids de l'héritage issu du C, car il n'y a, à ma connaissance, aucune différence lors du lancement d'une application écrite en C par rapport à une application écrite en C++.

Java et C# travaillant "derrière" une machine virtuelle, il était possible d'envisager le changement, mais, étant donné que nous sommes limités, pour le lancement de l'application, aux différentes bibliothèque du runtime (kernell32 dans le cas de windows), et en attente d'une uniformisation de l'ABI C++, il peut sembler "cohérent" de s'en tenir au dénominateur "le plus grand commun multiple", à savoir... l'interface C

La deuxième raison que je soupçonne est de ne pas vouloir ajouter une dépendance là où elle n'est pas forcément nécessaire:

Si l'on suivait le raisonnement jusqu'au bout, nous pourrions presque envisager de faire en sorte que le prototype de la fonction devienne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int main(std::vector<std::string> argv)

mais cela impliquerait une dépendance forcée vis à vis de la classe string et de la classe vector, alors... que ce serait peut être le seul endroit (accessible au départ de main, s'entend) où elle pourrait s'avérer nécessaire

Enfin, comme l'a fait valoir Médinoc, peut être n'est ce "simplement" que parce que la classe string n'est pas binairement compatible

Il me semble qu'il était question de lancer une "traque" à toutes les fonctions C++ manipulant encore des chaines de caractères C style afin de les remplacer par leur équivalent manipulant des std:: (w)string, mais, si l'on peut, effectivement envisager de remplacer le constructeur d'un i/o fstream, un remplacement similaire au niveau de main nécessiterait une refonte en profondeur de l'existant sur les différents système.

Et comme il est plus "sensé" de faire en sorte qu'un langage s'adapte (sans trop de mal) aux environnements sur lesquels il est employé que de demander aux différents environnements de s'adapter aux exigences d'un langage (surtout si le langage en question a vocation à rester "aussi près que possible" du matériel)...

[Médinoc]

Je sais que cela ne tient pas debout sous Windows, puisque le processus ne reçoit qu'une ligne de commande, et c'est lui qui la sépare avant d'appeler main().

Mais d'ailleurs, ça ne triendrait pas debout ailleurs non plus: Après tout, rien n'empêche d'écrire un point d'entrée ainsi:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int main(int argc, char *argv[])
{
	std::vector<std::string> args;
	for(int i=0 ; i<argc, i++) //Démarrer à 1 si on saute la commande
		args.push_back(std::string(argv[i]));
	return main(args);
}

[Lavock]

En fait, main, c'est tout un ensemble de directive système compliqué, juste histoire que ton processus s'intègre complétement dans ton OS. C'est principalement ce qui cause le problème de non-portabilité entre OS d'une même architecture (ça + les lib bas niveau).

Aussi en c++, il est facile de faire éxecuté du code un peu dangereux (en le plaçant dans un constructeur d'objet static), qui s'exécutera avant le main.

Sinon, je rejoint la majorité, void main est non-standard est ne devrait pas être utilisé. Libre à toi de respecté se standard.

Quand à la valeur retourner, elle dépend du système, et se trouve dans stdlib.h. Un code portable se verra toujours retourner EXIT_SUCCESS en cas de "réussite".