AccueilCodesTutorielsForumsEmploiLivresGuide achatConnexion

  • CodeS-SourceS
  • RSS CodeS-SourceS
  • CodyxBot, le Bot GTalk & MSN qu'il vous faut !
  • Générez des revenus avec vos codes, scripts et tutoriaux
  • Aide à la navigation du site
begin process at 2009 07 12 05:00:32
Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

101 commentaire(s) de verdy_p sur des sources sur tout CodeS-SourceS

Le : 24/03/2009 22:32:18
Source : CALCUL DE HASH SHA 256
A titre de comparaison, voici le code libre que j'avais posté il y a quelques temps ici (je ne vois pas ce qui a pu pousser lkes administrateurs du site ici à le supprimer !), et depuis plus de 8 ans ailleurs sur le Net (ce code est aussi utilisé en production depuis pas loin de 10 ans, et reste plus rapide que toutes les implémentations 100% java actulles sur le marché, et arrive même à battre les autres implémenttions en .Net et en C, il peut seulement être battu avec des optimisations parallèles SSE2 ou en assembleur pur uniquement sur les vieux processseurs Pentium sans SSE/MMX ou 486 et précédents; Java fait nettement mieux en restant avec le même code quasi optimum sur toutes les plateformes, grace à la compilation dynamique au runtime du Bytecode déjà optimisé dans le code ci-dessous sur la plateforme elle-même).

Voir la liste des fichiers sur (aucune pub, juste les fichiers):

http://org.rodage.com/pub/java/security/

(il y a d'autres algos que SHA256, il y a eu de très lègères modifications de performance depuis leur création, mais plus aucun changement depuis 2005). Ce sont toutes des implémentations en 100% pur Java (pas d'utilisation de DLLs natives via JNI), et donc totalement portable sur toutes plateforme compatible Java (des serveurs d'applications aux PCs ou Macs, aux plus simples téléphones mobiles, set-top boxes, consoles de jeux, ou appareils hifi intégrés comme des lecteurs DVD, webradios, lecteurs MP3 mobiles, etc, qui ont un firmware intégrant une VM Java).

Tout est disponible sous licence LGPL (dont une traduction française est disponible dans le même dossier).

Chaque algorithme est implémenté dans une classe implémentant l'interface standard MessageDigestSPI (donc compatible avec toute implémentation d'un JCE et pouvant remplacer les algos fournis par Sun). Le code est compatible avec toutes les versions de Java (il n'y a pas de spécificité demandant Java 5 ou 6).

Chaque algo est fourni avec sa classe de test, contenant les valeurs attendues de la quasi totalité des vecteurs standardisés de test dans les normes américaines FIPS ou européennes. Le code effectue enfin un test de performance et fait la comparaison de performances avec l'algo du JCE de Sun, quand il est présent: cette comparaison n'est pas toujours possible si votre JCE par défaut n'a pas l'algorithme correspondant: la classe de Test est à adapter aux versions de JCE avec lesquelles vous voulez comparer les performances et en vérifier les résultats.

Tous les algos de hachage sécurisés standards des normes FIPS sont présents (MD5, SHA1, SHA224, SHA256, SHA384, SHA512), ainsi que quelques autres (Tiger et Whirlpool).

Il n'y a pas MD2 ni MD4 car ils ne sont pas sécurisés du tout (ils n'ont été recommandés dans aucune norme) et pourtant plus lents que MD5. Mais j'en a des versions de même qualité si vous les voulez.

(Note: les commentaires sont en anglais, mais ils sont mis en forme pour JavaDoc.)

Le : 24/03/2009 21:34:53
Source : CALCUL DE HASH SHA 256
Concernant la sécurité, la réduction de longueur d'une clé de hachage sécurisée doit se faire par une méthode préservant la distribution des bits. Si on suppose que SHA256 a une distribution plate (ce qui devrait être le cas pour tout algorithme éprouvé) et en reconnaissant que SHA256 est reconnu comme bien plus résistant que MD5 ou SHA1 par le fait qu'il utilise un nombre d'états internes (ou degréds de libertés) bien plus élevé, indépendamment de la longueur de clé finale), il suffit simplement de tronquer la clé à la longueur voulue: c'est ce qui est fait par exemple dans SHA384 qui consiste simpelment à tronquer la clé de hachage en prenant les 384 premiers bits de la clé de hachage SHA512 (cela n'augmente ni ne diminue pas le nombre d'états internes dans le calcul).

Il n'y a aucune préférence de choix dans les bits de la clé obtenue à préserver: si une telle préférence existait et avait été démontrée, les algorithmes n'auraient pas été aprouvés avec la longueur de clé indiquée.

En terme de résistance aux collisions, évidemment, si on tronque trop, on augmente statistiquement le risque de collision (le passage de 256 bits à 64 bits mulitpliera ce risque par 2^(256-64) ce qui est évidemment énorme, et permet d'envisager à un coût faible la recherche de collision (qui surviendra sur ces 64 seuls bits, même si la clé originale sur 256 bits ne provoquait pas de collision).

Peut importe la méthode de réduction des clés utilisée, il n'y a aucun moyen de préserver la sécurité contre les collisions si on réduit le nombre de bits. Donc il est parfaitement inutile de chercher des méthodes compliquées (comme prendre un bit sur 4, ou compresser les 256 bits en les coupant en 4 paquaets combinés ensemble par un XOR): la sécurité obtenue sera la même.

Le seule problème avec une méthode avec troncature de clé plus longue, c'est que le calcul intermédiaire de clés plus longues nécessite plus de calcul, alors que cet excès n'apporte aucune sécurité supplémentaire significative par rapport à un autre algorithme "sécurisé" calculant directement une clé plus courte. Donc c'est vrai qu'on peut finalement se contenter d'utiliser SHA1 et non SHA256 comme algorithme de base.

D'une açon générale, pour une longueur de clé voulue donnée, on doit prendre un algorithme sécurisé ne calculant pas plus du double de cette longueur. Au delà c'est du travail inutile pour rien puisque le supplément d'effort est perdu.

Si le but n'est pas la sécurité mais simpement avoir des clés courtes suffisantes pour faire une table d'index par hachage résident en mémoire, SHA256 est certainement peu adapté et réduira les performances de votre application. Autant se contenter dans ce genre d'application de clé de hachage non sécurisées mais donnant une distribution suffisamment "plate" des bits afin que les "slots" dans la table de hachage soient équitablement utilisés. En général les tables de hachage en mémoire ont un nombre de slots relativement faible (guère plus de 65000) car on y stocke en fait un nombre limité d'objets (aussi car si on ugmente trop la tailel de la table de hachage, on va se retruver avec plein de slots vides qui occupent inutilement de la mémoire).

Pour cette raison, les table de hachage se contentent d'algorithmes plus simples basés sur une réduction par multiplication et addition dans un espace de Galois de longueur égale à la taille de la table de hachage. On choisit normalement une tailel qui sit un nombre premier pour les tailles faibles inférieures à 12 bits, et au delà on utilise une taille qui est une puissance de 2 dans le corps de Galois binaire, et cela suffit: le multiplicateur utilisé est en général dans ce cas un nombre proche du tiers de la taille totale N et qui soit premier avec cette taille, en fait le nombre premier le plus proche de N/e.

Par exemple pour une taille de table de hachage voisine de 1024, on choisit la taille première proche 1031, et le multiplicateur est alors le nombre premier le plus proche de 1031/e=379,28... qui est donc ici 379; la constante additive devrait être proche de la moitié de cette valeur, et également première, ici 379/2=189,5, on peut choisir 187; le calcul de hachage pour chaque octet à hacher est alors: nouvelleclé=(ancienneclé*379+187+octet) modulo 1031.

Pour indexer en revanche un nombre très élevé de fichiers par la valeur exacte de leur contenu (avec une clé si possible distincte pour la moindre modification de ce contenu) c'est là qu'on a besoin d'un algo sécurisé. Mais il ne faut pas se leurrer: il n'y a pratiquement aucun moyen d'assurer l'unicité et le risque de collision avec une clé de 64 bits seulement (quel que soit l'algo employé!). En revacnhe on peut estimer le nombre total de fichiers existants à tout instant ou le temps qui serait nécessaire pour atteindre un nombre donné, puis ensuite le nombre de fichiers auxquels il est possible d'accéder en un temps donné: s'il faut plus d'une vie à attendre même en employant tous les ordinateurs du monde pour en générer assez, il est pratiquement impossible d'obtenir une collision. On estimait il y a encore 5 ans qu'une longueur raisonnable actuelle est celle de la clé SHA1 (et pas moins), mais aujourd'hui la longueur minimale suggérée est de 128 bits (et par sécurité on choisit plutôt 192 bits).

En revanche contre le risque de production de collisions volontaires (dans le but de modifier des fichiers existants sans que cette modification soit détectable par la clé de hachage, il est hautement recommandé de ne plus descendre sous les 256 bits: c'est pour ça qu'on a l'algo SHA256, et déjà l'algo SHA512 pour le futur ou les plus paranoïaques (ainsi que SHA384 qui en est une version mineure obtenue par simple troncature de SHA512).

L'ennui des clés obtenues avec 256 bits ou moins est que le calcul se fait avec des entiers 32 bits: en augmentant le nombre de bits dans la clé, on a augmenté énormément le nombre d'opérations pour l'utilisation normale (ce qui pourrait rendre l'utilisation de ces algorithmes prohibitive pour la sécurisation tout en conservant les performances). De plus, en accroissant le nombre de variables internes, cela fait déborder les tailles de cache des processeurs, et les performances s'effondrent.

C'est pour ça que SHA512 (ou SHA384, mais aussi l'algo Tiger qui calcule des clé sur 192 bits d'une façon complètement différente des algos linéaires utilisés dans les algos MD ou SHA) utilise pour son calcul interne des entiers sur 64 bits et non 32 bits, des tailles maintenant supportées nativement par les processeurs, et qui diminuent le nombre d'opérations nécessaires sans réduire le nombre d'états internes et de degrés de libertés "cachés" dans la clé obtenue: cela a permi de continuer à augmenter la sécurité sans réduire significativement les performances (c'est vrai que le calcul sera plus long, mais ce n'est rien en fonction de la "loi de Moore" concernant l'évolution des performances des processeurs, ordinateurs, et systèmes en réseau, c'est à dire la capacité totale de calcul disponible en moyenne par poste utilisateur).

Bref, pour conclure: pas besoin de se compliquer avec les algos sécurisés connus si vos voulez des clés plus courtes: il suffit de les tronquer.

En revanche l'utilisation de deux clés obtenus par des algos distincts ne donne pour obtenir une clé composite ne donne PAS une sécurité équivalente à l'utilisation d'un algo sécurisé unique de longueur supérieure (la sécurité sera bien moindre).

Par exemple: SHA512 tronqué à 256 bits a une sécurité très légèrement supérieure à SHA256 (mais ce supplément est négligeable). Mais si on combine la clé SHA512 tronquée à 256 bits, avec la clé SHA256, on obtient une clé composite de 512 bits, mais qui sera de sécurité TRES NETTEMENT INFERIEURE à l'utilisation d'une clé unique SHA512 non tronquée !!!)

Ceci est une règle générale: les clés ne se combinent pas de façon additive mais sont seulement légèrement supérieures à la sécurité de la plus forte d'entre elles. La combinaison de deux clés d'algorithmes distincts ne peut servir qu'au cas où un algorithme réputé sécurisé voit sa sécurité brutalement diminuée: la seconde clé permet de conserver une sécurité minimale quand la securité de l'autre est compromise.

C'est pour ça que les certificats de sécurité des PKI comportent généralement une double signature (avec des clés de longueurs similaires, mais avec deux algorithmes), car il faudrait alors réussir simultanément à casser les deux algorithmes pour casser les deux certificats (le reste de l'effort de calcul pour réussir à produire une collision simultanée dans les deux algorithmes est alors négligeable par rapport à l'effort qui était initialement nécessaire pour casser chaque algorithme): la sécurité du certificat est alors effectivement celle de celui des deux algorithmes qui est le plus sécurisé.

En revanche une double clé ne sert à rien s'il s'agit de vérifier l'intégrité d'un fichier unique. La bonne méthode est plutôt d'utiliser un découpage du fichier en morceaux de taille inférieur à une limite maximale et de hacher chaque fragment: la sécurité de l'algorithme augmente mathématiquement quand la taille des fichiers est bornée (par exemple des fragments de 4Ko comportent 32768 bits, et il suffit d'avoir pour chacun d'eux une clé sur 128 bits, ce qui apporte une compression limitée à 1 bit sur 256 entre la oangueur de clé et celle du fichier:

ce taux de compression est correct et pas excessif par rapport à la longueur de clé (car on estime que que sur une clé sécurisée de taille N, au moins N/2 bits sont significatifs, mais souvent beaucoup plus et pratiquement jusqu'à N-k avec k très petit: ici une clé 128 bits d'un algo sécurisé approuvé donne au minimum 64 bits significatifs et peut-être jusqu'à 120 avec les méthodes connues de cryptanalyse actuelle.

Le risque de collision ne peut commencer à devenir un peu signiticatif sur 1 seul bit qu'à partir de longueur de fichiers dépassant le carré de cette longueur de résistance (120²=14400 bits, soit 1,8 Kio). Avec des fragments de 4Ko, on n'aura une résistance jusqu'à 2,2 bits, mais c'est insuffisant par rapport à la longueur significative de clé pour obtenir une collision véritable (ici 120 pour l'algo de clé sur 128 bits).

En fait on peut aller à des tailles de fragments en bits allant jusqu'au cube du nombre strictement minimum de bits significatifs dans la clé sécurisée: avec une clé de 128 bits, on a au strict minimum 64 bits significatifs et les fragments peuvent aller jusqu'à un strict maximum de 64^3=262144 bits (soit 32 Kio) (la clé 128 bits elle-même apportant une compression d'un tel bloc de 32 Kio d'un ratio de 1:256, ce qui est insigifiant par rapport à la taille de bloc à sécuriser ou authentifier)

Mais en revanche, pour des tailles de fichiers supérieures, il faut davantage de clés, une par bloc, et/ou des clés plus longues (mais c'est au prix des performances car des clés longues sur des fichiers longs représentent une masse de calcul non négligeable).

A vous de voir selon vos besoins s'il vous faut (et quand?) utiliser SHA256 (ou passer directement à SHA512 sur une plateforme 64-bits comme Intel IA64 ou AMD64/x64, puisque SHA512 est en fait maintenant légèrement plus rapide que SHA256 sur les plateformes 64-bits actuelles, avec du code spécialement optimisé pour chaque plateforme en prenant en compte les tailles de caches, et surtout les états d'attente ou de parallélisme possible des pipelines, le nombre de registres rapides et d'ALU indépendantes). Tout dépend largement de la taille des fichiers à hacher, de leur fréquence et de l'estimation de leur nombre total rencontré dans vos applications (ou parmi tous les utilisateurs de votre application si celle-ci est en réseau et notamment sur Internet), et du compromis fait entre performance et dégré (ou durée) de résistance aux attaques (éventuellement massives et coordonnées).

Et n'oubliez pas non plus de définir la valeur des données à protéger (et la durée de validité de cette valeur, puisqu'en général la valeur de toute information diminue avec le temps au contraire du coût nécessaire pour une tentative de violation de l'intégrité de cette information sur cette même période): il peut être plus rentable de ne pas utiliser inutilement les algos les plus sécurisés si au bout du temps nécessaire pour les casser cela a coûté plus cher que la valeur des données elle-mêmes.

Le : 23/03/2009 03:41:19
Source : TRAITEMENT DE L'IMAGE: FILTRE MÉDIAN EN TEMPS CONSTANT
ce que je voulais dire par filtre "discontinu" ce n'est pas "non linéaire". Il y a des filtres non linéaires qui restent continus; par exemple les filtres de flou gaussien, ou en vaguelettes sin(n.x)/x (ce type de filtre sert à la compression d'images comme à son filtrage, avec l'énorme avantage par rapport aux transformées FFT et dérivées que sont les transformées en sinus ou cosinus, que le filtrage permet de borner pratiquement exactement la bande passante du signal résultant dans une fenêtre presque parfaitement rectangulaire, sans aucun repli, tout en conservant la possibilité de restreindre cette bande passante pour aténuer certains détails sans trop de pertes au plan qualitatif, mais aussi en réduisant le bruit). Dans un filtre discontinu, tous les points du kernel ne contribuent pas avec un poids constant (et donc de façon indépendante des autres points) au signal final. La présence dans le filtre médian d'un opérateur discontinu est celle de l'opérateur binaire ">" (équivalent aussi à la somme d'un opérateur linéaire et de la valeur absolue d'une différene linéaire, cette valeur absolue étant cette fois l'opérateur non linéaire). D'autres opértateurs non linéaires utilisent des poids de degré supérieur à 1 (le poids total est à évaluer en fonction de la valeur de tous les points voisins dans le kernel).

Concernant la limite de précision, on peut noter aussi que c'est sur un filtre de rayon supérieur ou égal à 128 (et non 512) qu'il faut aussi augmenter cette précision dans le bin: l'algorithme ne le vérifie pas et les valeurs 16bits d'histogrammes peuvent donc déborder dans certains cas non "pathologiques" comme les plages toutes blanches ou toutes noires qui surviennent sur des zones saturées de l'image (image l'effet sur une photo avec un soleil, ou des zones d'ombre bien contrastées qu'on bien bien noires, notamment sur des scans en très haute résolution comme des radios ou images scanners).

A l'inverse, pour des rayons inférieurs à 8, le nombre de pixels dans le noyau est nécessairement sous 256, et utiliser 16 bits par valeur d'histogramme est un gaspillage; on pourrait à la place utiliser un codage 8-bits avec une meilleure parallélisation (aussi bien en MMX, que 3DNow, SSE, SSE2, Altivec...) Pour le filtrage du bruit de suantification des appareils photos à cellule CCS, les rayons seront nécessairement faibles, et peuvent énormément améliorer la compression JPEG ultérieure tout en réduisant les pertes et artéfacts. Pour l'élimination des artéfacts "carrés" de la compresion JPEG/MPEG ou pour la correction des blocs manquants dans une vidéo MPEG, un filtre médian de rayon 3 ou 4 suffit amplement, et donc là encore les histogrammes sur 8 bits seraient suffisants et encore plus rapides (mais toujours à coût quasi constant).

Pour le filtrage numérique du son en revanche, les échantillons 8 bits ne suffisent pas, même si l'entrée est seulement sur 8 bits, car ceux-ci sont dénormalisés par une transformation non linéaire (de type "loi-A" pour les anciens formats audio américains ou "loi-mu" presque partout ailleurs): souvent il faut avant tout traitement les convertir dans un espace linéaire sur 12 bits minimum (souvent 16 bits). Le filtrage du bruit se fait en plus dans un espace transformé (bidimensionnel celui-là, en temps et en fréquence) demandant une plus grande précision pour les fréquences centrales du spectre, là où aussi le bruit de quantification ou de mesure est le plus important. Hors, avec 16 bits de précision, la largeur des histogrammes devient prohibitive.

C'est pourtant essentiel dans la construction matérielle d'involuteurs en temps réel (par exemple dans les modems de type DSL) qui nécessitent des filtres d'élimination du bruit pas trop destructeurs d'information (car ce type de destruvtion supprime une autre chose essentielle, la phase du signal, pour n'en garder que l'amplitude moyenne dans une fréquence ou couleur donnée).

Bref, cet algo est très bien mais il faut en comprendre les limites, et l'adapter au cas à traiter. Les optimisations MMX/SSE/Altivec ne sont pas si essentielles que ça (et pas forcément péreines non plus) et masquent l'algorithme réel dont le principe est en fait bien plus simple que ne le laisse transparaitre le source.

Aussi il est effectivement ESSENTIEL de se rapporter au document de référence, et merci d'avoir mentionné la source (consulter l'article paru dans les communications IEEE au format PDF pour les détails, il est facile à comprendre même s'il est rédigé en anglais avec des schémas qui rendent le principe finalement très facile à comprendre), même s'il manque une visualisation du principe d'utilisation d'un histogramme au lieu du tri pour décider la valeur médiane:

Ce n'est pas évident de conclure que cette méthode a un temps constant, puisque la méthode utilise en fait une boucle d'intégration progressive de l'histogramme, la "courbe" de l'histograme n'ayant rien de linéaire ni nécessairement distribué de façon uniforme dans les cas réels: le cas moyen n'est valide que pour une image toute grise, le cas le plus favorable est l'image toute noire, le plus défavorable étant l'image toute blanche, et le temps effectif dépendant donc directement de la valeur médiane obtenue dans l'image source elle-même, avec de grosses variations de vitesse en fonction de l'éclairage moyen sur une photo dont la balance des blancs n'est pas nécessairement bien équilibrée sur la photo entière).

Le résultat de cet algorithme n'est donc pas un temps "constant" mais un temps "borné" entre deux bornes dans un rapport fini (jamais plus que le simple au double) qui ne dépend pas du rayon du filtre mais de la précision binaire de l'image source (c'est ce que veut dire "O(1)": ce n'est PAS une constante). Si on regarde les courbes affichées d'ailleurs, on voit que le temps n'est pas une droite parfaite mais connait des petites irrégularités en fonction du rayon sur une image réelle, et cette variation de temps est attendue mais limitée (ce qui permet de garantir par exemple un débit utile sur une vidéo avec une marge de variabilité étroite)

Le : 22/03/2009 21:28:47
Source : TRAITEMENT DE L'IMAGE: FILTRE MÉDIAN EN TEMPS CONSTANT
Il fautdrait tout de même noter que l'optimisation n'est intéressante QUE si la taille de fenêtre est bien plus grande que le nombre "constant" d'opérations (qui est, lui, proportionnel au produit du nombre de plans de couleurs par l'exponentielle de la profondeur des plans couleurs).

L'exemple prend une image 8 bits (ce qui est maintenant assez rare dans l'imagerie actuelle, la plupart des filtres pour la photo, la vidéo ou les scènes 3D demandant des scènes en 32 bits (hormis les rares cas d'images monochromatiques à faible résolution). L'optilisation dans ce cas ne sera valide que si la taille de fenêtre est supérieure à 512 pixels (total des opérations de somme et différences des histogrammes, augmenté en fait des comparaisons et additions). Hors, une fenêtre de largeur 512 pour le filtre est très supérieure à l'utilisation classique de ce type de filtre.

Le graphique de comparaison est trompeur et n'est sans doûte pas à l'échelle (pour moi, en dessous de r=17 environ, la méthode classique est plus rapide, c'est pourtant un cas trs courant de l'usage de ce genre de filtres pour les images usuelles, par exemple pour éliminer ou lisser les artefacts de compression JPEG ou MPEG ou corriger de blocs manquants dans une vidéo, sans que ces blocs ont une taille fixe 16x16 et dans ce cas le rayon r reste inférieure à cette limite) Hors le graphique montre tout le contraire, même pour r=1 où il est évident que la méthode classique (sans les multiples histogrammes à mettre à jour) sera plus rapide; la mesure serait donc fausse par des lectures multiples des pixels dans l'image source avec une API lente. (noter que la parallélisation reste encore possible même avec un filtre classique en O(r), seul le noyau changeant réellement mais pas les possibilités d'en utiliser un grand nombre d'instances en parallèle pour traiter toute l'image).

Cette optimisation ne peut donc résoudre que des cas particuliers très rares, à fort facteur de réduction sur des images très grandes et en faible résolution de couleur.

Ce cas serait celui de l'imagerie médicale de type des clichés radios, mais les filtres à effet de seuil aussi brutal que le filtre à médiane est en général inadapté car cela doit traiter des images réelles provenant de mesures dont la distribution de bruit ne subit pas un effet de seuil (de type loi de Poisson par exemple) mais plutôt de type Gaussien (il faut donc un filtre continu).

L'exemple donné (l'icône de Windows) n'est certainement pas celui le plus significatif: il est bien plus rapide d'utiliser la méthode à tri, d'autant qu'il est évident que la taille de fenêtre dans cet exemple est très réduite: le choix de la méthode de tri est important puique le tri ne part jamais d'une situation aléatoire après chaque pixel, mais ce tri subit un changement unique après chaque pixel: un tri par insertion dichotomique suffit (la suppression étant directe si on utilise une file de priorité parallèle au vecteur de tri), et donc sur une fenêtre de 16 pixels, il suffira de 4 ou 5 comparaisons au maximum pour réaliser l'insertion. On est alors très loin des 512 opérations par pixel...

Pourrais-tu préciser pour quel type d'images ce filtre est utilisé et en quoi le filtre discontinu à médiane s'avère plus adapté au problème à résoudre qu'un bien plus simple filtre continu à moyenne dont le comportement linéaire est réellement O(1) dans tous les cas et totalement indépendant à la fois de la taille de fenêtre comme à la profondeur binaire des plans de couleur, et ne nécessite pratiquement aucune mémoire annexe (pas besoin d'histogrammes)?

Sinon bravo pour la qualité du code et l'effort d'optimisation du kernel parallélisable sur un seul processeur avec ALTIVEC ou MMX ou SSE (mais il y a aussi des possibilité de parallélisation nettement plus rapides par GPU, ou par certains processeurs de signal de cartes audio, capable de paralléliser un nombre bien plus élevé de kernels, et il y a même des librairies communes permettant de le faire indépendamment des processeurs hôtes ou esclaves parallèles utilisés dans les différents matériels possibles).

Le : 17/03/2009 21:12:15
Source : TESTER LA VALIDITÉ D'UNE ADRESSE EMAIL SANS ATTENDRE DE RÉPONSE DE L'INTERNAUTE
Ce qui me choque dans l'expression régulière que tu donnes:

$regexp = "^([_a-z0-9-]+)(\.[_a-z0-9-]+)*@([a-z0-9-]+)(\.[a-z0-9-]+)*(\.[a-z]{2,4})$";

C'est le fait que tu tentes de valider la chaîne AVANT l'arrobe (@). Les restrictions que tu imposes ne sont pas valides, tous les caractères autorisés pouvant apparaître dans n'importe quel ordre, à n'importe quelle position et peuvent apparaître plusieurs fois. Pourquoi interdire donc deux points successif ou un point à la fin?

De plus, la casse des lettres AVANT l'arrobe est significative (rien ne garantit que le système cible ignore les différences de casse dans le nom d'utilisateur, même si c'est la plupart du temps vrai). Donc une adresse "machin@example.org" est DISTINCTE de "MACHIN@example.org", alors que la casse est ignorée dans le nom de domaine après l'arrobe. Il est cependant hautement recommandé de créer des comptes utilisateurs tout en minuscules afin d'éviter tout problème, avant que ceux-ci n'utilisent ce nom dans une adresse email.

Il n'est pas autorisé de modifier librement celle-ci dans un logiciel (donc une opération de "tolower($adresse_email)" est clairement invalide) dans le seul but d'exprimer l'adresse sous une forme "canonique" (en revanche on peut le faire pour le nom de domaine dont la forme recommandée est en minuscules.)

Attention aussi aux IDN : les caractères Unicode sont autorisés dans les noms de domaine (pour les valider, il faut utiliser les algorithmes de l'IDN, et éventuellement rechercher les caractères autorisés dans chaque registre TLD ou registre de second niveau, chaque niveau pouvant apporter des restrictions différentes pour chaque label séparé par un point. Si l'IDN est utilisé, on peut valablement convertir le nom de domaine sous une forme canonique n'utilisant que les minuscules ASCII, chiffres et signe moins (plus le point séparateur de labels pour les différents niveaux de domaine) grace à cet algorithme (après conversion, chaque label séparé par un point peut commencer par "xn--", les deux signes moins successifs étant réservés à cet usage)

La norme contient une liste de caractères autorisés qui sont tous sans restriction. Bref tout ce qui est avant l'arrobe ne doit être QUE:

"^([-_a-zA-Z0-9&~#'{|`_^=+}$*./]+)@(([a-zA-Z0-9-]+)(\.[a-zA-Z0-9-]+)*(\.[a-z]{2,4}))$"

De plus, le nom de domaine indiqué derrière l'arrobe peut aussi être une adresse (éventuellement entre crochets pour IPv6); en fait ce qui est demandé dans SMTP c'est que le nom puisse se résoudre comme un nom d'hôte pour le protocole "MX": ce nom d'hôte devant seulement supporter une requête DNS, donc permettre d'accéder au serveur DNS tournant à cette adresse, afin de récupérer son adresse "MX". L'adresse indiqué est donc celle de l'hôte d'un serveur DNS (pas nécessairement, et en fait très rarement celle de l'hôte du serveur SMTP).

De cette analyse cela extrait les chaines $1 (nom d'utilisateur) et $2 (nom d'hôte DNS). Chaque chaîne doit alors être traitée séparément. De la première chaine il n'y a rien à traiter, ce nom d'utilisateur est opaque et doit être conservé tel quel. Le nom d'hôte DNS en revanche doit vérifier celle d'un nom d'hôte valide:
- soit une adresse IPv4 valide (au format décimal avec 3 points séparateurs et 4labels numériques entre "0" et "255")
- soit une adresse IPv6 valide entre "[crochets]" au format hexadécimal, et dont la casse n'est pas significative; mais cette adresse peut être mise dans un format canonique avec un nombre variable de sous-labels hexadécimaux (entre "0000" et "FFFF" sur 1 à 4 chiffres) séparés par des ":", en une seule suite contenant exactement 8 sous-labels, ou en deux suites séparées par un unique "::" chaque suite comprenant de 0 à 7 sous-labels, mais dont le total des sous-lbels dans les deux suites ne peut excéder 8.
- soit un nom de domaine valide (comprenant au moins deux labels pour les adresses valides sur Internet, les labels étant séparés par des "."). Pour le valider, on doit d'abord scinder ce nom en autant de sous-labels, dont aucun ne doit être vide. Ensuite, si un label contient des caractères non ASCII, on doit le convertir avec l'algorithme Punycode en nom de label ASCII pur, puis contrôler sa longueur qui ne peut excéder 63 caractères chacun. Le label ASCII obtenu (composé de lettres ASCII dont la forme canonique est en minuscules, chiffres ASCII et signes moins ASCII) a ensuite des restrictions sur son format: il doit être composé de sous-labels séparés par de "-", dont ni le premier ni le dernier ne peut être vide. La dernière restriction à contrôler est éventuellement de rechercher si le nom de domaine est valide ou enregistrable sur Internet; c'est assez facile pour le label TLD (le dernier) à condition de connaître la liste des TLD valides (et de la mettre à jour car cette liste est évolutive), les seules restrictions actuelles étant qu'un TLD ne contient que des labels avant au moins deux caractères, et le TLD ne peut être entre "0" et "255" exactement (sans chiffre "0" en excès) car ils sont réservés pour représenter les adresses IPv4 (cette restriction ne concerne QUE le dernier label TLD mais ne s'applique PAS aux labels des autres niveaux, ainsi le domaine complet "0.com" est valide, mais pas "com.0").

L'étape suivante de validation demande une requête de résolution DNS pour savoir si le nom de domaine possède un enregistrement "MX" vers un nom de domaine ou d'hôte valide (avec la même syntaxe): noter que cette résolution peut conduire à autre nom de domaine, ou une adresse IPv4 ou une adresse IPv6 entre crochets; si un nom de domaine est retourné, on le valide de la même façon que dansle paragraphe précédent, mais il n'est PAS nécessaire que ce nom de domaine se résolve en une adresse IPV4.

Donc attention à ne pas utiliser gethostbyname() sans précaution pour faire cette validation, sauf si votre logiciel d'envoi de courrier ne sait envoyer un courriel que vers les hôtes SMTP en IPv4: mettez-le à jour pour qu'il sache aussi envoyer un courriel vers un serveur SMTP en IPv6; sendmail sait le faire depuis un bon moment, mais si vous utilisez votre propre script d'envoi de courriel avec une socket, assurez-vous de bien connaitre le protocole SMTP et de savoir ouvrir une socket vers un hôte IPv6, en consultant le format de l'adresse retourné par gethostbyname(), et en utilisant bind() avec les bons paramètres correspondant à ce format et avec le protocole TCP et le port 25 (attention aussi à la longueur de la structure d'adresse passée en argument). Si votre serveur d'envoi de courrier ne sait pas le faire, transmettez les email vers le serveur STMP de votre propre FAI (tous les FAIs savent relayer des courriel vers les hôtes SMTP en IPv6) et faite lui confiance (mais appliquez la charte d'utilisation pour ne PAS envoyer de spam même dans ce cas): il y a beaucoup moins de risque que votre FAI soit blacklisté si vous utilisez son serveur SMTP comme relai, que si vous envoyez vous-même le message vers le serveur STMP que vous avez résolu.

Cela veut dire qu'au delà de la phase de validation, il n'est pas nécessaire que vous réalisiez vous-même:
- la résolution de nom de domaine présent dans l'adresse email vers un nom de serveur DNS pour y rechercher l'adresse MX (attention: elle peut changer au cours du temps, ne gardez pas cette adresse de façon permanente dans un cache excessif, mais respectez la durée de validité retournée, donc faite confiance aux librairies ou fonction de votre système pour effectuer cette résolution en appliquant les règles prescrites pour la gestion des caches de clients DNS!),
- ni la résolution de l'adresse MX retournée en nom d'hôte SMTP (celle-ci peut aussi changer au cours du temps: même remarque pour la mise en cache),
- ni la connexion effective à ce serveur SMTP (par le protocole approprié)

Noter aussi que certains serveurs DNS ne sont joignables directement QU'avec IPv6, ce que la plupart des connexion Internet des particuliers ne savent pas faire (faute de support dans les sessions de transport PPP): utilisez les serveurs DNS donnés par votre FAI pour relayer (via IPv4) vos demandes de résolution de noms de domaines en noms d'hôte IPv4 ou IPv6 (puisque les serveurs DNS relais donnés par votre FAI savent interroger les serveurs DNS de certains domaines accessibles uniquement en IPv6 et pas en IPv4): si la résolution vous donne une adresse IPv6, il vous faudra trouver un relai 6to4 ou Teredo pour vous connecter à la cible indiquée, mais ce sera très lent. Envoyez plutôt vos mails au serveur SMTP de votre FAI qui dispose, lui d'un accès direct à IPv6.

Toute cette validation ne suffit pas encore; il faut, avant de continuer à utiliser cette adresse "prévalidée", vous assurer d'avoir l'accord de son propriétaire pour lui adresser du courrier (surtout si vous comptez le faire de façon automatique). La gestion correcte d'une liste de diffusion est une tâche ardue techniquement car elle doit respecter des normes de bonne conduite assez strictes (et un fonctionnement excellent dénué de toute erreur!), sinon vous risquez d'être blacklisté et de ne plus pouvoir envoyer de messages même à ceux dont vous aviez l'accord et attendent vos messages avec impatience ! En général il vaut mieux externaliser la gestion de vos listes de diffusion chez un fournisseur de messagerie tiers, gérant correctement et efficacement toutes les souscriptions (et désinscriptions) volontaires aux listes de diffusion et vous permettant aussi d'effacer toute adresse qu'on vous signalera (donc attention au choix du prestataire: il doit aussi respecter des normes pour garder vos listes de diffusion totalement privées).
En général, abstenez-vous d'inscrire vous même des adresses dans les listes gérées par des prestataires externes: laissez les gens y souscrire eux-même (contentez-vous de mentionner l'adresse de souscription à votre liste avec une page web explicative et les infos relatives aux règles d'usage). Dans ce cas, ce n'est pas à vous de valider les adresses mais à votre fournisseur.

Ne validez donc localement QUE les adresses pour lesquelles vous effectuerez des communications strictement personnelles (aucun envoi en groupe vers ces adresses individuelles que vous gérez vous-même, pas même pour leur envoyer des newsletters et autres infos relatives à votre site, et surtout pas pour ne leur envoyer que de la pub vers d'autres sites ou produits "partenaires").

Si vous avez des "partenaires", créez des listes de diffusion distinctes chez votre fournisseur de liste, faute de quoi, tout abus de la part de partenaire dans les contenus de leurs messages que vous allez relayer pour eux risquerait de compromettre votre propre service et le voir lui-même blacklisté. Ne fusionnez surtout pas les contenus des listes pour vos propres communications à vos utilisateurs avec les listes pour les messages de vos "partenaires" (et d'une façon générale, demandez leur de vous envoyer une copie certifiée de leur envois pour que vous puissiez en contrôler et approuver le contenu, et ensuite effectuer la diffusion de ce message par votre liste externe).

Enfin il est indispensable que vous assuriez le secret absolu sur le contenu de vos listes (la liste des souscripteurs devrait être secrète, même pour ceux qui y sont inscrits volontairement, à moins que vous n'indiquiez explicitement, avant qu'ils y souscrivent eux-même, que la liste des utilisateurs sera accessible à tous les souscripteurs).

Ne changez surtout pas de politique de confidentialité ensuite (sauf pour en restreindre d'avantage l'accès en cas de constatation d'abus par certains de vos utilisateurs): l'accès aux adresses contenues dans une liste doit être d'autant plus sécurisé et restreint que celle-ci contient de plus nombreuses adresses: au delà d'une vingtaine d'adresses, cette liste doit devenir fermée et inaccessible même à vos souscripteurs (résistez fermement à leurs demandes, mais créez une liste plus ouverte seulement pour ceux qui en veulent à leurs risques et périls).

Le : 17/03/2009 19:14:41
Source : CLASSE DE GESTION D'INTERFACE RÉSEAUX
Les "short tags" sont une nuisance dans le cas où un serveur héberge plusieurs moteurs de scripts: un même source doit alors être traité en plusieurs étapes, la sortie de PHP pouvant apsser par un filtre suivant (ou bien l'inverse aussi, selon l'extension donée au fichier source qui associé généralement le type du premier filtre utilisé).
Certaines de ces instructions de traitement (processing instructions) peuvent être nécessaires pour être compatibles avec des filtres XML, ou SSI par exemple, PHP le script PHP n'étant qu'une des mailles de la suite générale des traitements.
D'une façon générale, les tags plus explicites permettent aussi une identification plus sûre du contenu, surtut quand un source n'est plus lui-même associé à un nom avec une extension mais incorporé au sein d'un autre langage ou protocole de transport n'indiquant pas le type de fichier ni son nom.
C'est une bonne pratique de toute façon d'utiliser "<?php" et non "<?" seul qui reste ambigu.

Note: la non reconnaissance des short tags ne concerne pas QUE les vieilles versions de serveurs (d'aileurs ta remarque à propos d'IIS est inappropriée car IIS n'a pas de support de PHP par défaut, et IIS a toujours cette contrainte nécessitant un label pour associer le filtre correct devant traiter le script; et quel que soit l'age d'IIS, on a toujours eu la possibilité d'utiliser l'association de fichier pour désigner le premier filtre). Enfin même PHP lui-même, dans ses versions les plus récentes, peut encore être configuré pour ne PAS autoriser les short tags (l'option de configuration est présente depuis longtemps). La désactivation des shorttags est en fait bien plus souvent faite sur des serveurs Apache qu'IIS, Apache étant largement plus présent pour les serveurs pour le Web public qu'IIS utilisé principalement pour des Intranet et quelques applications métier ou pour des services d'administration locaux de Windows (qui de toute façon se fait plutôt avec des pages ASP, voire JSP, et pratiquement jamais avec PHP, pour des raisons de sécurité où le nombre de moteurs de scripts à maintenir est réduit au strict minimum, le tag "<?" étant alors utilisé pour désigner ce seul moteur de script autorisé et sans aucun chaînage vers un autre moteur ou filtre, toutes les autres PI comme "<?xml" étant passés en transparence complète dans le résultat, ou son contenu totalement filtré si le label de l'extension PI n'est pas explicitement déclaré et autorisé).

C'est donc bien "<?" qui est obsolète et vraiment trop vieux (et partiellement supporté encore, s'il n'est pas tout bonnement supprimé dans une version ultérieure en tant que nuisance) alors que "<?php" est hautement recommandé depuis maintenant longtemps et s'est imposé depuis des années (et sur certains serveurs partagés, l'option désactivant les shorttags est configurée mais pas modifiable du tout), avec un coût vraiment minime (3 caractères, est-ce que ça tue un source?).

Note: on trouve aussi "<?php5" et "<?php4" pour désigner la version de PHP à utiliser (PHP pouvant être lui-même configuré pour indiquer le label qu'il reconnaitra et ceux qu'il ignorera. Un filtre SSI d'Apache peut alors être configuré pour exécuter la bonne version en fonction des PI qu'il trouve dans un source. On trouve aussi "<?perl", "<?SSI", "<?asp", "<?xml", "<?python", etc... et il existe dans PHP des extensions permettant d'utiliser des sous-filtres en amont ou en aval de traitement, ou pour reprendre le traitement du résultat produit après un filtre intermédiaire (qui peut lui-même générer un script PHP dans son résultat, ou retourner des résultats dans divers autres formats indiqués par la signature du label PI en tête du fichier qu'ils produisent.) J'ai même vu "<?text" pour indiquer que toute la suite est du texte brut qui ne doit pas être parsé mais transmis en transparence complète (en ignorant toute présence d'un autre "<?" dedans ou "?>" qui ne doit pas autoriser la reprise de l'analyse lexico-syntaxique.)

Le : 04/03/2009 09:13:43
Source : JAVA : JEU OTHELLO - MULTI ET SOLO (MINMAX)
Moi non plus je n'ai pas de problème. Tout cele na peut venir que de ton environnement qui a transformé/transcodé les fichiers sources présents dans l'archive de façon inattendue. De plus il est étrange que ton environnement demande UTF-8 absolument pour le codage des fichiers sources, là où par défaut il prend un codage ISO-8859 qui ne peut pas échouer à la lecture et au décodage.
Avec quel outil as-tu donc désarchivé les fichiers sources? Avec quel éditeur as-tu esayé de les transformer? As-tu fait un transfert de Windows vers Linux via FTP en mode texte?...Regarde de ce côté là, corrige ton environnement, et recharge les sources originaux (pour éviter les pertes de caractères non décodables remplacés ici par des "?").

Le : 02/03/2009 19:06:03
Source : SIMULER LA VISIBILITÉ PACKAGE (COMME EN JAVA)
Pour ceux qui ne sont pas convaincus de ce que je vient de dire au sujet de l'intérêt majeur suscité par les VM, regardez ce qui se passe:
- du côté de la programmation massivement parallèle (sur le GPUs par exemple dans OpenGL et DirectX, qui deviennent programmebles de façon génériques avec des langages spécialisés)
- du côté des webservices et hébergements virtualisés (on parle de "thin client" et de "cloud computing"
- du côté du calcul distribué
- du coté des fondeurs de processeurs qui se sont lancés dans la bataille de la virtualisation.
- du côté de Microsoft qui défend encore sa voie .net et va tenter de l'imposer dans Windows 7 tout en promouvant sa plateforme VM ware (largement critiquée pour son surcoût exhorbitant en performance et son incapacité à supporter de nombreux coeurs ou le calcul massivement parallèle)
- les efforts faits par Sun et IBM pour créer un remplacement à son bytecode actuel pour Java (insuffisant et difficilement paralélisable et ne permettant pas de supporter tous les langages actuels ni d'offrir une interopérabilité totale avec dot.Net:

http://www.dotnetguru.org/modules.php?op=modload&name=News&file=article&sid=321&mode=thread&order=0&thold=0

(le but de ce projet est de créer une VM universelle)

Les compilateurs natifs sont en cours de tuning mais le but est bien de masquer l'architecture actuelle de la machine afin de rendre tous lesprogrammes et services déployables partout avec les performances optimales, et de permettre le support de toutes les architectures de virtualisation actuelles (qui seront émulées avec des performances excelentes et optimisées en fonction de la macjhien cible effectivement utilisée).
La virtualisation de tout le logiciel actuel, qu'il soit local ou un service réseau, avec un seul ou de nomberus utilisateurs, que ce soit pour des interfaces graphiques, des applis interactives, ou du calcul scientifique massif, avec une distribution automatique sur toutes les ressources de calcul disponibles dans un environnement hétérogène, constitiuent bien les voies suivies. On devrait aboutir en 2010 vers une version Beta de Java 7 sur cette architecture qui devrait aussi fonctioner comme un hyperviseur capable de supporter divers OS actuels (y compris Linux ou Windows). Du côté d'IBM, il planche avec AMD sur des accélélations matérielles de ce code VM qui deviendrait pris en charge de façon antive par les processeurs 32-bits et 64-bits actuels (il devrait aussi y avoir un support du code natif x86 ou x64 actuel par émulation dans cette VM future).
Evidamment derrière, il y a tout le marché futur des serveurs d'applications, et des services distribués, ou encore du logiciel hébergé comme un service et accessible depuis n'importe quel terminal connecté (du PC au téléphone mobile via les serveurs locaux d'entreprises), avec une échelonnabilité "à la demande".

Windows est clairement menacé, alors que Linux et Unix y voient leur planche de salut. Mais Microsoft prend désormais du retard et ne rient encre que par un marketing aggressif (il est probable qu'à l'avenir Windows deviendra gratuit, ce qui sera payant c'est l'offre de service en ligne pour l'hébergement ou l'interconnexion d'applications et de services). Dès l'année prochaine Java sera prêt alors que Microsoft en sera encore à tenter de mobiliser les entrerprises pour leur passage vers Windows 7 après avri raté l'étape de Vista.

Microsoft se trompe de guerre: l'OS n'est plus une ressources stratégique et ne se défend plus que par son "look" et son utilisabilité, des domaines où Linux et même Apple ont gagné des points, alors que maintenant d'autres plus gros encore que Microsoft se lancent dans la bataille: les FAI et les fournisseurs d'infrastructure réseau (et Google par exemple l'a bien compris); l'avenir ce n'est plus l'ordinateur et ce qu'il a "dans le ventre", mais le réseau, l'interopérabilité, l'accessibilité et l'échelonnabilité à la demande, une meilleure résistance aux pannes, et à un coût global largement inférieur et une administration unifiée et simplifiée), et pour les utilisateurs cela veut dire que l'effort est consenti envers une personnalisation facilitée.

Il faut reconnaitre que de moins en moins de monde s'intéressera à votre capacité à faire du code natif puisque c'est le compilateur intégré à la machine virtuelle qui offrira directement les meilleurs performances et de façon plus rapide et plus aisée à déployer, alors que votre code natif "fait maison" ne survivra pas à la demande de déploiement sur d'autres plateformes plus étendues et aura un cycle de vie de plus en plus court en comparaison du code managé qui verra son cycle de vie augmenter et plus intéressant à utiliser car déployable à plus grande échelle. Hormi les rares qui construisent du matériel (et ils sont de moins en moins nombreux à pouvoir le faire tant les coûts de recherche ont explosé), on aura moins intéret à faire de l'assembleur, du C, alors que le code managé sur VM (en C#/dot.net, Java, Python, ...) prend de plus en plus de valeur.

Note: Java a été porté en interne chez Sun sur plateforme VM .Net (au lieu des plateformes natives), mais c'est une étape intermédiaire pour porter le tout vers la VM universelle. Le débogage est en cours, et de nombreux JSR incluent le support des possibilités offertes par les futures VMs sur diverses plateformes; du côté applicatif, on s'oriente vers l'API unique, mais des implémentations plus nombreuses de la VM, masquant leurs diférences pour que le même code ou service soit accessible le plus possible depuis n'importe quel point même s'il n'est pas totalement exécuté localement.

Le : 02/03/2009 18:01:07
Source : SIMULER LA VISIBILITÉ PACKAGE (COMME EN JAVA)
Ici tu as une communauté pour le Python, mais pas pour le Ruby. Il me semble que la communauté Python est au contraire plus active que Ruby.

Evidemment il faut se faire à un léger changement de syntaxe: plus de point virgule pour séparer les instructions, mais une instruction par ligne (ou sinon un ":" pour indiquer que la suite de l'instriuction est formatée en bloc), plus d'accolades (les blocs sont indentés à la place, ce qui pousse au moins tous les programmeurs à indenter leur code correctement, rend le code lisible, et permet d'éviter les bogues relatifs aux mystérieux point-virgules ou accolades en trop ou mal appairés et corrigés ensuite de façon incorrecte.

Certains critiquent cette écriture, mais pour ceux qui veulent la syntaxe C/C++/Java classique, elle est possible dans une variante de Python compatible avec sa VM.

Le gros intéret de Python on écrit le code et on peut l'exécuter immédiatement, sans compilation préalable (la compilation est automatique, la VM compile juste ce qui est utilisé et maintient un cache dans des fichiers ".pyc"); il est même possible de modifier un source ".py" pendant son exécution (et forcer Python et relire une classe dès qu'elle cesse d'être utilisée).

Le démarrage de la VM Python est assez rapide, mais peut aussi consommer autant de mémoire que celle pour Java, il n'y a pas de vraie différence entre les deux à l'heure actuelle (la lourdeur apparente de Java tient au fait qu'on l'a trop vu utilisée pour exécuter des Applets web qui nécessitent un environnement assez lourd à initialiser, et de nombreuses librairies, alors qu'elles ne sont pas nécesaires absoluement à Java. Un script Java peut être aussi économe (mais il est dommage que la VM de Sun ne prenne pas en charge automatiquement la compilation des sources, ce que peuvent faire d'autres VM Java. De plus trop de gens ont connu Java du temps de Microsoft qui l'a rendu très lent et même incompatible, alors que depuis HotSpot dans Java 2, les performances n'ont plus rien à voir; aujourd'hui dans Java 5 on est loin de ce mauvais souvenir, Java est très rapide et bat pratiquement toujours .Net en performance comme en consommation de ressources mémoire, et en vitesse transactionnelle dans une contexte multithread ou multicoeur voire multiprocessus ou via des instances d'interfaces proxies de services réseaux); en performance brute sur des environnements hétérogènes, le même code obtient pratiquement les performances optimales de chaque architecture matérielle alors qu'un code compilé en C/C++ ou même C# ne se déploie de façon optimale que sur un nombre restreint de plateformes (aileurs les performances sont très mauvaises). Pour vous en convaincre, regardes la très grande lourdeur de l'interface graphique de Vista, toute en .Net, mal optimisée et qui consomme une grande quantité de ressources, et comparez à l'interface graphique de MacOSX qui contient une VM JAva presque invisible...

Le modèle de compilation dynamique à la demande (partiellement implanté dans Java qui demande une précompilation du bytecode, et dans Python à qui il manque encore le profilage à l'exécution pour la prédiction de branchement, pour l'allocation hiérarchisée des registres les plus rapides, et le regroupement relatif du code dans des pages mémoires plus localisées avec un meilleur taux de succès dans les caches matériels) est la solution d'avenir.

Il y aura encore du C ou du C++ voire de l'assembleur dans une partie des pilotes matériels du système hôte, mais de plus en plus de code sera virtualisé et optimisé localement à la demande selon le profil d'utilisation et de déploiement.

Il est même probable qu'une grande partie du code C ou C++ actuel sera compilé vers cette machine virtuelle (dans une forme modifiée, dite "managée") au lieu du code natif puisque cette dernière phase sera prise en charge séparément en fonction des capacités matérielles du système exécutant effectivement le code et qui peut être différent même de l'hôte du contrôleur général du système sur lequel l'application est installée, déployée ou utilisée.

Le : 02/03/2009 17:26:59
Source : CLASSE DE GESTION D'INTERFACE RÉSEAUX
Mettre un "?>" à la fin c'est une syntaxe équivalent à écrire un write() supplémentaire (dont la fin de chaine serait délimitée par "<?php" ou la fin de fichier).

Il n'y a qu'au début du fichier où on peut garder un "<?php" qui met fin à l'instruction write() implicite (qui n'est éliminée QUE s'il n'y a strictement rien avant).

Le problème du "?>" à la fin est qu'il peut trop facilement y avoir des blancs et sauts de lignes après (parfois ajoutés involontairemet dans les éditeurs par simpel navigation avec les flèches, et que les éditeurs de texte ne suppriment pas non plus automatiquement), et donc cette suite ne sera pas vide et compilera une instruction write() indésirable (qui plantera tout appel ultérieur à header() par exemple)...


1 2 3 4 5 6 7 8 9 10


Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Appels d'offres

Comparez les prix Nouvelle version


Adobe Flex Builder
Entre 607€ et 607€


Visiter le guide achat

Photothèque Nouveau !

Photo friends at the beach.Photo plage de nudistes
Photo Cockpit Airbus A320 Photo maison et plan

Visiter la photothèque


Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,265 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.