Reprise du message précédent :
 

BifaceMcLeOD a écrit a écrit :   Non, non, je reconnais que ce n'était pas clair.     Y a pas de malaise.

La prochaine fois, j'amènerai des madeleines, cher ami.

Comme d'habitude en C++, la spécification est la moins restrictive possible.
Cela dit, je me souviens d'un texte ou un expert évoquait le fait qu'on avait peut-être amené trop loin les templates C++.
 

J'imagine...

• spécificateur d'objet "trueconst": exige une valeur de compilation (vraie constante).
• directive "evaluate": pré-calcule une expression/fonction.
• spécificateur de fonction "reproductible": pour les mêmes entrées, on a les mêmes résultats.
• spécificateur de fonction "transparent": elle n'a aucune incidence sur l'état du programme/système (pas d'allocation, d'E/S, de variable statique/globale modifiée).

Comment le C++ signifie-t'il une fonction sans effet de bord ?
méthode const ? Cela ne concerne que l'objet.
 

Mon exemple est foireux... On pourrait le faire marcher avec un patron reproduisant le principe de "?:".
Mais je ne trouve pas d'exemple simple, je dois donc faire fausse route ici.
 

Ce qui est sûr, c'est que ça trahit une lacune du langage.
On ne nous a pas attendu pour s'en rendre compte, j'ai lu des allusions la-dessus.
 

Je pense à un objet s'allouant une ressource importante, et dont il est crucial de maîtriser le moment de la libération.
La méthode finalize laisse l'objet dans un état zombie qu'il faut savoir gérer.
Cela dit, c'est un petit prix à payer pour le confort d'objets se désallouant tout seuls.
 
Petit jeu:
Combien ceci fait-il d'allocations dynamiques en Java et en C++ ?

BifaceMcLeOD a écrit a écrit : Pour les types numériques -- je suppose que tu voulais parler d'étendre le jeu des types atomiques --, peu de langages permettent réellement de le faire. Java ne permet en effet de créer que des classes. Tu vas trouver que je la ramène encore, mais c'est une des choses que sait très bien faire Ada : -- Un type réel en virgule flottante à 10 chiffres  -- significatifs, à valeurs comprises entre -1 et 1. type Coefficient is digits 10 range -1.0 .. 1.0;      -- Un type réel en virgule fixe, à valeurs comprises  -- entre 0 et 255, et dont la différence entre 2 valeurs  -- possibles est toujours de 1/8. type Volt is delta 0.125 range 0.0 .. 255.0;

Ça c'est beau... Ça manque complètement au C++.
On peut se débrouiller avec les templates, mais c'est prise de tête, non-standard, et la compilation/optimisation n'a pas de prise directe dessus.
 

Ça rend le code plus lisible, ce qui est très appréciable:

Pour ce qui est du risque... On est libre de faire toutes les stupidités qu'on veut en C++.
 

J'ai commencé à lire ceci A Critique of C++ (3rd Ed.).
Pour l'instant c'est bien, mais trop abstrait à mon goût.
 
Disons que le C++ reste le langage dans lequel on peut faire ce qui n'est pas possible avec les autres... à condition d'être un dieu de la programmation.
Très puissant, conçis mais peu commode, très efficace pour se tirer une balle dans le pied.
Il est un terrain d'expérimentation qui peut ouvrir de nouveaux domaines, il bénéficie donc du soutien et du travail d'experts de haut vol.
 
Si il s'agit de produire régulièrement du code de façon fiable, c'est un choix discutable, c'est vrai.
 
 
Java a repris la syntaxe du C++, mais on a tort de les comparer, ils n'ont pas le but, ni la même utilisation.
 
 
Je connaît un peu BASIC, Pascal, VB, Java; et relativement bien C et C++.
Donc, mon avis manque d'expérience, mais je le donne quand même.

Tu peux déjà télécharger un JDK1.3 modifié pour supporter les génériques sur http://developer.java.sun.com/deve [...] rics/?s=03

J'ai enfin regardé ce matin.
 
En Pascal (et ce n'est pas propre à Turbo Pascal, car cela fait partie de la norme ANSI), il est possible de définir un type procédure ou un type fonction. Equivalent au type pointeur sur fonction typé de C. Tu peux aussi définir un type tableau de procédures/fonctions. Donc une procédure ou une fonction peut retourner une variable d'un tel type, et tu peux ensuite accéder à un élément de ton tableau et invoquer la procédure/fonction correspondante.
 
Par contre, pour continuer sur les différences entre Pasca et C, j'ai trouvé une fonctionnalité syntaxique existant en C et pas en Pascal : les paramètres variables. Mais à mon avis, on peut toujours se débrouiller sans (par exemple avec un tableau).

Bien sûr, il faut un minimum de bonne foi de la part du programmeur (genre pas de variable locale pointeur qui récupère un argument const ou this et qui le caste en non-const). Mais si tous les paramètres sont const et que la fonction l'est aussi, cela devrait pouvoir marcher pas trop mal.
 

Oui, c'est vrai que du coup, tu es obligé de prévoir un état "en fin de vie" de l'objet explicite, avec appel explicite de méthode pour que l'utilisatur puisse libérer cette ressource quand il faut, et levée d'exception si on essaie d'utiliser l'objet après libération de la ressource.
 

En Java, zéro : il faut faire des new explicites.
Bon, OK, j'ai répondu exprès à côté...
 

Pour info, la surcharge des opérateurs existe aussi en Ada : "+" et "-" unaires et binaires, "*", "/", "mod" et "rem" binaires ("rem" est un modulo arithmétique), et, pour certains types bien précis, pour lesquels l'affectation et la comparaison n'existe pas (c'est le programmeur qui le dit explicitement par ailleurs), les opérateurs ":=" (affectation) et "=" (comparaison).
 

Le problème, c'est que l'expérience montre qu'il vaut mieux ne pas faire totalement confiance à l'humain qu'est le programmeur : quand il a des outils, il a très fortement tendance à les utiliser (cette remarque n'est pas propre à la programmation).
D'oùu l'utilité de fournir des outils alternatifs à côté des outils très puissants, plus spécialisés mais aussi plus sûrs.
 
Un seul exemple : il y a 30 ans, certains ne juraient que par le "goto". On a montré à ce moment-là que les structures de contrôles "for" et "while do"/"repeat until" étaient beaucoup plus sûres et permettaient de masquer le goto dans 99,9 % des cas tout en en gardant l'efficacité (j'ai bien dit "masquer", puisque dans la réalité, cela revient à ça).
Restaient encore, il y a 10-15 ans, quelques cas où le "goto" restait nettement plus difficile à éviter : la récupération sur erreur, et en particulier quand on avait besoin de libérer des ressources après la détection de l'erreur. Aujourd'hui, le mécanisme de traitement d'exceptions ("try/catch/finally" ), beaucoup plus sûr, remplace avantageusement tous ces cas résiduels, et on n'a plus jamais besoin du "goto".
(en fait, si, il y a un cas : quand on veut implémenter la gestion logicielle de threads légers non préemptifs en C, on a besoin des "long-jumps" : je me suis déjà amusé à ça... Mais bon, c'est très localisé dans le code qui encapsule le changement de contexte)
 

Et tu as raison, il est très intéressant.  

J'ai corrigé la question du tableau .
 

J'ai lu des articles de Bjarne Stroustrup.
Il souhaite un langage avec un jeu réduit de fonctionnalités fondamentales très puissantes, ce qui est le cas actuellement.
Pour lui, tout le reste doit pouvoir venir de librairies, à étoffer maintenant.
 
Il a raison dans le sens où on ne peut pas préjuger de l'emploi du langage, ni des attentes du futurs.
L'histoire de l'informatique est jonchée de langages taillés sur mesure pour un usage spécifique, mais qui n'ont pas survécu à l'évolution.
 
Il a tort dans la mesure où certaines choses basiques sont compliquées à obtenir, et cela gêne tout le monde.
Il y a des choses époustouflantes dans les librairies boost, mais est-ce raisonnable ? Ça n'est vraiment pas à la portée des néophytes.
 
 
 
Pour le coup j'ai épuisé mes pensées, je n'ai plus rien à ajouter... pour l'instant .

Musaran a écrit a écrit : J'ai corrigé la question du tableau .

En Java, tu ne peux pas allouer plusieurs niveaux de tableaux en même temps. Seul un tableau est alloué, de la taille indiquée, puis il est rempli de null.
Donc pour créer un tableau tri-dimensionnel, tu dois forcément écrire :

Et là, tu as alloué [i]2 * x * y tableaux, c'est clair.

Tu es vraiment sûr ?
Ma mémoire me joues des tours et me faire voire Java meilleur qu'il ne l'est.
 
A propos des contraintes de paramètres de patrons, voici des extraits de cette interview de Bjarne Stroutrup: http://www.research.att.com/~bs/01chinese.html.
 

 
J'aime bien ce qu'il dit.
Il a visiblement un bon recul, une bonne vue d'ensemble, des idées claires.
Je recommande la lecture de son site, c'est très instructif.
 
 
Un avantage de s'investir en C++ est que le plafond est très haut.
C'est à dire qu'on peut toujours s'améliorer, jusqu'à un niveau très élévé, avec très peu de chance de toucher une limite du langage.
Si on s'y prends bien, le code est extensible et réutilisable à volonté, mais ça demande de la maîtrise.
C++ est complexe.

Rien à ajouter.
 
PS : le mot anglais "decade" se traduit en français par "décennie". En français, une décade est un groupe de 10 jours, comme défini dans le calendrier révolutionnaire (au même titre que les noms de mois "brumaire", "vendémiaire", "nivose", "pluviose", etc).

Arf... 10 jours ça fait un peu court. Un faux ami m'a trahi, je ne me suis rendu compte de rien.
 
Ah tiens, les dimensions commencent à droite en Java ?
Je crois que tu as raté le "tableau[i][j]".
 
Bref, en Java chaque tableau est un objet, et il n'y a pas vraiment de tableaux multi-dimensions.

Total: 1 + z + y*z + x*y*z allocations dynamiques, ce qui peut être beaucoup.
Du coup, il semble qu'il vaut mieux mettre les plus grandes dimensions en dernier (donc à droite ?).
 
En C++, entre 0 et (1 + x + x*y) selon que les dimensions soient constante, variables, ou un mélange des 2.
Il y a même des combinaisons intermédiaires.
Et il vaut mieux mettre les plus grandes dimensions en premier (à droite ).
 
Ça reste dur à gérer et propice au bogues !

Pour BiFace & Musaran,  
Je suis assez d'accord avec le fait que Ada est un bon langage avec nombre de possibilites avancees que l'on ne trouve pas ailleurs et une bonne methodologie (le premier compilo Ada (Thomson?) que j'ai utilise tournait sur un 386).
Mais il a une syntaxe que l'on aime ou pas (j'aime pas trop).
Il a de plus une precedence de l'operateur - assez inhabituelle.
 
BiFace, entre Eiffel et Ada, tu pourrais nous faire un recapitulatif des points forts/faiblesses, si tu connais bien les deux langages?
 
A+,

Je connais très mal Eiffel, et je ne l'ai jamais utilisé, désolé.
 
De ce que je m'en souviens, une des principales caractéristiques d'Eiffel est de pouvoir définir des préconditions et des postconditions pour chaque méthode, ainsi que des invariants (sorte de conditions toujours vérifiées) valables pour l'ensemble du code. Ces conditions qui sont automatiquement vérifiées par le compilateur. Ceci permet de définir une sorte de programmation par contrat, puisque l'implémenteur s'engage à ce qu'un certain nombre de conditions écrites dans le code soient toujours respectées.
Je me trompe ?
 
Tiens, au détour de mes pérégrinations, j'ai trouvé ceci (rien à voir avec la discussion qui précède, mais ça ne fait rien) :  
http://perso.club-internet.fr/ppra [...] ation.html
Intéressant.

Juste une chose, je sais pas si kk'un l'a déja dit, je pense ke oui!!!!
 
Vu ke le java est un langage interpretet, il est totalement portable ss n'importe kel OS, alors ke le C ben le faire passer ne seresse ke de Unix à Linux et bien la merde ke c qd ca commence à etre un peu compliké le code.
 
Alors ke le java, compliké ou pas, tu prends ton prog, et ca roule n'importe ou!!!!!!!!!!!!!!!!!!
 
Ca c vraiment un gros avantage, et ds ma boite on pleure ne ce moment car on porte tt de unix à linux et ca fait ke merder!!!!!

Ecrire du code portable tous Unix et NT en C/C++ requiert une grande expérience et une grande rigueur. Mais ça a longtemps été le lot de tous ceux qui développaient des applications systèmes portables (exemple, un SGBD).
Dans ces situations-là, on apprécie le principe d'encapsulation, et surtout, on apprécie les développeurs qui écrivent proprement...  

oui peut etre, mais essaye de faire un multi threading portable en c de unix vers linux ou vers win.(ou le mappage mémoire diffère aussi!!)
 
Ou alors un mappage mémoire,,vu ke les instructions "shell" different:
 
genre "pthread" est différent, alorsd ke si tu fait du multi threadé avec du java, ben t'as aucun problème de potage.
 
Je sais ceux st des cas peut utilisés, mais tu vois on a beau programmer portable, tt ne l'est pas en c!!!!!!!!!
 
Voila c tout!

Le multithreading portable en C, c'est tout à fait possible : je l'ai fait. Mais c'est clair qu'il faut écrire une surcouche pour encapsuler les différentes implémentations de threads (pthreads/green threads/threads Sun/threads NT/...), avec moult #ifdef en son sein suivant la plate-forme.

J'imagine meme pas la gueule du code à vomir.
 
Et puis le code k'on avait à porter a été écrit il y a 7 ou 8 ans, et ils ne pensaient pas du tout le faire passer un jour de HP-RT à pentium.
Mais vu aujourd'hui les différences prix/performances, ils ont changé le fusil d'épaule.
 
Alors ke si ca avait était fait direct en java, tu code ss te soucier du portage et vlam ca passe.
 
Et puis bon le java c plus sympa à écrire je trouve (y en a ki diront surement moins rigoureux!!!!)

Non, non, ça restait assez lisible. Mais surtout, c'était localisé. Et le reste du code, qui reposait sur cette couche d'encapsulation, était tout à fait propre, puisque lui était parfaitement portable.

7-8 ans, c'est bigrement long en informatique.
Il est difficile de savoir ce que nous réserve l'avenir, et je ne suis pas sûr qu'on y trouve Java si portable que ça.
A commencer par l'imminent passage à 64 bits.

? qu'est ce que ca changerat pour java ???
t'aura une JVM 64 bits et point bart !
 
 
et puis ca fait déjà quelques années qu'il est iminent le passage !

Oui, je suis d'accord avec benou. Les principaux points de non-portabilité des programmes Java sont leurs parties natives. Mais la définition du langage proprement dite ne suppose rien sur la taille du mot machine (ni de son "boutisme" d'ailleurs, qui, pour m'y être confronté, est encore plus compliquée à gérer dans du code C/C++, soit dit en passant).

J'avais lu que l'int Java est défini comme 32 bits.
 
Pour ce qui est du boutisme, je suppose que Java offre des fonctions de communication qui le gèrent.

Les types de base Java ont une type fixe quelle que soit la taille du mot pour le processeur, alors qu'en C, le type "int" a pour taille celle du registre processeur (donc 16 bits sur le 8086 ou le 68000, 32 bits sur un 80386, et 64 bits sur l'Alpha ou un processeur SPARC64).