Reprise du message précédent :

 
   
 
Un compilateur ASM il fait pas grand chose sur ton code asm hein...  
 
Et trouver une adresse valide a la compilation faut etre fort  
 
EDIT : Mais n'en parlons plus si c'etait bien une erreur  

euh, le garbage collector, il sert à quoi ?

 
Euh c'est pas a la compilation ca, c'est lors de l'execution que tu peux trouver une adresse libre...
 
 
 
EDIT : Enfin si tu peux bien sur, mais je voulais dire "hors allocation mémoire necessaire au programme" (ton 0x0 m'a fait pensé a ca)

Je sais faire du php, C, C++ , java. Enfin, faire est un grand mot.  J'aimerais justement aprofondir ma connaissance du c++ ou du JAVA. Quel est le langage que vous me conseillez  

ça va pas être facile de répondre, chacun va défendre son pain
 
pour ma part: C++
question de goût surtout

ca depend de tes besoins
 
EDIT : mais comme ca je dirai c++

Disons que c'est pas une question de besoins, je vois plus ça dans l'optique d'un travail/futur.

en fait tout dépend de ce que tu comptes faire, et dans quel domaine tu comptes travailler, et quel genre d'applis tu comptes développer.
 
Système+tout le reste -> C++
Autre que système -> Java
 
Par système, j'entends des softs pour power users qui fonctionnent près de l'OS, mais C++ peut en fait tout faire. Tu sais pas faire un défragmenteur de disque avec Java (enfin je crois pas mais ça me paraît pas le choix le plus pertinent).

si c'est pour le boulot, ce sera plutôt Java AMHA.

L'assembleur !
Comme ça, quand tu passeras à des langages comme le C/C++, les notions de pointeurs, pointeurs de fonction, décalages de bits, n'auront plus aucun secret pour toi !

 
vendredi c'était hier

En fait, j'ai déjà fait de l'assembleur, la notion de pointeur, je la connais, les décallages, tout ça ça va... C'est juste que je trouve ma connaissance trop légère pour faire quelque chose de correct.  

cool, pour pouvoir utiliser les fonctionalités les plus miteuses (dont il existe un équivalent propre à chacune dans dans d'autres langages, sauf pour le déalage de bits) de ces langages.

Et vous pensez quoi du python?
 
CHaiCA

 
Le Python c'est bien, mangez en !

 
... avant qu'il ne vous mange

tain, mais t'as fumé quoi toi ?

Rien, il fait juste trop chaud

ça suce des  

c'est pas typé statiquement

asm ownz  

mais jetez tout de même un oeil a ruby

typage statique suxor grave, mais on en a déja parlé y'a un bout de temps sur une tribune quelconque  

 
faut le dire vite ...
 
java et C++ ne joue totu simplement pas dans la même catégorie.
Ya des trucs pour lesquels tu iras bcp plus vite à faire Java ou que tu ne pourras pas faire autrement (ex : développement Web, application pour tel portable, ...), et d'autre type d'app pour lesquels le C++ sera plus adapté pour es raison de performance ou d'impossibilité de le faire en Java (interface graphique, moteur 3D, sniffeur réseau, etc ...)
 
mais bon, tu faire des trucs en Java que tu ne peux pas faire en C++ ... genre, j'attend de voir une appli c++ pour un Nokia 3410 ...
 

on va pas chipoter sur les détails hein
 
tiens et la JVM du 3410, elle est programmée en quoi?
 

 
je pencherais plus pour du C que du C++
 
et puis bon, le 3410 est dans la poche de plus d'un million de français, et les prévisions pour la fin 2003 sont de 350 millions de téléphones java dans le monde ... on doit pas être loin du nombre total de PC ... j'appelle pas ca un détail

sans oublier les autres modèles comme le 6100

 
je pense aussi, ca m'etonnerait qu'il y en ait qui s'enquiquine a pondre un compilo C++ pour une plateforme pareille....

pour les 350 M, je parlais tout modèle confondu, hein

ou le 3510, ou le 7650, ou le 3650 ou un de ces téléphones là : http://www.nokia.com/nokia/0,5184,2790,00.html
 
puis bon, y a pas que des nokia ...

 
Justement ! C'est aussi pour cela que c'est bien Et pour la suite de la discution, faut voir avec ce gars qui te l'expliquera bien mieux que moi : http://mindview.net/WebLog/log-0025
 

Déconnecter les sécurités pour faire croître la taille, c'est diminuer la qualité. Résultat, le rebootage et le plantage sont devenus une culture : http://ovh.com/fr/ovh/news/index.c [...] ction&id=3
 

 
fallait y penser : habituer le client à utiliser de la merde !

 
C'est bizarre, je n'ai pas la même traduction que toi de ce paragraphe. Il ne faut pas utiliser babelfish pour lire les sites étrangés tu sais. Moi je lis :
 
"C'était une énigme pour moi : si le typage statique est tellement important, pourquoi est-ce que des gens sont parfaitement capables de réaliser des projets gros et complexes en Python ( en un temps bien plus court par rapport à un langage typé statiquement )."
 
A aucun moment il n'a dit que l'on sacrifie la qualité finale.

je ne prends pas ce document comme référence.
Si vraiment le typage statique est inutile alors Smalltalk et Lisp éclatent tout le monde, python y compris.
 
Sauf que je on voit la qualité des outils que j'utilise, l'augmentation de leur présence au quotidien, je me dis qu'il faudrait peut-être arrêter de faire la malin en supprimant le peu de garde-fous qui existent.
 
D'autant plus qu'il existe d'excellents systèmes de types, souples mais incassables (sans cast suceptibles de lever une exception).
 
 
edit : désolé pour le temps d'édition mais le réseau est tombé.

 
Il me semble que le Python ou le Ruby sont aussi dynamiquement typé que le Smalltalk et le Lisp. Et pour ce qui est des outils de mauvaise qualité que tu utilises, je pourrais te demander en quel langage ils sont écrits. Je ne pense pas que ce soit en SmallTalk ou en Python. Alors pourquoi tu prends exemple sur eux ? Qui te dis que si ils n'avaient pas été fait dans un langage dynamiquement typé ils ne seraient pas beaucoup plus fiable ?

Il sont écrits (en général) dans des langages statiquement typés. Donc c'est pas en les réécrivant dans un langages moins sûr que ça va s'améliorer. S'ils doivent être réécrits, c'est dans un environnement plus sûr (ce que n'offrent pas intrinsèquement ces langages).
 
Il y a aussi un autre problème, remplacer la vérification de types par des tests, c'est reposer sur des humains. Hors ce type de discours n'est pas exactement écrit par le pisseur de code moyen mais par des gens déjà largement au-dessus de la masse (Robert C Martin, Bruce Eckel pour ne citer qu'eux). Hors on ne fait pas reposer une industrie sur des moutons à 5 pattes mais sur des gens normaux. Qui n'auront ni leur expérience (car ils sont déjà relativement vieux) ni leur taux de couverture dans les tests.
 
edit : citation plus courte

 
Et en lisant l'article cité, je reprends un phrase très important : "If it's not tested, it's broken.". Aucun système de typage aussi contraignant soit il ne peut remplacer une bonne série de tests unitaires. Alors si ces tests fait au niveau du compilateur ne suffisent pas, pourquoi s'encombrer ? Pour se donner un faux sentiment de sécurité ? C'est un peu comme les serveurs windows qui peuvent s'administrer avec un niveau de formation au ras des paquerettes. Enfin c'est ce que la pub disait.

Pour en faire faire le minimum par les humains, qui sont plus à-même de se planter que le compilo.
D'autre part, quelle est la garantie que la série de tests unitaires est "bonne" ? Parce qu'ils ont été écrit par RC Martin.
Un système de types à une qualité qui se maîtrise. D'autre part, la preuve formelle continue à avancer (même si un certain nombre de limites formelle ont été démontrée).
 
Le système de types est là pour limiter la quantité de tests à effectuer.

 
Mais au final, est ce qu'il limite vraiment la quantité de tests à effectuer ? Si on veut être exaustif, il faut ecrire des tests qui évaluent toutes les combinaisons d'execution possible. Que se soit avec un langage statiquement typé ou non. Effectivement, avec un système de types parfais ( ce qui n'est pas possible ), il n'y aurait que les erreures de logiques qui restent mais ca ne diminue pas la quantité de test a écrire que je sache. Et dans l'autre cas ( langage dynamiquement typé ), les erreurs de types seraient trouvées pendant la procédure de test.

De l'interet de "->" en C
 
 
Je precise que je sais a quoi sert "->" en C, c'est a dire dans quel cas on l'utilise
 
Ma question est, pour dire les choses simplement :

 
Pourquoi a.membre n'est il pas valide en C ? Ou plutot, pourquoi a t'il ete decide que a.membre ne serait pas valide ? Car je ne vois pas du tout les ambiguite que "->" peut lever. Connaissant le type de "a", pourquoi mon compilo ne remplacerait il pas "a.membre" par "a->membre" au lieu de m'imposer ces contorsions ?
 
 

 
Pour résumer un peu ce qui a été dit ailleur:
 
1) c plus lisible, on sait tout de suite qu'on est en train de bosser sur un pointeur et pas sut une structure ou une union.
2) Comme le . et la -> ne se traduisent pas par les même suite d'opérations il parait logique d'avoir introduit deux opérateurs distincts.