Passage de pointeurs ?

Ca peut etre le cas , ca sert pas qu'a faire de l'affichage . Remplir une matrice 15*15 ou realloc dynamiquement c'est moche de mettre 10-15lignes dans le code a chaque fois

Y a pas que le passage par valeur dans la vie. Passage par références, pointeurs... Une variable peut aussi être un tableau, etc.
Et heureusement ! Sinon on serait quand même super limités...
Bref, CTLP

Techniquement, la valeur que tu passes est une adresse. Tu peux modifier la variable qui s'y trouve, mais ce n'est pas vraiment elle qui a été passé en paramètre. J'hésiterais donc à réprimander Dorni sur cette base. Mais bon... ça reste une question de français plus que de programmation.

Ce qui est malheureux, c'est qu'on ignore de quel langage il est question ici. Dans ceux que je connais, une valeur passée en paramètre se verra copié sur la pile et une modification de la copie elle-même (et non ce vers quoi elle peut pointer) n'aura donc pas d'incidence sur la valeur originale. Mais est-ce toujours le cas? C'est une question qui mérite d'être posée et je ne serais pas prêt à parier sur la réponse. Même en C/C++ il faut réfléchir un peu. D'après-vous, qu'arrive-t-il si on "inline" une fonction? La copie se fait-elle quand même? Si elle ne se faisait pas et que le paramètre était modifié, la modification serait fait sur la valeur originale elle-même! Mais n'ayez crainte, une fonction, même marquée "inline" par le programmeur, ne sera jamais "inlinée" par le compilateur si un paramètre est modifié.

surtout que tu précises même pas de quel langage il s'agit

Nan mais ça peut, mais en général ce n'est pas le cas.

Perso je pense naïvement au PHP étant donné que c'est ce que j'utilise le plus : il y a une syntaxe spécifique pour passer des variables par référence à une fonction, laquelle peut donc réellement agir sur les emplacements mémoires représentés par ces variables. Mais de base, c'est un comportement "traditionnel" : les variables passées à la fonction sont "copiées" en tant qu'arguments de cette dernière (mon explication sucks un peu techniquement mais vous voyez le truc).

(Je précise pour la postérité que cette distinction s'effectue dans la déclaration de la fonction en question, et pas dans son appel, chose qu'on pouvait faire avant mais qui est dépréciée depuis quelques versions mineures.)

Effectivement, en VB.Net tu peux passer un paramètre ByVal ou ByRef, en C# tu peux préciser ref ou out sur un paramètre, etc...

Ça dépend du langage.
CTLP.

Il a raison, BEDP.
Vous evoquez les pointeurs et autres passages par référence, donc la valeur (de la référence ou du pointeur) passée à la fonction n'est pas modifiée.

M'enfin, ici comme en tout, il y a plusieurs points de vue possibles.

Tel que c'est écrit, le prof soutient que TOUT passage de paramètre se fait par référence.
Donc BEDP.

Et si on veut être vicieux, on peut parler de Java où les paramètres des méthodes sont systématiquement passés par valeur. Mais comme on ne manipule pas les objets directement comme on pourrait le penser naïvement quand on découvre le langage, mais par référence, les objets eux-mêmes peuvent être modifiés.

Extraits de http://docs.oracle.com/javase/tutorial/java/javaOO/arguments.html :

Primitive arguments, such as an int or a double, are passed into methods by value. This means that any changes to the values of the parameters exist only within the scope of the method. When the method returns, the parameters are gone and any changes to them are lost.

Reference data type parameters, such as objects, are also passed into methods by value. This means that when the method returns, the passed-in reference still references the same object as before. However, the values of the object's fields can be changed in the method, if they have the proper access level.

"qu'une fonction modifiait les valeurs des variables que l'on passe en paramètre."
Ça pouvait être une fonction ou un langage en particulier... vu que ce PEBKAC manque de précision on devrait accorder le bénéfice du doute au prof.

Je renchéris, ce serait bien de savoir de quoi on parle ici !

Le problème c'est que le langage n'est pas précisé dans le PEBKAC. En général les deux modes sont possibles (passage par valeur ou référence), mais je ne serais pas étonné qu'il en existe qui passent tout par référence. Ou alors qui passeraient les paramètres par référence si rien n'est précisé, le COBOL par exemple le fait.

Idem, c'est un peu vague. Impossible de voter BEDP ou CTLP.

Ben, elle modifie la valeurs si la variable et pointé CTLP, de plus sur certain système (wlanguage ...) la variable est pointé par défaut, il faut donc précisé l'inverse à savoir quel est local.

cela dépend complètement du langage utilisé, sans autres précisions on est obligé de dire qu'elle est modifiable , pas nécessairement modifié mais pour le coup CTLP

Vous omettez le passage sur les contre-exemples.

En php les objets sont passés par référence, pour les valeurs il faut mettre un & devant le nom de la variable si on veut la passer par référence.

Bande de moi, va !

Certes, un bon contre-exemple invalide un argument. Mais là nous n'avons pas d'exemples de ces contre-exemples, on ne peut pas juger.

EDIT: de plus rien ne précise que le langage appris est connu des étudiants.

En C# si tu passes un objet "maison" en paramètre il est forcément par référence, tu pointes vers le même emplacement mémoire, donc si tu le modifies dans l'appelée, l'appelant le récupère modifié.
Seul les types primitifs doivent être précisé ref (même emplacement mémoire) ou out (l'appelé doit modifier la valeur) pour être pris par référence.

Mais le problème que vous posez vaut pour tout PEBKAC.
Tout PEBKAC peut être remis en cause avec un contexte et des paramètres inconnus ou peu clairs.

Or, il me semblait que l'on considérait l'auteur comme la personne ayant raison par défaut, sauf preuve manifeste du contraire. Ce qui n'est pas le cas ici.

Pas mal de langages "recents" font du passage par reference :
- Java
- Python
- ...

Je suis d'accord avec toi, mais dans le cas présent, je maintiens qu'il manque des éléments pour voter.

"Ce cours-ci, il a expliqué et soutenu [...] qu'une fonction modifiait [toujours] les valeurs des variables que l'on passe en paramètre" m'aurait clairement fait pencher du côté du BEDP.

À un mot près c'est dommage... Et je veux bien être considéré comme tatillon mais je ne serais pas le seul à plonger !

Bon ok, je ne suis pas programmeur, mais le passage par référence je l'ai vu dans à peu prêt tous les langages que j'ai cotoyé (PHP, C, PowerShell, ptet C++ et Perl là je ne me souviens plus).
Et je ne vois pas comment l'expliquer autrement que la fonction modifie la variable qui lui est passée en référence (car on lui passe bien la référence/pointeur/adresse d'une variable externe à la fonction, donc on modifie son contenu soit la valeur de la variable).

D'ailleurs, sur les sites des éditeurs de ces langages (enfin pour PHP et PowerShell), c'est toujours expliqué comme ça.
Exemple : http://php.net/manual/fr/language.references.pass.php

Donc je valide l'explication du prof, mais il est vrai que ce n'est valable QUE dans ce cas présent, et qu'il ne faut pas le généraliser.

passage par référence en C?? Oo

point soumis à controverse :
http://javadude.com/articles/passbyvalue.htm

Je ne suis pas programmeur, je le répète. On appelle ça un passage par référence en PHP. En C, ça doit être le passage par pointeur ou quelque chose dans le genre, appelez-le comme vous voulez je ne suis pas pointilleux là dessus, mais au final ça reviens au même dans l'utilisation qui en est faite : on modifie la valeur d'une variable créée et utilisée à l'extérieur de la fonction.

Effectivement ca depends du language et du mode de passage de parametre (reference,pointeur). Soit vous etes tous les deux des pebkac,soit aucun des deux (il faut etre moins categorique)

En java, on ne passe en argument que des type canoniques (immutables) ou des references (immutables aussi) vers de objets.
Donc, on ne peut pas modifier un parametre. Par contre, dans le cas des references, on peut modifier l'objet pointé par la reference si il est mutable, ce qui peut revenir a modifier le parametre.

@Yomama :

#include <stdio.h>
 
 void fontionQuiTue(int *a){
         (*a)++;
 }
 
 int main(int argc,char ** argv){
         int a=2;
         fontionQuiTue(&a);  // Je crois que ça s'appelle passage par référence.
         printf("Magie %d/n",a);
         return 0;
 }

fuck les commentaires n'affichent pas les étoiles. Désolé pour l'hérésie du commentaire en C++.

Bof aucune controverse, que des noob</troll>. C'est juste que la valeur des objets (ceux créé avec new) est une adresse mémoire contrairement au type primitif. Donc toujours par référence pointeur pour les objet et par valeur pour les type primitif (int,char, byte,...).

Non, Java passe toujours les variables par valeur...

Néanmoins, en interne, le compilateur JIT effectue les optimisations dynamiquement, et si possible passe l'information par référence pour gagner de la vitesse.

Je me lève je confirme et je sors.

Sinon en prolog c'est toujours vrai.

Dans les langages récents comme Java ou C# , la notion de passage par référence ou valeur n'a pas beaucoup de sens. On considère toujours que le passage s'effectue par valeur. C'est à dire que la variable reste locale et n'affecte jamais la variable utilisée par l'appel.

Quand on passe un objet, on passe une copie du pointeur de cet objet. Si dans ta fonction tu fais A = new MyObj(), tu n'effaces pas ton objet source, il est toujours là, donc c'est un passage par valeur.

mh pourquoi pas, j'aurais tendance à appeler ça un passage par valeur d'un pointeur.

Parce que le passage par référence introduit par le c++ (qui n'existe pas en c) cohabite avec ce que tu montres:

#include <stdio.h>
 
 void fonctionQuiTue_pointeur(int *a) {
     (*a)++;
 }
 
 void fonctionQuiTue_reference(int &a){
     a++;
 }
 
 int main(int argc, char ** argv){
     int a=2;
     fonctionQuiTue_pointeur(&a);
     printf("Magie %d/n", a);
     
     fonctionQuiTue_reference(a);
     printf("Magie encore plus %d/n",a);
 
 }

dans l'exemple précédent, je considère que fonctionQuiTue_pointeur prend son paramètre par valeur, paramètre qui est un pointeur : dans main, je ne passe pas a mais l'adresse de a, ladite adresse est copiée dans le pointeur a de fonctionQuiTue_pointer : passage par valeur.

fonctionQuiTue_reference, utilise le mécanisme de référence du C++ qui n'existe pas en C, et prend bel et bien son paramètre par référence : dans main je lui donne a.

(oui je sais printf c'est C et pas C++, c'était pour l'exemple)

Euh... non !

En Java, lorsqu'on passe un paramètre à une méthode, il est passé par valeur sur la pile. Au retour de la méthode, si un paramètre passé était tiré d'une variable, elle possède toujours l'ancienne valeur.

Mais cela ne veut pas dire qu'on ne peut pas changer le contenu de la variable qui contient la valeur du paramètre passé au début de la méthode. Ce n'est pas une pratique conseillée, il est souvent suggéré de déclarer les variables utilisées pour les paramètres dans une signature de méthode en final, mais il ne s'agit en rien d'une obligation.

Je crois que tu confonds passage par valeur (la valeur est recopiée, donc il n'est pas possible d'impacter le contexte lors de l'appel) et les variables déclarées immuables (avec le mot-clef final).

En revanche, je suis d'accord avec toi (et je l'avais précisé dans mon message) : il est possible de modifier un objet référencé. Mais bon, juste pour pinailler, il n'est pas nécessaire que l'objet soit modifiable pour le modifier... Si le security manager laisse passer l'appel à AccessibleObject.setAccessible(boolean), il est possible de changer même un attribut privé dans un objet.

Bon, il est tard et je ne suis pas sûr d'être très clair... J'espère cependant avoir contribué à une meilleure compréhension du fonctionnement.

C'est un pebkac vachement mal posé quand même

- On connait pas le langage source
- Le prof voulait-il dire "une fonction modifie toujours les variables passés en paramètre" (dans ce cas c'est un gros pebkac) ou bien "une fonction PEUT modifier les variables en paramètres si ils sont passés par référence"(dans ce cas c'est toi le pebkac)????

Des précisions boudiou, on peut pas juger sinon!

Edit : Mais d'usage, pour les puristes, une fonction n'est pas censée modifier les paramètres (c'est quand même abbérant quand on y pense de toutes façons), c'est plutôt le rôle des procédures de faire cela.

Exact ! Merci pour la précision :)

Oups, effectivement il manque un peu de précisions ici.
Le langage, c'est du Python, et le prof voulait dire que la fonction modifiait toujours les variables passées en paramètres (variables de type int).
Edit :
Du coup nos codes ressemblent à ça :

def fonction1(x,y,z):
    aux_x_fonction1=x
    aux_y_fonction1=y
    aux_z_fonction1=z
   ...

Bouuh, effectivement, c'est très laid :D
Dommage que cette précision manque dans le PEBKAC, il aurait été mieux apprécié.

Beaucoup de langages (voir, la majorité d'entre eux) ne font pas de différence entre une fonction et une procédure. En fait, beaucoup argüeront qu'il n'y a pas de réelle différence entre les deux concepts.

Mais Il est vrai que le pebkac manque cruellement de précision.

D'ac-cord... ~_~
Bon je sais quoi voter à présent.

J'ai bien parlé de purisme :)

Ah quand même! Alors oui ton prof est un putain de pebkac!!!