sur la declaration de la methode void main()

Version imprimable

Voir 40 message(s) de cette discussion en une page

05/08/2009, 19h33
Davidbrcz

Citation:

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.
07/08/2009, 07h50
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.
07/08/2009, 11h11
JolyLoic
Citation:

Envoyé par Melem

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:

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

Citation:

Envoyé par Melem

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

Ça, d'accord.
07/08/2009, 11h52
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.
07/08/2009, 17h41
Melem

Citation:

Envoyé par JolyLoic

Le sizeof n'est pas le seul contexte.

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

Citation:

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.

Citation:

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 ;).
08/08/2009, 18h01
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...)
03/12/2009, 17h03
guendalf

question toute bête

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:

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 ?
03/12/2009, 17h10
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.
11/12/2009, 18h32
koala01

Salut,

Citation:

Envoyé par 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...)

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 :D

Citation:

Envoyé par 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:

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:D

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:

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 :question:

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)...

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:

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); }

11/12/2009, 19h25
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".

Voir 40 message(s) de cette discussion en une page