Parse error: syntax error, unexpected $end in

bonsoir au tous,
voici une erreur au niveau de ce code.

Code:

---

1 2 3 4 5 6 7

<div class="feature"> <?php for($i=0;$i<$r+$s;$i++){for($i=0;$i<$ligne[i];$j++)?> <img src="<?php echo$tab[$i][$j]?>" class="piccola"/> <?php}?>   </div>

---

j'obtiens l'erreur suivante.

Parse error: syntax error, unexpected $end in C:\Program Files (x86)\EasyPHP-5.3.9\www\progetto nuovo\risultatiricerca.php on line 129
la ligne 129 est la derniére ligne de ma pagae.
en plus il n'a ya aucune erreur au niveau des tabaleaux ligne et tab.
merci de votre aide

Il manque certainement une accolade fermant un bloc. D'ailleurs il manque celle qui ouvre le bloc après for($i=0;$i<$ligne[i];$j++)

Re-indente correctement ton code pour qu'il redevienne lisible, tu trouvera certainement d'ou ça vient.

Citation:

---

Envoyé par djibxav

Il manque certainement une accolade fermant un bloc. D'ailleurs il manque celle qui ouvre le bloc après for($i=0;$i<$ligne[i];$j++)

Re-indente correctement ton code pour qu'il redevienne lisible, tu trouvera certainement d'ou ça vient.

---

j'ai toujours le meme probleme. j'ai ajouté l'accolade mais il m'affiche toujours la meme erreur. :(

$ligne[i] produira une erreur (sauf si une constante i existe quelque part).

salut,

ça marcherait pas mieux comme ça:

Code:

---

1 2 3 4 5 6 7

<div class="feature"> <?php for($i=0;$i<$r+$s;$i++) { for($j=0;$j<$ligne[$i];$j++) echo"<img src=\"{$tab[$i][$j]}\" class=\"piccola\"/>"; }?> </div>

---

c'est pour ça que ce genre de mélange html/php est déconseillé si on comprends pas bien comment ça marche :zoubi:

en plus essayes de bien indenter ton code, ça montre mieux les problème d'accolades... et ça permet de voir que tu t'es planté dans ta 2ème boucle en la copiant-collant... et en effet tu as oublié un $ devant le i de $ligne[$i]
ça complique la lecture et le débogage :aie:

Code:

---

echo '<img src="'.$tab[$i][$j].'" class="piccola"/>';

---

sera un peu plus lisible et rapide

pas plus rapide du tout... :zoubi:
mais c'est aussi l'occasion de montrer au débutants des écritures qui peuvent être comme celle-là dur à trouver, tu lui en présente la 2ème...

:ccool:

Quand PHP rencontre une chaîne entre guillemets, il analyse la chaîne à la recherche du signe dollar (pour substituer par la valeur de la variable), il recherche aussi l'anti-slash (par ex pour remplacer \n par un saut à la ligne, \t par un caractère de tabulation etc ) et il recherche aussi les accolades pour substituer par la valeur d'un élément de tableau.

Alors qu'une chaîne entre apostrophes est copiée directement sans analyse ... C'est plus rapide n'est-ce pas.

ma version équivaut à un sprintf en c
oui mais toi tu génère 2 opération de concaténation indépendantes, au final ça revient au même en terme de temps d'exécution

tu y gagnes, en effet, par contre dans le cas où tu ne fais qu'afficher...
exemple:

Code:

---

echo 'ce truc est plus rapide';

---

n'est qu'affiché...donc rapide que:

Code:

---

echo "ce truc est moins rapide";

---

car là tu parses la chaine pour rien...

dés que tu introduit des concaténation, ça n'est plus vrai du tout car ce que tu parses pas dans la chaine, l'interpréteur le fait en externe... au final, il n'y a quasiment pas d'écart entre les 2...

Code:

---

echo 'valeur:'.$val.' unités';

---

prend à peu près le même temps d'exécution que:

Code:

---

echo "valeur:$val unités";

---

enfin là c'est chercher la petite bête, c'est surtout une question de faire plus ou moins ressortir les variables dans ton code en fonction du parseur de ton EDI préféré et des règles de coloration syntaxique qu'il a...

moi, sous eclipse, dans mon écriture, il le fait ressortir, la plupart des EDI ne le font pas et affiche tout comme une simple chaine...

parce, qu'entre nous, rien qu'un appel de fonctions utilisateurs ou les mécanismes de POO, bien pratiques pour faire un code mieux structuré et réutilisable coutent plusieurs fois l'interprétation d'une chaine ou les opération de concaténation équivalente...

:aie:

quand tu fais du php c'est pas là qu'il faut chercher les optimisations, c'est dans les échanges avec le SGBD ou le avec système de fichier... et faire attention au nombre de fichiers utilisés en moyenne pour générer ton codes (includes, etc...)

et pour compacter la taille en mémoire, ne pas pondre des variables à tout bout de champs pour des raisons de soit disant lisibilité qui génèrent autan d'allocation mémoire, durant, la plupart du temps, tout la durée de vie des scripts...

:ccool:

D'abord on lit que ce n'est "pas plus rapide du tout"
puis "prend à peu près le même temps d'exécution".
C'est bien on progresse...
Mesurer le code au lieu de noyer le poisson.
Chacun se fera son opinion.

tu chipotes mais si tu veux la jouer formel, pas de soucis...

un peu de théorie des langages... sais tu comment est implémenté un parseur?

c'est un automate fini qui suit des règles pour déterminer son comportement...

parser une chaine encadrées par "" revient à l'interpréter avec autan de règles qu'il y a de cas à gérer:

• insérer la valeur d'une variable (hors les tableaux) si $ est trouvé
• insérer la valeur d'un tableau ou d'une variable si {$ est trouvé
• remplacer les séquences d'échappement (moins de 10 règles)

c'est l'équivalent d'un sprintf c en plus simple (beaucoup moins de cas à gérer)... ça n'utilise que de simples buffers pour les récupérations des variables et c'est implémenté comme une regexp simple et figé donc très optimisée...

le parseur php:

• reconnaitre tous les expressions du langage (100 à 120 de base + les extensions+les fonctions utilisateur)
• hiérarchisation des opération en fonction de la préséance des opérateurs
• instancier les appels de fonction quand ils sont trouvé (gestion de la pile d'appel, interprétation à la volée du leur code si php ou exécution si c'est une lib c)

si tu me dis que ça c'est l'équivalent d'un sprintf ?

donc au final:

Code:

---

echo'machin'.$bidule;

---

est un peu près identique, car tu as l'appel à la fonction de concaténation "." (et ce que ça implique), par rapport à:

Code:

---

echo"machin$bidule";

---

ou tu as aussi le même nombre d'appels car ce que le parseur de chaine ne fait pas c'est celui de php qui le fait...

mais franchement, à part si tu me parles d'une chaine de plusieurs ko et peu de concaténation dans l'autre cas, faut arrêter de chercher la petite bête... je suis même pas sur que tu mesures la différence, surtout vu le fonctionnement de php... car là, la différence entre les 2 est directement proportionnelle à la taille de chaine de caractères à brasser...

mais comme tu peut être amené à traiter des chaines longues, c'est normal qu'ils disent de se méfier entre '' et ""...

quand tu vois:

• juste au lancement d'un script le temps de génération de super globale en différentes versions ($_POST, $_GLOBAL, etc...) en fonction des réglages de php...
• ou le temps de copie d'un tableau dans un foreach si tu utilises pas de référence
• ou le pire, si tu choisis mal la méthode de lecture d'un fichier selon ce que tu dois faire avec son contenu
• ou encore si tu fais plein d'allers-retours mysql/php plutôt que d'essayer de les mutualiser...

bref, autan pour une meilleure gestion de la mémoire et des temps d'exécution je veux bien qu'on regarde:

• à minimiser le nombre de variables
• à éviter d'avoir trop de scripts php à inclure sous peine des bouffer vite beaucoup de ressources
• à bien choisir les méthodes d'i/o pour les fichiers ou les autres protocoles de communication
• à ne pas mettre n'importe quoi dans les sessions quand on les utilise
• à ne pas comprendre la différence entre un objet et un tableau selon les utilisations

ça, ça plombe vraiment les performances si c'est mal géré... le php est un langage INTERPRÉTÉ, le reste c'est plutôt plus que négligeable ou alors faut utiliser un langage compilé (c/c++ par exemple) ou compilé en JIT (c#, java par exemple) si tu cherches LA performance...

bref... si tu veux faire du benchmark avec php, c'est plus du ressenti par l'humain qui en voit l'exécution... surtout que pour une ressource web (ou réseau) à bien d'autres paramètre qui viennent pourrir les performances (qualité du réseau, gestion des caches http, ressources disponibles coté serveur et client, etc...)...
quand tu vois la difficulté à en faire un avec un langage compilé, rien qu'à cause de l'ordonnanceur des OS qui fausse les mesures, ça donne une idée de ce que serait un benchmark sur un script php qui a plein d'appels intermédiaires induits (apache, script de configurations, etc...) avant qu'on passe vraiment à lui...

cordialement :zoubi:

http://m-fernandez.developpez.com/ar...p/bench/#LII-B

On voit que " ou ' ne font aucune différence (1 centième de seconde sur 3 millions d'itérations oulala, ça vaut le coup de se prendre la tête)

La variable dans la chaîne en revanche ajoute 1 seconde sur 3 millions d'itération, c'est juste risible tellement c'est insignifiant, mais je conseille quand même d'éviter juste pour cause de lisibilité.

C'est comme les intégristes de l'echo $a,$b au lieu de echo $a.$b qu'est ce que ça peut m'énerver. 3 dixièmes de seconde sur 3M itérations, je vais peut être me faire fabriquer un t-shirt "je concatène et j'assume farpaitement"


En résumé, ma position pour les chaines à toujours été la suivante, râler quand c'est illisible mais ne pas em****er le monde parce que c'est pas ma syntaxe préférée "/' pour les chaines ou ./, pour les echos.

:mouarf:

je me sentais seul... :ccool:

même si l'article date... ça a pas changé l'ordre de grandeur des résultats :zoubi: