for (int i = 1; i <= N; i++) {
     tabTarger[i – 1] = tabSource[i – 1];
}

Avant de voter, j'aimerais savoir ce qui te choque là-dedans.

Je suppose qu'il pourrait partir de 0 et éviter la soustraction... Chose à mon avis simplifiée par le compilateur, donc strictement équivalente.

Le fait que "l'indiçage" du tableau commence à zéro (ce n'est pas le cas de tous les langages) oblige à faire -1 quelque part.
Il est vrai qu'habituellement, on fait -1 sur le nombre d'éléments du tableau pour ne pas avoir à décrémenter l'indice à chaque fois qu'il est utilisé dans la boucle.
Mais, à priori, son code ne devrait pas poser de problème (si N est bien initialisé).

Comme dit sur un PEBKAC précédent, un code non optimisé mais fonctionnel n'est pas un PEBKAC c'est sur que de mettre for i = 0; i < N; i++ serait un peu plus propre mais bon...

Certes, mais là il s'agit d'un cours, pas d'un code qui a été maintenu pendant 20 ans par 30 personnes différentes, il n'y a pas d'excuses. PEBKAC validé pour ma moi.

P.S. Il ne me semble pas évident que le compilateur réussisse à optimiser ça et que ce ne soit pas au prix de rater une autre optimisation.

Il s'agit peut-être d'un cours maintenu pendant 20 ans... qui était à l'origine un cours de Pascal ?

Les boucles sont en général optimisées par le compilo. Après, ça dépends peut-être du niveau d'optimisation demandé, mais elles sont généralement bien comprises par le compilateur, et ce genre de cas me semble tout à fait apte à être optimisé au cours de l'analyse de la boucle, surtout aussi simple : i n'est utilisé nulle part ailleurs que pour l'indexage des tableaux, càd un pointeur incrémenté à chaque itération...

Sans doute une faute de frappe en rédigeant le PEBKAC mais le tableau de destination, il ne sʼappellerait pas plutôt tabTarget ?

Je parie que c'est pour l'exemple. Il dit on va de 1 à n donc for (i=1;i<=n;i++) mais le tableau va de 0 à n-1.
Le but est d'évaluer les étudiants en regardant quels sont ceux qui vont le simplifier.

Le bon vieux coup du "C'était pour voir si vous étiez attentifs" ...

Je ne connais pas bien le langage C mais n'était-il pas envisageable d'affecter directement le contenu de tabSource à tabTarguet ?

J'ai la flemme de tester (et pas fait de C++ depuis des lustres), mais ne pourrait-on pas faire directement tabTarger = tabSource ?

pas intuitivement, mais oui avec un memcpy (pour le langage C),

pour C++ ça dépend du type du tableau, dans l'exemple ci dessus ça pourrait être un conteneur de la librairie standart, vector par exemple, auquel cas tu peux utiliser le constructeur par copie, ce qui donne un rendu plus intuitif dans le code.

Le code présenté n'est donc pas un PEBKAC (même si ce n'est peut-être pas le plus optimisé). Je vote donc CTLP.

Nope, tu te retrouverai avec deux pointeurs qui pointent sur la même mémoire.

Par contre, en C++, mieux vaut utiliser les conteneurs de la STL, et donc profiter de leur constructeur par copie pour ce genre de cas.

@Shadam : Je suis entièrement d'accord. Ce serait comme dire : il a utilisé i++ au lieu de ++i donc PEBKAC.
C'est stupide.

(Pour l'anecdote, et d'après ce dont je me souviens en C++, ++i est dans le pire des cas aussi rapide que i++, et dans le meilleur des cas, plus rapide. Mais encore une fois, ce n'est pas une optimisation qui va changer la face du monde informatique, on risquerais de gagner quoi, 1 à 2 cycles d'horloge processeur...)

@Raizarachi : i++ (post-incrementation) est différent de ++i (pré-incrementation)

int a = 5, b = 5; 
 int c = ++a; //c vaut 6
 int d = b++; //d vaut 5 

En C aussi ça dépend du type de tableau.
Si tu fait un memcpy d'un tableau long[] dans un short[], par exemple, le résultat risque de ne pas être celui auquel tu t'attend.

Personnellement, je valide : si les élèves n'ont pas une réflexion très avancée (du genre "l'prof à écrit ça, alors je met ça"), ou une expérience minimale, ce genre de code les embrouillent complètement. (Oui, il y a du vécu, Loy, le donneur de cours bénévole de son internat ... qui s'arrache violemment les cheveux :p)

@chipeauteur: T'as déclaré 2 variables `a` et `b` alors que tu aurais pu te servir de `a` à chaque fois vu que tu ne changes pas sa valeur, PEBKAC.

Euh... bah si, il change sa valeur... a et b valent tous deux 6 après leur utilisation respective.

Ha bon ? ++a ne change pas a ?

EDIT : Grillé par Epok__

N'utilisons que a, comme préconisé par Shadam :

int a = 5;
 int c = ++a; //c vaut 6
 int d = a++ // d vaut 6 

Et à la fin, a vaut 7 alors que dans mon premier exemple il vallait 6

Epok__ et Picc : c'est épique à notre époque !

Il me semble que memcpy copie la plage mémoire sans se soucier du type de contenu. Tu lui passe donc un pointeur source, et il le copie vers un pointeur cible. Si tu passe les bons pointeurs et la bonne taille (un simple nbrÉlements * sizeof(type) devrait suffire), je ne vois pas pourquoi il y aurait des problèmes.

À la limite, si les types source et destination n'ont pas la même taille, il pourrait y avoir des problèmes pour des raisons d'endianness en cas de copie élément par élément, mais pas en opérant sur une plage mémoire.

Après, si les types n'ont pas la même taille, faut être sûr de les manipuler correctement, mais c'est souvent utilisé en C : par exemple faire un union entre un entier sur 32 bits et un tableau de 4 octets, pour ensuite utiliser soit la totalité de la valeur, soit un octet particulier.

@Picc
Comme tu dis, il faut faire moins quelque part.
Mais on le faisant dans le corps de la boucle, comme ici, une personne en apprentissage risque de passer à côté du fait que les indices de tableaux commencent à 0 en C/C++.
Alors que quand c'est dans le "for", c'est visible tout de suite, même si on ne fait que jeter un coup d'œil rapide sur le code.

" il pourrait y avoir des problèmes pour des raisons d'endianness"
Qui a dit que les informaticiens parlaient un jargon incompréhensible ?

En français, on parle de boutisme... « gros boutisme » et « petit boutisme »... C'est moche et ça veut rien dire. Je préfère le terme original.

Bonne année + 5 minutes.

Enfin, tout est relatif.

Bonne année tout le monde!

Bananier et bonne santé à tous !

Parce que _endianness_ c'est plus parlant, peut-être ? En plus c'est chiant à prononcer ! Boutisme est un calque direct de l'anglais, la seule raison de ne pas l'utiliser c'est ce pédantisme à la con qui refuse depuis une ou deux décennies d'adopter les néologismes du français.

Je ne connait pas le C++, mais il n'y a pas moyen de faire un itérateur avec un foreach?
genre comme en php:

foreach($tabSource as $key => $value) $tabTarget[$key] = $value;

Très bien, alors du coup, je t'attends pour remplacer « cliquer » par « cliqueter » selon les recommandations officielles. On en reparle après.

J'ai découvert le terme « boutisme » sur internet, selon les mêmes recommandations. Jamais personne que je connais n'a employé le terme. Alors oui, utilisons des termes décrétés par des types qui ne sont pas du milieu et n'en connaissent même pas la signification, c'est tellement plus français...

C'est comme « bug » et « bogue »... « Bug » a une signification historique. Mais ça ne fait pas français. Du coup, on préfère recycler un mot qui n'a aucun lien, la « bogue » de châtaigne. Mais au moins, ça fait français.

De base foreach n'existe pas en C++.

Et les possibilités pour un faire serait inadapté pour le cas de l'exemple : plus long à codé qu'une boucle for et surement moins efficace.

En C++ je vois 2 options simple :
- la boucle avec la copie pour chaque élément
- si on est sur un tableau de type de base : un gros memcpy.

Pas d'itérateur relativement natif comme en java non plus? <troll>Tain, c'est vide et nul le C++</troll>

Jʼai déjà rencontré des programmeurs qui parlaient de « petit Indien » et « gros Indien ». La première fois, ça surprend.

Joli, un mélange des termes anglais et français, avec une approximation phonique au milieu ! Je crois que j'utiliserai ces termes maintenant.

que l'on dise «petit boutien» et «gros boutien» ne me dérange pas puisque cette appellation vient du roman les voyages de gulliver, où je sais plus quel peuple se divise entre «petit boutiens» et «gros boutiens» (respectivement «little endians» et «big endians» en version anglaise), selon que les gens considère qu'il faut manger les œufs à la coque par le gros ou le petit bout.

http://en.wikipedia.org/wiki/Endianness#Etymology

Le code est fonctionnel certes, mais c'est un PEKBAC car c'est de la mauvaise programmation, ce n''est ni logique ni habituel de commencer à 1 au lieu de commencer à 0 pour iterer sur un tableau.

C'est impardonnable pour un prof.