go

Patrick Lamaizière a écrit :

La plupart des points me semble obsolètes. J'ai fais pas mal de delphi
et ça doit être la seule implémentation qui a survécu (avec FreePascal
qui est plus ou moins compatible avec delphi).

Il reste aussi Gnu Pascal mais les 2 seuls encore vraiment actifs sont
Delphi et Free Pascal.

Concernant les strings, le vieux type pascal n'est plus utilisé depuis
belle lurette. Les chaînes sont complétement dynamiques.

Effectivemment mais les chaînes de taille fixe restent disponibles.

Pour le typage des tableaux, c'est toujours vrai mais on peut utiliser
des tableaux dynamique sans taille fixe.

On peu parfaitement écrire des procédures ou des fonctions qui traitent
des tableau de dimensions quelquonques.

function ArraySum(var tb : array of integer) : integer;
var
sum : integer = 0;
i : integer;
begin
for i :=Low(tb) to High(tb) do
sum := sum + tb[i];

ArraySum := sum;
end;

Concernant les variables d'itération dans une boucle for, c'est toujours
vrai, elles sont indéfinies en dehors de la boucle.

Non c'est faux. On ne peut juste pas modifier la valeur de la variable
d'itération dans une boucle for mais elles existent en dehors des
boucles et il faut même les déclarer.

Je crois qu'il y a un "default" sur le case et un "break" (mon pascal
est rouillé).

C'est vrai.

Les gros reproches que j'ai vis à vis du pascal moderne "Object Pascal"
comme ils disent c'était l'absence de généricité et la pauvreté des
conteneurs. Ainsi qu'une gestion de la création et destruction des
objets manuelle et très pénible.

Il existe 2 types d'objets. Ceux définis avec le mot clé 'objet' pour
lesquels les appels du constructeur et du destructeur ne sont pas
automatiques. Ce sont les objets du temps de Turbo Pascal 5.5 et plus
(1989). Depuis Delphi (1995) on peut aussi définir les objets avec le
mot clé 'class'. Ces objets ne peuvent être que dynamiques. Les
constructeurs et destructeurs sont alors appelés automatiquement à la
création et à la destruction de l'objet. La généricité existe mais c'est
assez récent je dirais 3 ou 4 ans. Pour les conteneurs je n'en sais rien.

De toutes façons c'est mort...

Ou pas loin...

batyann811 :

Non c'est faux. On ne peut juste pas modifier la valeur de la variable
d'itération dans une boucle for mais elles existent en dehors des
boucles et il faut même les déclarer.

Oui mais elles sont *indéfinies* en dehors de la boucle
for i := 0 to 30 do begin
...
end;

write (i);

La valeur de i dans le write n'est pas définie, ie i != 30

Ça j'en suis sûr parce que je me suis fait avoir...

Si par hasard (un coup de malchance) tu devais compiler du pascal sous
Linux sache qu'il existe au moins 2 compilateurs (Free Pascal et GNU
Pascal) donc pas la peine de se faire chier avec p2c.

Pour ce qui est de la traduction du Pascal vers C par un simple
preprocesseur j'ai quand même des doutes. En particulier pour les
ensembles et les differents contrôles effectué à l'exécution
(débordement d'entier, contrôle des indices des tableaux). Imaginons un
cas simple. Tu définis le type TNote comme un entier qui varie entre 0
et 20. Il te faut bien une table des symboles pour pouvoir mémoriser ces
bornes afin d'effectuer les contrôles nécessaires à l'exécution. Et si
en plus ce type est défini dans une unité et utilisé dans une autre...
Ça me parait beaucoup pour un préprocesseur même genre m4. Après si ton
truc ne traduit qu'un seul fichier sans les contrôles à l'éxecution
pourquoi pas mais c'est assez réducteur.

Patrick Lamaizière a écrit :

Oui mais elles sont *indéfinies* en dehors de la boucle
for i := 0 to 30 do begin
...
end;

write (i);

La valeur de i dans le write n'est pas définie, ie i != 30

Ça j'en suis sûr parce que je me suis fait avoir...

Ça c'est possible mais j'ai du mal à saisir la gravité du truc. Une fois
que ta boucle est finie tu te tapes un peu de la valeur de i. Soit tu as
besoin de la valeur de i en fin normale de boucle et là c'est facile
c'est 30. Soit tu es sorti de ta boucle par un break et là tu n'aurais
pas du utiliser un for mais un while ou un repeat.

Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC)
JKB <knatschke@koenigsberg.fr> a écrit :

Le 26-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
>
>> 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 gen re
>> 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é.

C'est le délai d'attente (timeout) de la connexion qui ne marche pas ?
Ou le client n'est plus connecté mais l'objet de connexion sur le
serveur ne le signale pas ?

Hum... dans tous les cas on s'est éloigné de la gestion de la mémoire
par Java que tu critiquais à l'origine.

>> 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

"Directement", ça veut dire sans apprendre à programmer ;) ?
Pour gérer la mémoire en java, il faut en gros simplement savoir que
tout ce qui n'est plus accessible de nulle part est automatiquement
libéré. Ca me paraît beaucoup plus facile d'accès que savoir fair e ça
correctement en C.

Le Thu, 26 Nov 2009 17:32:38 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> a écrit :

batyann811 , dans le message
<4b0eacf7$0$991$ba4acef3@news.orange.fr>, a écrit :
> Justement parce que c'est juste un pointeur déguisé.

Non.

Ben alors en C il y a des tableaux mais on ne peut pas les passer en
paramètre ? Un super type de données donc...

Le Sat, 28 Nov 2009 13:13:32 +0000 (UTC)
JKB <knatschke@koenigsberg.fr> a écrit :

> 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.

J'aime beaucoup cette citation qui lui est attribuée :
"Je rêvais d'un ordinateur aussi facile à utiliser qu'un téléphon e.
Dans un sens mon rêve s'est réalisé, maintenant mon téléphone est
aussi compliqué qu'un ordinateur."

> 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.

+1

> >> Pour te fixer un peu les idées et enfoncer le clou, le
>> recours à un goto signifie quasiment toujours que tu essaies de
>> récupérer un cas que tu as oublié de traiter, c'est un cataplasme
>> sur une jambe de bois. NOTE BIEN QUE J'AI ÉCRIT QUASIMENT
>> TOUJOURS. Je le mets en majuscules parce que ta comprenette est
>> bouchée à l'émeri.
>
> C'est pour ca qu'a chaque fois que je vois des goto, ils sont
> toujours dans des series de conditions et pointent tous vers un
> point unique.

Va jusqu'au bout de ton raisonnement et tu verras que c'est
justement l'utilisation du goto la plus mauvaise qui soit. Je
ne vais pas essayer de t'expliquer, il me faudrait beaucoup trop de
temps, tu prendras une éternité pour comprendre et je n'en ai pas la
patience.

Mais par exemple quand tu veux tester le résultat d'une série de
fonctions que tu appelles (cas où elles renvoient une valeur
indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca
évite d'imbriquer des appels qui sont séquentiels juste pour gérer
les erreurs.

JKB wrote:

Celle que tu as judicieusement viré et qui concernait ta comparaison
foireuse entre le nombre de goto présents dans sendmail et dans
qmail.

J'ai pas vu de "?" dans ton post.

Elle était dans le tien. Tu ne sais même plus ce que tu écris, ça
devient franchement grave.

Si elle etait dans le mien, c'est que ca appelle une reponse de ta part.
Pas de la mienne.

le 'quelques jours' prouve que tu n'as jamais été confronté à de la
réécriture de code. Ce ne sont pas quelques jours, mais au mieux
quelques semaines parce qu'il faut y inclure la validation. Enfin,
venant d'un bricoleur...

Si c'est quelques semaines, on y passe le quelques semaines. Sendmail
est un projet assez important pour qu'il soit bien ecrit.

Non, ce n'est _pas_ bien. Et ce n'est pas parce qu'il y en a en
pagaille un peu partout que c'est bien. Je te mets d'ailleurs au
défi de débugguer un truc qui merdoie lorsque tu as des goto
partout (surtout en multithreadé, parce que là...).

Qui t'a parle de goto "partout".

Goto est comme toute chose, il faut l'utiliser a bon escient. C'est a
dire lorsque cela se justifie. Ni plus ni moins. J'ai l'avis qu'on en
trouve partout et que de facon generale, il est utilise a bon escient et
que ca ne montre en aucune facon un mauvais design.

C'est pour ca qu'a chaque fois que je vois des goto, ils sont toujours
dans des series de conditions et pointent tous vers un point unique.

Va jusqu'au bout de ton raisonnement et tu verras que c'est
justement l'utilisation du goto la plus mauvaise qui soit. Je ne
vais pas essayer de t'expliquer, il me faudrait beaucoup trop de temps,
tu prendras une éternité pour comprendre et je n'en ai pas la patience.

C'est pourtant dans cette optique qu'on le trouve dans sendmail (entre
autres).

Je n'ai pas de leçon de programmation à recevoir d'un type comme
toi. D'ailleurs, je n'essaie pas non plus de t'en donner parce que
le boulot serait énorme. Je ne parle pas de leçon de programmation
pour bricoler un petit script en perl dans un coin, mais pour coder
des applications sérieuses.

T'inquiete pas, mes applications gerent quelques millions d'utilisateurs
et sont tout a fait stables, performantes et font ce qu'on attend
d'elles. Je sais que t'as une plus grosse bite, que tu es meilleur que
tout le monde et que tes connaissances infinis de l'univers et de toutes
ces sortes de choses te permettent de me regarder avec mepris. Mais mon
code a le merite de faire ce qu'on en attend et cela me suffit. Il a
quelques goto parce que c'est mieux de le faire avec des goto que sans
et c'est tout.

J'ai meme travaille avec des languages qui n'ont comme instruction de
base que if et goto (pas de fonction, pas de return ... le reste des
instructions sont fonctionnelles).

Non, on n'est pas d'accord. Tu justifies l'utilisation du goto, je
prétends que le goto est une verrue dans les applications normales
et ne se justifie que dans des applications noyau pour des raisons
totalement différentes.

Et dans sendmail parce que c'est un logiciel parfait fait par des genies
en des temps lointains.

Yliur wrote:

Mais par exemple quand tu veux tester le résultat d'une série de
fonctions que tu appelles (cas où elles renvoient une valeur
indiquant qu'il y a eu ou non une erreur, donc sans exceptions) ? Ca
évite d'imbriquer des appels qui sont séquentiels juste pour gérer
les erreurs.

Le Monsieur te dit que c'est de la programmation de merde. Il prefere
imbriquer les if jusqu'a plus soif.

Pourtant, c'est evident que le goto permet de gerer proprement ce genre
de cas et c'est d'ailleur dans ce genre de contexte qu'il est
habituellement utilise.