go
remy
bonjour
quelqu'un a déjà testé ou essayé
http://www.al-aide.com/article/linux-4/go-nouveau-langage-chez-google-548540/
c'est une vraie question merci remy
batyann811
>
> bonjour
>
> quelqu'un a d�j� test� ou essay�
>
> http://www.al-aide.com/article/linux-4/go-nouveau-langage-chez-google-548540/
>
>
> c'est une vraie question merci remy
>
remy
> remy a écrit :
>>
>> bonjour
>>
>> quelqu'un a déjà testé ou essayé
>>
>>
>>
>> c'est une vraie question merci remy
>>
> Oui
batyann811
> batyann811 a �crit :
>> remy a �crit :
>>>
>>> bonjour
>>>
>>> quelqu'un a d�j� test� ou essay�
>>>
>>>
>>>
>>> c'est une vraie question merci remy
>>>
>> Oui
> et alors
>
>
Mais � mon avis c'est � chier comme tous les langages plus ou moins
d�riv�s du C.
Mihamina Rakotomandimby
>>> quelqu'un a d�j� test� ou essay�
> et alors
Il a repondu a ta question, tu veux chercher la petite bete?
--
Administration syst�me
Recherche & D�veloppement
GulfSat/Blueline, Madagascar
Tel: +261 33 11 207 36
remy
> remy a écrit :
>> batyann811 a écrit :
>>> remy a écrit :
>>>>
>>>> bonjour
>>>>
>>>> quelqu'un a déjà testé ou essayé
>>>>
>>>>
>>>>
>>>> c'est une vraie question merci remy
>>>>
>>> Oui
>> et alors
>>
>>
>
> Mais à mon avis c'est à chier comme tous les langages plus ou moins
> dérivés du C.
pas sûr puisque le principal défaut du C c'est la gestion de la
mémoire et comme il y a un garbage collector
cela donne un langage sécu de manière structurelle
pas de débordement de tampon
si tu rajoutes le fait qu'il soit compilé et multi threads par nature
tu as un environnement rapide
j'ai juste un petit problème de compréhension
avec la programmation système surtout si système veut dire noyau
qui gère la mémoire ?
remy
remy
> 11/26/2009 01:44 PM, remy:
>>> Oui
>> et alors
>
> Il a repondu a ta question, tu veux chercher la petite bete?
>
JKB
Re: go,
remy ?crivait dans fr.comp.os.linux.debats :
> batyann811 a écrit :
>> remy a écrit :
>>> batyann811 a écrit :
>>>> remy a écrit :
>>>>>
>>>>> bonjour
>>>>>
>>>>> quelqu'un a déjà testé ou essayé
>>>>>
>>>>> http://www.al-aide.com/article/linux-4/go-nouveau-langage-chez-google-548540/
>>>>>
>>>>>
>>>>> c'est une vraie question merci remy
>>>>>
>>>> Oui
>>> et alors
>>>
>>>
>> J'en sais rien. Je ne l'ai pas essayé mais quelqu'un l'a fait c'est sur.
>>
>> Mais à mon avis c'est à chier comme tous les langages plus ou moins
>> dérivés du C.
>
>
> pas sûr puisque le principal défaut du C c'est la gestion de la
> mémoire et comme il y a un garbage collector
> cela donne un langage sécu de manière structurelle
> pas de débordement de tampon
Tu te rends compte de ce que tu es capable d'écrire ? Je te rappelle
que Java est un langage à GC, ce n'est pas ce qui empêche les fuites
mémoire partout, parce qu'en général, il faut déréférencer les
objets pour que le GC récupère la mémoire (et au prix d'une
consommation de ressources sans aucune mesure).
Bref, le GC, c'est une rustine pour les gens qui ne savent pas
programmer (ou qui utilisent la mémoire comme des gorets).
> si tu rajoutes le fait qu'il soit compilé et multi threads par nature
> tu as un environnement rapide
Multithread par nature... J'aimerais bien qu'on m'explique le
concept. C'est assez marketteux. _Aucun_ langage n'est multithread
par nature dès lors qu'il s'appuie sur un OS. Il va toujours
terminer par un appel à un truc qui gère les threads à sa place.
Qu'il fournisse un mécanisme pour gérer les threads de façon
portable, peut-être. Il y a juste un truc qui risque de coincer si
ce truc n'utilise pas une VM, c'est les limitations de l'OS hôte (le
coup des threads et de la préemption de Windows risque d'être assez
marrant en terme de portabilité).
> j'ai juste un petit problème de compréhension
> avec la programmation système surtout si système veut dire noyau
>
> qui gère la mémoire ?
C'est _toujours_ le programmeur qui gère de manière directe ou
indirecte la mémoire. Après, on peut le faire efficacement façon C
ou le masquer dans un tas de trucs abscons façon C++ ou Java. Mais
au final, c'est _toujours_ le programmeur qui fait.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
batyann811
>
>
> pas s�r puisque le principal d�faut du C c'est la gestion de la
> m�moire et comme il y a un garbage collector
> cela donne un langage s�cu de mani�re structurelle
> pas de d�bordement de tampon
>
Pour moi les 2 principaux d�fauts du C c'est
1 - Typage pas assez strict (pas de bool�en, pas d'enum, pas de type
intervalle, ...)
2 - Permet trop facilement de faire des trucs illisibles
Bref c'est et �a aurait du rester une sorte d'assembleur un peu �volu�.
Mihamina Rakotomandimby
>> Mais � mon avis c'est � chier comme tous les langages plus ou moins
>> d�riv�s du C.
Au lieu de faire semblant de savoir des choses,
tu aurais pu savoir faire une recherche et
tomber sur ceci:
http://groups.google.com/group/fr.comp.lang.c/browse_thread/thread/82c1fdd4a591d3a6#
JKB
Re: go,
> remy a écrit :
>>
>>
>> pas sûr puisque le principal défaut du C c'est la gestion de la
>> mémoire et comme il y a un garbage collector
>> cela donne un langage sécu de manière structurelle
>>
>
> Pour moi les 2 principaux défauts du C c'est
> 1 - Typage pas assez strict (pas de booléen, pas d'enum, pas de type
> 2 - Permet trop facilement de faire des trucs illisibles
Je peux de faire des trucs illisibles en Fortran95 ou en ADA...
> Bref c'est et ça aurait du rester une sorte d'assembleur un peu évolué.
Le problème du C, c'est qu'il devrait se cantonner à son domaine, à
savoir la programmation système.
batyann811
>
> Je peux de faire des trucs illisibles en Fortran95 ou en ADA...
>
Oui mais en ADA c'est plus dur. Pas && << >> % ++ -- et toutes ces
conneries.
>
> Le problème du C, c'est qu'il devrait se cantonner à son domaine, à
> savoir la programmation système.
>
Oui un assembleur evolué.
Kojak
JKB <knat...@koenigsberg.fr> a écrit :
> Le 26-11-2009, ? propos de Re: go,
> remy ?crivait dans fr.comp.os.linux.debats :
> > pas sûr puisque le principal défaut du C c'est la gestion de la
> > pas de débordement de tampon [...]
>
> Tu te rends compte de ce que tu es capable d'écrire ? Je te
> rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
> les fuites mémoire partout, parce qu'en général, il faut déréférencer
> les objets pour que le GC récupère la mémoire (et au prix d'une
> consommation de ressources sans aucune mesure).
T'énerve pas ! Tu sais très bien que dès qu'un nouveau langage sort,
t'as tout les gogos qui se jettent dessus croyant que ça va résoudre
tous leurs problèmes.
> Bref, le GC, c'est une rustine pour les gens qui ne savent pas
> programmer (ou qui utilisent la mémoire comme des gorets).
Ah là non ! Ne crache pas sur Lisp, s'il te plaît ! :-)
--
Jacques.
JKB
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
>>
>> Je peux de faire des trucs illisibles en Fortran95 ou en ADA...
>>
>
> Oui mais en ADA c'est plus dur. Pas && << >> % ++ -- et toutes ces
> conneries.
Il y a longtemps que tu n'as pas fait d'ADA, toi. L'intérêt d'ADA,
c'est d'écrire un code dont le comportement est reproductible. On se
contrefiche de la lisibilité de la syntaxe. Avec ADA, il est
parfaitement possible d'écrire du code objet et ça peut rapidement
devenir illisible (de la même façon qu'en C, on peut écrire des
choses propres).
>>
>> Le problème du C, c'est qu'il devrait se cantonner à son domaine, à
>> savoir la programmation système.
>>
>
> Oui un assembleur evolué.
Certainement pas. Le C n'est pas un assembleur évolué. Un assembleur
évolué, ce serait Macro32 de VMS. Ce n'est pas un assembleur évolué
parce qu'il ne permet l'accès à un paquet de structures de contrôle,
parce qu'il ne garantit pas l'exécution dans un ordre donné, ni
l'atomicité, ni d'ailleurs rien d'autre qui est faisable en
assembleur. C'est même pour cela qu'au fond des OS, il y a quasiment
toujours des routines écrites directement en assembleur !
batyann811
> Il y a longtemps que tu n'as pas fait d'ADA, toi. L'intérêt d'ADA,
> c'est d'écrire un code dont le comportement est reproductible. On se
> contrefiche de la lisibilité de la syntaxe. Avec ADA, il est
> parfaitement possible d'écrire du code objet et ça peut rapidement
> devenir illisible (de la même façon qu'en C, on peut écrire des
> choses propres).
Je ne me contrefiche pas de la lisibilité de la syntaxe.
On peut écrire du code propre en C si on veut oui mais c'est plus facile
à faire en ADA : le compilateur t'aide.
>
> Certainement pas. Le C n'est pas un assembleur évolué. Un assembleur
> évolué, ce serait Macro32 de VMS. Ce n'est pas un assembleur évolué
> parce qu'il ne permet l'accès à un paquet de structures de contrôle,
> parce qu'il ne garantit pas l'exécution dans un ordre donné, ni
> l'atomicité, ni d'ailleurs rien d'autre qui est faisable en
> assembleur. C'est même pour cela qu'au fond des OS, il y a quasiment
> toujours des routines écrites directement en assembleur !
Allez si ça peut te faire plaisir je vais dire que c'est un assembleur++
Stéphane CARPENTIER
> Le 26-11-2009, ? propos de
> Re: go,
> batyann811 ?crivait dans fr.comp.os.linux.debats :
>
> Je peux de faire des trucs illisibles en Fortran95 ou en ADA...
Pour le programme le plus illisible, il doit être dur de faire pire qu'APL.
Stéphane CARPENTIER
> 11/26/2009 01:44 PM, remy:
>>>> quelqu'un a d�j� test� ou essay�
>>> Oui
>> et alors
>
> Il a repondu a ta question, tu veux chercher la petite bete?
Il essaye de faire vivre son troll, il ne faut pas lui en vouloir.
Kojak
Stéphane CARPENTIER <stef.ca...@gratuit.fr.invalid> a écrit :
C'est reconnu comme un langage «write only». Par contre, pour la
concision, il n'y a pas mieux.
--
Jacques.
batyann811
>
> pas s�r puisque le principal d�faut du C c'est la gestion de la
> m�moire et comme il y a un garbage collector
> cela donne un langage s�cu de mani�re structurelle
> pas de d�bordement de tampon
J'avais pas vu � la premi�re lecture mais c'est quoi le rapport entre un
GC et un d�bordement de tampon ?
Kojak
batyann811 <batya...@invalid.fre> a écrit :
> J'avais pas vu à la première lecture mais c'est quoi le rapport entre
> un GC et un débordement de tampon ?
Des histoires de bonnes femmes, à tous les coups. :-)
--
Jacques.
debug this fifo
> On peut écrire du code propre en C si on veut oui mais c'est plus facile
> à faire en ADA : le compilateur t'aide.
>
Ada, c'est le langage que quand tu reviens du marche, que tu as achete
quatre poires et six pommes, tu peux pas savoir combien tu as de fruits.
batyann811
> Ada, c'est le langage que quand tu reviens du marche, que tu as achete
> quatre poires et six pommes, tu peux pas savoir combien tu as de fruits.
>
:-)
Disons si tu veux ça peut conduire à ça mais on peut contourner en
appelant une fonction C. ;-)
debug this fifo
>
> Pour moi les 2 principaux d�fauts du C c'est
> 1 - Typage pas assez strict (pas de bool�en, pas d'enum, pas de type
fud detected...
> intervalle, ...)
> 2 - Permet trop facilement de faire des trucs illisibles
comme la plupart des langages de programmation, en fait.
batyann811
>
> Des histoires de bonnes femmes, à tous les coups. :-)
>
C'est vrai que si GC veut dire Gros Cul...
batyann811
> batyann811 wrote:
>>
>> Pour moi les 2 principaux d�fauts du C c'est
>> 1 - Typage pas assez strict (pas de bool�en, pas d'enum, pas de type
> ^^^^^^^^^^
> fud detected...
Non non. Je suis s�rieux je ne consid�re pas les enums du C comme un
vrai type �num�r�.
>> intervalle, ...)
>> 2 - Permet trop facilement de faire des trucs illisibles
>
> comme la plupart des langages de programmation, en fait.
Sauf qu'en C, quand tu le fais, tu passes pour un pro au lieu de passer
pour un con. ;-)
Nicolas George
�crit�:
> Pour moi les 2 principaux d�fauts du C c'est
> 1 - Typage pas assez strict (pas de bool�en, pas d'enum
Donc le probl�me du C, c'est que tu n'y connais rien.
remy
je n'ai jamais vu de fuite mémoire ou plutôt
je ne l'ai jamais rencontrée avec du code java
maintenant qu'une implémentation d'un gc soit foireuse, je veux bien te
l'accorder, de tout manière je n'ai pas parlé de fuite mémoire
mais de débordement de tampon
en gros mais en très gros hein
un gc c'est quoi ?
c'est un programme qui tourne tout seul dans son coin type démon
il te renvoie un pointeur et ce pointeur est accompagné
d'un compteur qui explique combien il y a de copies de cette donnée
ou de pointeurs qui pointent sur cette zone au choix
quand le compteur est à zéro le système libère la zone
alors que cette zone ne soit pas libérée de manière instantanée je te
l'accorde, mais ce n'est pas une fuite mémoire, juste une zone qui n'est
pas encore libérée sauf si il merde dans son décompte ou comptage bien
sûr
ensuite ce genre de gestion rend impossible l'exécution de cette zone
et en plus elle est allouée dans une partie non connue et qui change
pratiquement à chaque exécution du code
>> si tu rajoutes le fait qu'il soit compilé et multi threads par nature
>> tu as un environnement rapide
>
> Multithread par nature... J'aimerais bien qu'on m'explique le
> concept. C'est assez marketteux. _Aucun_ langage n'est multithread
> par nature dès lors qu'il s'appuie sur un OS. Il va toujours
> terminer par un appel à un truc qui gère les threads à sa place.
> Qu'il fournisse un mécanisme pour gérer les threads de façon
> portable, peut-être.
voilà, je me suis mal exprimé, désolé, je voulais dire de manière
portable et simple , sans usine à gaz
en java si cela n'a pas changé, le code s'exécute par défaut dans le
thread de l'interface graphique, c'est moyen je trouve
Il y a juste un truc qui risque de coincer si
> ce truc n'utilise pas une VM, c'est les limitations de l'OS hôte (le
> coup des threads et de la préemption de Windows risque d'être assez
> marrant en terme de portabilité).
>
>> j'ai juste un petit problème de compréhension
>> avec la programmation système surtout si système veut dire noyau
>>
>> qui gère la mémoire ?
>
> C'est _toujours_ le programmeur qui gère de manière directe ou
> indirecte la mémoire. Après, on peut le faire efficacement façon C
> ou le masquer dans un tas de trucs abscons façon C++ ou Java. Mais
> au final, c'est _toujours_ le programmeur qui fait.
>
ben comme je suis une grosse faignace, je veux qu'on le fasse à ma
place,j'ai autre chose à faire qu'à compter les octets utilisés
non mais
> JKB
>
remy
Nicolas George
, dans le message <4b0e75d2$0$25799$426a...@news.free.fr>, a �crit�:
> Pour le programme le plus illisible, il doit �tre dur de faire pire qu'APL.
Je suis, et je monte avec Unlambda.
batyann811
en C pas des types entiers d�tourn�s.
Nicolas George
�crit�:
> Tu montres ou sont les *vrais* types �num�r�s et le *vrai* type bool�en
> en C pas des types entiers d�tourn�s.
Les types �num�r�s et les bool�ens _sont_ des entiers, tu n'y peux rien.
batyann811
> Tu montres ou sont les *vrais* types �num�r�s et le *vrai* type bool�en
> en C pas des types entiers d�tourn�s.
>
remy
batyann811
>
> Les types �num�r�s et les bool�ens _sont_ des entiers, tu n'y peux rien.
Super ! Donc vrai + rouge = 6 ! La classe. Merci.
batyann811
>
> Les types �num�r�s et les bool�ens _sont_ des entiers, tu n'y peux rien.
Ce sont des entiers en C dans un vrai langage ce sont juste des types
scalaires. Les entiers aussi sont des types scalaires mais en aucun cas
les types �num�r�s et le type bool�en ne sont des entiers.
debug this fifo
> les types �num�r�s et le type bool�en ne sont des entiers.
>
le booleen non entier, c'est pour la logique floue.
batyann811
>
:-)
En fait un boole�n et un entier c'est un peu comme un CD d'Annie Cordy
et un sous marin nucl�aire. Pas grand chose � voir.
Mais pas mal la blague sur la logique floue.
doug713705
>> Des histoires de bonnes femmes, ￜ tous les coups. :-)
>>
>
> C'est vrai que si GC veut dire Gros Cul...
Si le tampon dï¿œborde par le cul c'est qu'il faut relire la page de man
affï¿œrante,
--
Doug713705
Yliur
> > Tu te rends compte de ce que tu es capable d'écrire ? Je te
> > rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
> > les fuites mémoire partout, parce qu'en général, il faut
> > déréférencer les objets pour que le GC récupère la mémoire (et au
> > prix d'une consommation de ressources sans aucune mesure).
> >
> > Bref, le GC, c'est une rustine pour les gens qui ne savent
> > pas programmer (ou qui utilisent la mémoire comme des gorets).
> >
>
> je n'ai jamais vu de fuite mémoire ou plutôt
> je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez
rares en Java. C'est juste quand la variable est référencée dans un
endroit "annexe", par exemple elle est stockée dans une table de
hachage (indexation). Et encore, l'utilisation de références
faibles permet de ne pas s'occuper de ça dans ce cas.
> en java si cela n'a pas changé, le code s'exécute par défaut dans le
> thread de l'interface graphique, c'est moyen je trouve
Ben il s'agit uniquement du code en réaction aux événements
utilisateurs (quand il clique sur un bouton par exemple). Et ça peut
être ça que tu veux, pour éviter que l'utilisateur puisse cliquer sur
plusieurs boutons "en même temps" (c'est-à-dire que le code exécuté
en réaction aux clics s'exécute en parallèle). Si le traitement
déclenché est long et que tu veux l'exécuter dans un autre fil
d'exécution, il faut effectivement créer toi-même le nouveau fil.
Yliur
> >
> > Certainement pas. Le C n'est pas un assembleur évolué. Un
> > assembleur évolué, ce serait Macro32 de VMS. Ce n'est pas un
> > assembleur évolué parce qu'il ne permet l'accès à un paquet de
> > structures de contrôle, parce qu'il ne garantit pas l'exécution
> > dans un ordre donné, ni l'atomicité, ni d'ailleurs rien d'autre qui
> > est faisable en assembleur. C'est même pour cela qu'au fond des OS,
> > il y a quasiment toujours des routines écrites directement en
> > assembleur !
>
> Allez si ça peut te faire plaisir je vais dire que c'est un
> assembleur++
>
++assembleur, il faut l'améliorer avant de l'utiliser.
Yliur
batyann811 <batya...@invalid.fre> a écrit :
> debug this fifo a écrit :
> > batyann811 wrote:
> >>
> >> Pour moi les 2 principaux défauts du C c'est
> >> 1 - Typage pas assez strict (pas de booléen, pas d'enum, pas de
> >> type
> > ^^^^^^^^^^
> > fud detected...
>
> Non non. Je suis sérieux je ne considère pas les enums du C comme un
> vrai type énuméré.
Si on est un peu strict/méchant, il n'y a pas non plus de tableaux ni
de caractères en C. Il y a bien des éléments de syntaxe pour gérer
des tableaux ou des caractères, mais c'est pour faire semblant :
- un "tableau" c'est juste un pointeur, ce qui fait qu'il faut
noter à côté sa taille.
- un "caractère" c'est juste un octet, on ne peut pas faire de
correspondance non ambiguë avec un caractère parce que l'encodage
n'est pas spécifié.
batyann811
>
> Si on est un peu strict/m�chant, il n'y a pas non plus de tableaux ni
> de caract�res en C. Il y a bien des �l�ments de syntaxe pour g�rer
> des tableaux ou des caract�res, mais c'est pour faire semblant :
> - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut
> - un "caract�re" c'est juste un octet, on ne peut pas faire de
> correspondance non ambigu� avec un caract�re parce que l'encodage
> n'est pas sp�cifi�.
>
100% d'accord. Et c'est m�me pas �tre m�chant.
doug713705
>> les types ï¿œnumï¿œrï¿œs et le type boolï¿œen ne sont des entiers.
>>
>
> le booleen non entier, c'est pour la logique floue.
if (bool == 0.5){
printf "ptet bin qu'oui, ptet ben qu'non"
}else{
printf "vous n'etes pas Normand."
}
--
Doug713705
Nicolas George
�crit�:
> Ce sont des entiers en C dans un vrai langage ce sont juste des types
> scalaires. Les entiers aussi sont des types scalaires mais en aucun cas
> les types �num�r�s et le type bool�en ne sont des entiers.
C'est fondamentalement la m�me chose.
batyann811
>
> C'est fondamentalement la m�me chose.
En C oui... Dans la plupart des autres langages non.
remy
>>> Tu te rends compte de ce que tu es capable d'écrire ? Je te
>>> rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
>>> les fuites mémoire partout, parce qu'en général, il faut
>>> déréférencer les objets pour que le GC récupère la mémoire (et au
>>> prix d'une consommation de ressources sans aucune mesure).
>>>
>>> Bref, le GC, c'est une rustine pour les gens qui ne savent
>>> pas programmer (ou qui utilisent la mémoire comme des gorets).
>>>
>> je n'ai jamais vu de fuite mémoire ou plutôt
>> je ne l'ai jamais rencontrée avec du code java
>
> Les cas où il faut "déréferencer" des variables sont en effet assez
> rares en Java. C'est juste quand la variable est référencée dans un
> endroit "annexe", par exemple elle est stockée dans une table de
> hachage (indexation). Et encore, l'utilisation de références
> faibles permet de ne pas s'occuper de ça dans ce cas.
>
>
j'avais fait un peu exprès
je savais que jdk y fait une allergie
et qu'il a eu des gros problèmes avec
>> en java si cela n'a pas changé, le code s'exécute par défaut dans le
>> thread de l'interface graphique, c'est moyen je trouve
>
> Ben il s'agit uniquement du code en réaction aux événements
> utilisateurs (quand il clique sur un bouton par exemple). Et ça peut
> être ça que tu veux, pour éviter que l'utilisateur puisse cliquer sur
> plusieurs boutons "en même temps" (c'est-à-dire que le code exécuté
> en réaction aux clics s'exécute en parallèle). Si le traitement
> déclenché est long et que tu veux l'exécuter dans un autre fil
> d'exécution, il faut effectivement créer toi-même le nouveau fil.
>
cela ne se voit pas trop parce que les machines sont surpuissantes
mais il était assez courant d'avoir des interfaces gelées
parce que les traitements d'une action étaient longs
tiens au hasard un tri à la con au début pas de problème très peu de
données
6 mois après, 10 secondes avant de pouvoir utiliser l'interface
et en particulier le bouton stop
remy
>> Ce sont des entiers en C dans un vrai langage ce sont juste des types
>> scalaires. Les entiers aussi sont des types scalaires mais en aucun cas
>
> C'est fondamentalement la même chose.
http://www.idris.fr/su/Vectoriel/brodie/cc_sizeof.html
au mieux 16 bits et un int sur un proc de 64 bits
il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes
par contre pour le c ce sont des souvenirs
remy
remy
>>> Tu te rends compte de ce que tu es capable d'écrire ? Je te
>>> rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
>>> les fuites mémoire partout, parce qu'en général, il faut
>>> déréférencer les objets pour que le GC récupère la mémoire (et au
>>> prix d'une consommation de ressources sans aucune mesure).
>>>
>>> Bref, le GC, c'est une rustine pour les gens qui ne savent
>>> pas programmer (ou qui utilisent la mémoire comme des gorets).
>>>
>> je n'ai jamais vu de fuite mémoire ou plutôt
>> je ne l'ai jamais rencontrée avec du code java
>
> Les cas où il faut "déréferencer" des variables sont en effet assez
> rares en Java. C'est juste quand la variable est référencée dans un
> endroit "annexe", par exemple elle est stockée dans une table de
> hachage (indexation). Et encore, l'utilisation de références
> faibles permet de ne pas s'occuper de ça dans ce cas.
>
et qu'il a eu des gros problèmes avec
>
>> en java si cela n'a pas changé, le code s'exécute par défaut dans le
>> thread de l'interface graphique, c'est moyen je trouve
>
> Ben il s'agit uniquement du code en réaction aux événements
> utilisateurs (quand il clique sur un bouton par exemple). Et ça peut
> être ça que tu veux, pour éviter que l'utilisateur puisse cliquer sur
> plusieurs boutons "en même temps" (c'est-à-dire que le code exécuté
> en réaction aux clics s'exécute en parallèle). Si le traitement
> déclenché est long et que tu veux l'exécuter dans un autre fil
> d'exécution, il faut effectivement créer toi-même le nouveau fil.
>
ela ne se voit pas trop parce que les machines sont surpuissantes
Richard Delorme
> Si on est un peu strict/m�chant, il n'y a pas non plus de tableaux ni
> de caract�res en C. Il y a bien des �l�ments de syntaxe pour g�rer
> des tableaux ou des caract�res, mais c'est pour faire semblant :
> - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut
> noter � c�t� sa taille.
C'est faux. En C un tableau n'est pas un pointeur et leur taille,
mesur�e par sizeof, diff�re.
int t[100];
int n_element = sizeof (t)/ sizeof (t[0]);
int *p = t;
int nimporte_quoi = sizeof (p)/ sizeof (p[0]);
n_element vaut 100, tandis que nimporte_qoui a une valeur d�pendant de
l'impl�mentation (g�n�ralement 1 ou 2).
--
Richard
Bruno Ducrot
N'importe quoi.
> cat t.c
#include <stdio.h>
#include <stdbool.h>
enum color {
red = 41,
green,
blue,
};
int
main(void)
{
enum color rouge = red;
bool vrai = true;
printf("vrai + rouge == %d\n", vrai + rouge);
return 0;
}
> gcc t.c
> ./a.out
vrai + rouge == 42
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
JKB
Re: go,
remy ?crivait dans fr.comp.os.linux.debats :
>>>> Tu te rends compte de ce que tu es capable d'écrire ? Je te
>>>> rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
>>>> les fuites mémoire partout, parce qu'en général, il faut
>>>> déréférencer les objets pour que le GC récupère la mémoire (et au
>>>> prix d'une consommation de ressources sans aucune mesure).
>>>>
>>>> Bref, le GC, c'est une rustine pour les gens qui ne savent
>>>> pas programmer (ou qui utilisent la mémoire comme des gorets).
>>>>
>>> je n'ai jamais vu de fuite mémoire ou plutôt
>>> je ne l'ai jamais rencontrée avec du code java
>>
>> Les cas où il faut "déréferencer" des variables sont en effet assez
>> rares en Java. C'est juste quand la variable est référencée dans un
>> endroit "annexe", par exemple elle est stockée dans une table de
>> hachage (indexation). Et encore, l'utilisation de références
>> faibles permet de ne pas s'occuper de ça dans ce cas.
>>
> j'avais fait un peu exprès
> je savais que JKB y fait une allergie
> et qu'il a eu des gros problèmes avec
Disons que j'ai un soft qui est un serveur en java et qui tourne
24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu ne veux
pas que le truc se mette à bouffer toute la mémoire avec des
connexions TCP (et donc des threads) mortes qui continuent à polluer
la JVM. Les problèmes, ça arrive _très_ vite avec ce genre de gag.
Le problème de cette gestion des ressources, c'est que ça cache
tout et que le programmeur qui n'est pas passé par la case C ne sait
plus exactement ce qui se passe.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Yliur
> >> en java si cela n'a pas changé, le code s'exécute par défaut dans
> >> le thread de l'interface graphique, c'est moyen je trouve
> >
> > Ben il s'agit uniquement du code en réaction aux événements
> > utilisateurs (quand il clique sur un bouton par exemple). Et ça
> > peut être ça que tu veux, pour éviter que l'utilisateur puisse
> > cliquer sur plusieurs boutons "en même temps" (c'est-à-dire que le
> > code exécuté en réaction aux clics s'exécute en parallèle). Si le
> > traitement déclenché est long et que tu veux l'exécuter dans un
> > autre fil d'exécution, il faut effectivement créer toi-même le
> > nouveau fil.
> >
>
> ela ne se voit pas trop parce que les machines sont surpuissantes
> mais il était assez courant d'avoir des interfaces gelées
> parce que les traitements d'une action étaient longs
>
> tiens au hasard un tri à la con au début pas de problème très peu de
> données
>
> 6 mois après, 10 secondes avant de pouvoir utiliser l'interface
> et en particulier le bouton stop
Oui mais en général quand tu cliques sur un bouton l'action est
quasiment instantanée et tu ne veux pas qu'autre chose puisse
s'exécuter en même temps dans l'interface, pour des raisons de
cohérence (si les deux actions modifient l'interface graphique,
elles doivent se dérouler l'une après l'autre, ne serait-ce que si
l'utilisateur a cliqué deux fois par mégarde sur le bouton).
C'est à toi de déterminer que telle action risque de prendre du temps
et de gérer l'exécution parallèle, ce n'est pas le cas de la plupart
des actions. Et effectivement si on n'a pas pensé qu'une action
donnée risquait de poser problème on peut avoir des surprises :) . Et
si tu t'es donné la peine de faire un bouton stop, il faut aussi de
donner la peine de tester qu'il sert à quelque chose ;) .
Et euh... pour avoir des tris de 10 secondes, c'est un tri à bulles ou
il y a des millions (milliards ?) de données ?
Yliur
Richard Delorme <abu...@nospam.fr> a écrit :
> Le 26/11/2009 15:44, Yliur a écrit :
>
> > Si on est un peu strict/méchant, il n'y a pas non plus de tableaux
> > ni de caractères en C. Il y a bien des éléments de syntaxe pour
> > gérer des tableaux ou des caractères, mais c'est pour faire
> > semblant :
> > - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut
> > noter à côté sa taille.
>
> C'est faux. En C un tableau n'est pas un pointeur et leur taille,
> mesurée par sizeof, diffère.
>
> int t[100];
> int n_element = sizeof (t)/ sizeof (t[0]);
> int *p = t;
> int nimporte_quoi = sizeof (p)/ sizeof (p[0]);
>
> n_element vaut 100, tandis que nimporte_qoui a une valeur dépendant
> de l'implémentation (généralement 1 ou 2).
>
Mais ça ne marche que pour les tableaux statiques, parce que le
compilateur peut retrouver la taille du tableau. Donc par exemple si
tu passes le tableau en paramètre à une fonction, tu ne peux pas
avoir sa taille, si ?
Yliur
remy <re...@fctpas.fr> a écrit :
Il me semblait qu'en C la taille (en octets) des types numériques
n'était pas spécifiée ? Et que selon le compilateur et la plate-forme
on pouvait avoir des tailles différentes, la seule garantie étant que
short <= int <= long (en nombre d'octets) ?
D'ailleurs je suis presque sûr d'avoir vu des int stockés par un
programme C dans un fichier et qui étaient sur 2 octets (compilateur
Borland).
Yliur
> Disons que j'ai un soft qui est un serveur en java et qui
> tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu
> ne veux pas que le truc se mette à bouffer toute la mémoire avec des
> connexions TCP (et donc des threads) mortes qui continuent à
> polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre de
> gag.
>
Des serveurs d'application java qui tournent 24h/24 ce n'est pas
exceptionnel. Je ne vois pas dans quel cas des connexions TCP
pourraient être conservées comme ça. Tu as un exemple (sur un
serveur d'application ou un serveur que tu écris toi-même, qui est
peut-être le cas dont tu parles) ?
> Le problème de cette gestion des ressources, c'est que ça
> cache tout et que le programmeur qui n'est pas passé par la case C ne
> sait plus exactement ce qui se passe.
>
> JKB
>
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
JKB
Re: go,
>
>> Disons que j'ai un soft qui est un serveur en java et qui
>> tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu
>> ne veux pas que le truc se mette à bouffer toute la mémoire avec des
>> connexions TCP (et donc des threads) mortes qui continuent à
>> polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre de
>> gag.
>>
>
> Des serveurs d'application java qui tournent 24h/24 ce n'est pas
> exceptionnel. Je ne vois pas dans quel cas des connexions TCP
> pourraient être conservées comme ça. Tu as un exemple (sur un
> serveur d'application ou un serveur que tu écris toi-même, qui est
> peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java effectivement
développé par une équipe maison (qui connaît parfaitement ces
technos). Le truc était utilisé entre la France et des pays à accès
internet aléatoires que je ne citerais pas. Il a fallu bricoler tout
un système pour faire le ménage dans les threads morts sur des
timeout de sockets et des trucs plus bizarres encore. Au début, ça se
soldait par un redémarrage du truc tous les jours à 6h00 du matin.
Aujourd'hui, la chose est stabilisée, mais ça n'a pas été simple.
La solution a été de coller un thread de surveillance qui 'pingue'
le client. Si le client ne répond pas à trois ping consécutifs, sa
session sur le serveur est libérée. Tous les mécanismes prévus par
Java fonctionnaient parfaitement avec une socket locale, mais plus
avec une socket réseau dès lors que l'accès était de mauvaise
qualité.
>> Le problème de cette gestion des ressources, c'est que ça
>> cache tout et que le programmeur qui n'est pas passé par la case C ne
>> sait plus exactement ce qui se passe.
>>
>> JKB
>>
>
> Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un truc
comme java ?
batyann811
>> cat t.c
> #include <stdio.h>
> #include <stdbool.h>
>
> enum color {
> red = 41,
> green,
> blue,
> };
>
> int
> main(void)
> {
> enum color rouge = red;
> bool vrai = true;
>
> printf("vrai + rouge == %d\n", vrai + rouge);
> return 0;
> }
>> gcc t.c
>> ./a.out
> vrai + rouge == 42
>
Et oui malheureusement... Tout � fait le genre de truc qui ne devrait
m�me pas �tre compil�.
$ cat test_enum_bool.adb
with Ada.Text_IO;
use Ada.Text_IO;
procedure Test_Enum_Bool is
type Color is (Red, Green, Blue);
Rouge : Color := Red;
Vrai : Boolean := True;
begin
Put("Vrai + Rouge =");
Put(Rouge + Vrai);
New_Line;
end Test_Enum_Bool;
$ gnatmake test_enum_bool.adb
gcc -c test_enum_bool.adb
test_enum_bool.adb:11:14: invalid operand types for operator "+"
test_enum_bool.adb:11:14: left operand has type "Color" defined at line 5
test_enum_bool.adb:11:14: right operand has type "Standard.Boolean"
gnatmake: "test_enum_bool.adb" compilation error
remy
même plus vieux
le time out n'était pas remonté de mémoire
donc pas de désalocation du socket puisqu'il n'était pas fermé
ce n'est pas un problème de gc
change de jmv
remy
>>> Le problème de cette gestion des ressources, c'est que ça
>>> cache tout et que le programmeur qui n'est pas passé par la case C ne
>>> sait plus exactement ce qui se passe.
>>>
>>> JKB
>>>
>> Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
>
> La question est donc : peut-on directement attaquer par un truc
> comme java ?
>
> JKB
>
Nicolas George
�crit�:
> En C oui...
Non, fondamentalement. Cherche ce mot dans le dictionnaire si tu as des
doutes sur son sens.
Nicolas George
> Mais �a ne marche que pour les tableaux statiques
Non, les VLA sont standards depuis dix ans.
> tu passes le tableau en param�tre � une fonction, tu ne peux pas
> avoir sa taille, si ?
On ne peut pas passer un tableau en param�tre.
batyann811
> Non, fondamentalement. Cherche ce mot dans le dictionnaire si tu as des
> doutes sur son sens.
Non. Entiers et �num�r�s (les bool�ens n'�tant qu'un cas particulier
d'�num�r�s) sont "fondamentalement" et ont des usages "fondamentalement"
diff�rents.
remy
http://www.commentcamarche.net/contents/cpp/cpptype.php3
int Entier
2 (sur processeur 16 bits)
4 (sur processeur 32 bits)
bool Booléen
Même taille que le type int, parfois 1 sur quelques compilateurs
un bool sur un sur processeur 64 bits 8 octets peut etre?
super pour 2 état
remy
batyann811
>
> On ne peut pas passer un tableau en param�tre.
Justement parce que c'est juste un pointeur d�guis�.
remy
> Nicolas George a écrit :
>>
>> On ne peut pas passer un tableau en paramètre.
>
> Justement parce que c'est juste un pointeur déguisé.
parce qu' en plus c'est carnaval
remy
remy
msg 4
remy :-) souvenir souvenir
debug this fifo
> int Entier
> 2 (sur processeur 16 bits)
pas toujours.
Nicolas George
�crit�:
> Non. Entiers et �num�r�s (les bool�ens n'�tant qu'un cas particulier
> d'�num�r�s) sont "fondamentalement" et ont des usages "fondamentalement"
> diff�rents.
Les usages ne sont pas les m�mes, mais le concept math�matique derri�re est
exactement le m�me.
Nicolas George
�crit�:
> Justement parce que c'est juste un pointeur d�guis�.
Non.
batyann811
>
> Les usages ne sont pas les m�mes, mais le concept math�matique derri�re est
> exactement le m�me.
Il se trouve que je parlais d'informatique pas de math.
Stéphane CARPENTIER
> le client. Si le client ne répond pas à trois ping consécutifs, sa
> session sur le serveur est libérée.
Si la politique sécurité du client est de ne pas répondre au ping (je
sais que c'est de la sécurité d'imbéciles, mais ça existe) ça se passe
comment ?
Stéphane CARPENTIER
> St�phane CARPENTIER
> , dans le message <4b0e75d2$0$25799$426a...@news.free.fr>, a �crit :
>> Pour le programme le plus illisible, il doit �tre dur de faire pire qu'APL.
>
> Je suis, et je monte avec Unlambda.
Je ne connaissais pas.
D'apr�s ce que j'en ai vu, �a doit �tre possible de faire plus illisible
qu'APL, mais je ne suis pas s�r.
Par contre, d'apr�s ce que j'en ai vu, pour faire la m�me chose, APL
utilisera beaucoup moins de caract�res pour �tre illisible.
Patrick Lamaizière
> en gros mais en tr�s gros hein
> un gc c'est quoi ?
>
> c'est un programme qui tourne tout seul dans son coin type d�mon
> il te renvoie un pointeur et ce pointeur est accompagn�
> d'un compteur qui explique combien il y a de copies de cette donn�e
> ou de pointeurs qui pointent sur cette zone au choix
> quand le compteur est � z�ro le syst�me lib�re la zone
Ben non pas vraiment. �a ne fonctionne pas par comptage de r�f�rence
mais sur *l'accessibilit�* de la donn�e. Tu peux avoir des r�f�rences
cycliques : A pointe sur B qui pointe sur C qui pointe sur B.
Si la r�f�rence de A vers B est supprim�e, B n'est plus *accessible* et
il faut supprimer B et C. M�me si tu as toujours des r�f�rences entre
B et C.
Patrice Karatchentzeff
> Par contre, d'aprï¿œs ce que j'en ai vu, pour faire la mï¿œme chose, APL
> utilisera beaucoup moins de caractï¿œres pour ï¿œtre illisible.
Bof... un binaire dans le texte sera beaucoup moins lisible et ne
comportera que deux caractￜresￜ;-)
PK
--
ￜￜￜￜￜￜ|\ￜￜￜￜￜￜ_,,,---,,_ￜￜￜￜￜￜￜPatriceￜKARATCHENTZEFF
ZZZzzￜ/,`.-'`'ￜￜￜￜ-.ￜￜ;-;;,_ￜￜￜmailto:p.karatc...@free.fr
ￜￜￜￜￜ|,4-ￜￜ)ￜ)-,_.ￜ,\ￜ(ￜￜ`'-'ￜￜhttp://p.karatchentzeff.free.fr
ￜￜￜￜ'---''(_/--'ￜￜ`-'\_)ￜￜￜￜￜￜￜ
batyann811
>
> Non.
Et pourtant...
Nicolas George
�crit�:
> Et pourtant...
Tu illustres encore une fois que ceux qui gueulent le plus fort sur le C
sont ceux qui ne le connaissent que m�diocrement.
batyann811
>
> Tu illustres encore une fois que ceux qui gueulent le plus fort sur le C
> sont ceux qui ne le connaissent que m�diocrement.
Je le connais assez pour en faire le moins possible.
J'attends toujours que tu me montres ou sont les *vrais* types �num�r�s
et les *vrais* bool�ens en C. �a doit �tre simple pour un connaisseur...
Stéphane CARPENTIER
> Stï¿œphane CARPENTIER <stef.ca...@gratuit.fr.invalid> a ï¿œcrit :
>
>> Par contre, d'aprï¿œs ce que j'en ai vu, pour faire la mï¿œme chose, APL
>> utilisera beaucoup moins de caractï¿œres pour ï¿œtre illisible.
>
> Bof... un binaire dans le texte sera beaucoup moins lisible et ne
Quand je parle du nombre de caractï¿œres, c'est le nombre de caractï¿œres
dans le programme, pas le nombre de caractï¿œres diffï¿œrents.
Par exemple, regarde lￜ :
http://www.afapl.asso.fr/Aplmtlab.htm
et compare le nombre de caractï¿œres utilisï¿œs entre les programmes Matlab
et APL. Un programme en APL est plus court, c'est flagrant.
Regarde par exemple le programme pour trouver 8 dames sur l'ï¿œchiquier.
Essaye de faire un programme (dans le langage de ton choix) qui fait la
mï¿œme chose en appuyant sur autant de touches. Pour faire ï¿œa en cobol, il
doit falloir 1000 lignes de code.
Nicolas George
�crit�:
> Je le connais assez pour en faire le moins possible.
Oui, �a se voit. Je te conseille d'en parler le moins possible �galement.
Emmanuel Florac
> 1 - Typage pas assez strict (pas de booléen, pas d'enum, pas de type
> intervalle, ...)
Le typage "fort" c'est nullissime, tu passes ta vie à faire du
transtypage, les 3/4 de ton code ne sert à rien.
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
batyann811
Comme toi des des enums et des booleens du C ?
batyann811
>
> Le typage "fort" c'est nullissime, tu passes ta vie à faire du
> transtypage, les 3/4 de ton code ne sert à rien.
>
On peut dire ça pour les types entiers. Encore que ça peut permettre de
détecter quelques erreurs et que ton 3/4 est largement exagéré. En ce
qui concerne les types énuméré et le booléen c'est plutôt le point de
vue du C (de ne pas en avoir) qui est nullissime. Et ça me parait
autrement plus grave.
JKB
Re: go,
Ouaips ! Le problème existe sur :
cauchy:[~] > java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (6b16-4)
OpenJDK 64-Bit Server VM (build 14.0-b15, mixed mode)
cauchy:[~] > uname -a
Linux cauchy 2.6.30.5 #2 SMP PREEMPT Wed Sep 2 15:14:49 CEST 2009 x86_64
GNU/Linux
lebegue:[~] > java -version
java version "1.4.2_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
lebegue:[~] > /opt/jdk1.6.0_01/bin/java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode)
lebegue:[~] > uname -a
SunOS lebegue 5.9 Generic_122300-44 sun4u sparc SUNW,Ultra-2
tchaikovski:[~] > java -version
java version "1.5.0_17"
Java(TM) Platform, Standard Edition for Business (build 1.5.0_17-b04)
Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
tchaikovski:[~] > uname -a
SunOS tchaikovski 5.10 Generic_127127-11 sun4v sparc
SUNW,SPARC-Enterprise-T1000
Je pense que Sun ne sait donc pas écrire une JVM correcte. Quant aux
versions 1.1 ou 1.2, tu repasseras puisque en 1.6, le problèem est
_toujours_ là. Par ailleurs, le problème est indépendant de l'OS
comme tu le vois.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
JKB
Re: go,
remy ?crivait dans fr.comp.os.linux.debats :
Tu as fini de raconter des conneries ? Le Turbo C que j'utilisais
sur mon PS/2 (i386DX, donc vrai 32 bits) avait des ints sur 16 bits.
Pour avoir des 32 bits, il fallait utiliser un long.
> bool Booléen
> Même taille que le type int, parfois 1 sur quelques compilateurs
>
> un bool sur un sur processeur 64 bits 8 octets peut etre?
> super pour 2 état
Et ce n'est pas idiot. C'est même pour cela qu'il y a des logical*8
en Fortran pour permettre des alignements de données. C'est fou le
temps qu'on peu perdre en n'alignant pas les données !
JKB
Re: go,
C'est un ping entre le client et le serveur sur la socket utilisée
par l'application, pas un ping au sens ICMP du terme. Si le client
ferme sa socket applicative, son client ne fonctionnera pas, donc la
remarque est caduque.
Stephane TOUGARD
> La question est donc : peut-on directement attaquer par un truc
> comme java ?
Et la reponse est "Oui, bien sur !".
Richard Delorme
Je plussois avec Emmanuel. L'intérêt du typage booléen et des
énumérations tel qu'il est défini dans le langage C (C99 pour les
booléens), c'est de rendre le code plus clair, en ajoutant une sorte de
commentaire aux valeurs que peut avoir une variable.
Maintenant interdire des opérations entre énums, entiers, booléen, etc.
au nom du typage fort, n'apporte qu'un blocage stupide qu'on est obligé
de contourner par du code inutile. Quel intérêt d'interdire :
enum coordinate x, y;
enum offset dx;
/* initialisations */
y = x + dx;
--
Richard
Stephane TOUGARD
> Donc le problème du C, c'est que tu n'y connais rien.
Le C est un excellent language. D'ailleurs, Perl est ecrit en C.
Nicolas George
<4b0f7c4b$0$9771$426a...@news.free.fr>, a �crit�:
> Le typage "fort" c'est nullissime, tu passes ta vie � faire du
> transtypage
Quand on ne sait pas programmer. Comme en C, d'ailleurs.
Jo Kerr
> Emmanuel Florac a ï¿œcrit :
>>
>> Le typage "fort" c'est nullissime, tu passes ta vie ￜ faire du transtypage,
>> les 3/4 de ton code ne sert ￜ rien.
>>
>
> On peut dire ï¿œa pour les types entiers. Encore que ï¿œa peut permettre de
> dￜtecter quelques erreurs et que ton 3/4 est largement exagￜrￜ. En ce qui
> concerne les types ￜnumￜrￜ et le boolￜen c'est plutￜt le point de vue du C
> (de ne pas en avoir) qui est nullissime. Et ï¿œa me parait autrement plus
> grave.
Quel gros nul ce Ritchie !
Il aurait pu demander conseil ￜ batyann811. ;-)
--
In gold we trust (c)
Patrice Karatchentzeff
> Le C est un excellent language. D'ailleurs, Perl est ecrit en C.
Perl est aussi ï¿œcrit en perl.
Stephane TOUGARD
>> Le C est un excellent language. D'ailleurs, Perl est ecrit en C.
Ce qui prouve que perl est un excellent language aussi.
batyann811
> Je plussois avec Emmanuel. L'intérêt du typage booléen et des
> énumérations tel qu'il est défini dans le langage C (C99 pour les
> booléens), c'est de rendre le code plus clair, en ajoutant une sorte de
> commentaire aux valeurs que peut avoir une variable.
> Maintenant interdire des opérations entre énums, entiers, booléen, etc.
> au nom du typage fort, n'apporte qu'un blocage stupide qu'on est obligé
> de contourner par du code inutile. Quel intérêt d'interdire :
> enum coordinate x, y;
> enum offset dx;
> /* initialisations */
> y = x + dx;
Quel intérêt d'autoriser :
int i;
enum couleur col;
bool condition;
col = rouge;
i = (57 * col + contition) / 42;
batyann811
>
> Quel gros nul ce Ritchie !
> Il aurait pu demander conseil ￜ batyann811. ;-)
>
A l'ï¿œpoque j'ï¿œtais beaucoup trop jeune et donc pas dispo. Cependant il y
avait 100000 fois mieux : Niklaus Wirth.
De plus les idï¿œes de Ritchie sur les enums ou l'absence de booleens ne
devaient pas ￜtre si bonne puisque Stroustrup s'est senti obligￜ d'y
apporter quelques corrections. Cependant je ne doute pas que Ritchie a
fait ces choix en toute conscience. Il voulait un langage d'assez bas
niveau et certainement un compilateur assez simple ￜ ￜcrire. Le drame
c'est que son langage a trop bien marchￜ...
Nicolas George
> De plus les id�es de Ritchie sur les enums ou l'absence de booleens ne
> devaient pas �tre si bonne puisque Stroustrup s'est senti oblig� d'y
> apporter quelques corrections.
Ne me fais pas rire. Prendre Stroustrup comme r�f�rence�!
JKB
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
> Jo Kerr a écrit :
>>
>> Quel gros nul ce Ritchie !
>>
>
> A l'époque j'étais beaucoup trop jeune et donc pas dispo. Cependant il y
Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.
> De plus les idées de Ritchie sur les enums ou l'absence de booleens ne
> devaient pas être si bonne puisque Stroustrup s'est senti obligé d'y
> apporter quelques corrections.
Remouais. Une autre référence pas controversée du tout.
Personnellement, l'évocation de ce type aurait plutôt tendance à me
faire vomir.
> Cependant je ne doute pas que Ritchie a
> fait ces choix en toute conscience. Il voulait un langage d'assez bas
> niveau et certainement un compilateur assez simple à écrire. Le drame
> c'est que son langage a trop bien marché...
Le drame, ce n'est pas que ce langage ait bien marché. Son drame,
c'est qu'il est utilisé dans plein de domaines où il existe des
langages bien mieux fichus. Le C, c'est avant tout pour de
l'écriture système. Lorsqu'on fait du calcul, on devrait utiliser le
Fortran qui a été écrit pour cela. Pour l'embarqué ou le sensible,
ADA est tout indiqué. Le problème est qu'on utilise du C (ou C++,
même combat) partout en partant du principe que c'est une panacée,
ce qui n'est pas le cas. Écrire un code C parfaitement portable et
qui récupère toutes les erreurs de toutes le fonctions, c'est un
sacré boulot et quasiment personne ne le fait, alors que c'est assez
trivial dans d'autres langages.
batyann811
>
> Ne me fais pas rire. Prendre Stroustrup comme r�f�rence !
Rire ! Mais c'est une bonne id�e �a. Tu devrais essayer de temps en temps.
Je ne dis que Stroustrup est une r�f�rence (quel nom p�nible au
passage). Niklaus Wirth en revanche...
batyann811
>
> Mouais... Affaire de goût. Le seul avantage de ce type, c'est
> d'avoir rué contre le goto.
>
Je trouve qu'il a quand même pondu des langages pas mal : Pascal, Modula-2.
>
> Remouais. Une autre référence pas controversée du tout.
> Personnellement, l'évocation de ce type aurait plutôt tendance à me
> faire vomir.
>
Je dis juste qu'il a essayé de corriger (un peu) les enums du C et d'y
ajouter des booléens. Rien de plus. Et comme de toutes façons il a voulu
garder une certaine compatibilité avec le C...
>
> Le drame, ce n'est pas que ce langage ait bien marché. Son drame,
> c'est qu'il est utilisé dans plein de domaines où il existe des
> langages bien mieux fichus. Le C, c'est avant tout pour de
> l'écriture système. Lorsqu'on fait du calcul, on devrait utiliser le
> Fortran qui a été écrit pour cela. Pour l'embarqué ou le sensible,
> ADA est tout indiqué. Le problème est qu'on utilise du C (ou C++,
> même combat) partout en partant du principe que c'est une panacée,
> ce qui n'est pas le cas. Écrire un code C parfaitement portable et
> qui récupère toutes les erreurs de toutes le fonctions, c'est un
> sacré boulot et quasiment personne ne le fait, alors que c'est assez
> trivial dans d'autres langages.
Je souscris à 100%. Quand je disait "trop bien marché" je voulais dire
qu'il a été utilisé par tout et pour tout.
JKB
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :
>>
>> Mouais... Affaire de goût. Le seul avantage de ce type, c'est
>> d'avoir rué contre le goto.
>>
>
> Je trouve qu'il a quand même pondu des langages pas mal : Pascal,
Il faudra un jour qu'on m'explique la différence _fondamentale_
entre C et Pascal. J'ai beau chercher, je ne vois pas bien.
On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de
gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).
> Modula-2.
Même remarque.
>> Remouais. Une autre référence pas controversée du tout.
>> Personnellement, l'évocation de ce type aurait plutôt tendance à me
>> faire vomir.
>>
>
> Je dis juste qu'il a essayé de corriger (un peu) les enums du C et d'y
> ajouter des booléens. Rien de plus. Et comme de toutes façons il a voulu
> garder une certaine compatibilité avec le C...
Et alors ? C'est au programmeur de faire la différence. Entier,
booléen, énumération, pour le processeur, ça termine en entier
quel que soit le langage (sauf à adresser des bits directement).
La différence, c'est l'autorisation ou non du transtypage.
Maintenant, très clairement, si on interdit le transtypage
implicite, il faut _aussi_ pour être cohérent que le langage vérifie
à la volée les indices de tableaux, les longueurs de buffers et tous
les dépassements entiers qui peuvent survenir. Donc, soit on utilise
le C en étant conscient des problèmes de transtypages et de
dépassements de tous acabits, soit on utilise un langage plus
strict (mais avec tout ce qui vient dans le paquet).
>> Le drame, ce n'est pas que ce langage ait bien marché. Son drame,
>> c'est qu'il est utilisé dans plein de domaines où il existe des
>> langages bien mieux fichus. Le C, c'est avant tout pour de
>> l'écriture système. Lorsqu'on fait du calcul, on devrait utiliser le
>> Fortran qui a été écrit pour cela. Pour l'embarqué ou le sensible,
>> ADA est tout indiqué. Le problème est qu'on utilise du C (ou C++,
>> même combat) partout en partant du principe que c'est une panacée,
>> ce qui n'est pas le cas. Écrire un code C parfaitement portable et
>> qui récupère toutes les erreurs de toutes le fonctions, c'est un
>> sacré boulot et quasiment personne ne le fait, alors que c'est assez
>> trivial dans d'autres langages.
>
> Je souscris à 100%. Quand je disait "trop bien marché" je voulais dire
> qu'il a été utilisé par tout et pour tout.
JKB
Stephane TOUGARD
> Mouais... Affaire de goût. Le seul avantage de ce type, c'est
> d'avoir rué contre le goto.
Je ne vois aucun probleme a utiliser GOTO quand cela est necessaire. En
particulier quand cela permet de ne pas s'embarquer dans des
imbrications de if.
JKB
Re: go,
Depuis que je ne code plus en Basic de base (le truc avec les
numéros de lignes, parce que même en Turbo Basic, je n'ai jamais
utilisé de goto), je n'ai plus _jamais_ utilisé ce truc et sans
imbriquer des if à n'en plus finir. Si pour éviter des constructions
de structures conditionnelles tu es contraint à l'utilisation du goto,
c'est que ton code a un sérieux problème de conception.
J'attends aussi l'argument du "le goto, ça évite au programme de
gérer la pile en passant d'un point à un autre d'une routine", parce
que c'est trivialement faux. Le goto en question, il fait beaucoup
plus de choses que de sauter à l'étiquette (il vire les varables
locales aux blocs, bidouille la pile, bref, plein de choses dans le
dos de l'utilisateur). Dans tous les cas, c'est préjudiciable
(lisibilité du code, côté spaghetti et surtout opérations sur la
pile et le tas).
batyann811
>
> Il faudra un jour qu'on m'explique la différence _fondamentale_
> entre C et Pascal. J'ai beau chercher, je ne vois pas bien.
intervales, les ensembles, le contrôle des bornes bornes des tableaux,
la gestion des chaînes de caractères largement plus simple qu'en C, pas
besoins de se faire chier avec un makefile et des '.h'. Tu peux trouver
que ça n'est pas fondamentale mais qu'est ce que c'est agréable à l'usage !
Il y a bien sûr des trucs en moins (les champs de bits) ou qui sont un
peu plus pénible : le point virgule en séparateur d'instruction (ça
c'est une vraie connerie).
> On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de
> gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).
>
Pas le préprocesseur du C alors... Après tout dépend de ce qu'est un
préprocesseur pour toi.
>> Modula-2.
>
> Même remarque.
>
Assez peu de différences par rapport au pascal. Principalement un
système de module qui se rapproche plus des packages d'ADA et une
syntaxe qui evite les begin/end à répétition.
>
> Et alors ? C'est au programmeur de faire la différence. Entier,
> booléen, énumération, pour le processeur, ça termine en entier
> quel que soit le langage (sauf à adresser des bits directement).
> La différence, c'est l'autorisation ou non du transtypage.
Bof. Le programmeur c'est un être humain, il fait des erreurs alors
autant que le compilo en détecte un maximum. Après je ne sais pas
l'usage que tu as des enums mais pour l'usage que j'en ai je ne vois que
très peu de raisons de pourvoir les mélanger avec des entiers dans des
expressions ou de pouvoir les additionner entre eux. Mais si tu as des
exemples...
> Maintenant, très clairement, si on interdit le transtypage
> implicite, il faut _aussi_ pour être cohérent que le langage vérifie
> à la volée les indices de tableaux, les longueurs de buffers et tous
> les dépassements entiers qui peuvent survenir. Donc, soit on utilise
> le C en étant conscient des problèmes de transtypages et de
> dépassements de tous acabits, soit on utilise un langage plus
> strict (mais avec tout ce qui vient dans le paquet).
Sinon Pascal, Modula et ADA font tous les contrôles dont tu parles et
c'est très bien. Aller pour te faire râler je rajoute Java à la liste
(sauf pour les dépassements d'entiers).