Discussion :

[Luc Hermitte]

Pardon?
Qu'est-ce que l'encodage vient faire ici?
'c' correspond à la lettre "c", par définition.

Dans ce débat stérile, l'encodage vient faire des choses. Pour ceux qui ont bidouillé sous windows, 'c' vaudra certes toujours la même chose (si on affiche sa valeur entière). Ce n'est pas le cas de 'é' selon que le fichier soit en latin-1/windows-1252 ou en oem850 -- et je me restreins ici au 8-bits. Les questions récurrentes sur comment écrire des accents sous windows montrent une bonne incompréhension des débutants sur le sujet.

Mais ... 'c' n'est pas toujours égal à 99. Cela va dépendre de l'encodage du fichier encore une fois. En ECBDIC, c'est encore autre chose. Et pire, comme l'a souligné gl, 'j'-'i' ne vaut pas 1 mais 2 dans les fichiers encodés en ECBDIC.

Après, ce n'est pas propre au C. Sauf si on veut vraiment considérer que si 'c' est un int en C, alors 'z'-'a' devrait valoir 25. Mais est-ce important ?

Enfin, quand tu dis que 'c' correspond à la lettre "c", tu fais une supposition sémantique. Tu donne un sens à un entier -- en C du moins. Tu donnes le sens lié à ce que les fonctions d'I/O afficheront en fonction de la locale du programme, de la locale du terminal/GUI, et de l'encodage du fichier. Si parmi les 3 il y a une différence, selon la nature de la différence, 'é' ne donnera plus la e-acentué, voire dans des cas plus exotiques 'c' ne donnera plus "c".

Est-ce que les débutants ont besoin de comprendre ça ? (en dehors de windows) Non pour ma part. Ni de le comprendre, ni de le subir. Qu'ils commencent par comprendre la différence entre une nombre et sa représentation textuelle dans une base (2, 10, 8, 16, ...).

[Logan Mauzaize]

Et C et en C++, 'c' est un char, un char est un entier.
'c' correspond à la valeur ASCII du caractère c mais n'est en rien un caractère.

C'est le problème, tu t'attaches à un (ou deux langages) et non à la programmation en générale et à la sémantique de ce que tu déclares.
D'où j'insiste sur la sémantique.

Pour ne penser strictement qu'en C/C++, un char fait un 8-bits. Il me semble qu'un entier (int) ne fait que la moitié de la taille du bus, soit 16/32-bits sur les plateformes 32/64-bits. Et encore cela dépend des compilateurs.
Je m'étendrai pas plus sur le C/C++ n'ayant pas plus de connaissance sur cet environnement.

En quelle honneur ?
Si j'ai envie que ça signifie "2 lettres après c dans mon alphabet", j'ai pas le droit ?

"2 lettes après c", ce n'est pas une "addition" mais un "décalage". Les libertés prisent par les informaticiens "électroniciens" ne doivent pas devenir la logique des autres informaticiens.
Je suis persuadé que pour une personne ne raisonnant pas en "électronique", répondra que le résultat est "c2" et non "e".

Je ne vois pas en quoi il serait absurde d'additionner un caractère et un entier, du moment qu'on peut donner une définition formelle d'une telle opération.

Je n'ai rien contre cette idée, on peut aussi définir que "/" (diviser) me donne le découpage en octets. Dans les concepts humains, les opérations (+, -, /, *) font partie de l'arithmétique qui n'est pas défini dans le domaine des "caractères" (hormis "i", la constante d'Euler et quelques autres symbolismes).

1) L'alphabet est une liste ordonnée de caractères : abcdefghijklmnopqrstuvwxyz
(en fait il peut y avoir beaucoup plus de caractères que dans mon exemple, par exemple il y en a 256 dans le jeu iso-latin-1)

2) Si c est le caractère d'indice n dans l'alphabet, et si i est un entier, c + i est le caractère d'indice n + i dans l'alphabet.

Voilà : on a défini une addition entre un caractère et un entier. Cela se tient théoriquement, cela a une utilité pratique, et cela est (relativement) indépendant de la représentation exacte des caractères.

Admettons donc ce que tu dis. Puisqu'on peut appliquer l'arithmétique, il y a une relation d'ordre tel que a-1 < a < a+1 (a étant n'importe quel caractère). Admettons aussi que je souhaite faire une recherche alphabétique (sémantiquement il n'y a aucun abération), sur 'Å' ?
Ma relation d'ordre sémantique n'est pas préservé. Donc non un jeu de caractères n'est pas une simple liste.
Donc non, théoriquement cela ne se tient pas et l'arithmétique ne peut pas s'y appliquer.

De toute façon le C est un des meilleurs langages pour débuter précisément parce qu'il est un des pires... paradoxal isn't it ?

Ca dépend pour qui. Pour des étudiants en IUT info pourquoi pas mais pour d'autres, je pense clairement que c'est un mauvais choix. Comme je le disais initialement, l'approche est un point très important dans l'apprentissage de la programmation.

Je ne vois pas le problème dans le langage. Le problème dans ce topic est la pluie d'assertions absurdes.
C'est vraiment n'importe quoi comme argument.
Le fait que les gens ne soient pas d'accord ne prouvent absolument RIEN, sauf le fait que la moitié des assertions dans ce topic sont grossièrement fausses.

C'est une preuve de non-consensus et donc de non universalité de la solution. Par conséquent, la solution n'est pas optimale. En d'autres mot pas la "meilleure". CQFD ?
En revanche nous sommes d'accord sur un point, il y a de fausses assertions. Certains pensent comme des "électroniciens" et non comme des personnes quelconques envisageant d'apprendre la programmation de manière générale. Mais je suis prêt à entendre que je me trompe sur cette assertion, auquel cas effectivement je me rangerai du côté de certains.

Pardon?

7-bits ca fait pas un "int" en C ou C++ (tout compilateur confondu). J'aurai même tendance à dire toute plateforme et langage confondu.

Du point de vue du compilateur, 'c' est seulement un nombre. Pas autre chose.

Rien à foutre du compilateur, c'est pas à lui qu'on apprend la programmation. D'ailleurs la programmation ce n'est pas l'art de compiler mais d'écrire des sources ...

C'est quoi le "point de vue sémantique"?

Qui a un sens / Relatif à l'interprétation des symboles. Alors se pose la question un sens pour qui ? Le compilateur ou le programmeur ?
Il me semble que le sujet porte sur les gens qui programment et non les gens qui compilent ?

Qu'est-ce que l'encodage vient faire ici?
'c' correspond à la lettre "c", par définition.

L'encodage vient faire que c'est l'argument soulevé par les défenseurs de la syntaxe 'c'+2 donne 'e' ... C'est de la mauvaise fois ou juste une incitation au troll ?

[gl]

http://codepad.org/ktMS89K2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Segmentation fault

Au temps pour moi, je n'avais pas vu l'erreur sur le guillemet dans le code.

[gl]

Pour ne penser strictement qu'en C/C++, un char fait un 8-bits. Il me semble qu'un entier (int) ne fait que la moitié de la taille du bus, soit 16/32-bits sur les plateformes 32/64-bits. Et encore cela dépend des compilateurs.

C'est même encore plus compliqué que ça, le char faut au moins 8 bits (pour être précis, ce ne sont que les plages de valeurs qui sont garanties pas les tailles qui sont simplement déduites de ces plages) Mais il peut faire plus (9 bits, 16 bits, 32 bits ou autres), 8 bits est simplement la taille la plus répandues (et de loin) et une hypothèse simplificatrice souvent prise (et amha raisonnable). La norme ne précise même pas si le "plain char" est signé ou non (contrairement aux autres types entiers).
La seule garantie est qu'un plain char doit pouvoir contenir la plage de valeur [0, 127] et que sizeof(char) vaut 1 (même pas nécessairement un octet, c'est juste l'unité de mesure de base).
Pour le int, la garantie porte sur la plage [-32767, 32767] c'est tout (et en pratique c'est un type dont la taille est effectivement très variable selon les implémentations)


Bref, je te rejoins, le C pour débuter ce n'est pas la panacée. Et les raccourcis pris lors de cet apprentissage en tant que premier langage pose assez régulièrement problème plus tard (autant pour les encodages sur les lettres non accentuées ce n'est que rarement un problème, autant la taille des types, le boutisme ou le caractère signé ou non de char pose très rapidement des soucis).

[Luc Hermitte]

a-

Après, ce n'est pas propre au C. Sauf si on veut vraiment considérer que si 'c' est un int en C, alors 'z'-'a' devrait valoir 25.

J'ai rien compris.

b-

Enfin, quand tu dis que 'c' correspond à la lettre "c", tu fais une supposition sémantique.

Pardon?
C'est quoi "sémantique"?

c- [...]Dans quels cas plus exotiques?

a- Les problèmes d'encodage fichiers en windows1252 et console en OEM ne sont pas propres au C. Ils vont se poser avec tous les autres langages.
En revanche, 'c' est un nombre que dans quelques langages comme le C (et le C++), et seuls ces langages permettent d'écrire directement 'z'-'a'.
Mais un programme C qui contient 'z'-'a', dans l'encodage de la machine où il va s'exécuter ne peut pas garantir, que la différence soit toujours de 25.

b- C'est le sens de "sémantique" (sic) qui ne te parle pas ? Ou tu trouves que l'on dit n'importe quoi ? Je n'arrive pas à savoir.
La sémantique, c'est le sens que l'on donne à une chose. Et tout le monde ne donne pas le même sens à 'i'+2. Pour certains ce sera 'i2', pour d'autres le nombre complexe i plus l'entier 2, pour d'autres encore le caractère 'k' (et ils pourront être surpris de trouver 'j' à la place sur des conf exotiques...)

c- exotiques comme dans ECBDIC, ici.

[Aiekick]

La programmation n'est pas facile par nature et ne le sera sans doute jamais. C'est peut-être pour cela qu'on paye des programmeurs : Parce que ca reste un métier avant tout.

Pour en revenir sur le langage à apprendre en premier je maintiens qu'il faut un langage bas niveau. Sinon un débutant peut-être confronté à un problème dès lors qu'il fait une simple addition. Exemple en python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
def shouldAlwaysReturnTrue(x, y) :
  return x + y - x == y

x = 2.0
y = 1.0
result = shouldAlwaysReturnTrue(x, y)
print result

x = 1.0E100
y = 1.0E-5
result = shouldAlwaysReturnTrue(x, y)
print result

L'exemple montre qu'une "formule" mathématique (x + y - x = y) qui est censé être toujours vrai pour n'importe quel nombre devient "mystérieusement" fausse pour certaines valeurs. Comme quoi, l'abstraction fourni par le langage n'a pas durée longtemps. Évidement, ca s'explique à cause de la nature des nombres flottants et de leur représentation. Mais sans aborder des notions bas niveau, on ne peut pas l'expliquer. Donc plutôt que de laisser une personne découvrir cela par lui-même (ce qui peut-être douloureux), autant lui expliquer dès le début.

La programmation n'est pas plus compliquée qu'un autre métier. ça nécessite une formation et c'est comme tout.

Et savoir implémenter un algorithme est différent que de concevoir un algorithme.
Mais finalement un algorithme est juste une description d'un processus manuel a un niveau d'abstraction supérieur.
Ce qu'on sait faire à la main on sait le programmer. ( évidemment je parle technique pas artistique )
donc on en a tous fait un sans savoir que s'en était un.

Donc en 1er lieu, il faut apprendre a faire des algo, et après seulement a les implémenter. et le fait d’utiliser des langages comme lua et python
permet de rester au plus prêt de l'algo et de ne pas s'encombrer l'esprit avec la gestion mémoire ou autres joyeuseté comme je l'ai dit.

[Neckara]

Pour ne penser strictement qu'en C/C++, un char fait un 8-bits. Il me semble qu'un entier (int) ne fait que la moitié de la taille du bus, soit 16/32-bits sur les plateformes 32/64-bits. Et encore cela dépend des compilateurs.

Ne confond pas int et entier.

Un (unsigned|signed) (char|short|int|long int|long long int) est un entier.

Et un char ne fait pas "8-bit".
La norme défini une taille minimale mais rien de plus (bien qu'on retrouve le plus souvent des char sur 8 bits).

[Deuzz]

Bonjour

Vous êtes rigolo avec vos débats à savoir si on peut additionner 'c' et "2" ou savoir si c'est le code ascii, la valeur ou que sais-je qu'il faut prendre en compte....

Simple rappel pour ceux pour qui l'école est trop loin. Ma fille est en primaire et à son niveau on lui apprend qu'il est impossible de soustraire un grand nombre à un petit... plus tard elle verra les nombres négatifs. Au collège on apprend qu'il n'y existe pas de racine carrée négative et au lycée on apprend les nombres imaginaires. L'apprentissage est ainsi fait que l'on ne cesse en complexifiant les choses de remettre en cause les savoirs précédemment acquis.
Sauf à vouloir faire de la sélection commencer par compliquer tout n'est pas le plus pertinent lorsque l'on veut enseigner un savoir. Alors autant commencer par quelque chose de simple. Il sera toujours temps pour ceux qui veulent en savoir plus de découvrir toutes les subtilités de la discipline.

[MarieKisSlaJoue]

Malheureusement beaucoup ne raisonne pas comme ça. Pour eux l'informatique dois faire peur pour ne garder que les plus compétents... Certain sont resté bloqué en -50 av JC apparemment...
Et pour beaucoup de professeur, de professionnelles et même d'élève par contagions pense du coup que si on à pas commencé par apprendre le C en premier langage. On ne sera jamais plus fort en programmation que quelqu'un qui à commencé par ça.

[Deuzz]

Pour eux l'informatique doit faire peur pour ne garder que les plus compétents... Certains sont restés bloqués en -50 av JC apparemment...

Heureusement que les médecins ne sont pas formés comme ça...
J'imagine bien le carnage : "Ben oui, on commence directement par la chirurgie comme ça on ne garde que les meilleurs et les plus motivés. "

[esperanto]

'c' est un caractère, point. Sa représentation ASCII n'est pas un entier mais 7-bits, son codepoint Unicode est effectivement un entier 32-bits. Mais ce n'est pas le cas des caractères décomposés en Unicode.
Rien que ce micro "débat" est une preuve du problème.

Exact. J'irais même plus loin : un encodage met en relation bijective des caractères d'un côté, des groupes de bits (et non des nombres) de l'autre.
Le pire exemple : UTF-8. Le caractère é est représenté par les 16 bits C3 A9. Nulle part vous ne trouverez utilisé le nombre 0xC3A9 pour représenter un é : le point de code Unicode correspondant est 0xE9. Donc dans un tel encodage on ne peut même plus dire qu'un caractère est un nombre (quoi qu'on pourrait dans Unicode, qui n'est pas un encodage mais un jeu de caractères - UCS2 ou UTF-8 sont des encodages, c'est toute la différence)
En tout cas je souhaite bien du plaisir à ceux qui voudront utiliser un texte UTF-8 avec le type char du C.

a- Les problèmes d'encodage fichiers en windows1252 et console en OEM ne sont pas propres au C. Ils vont se poser avec tous les autres langages.

Je dirais plutôt : dans tous les langages qui assimilent implicitement un caractère à son encodage.
Pour prendre un contre-exemple, en Java tu as les types char et byte sans aucune règle de conversion implicite définie : si tu veux passer de l'un à l'autre tu dois passer par la librairie io où tu indiques explicitement l'encodage (ou au pire tu laisses choisir l'encodage par défaut, mais il est quand même dans la définition de la fonction).

Donc je suis d'accord : pour le débutant, se baser sur un langage pour lequel char et int sont considérés comme une même notion, sans obligation de spécifier l'encodage, me paraît une aberration.

[Luc Hermitte]

Je dirais plutôt : dans tous les langages qui assimilent implicitement un caractère à son encodage.
Pour prendre un contre-exemple, en Java tu as les types char et byte sans aucune règle de conversion implicite définie : si tu veux passer de l'un à l'autre tu dois passer par la librairie io où tu indiques explicitement l'encodage (ou au pire tu laisses choisir l'encodage par défaut, mais il est quand même dans la définition de la fonction).

Je ne suis pas sûr d'en saisir les implications.

Soit un .java écrit/encodé en latin1/windows1252, avec dedans un print("je vais au café"). (ou équivalent).
Questions :
1- Est-ce que le codeur peut écrire cela ? Ou doit-il alors avoir son fichier soit en utf-8, soit écrire des "\umachins" à la place du "é" ?
2- Que verra-t-on si on fait tourner ce programme dans la console de windows (avec et sans chcp 1252 avant -- ou autre chcp),
3- Et que verra-t-on dans la console de Cygwin ?

[esperanto]

Je ne suis pas sûr d'en saisir les implications.

Soit un .java écrit/encodé en latin1/windows1252, avec dedans un print("je vais au café"). (ou équivalent).
Questions :

Tes questions sont tout à fait pertinentes, elle montrent bien que le problème existe et doit être pris en compte, alors que les programmeurs C ont tendance à considérer que l'encodage est défini par la machine et basta.
En plus tes trois questions montrent bien les étapes du processus.

1- Est-ce que le codeur peut écrire cela ? Ou doit-il alors avoir son fichier soit en utf-8, soit écrire des "\umachins" à la place du "é" ?

Pour le point 1, donc au moment de la compilation, la commande javac a un paramètre "encoding". Donc si tu sais que tous tes fichiers sont en cp1252, ou au contraire que tous sont en UTF-8, soit tu passes l'option à javac, soit tu définis la variable d'environnement JAVA_TOOLS_OPTIONS qui va bien. Le rôle des codes \uXXXX, c'est soit de rendre le fichier java indépendant de tout encodage, soit de te permettre de rajouter des caractères que tu n'as pas sur ton clavier par exemple.
Un collègue me fait régulièrement remarquer qu'une des grosses erreurs des premières versions Java, jamais corrigée depuis, est d'avoir choisi ISO-8859-1 comme encodage par défaut pour les fichiers .properties : d'où la masse de \uXXXX quand ce fichier sert pour une traduction vers le russe...

2- Que verra-t-on si on fait tourner ce programme dans la console de windows (avec et sans chcp 1252 avant -- ou autre chcp),

Pour le point 2, au niveau donc de la JVM, il faut savoir que le fichier .class contient forcément la chaîne Unicode : la compilation comprend, entre autres choses, la conversion des caractères en fonction du choix que tu as fait au point précédent. Tout cela en vertu d'une règle bien connue de Java : la même classe doit donner le même résultat sur toutes les plateformes. Donc si tu prends ta classe et que tu l'exécutes sur une autre machine, elle doit donner le même résultat.

3- Et que verra-t-on dans la console de Cygwin ?

Pour le point 3, tu es au niveau de la console. Celle-ci a son propre encodage, probablement défini dans LC_NAME. Ce qui va donc se passer : avant d'exécuter le programme, la JVM demande à la console quel est son encodage; puis quand il faut afficher un é, dans le .class elle lit un é en Unicode, mais elle sait qu'elle doit le convertir dans l'encodage de la console. Et entre la JVM et la console, elle transmet un caractère converti, et là petit détail : un caractère converti, que ce soit en utf8 ou en cp1252, ce sont des octets (byte). Enfin, la console convertit ces octets en points à allumer ou à éteindre sur l'écran, au moyen d'une police de caractères.

Voila, tu as maintenant toutes les étapes dans le cas où le caractère é vient de ton programme. Maintenant, dans mon message, je pensais plutôt au cas où les caractères ont été lus ailleurs, dans un socket ou un fichier par exemple.
Dans un flux de données, fondamentalement, on lit toujours des octets. Si on veut des caractères il faut les convertir et donc savoir en amont dans quel encodage ils sont. La déclaration au début des fichiers xml ou html sert justement à cela (quand l'entête http ne contient pas une déclaration contradictoire...)
Quand tu ouvres un fichier en java, tu vas commencer par créer un FileInputStream, qui ne sait lire que des octets. Puis si tu veux des caractères tu vas l'englober dans un InputStreamReader, et là miracle : il y a un paramètre "encoding" dans le constructeur! Certes il y a une valeur par défaut mais si tu lis la description dans le javadoc tu ne peux pas l'ignorer!
Evidemment la situation est symétrique pour l'écriture : les streams n'écrivent que des octets, si tu veux écrire des caractères tu dois créer un writer... et spécifier l'encodage.

[Logan Mauzaize]

Java stocke en interne les char selon un dérivé de l'UTF-16 (bytecode inclus).

Le code source est lu par le compilateur en lisant par défaut l'encodage du système ou bien celui spécifié en paramètre.

La VM lors de son exécution, écrit sur la console en utilisant par défaut l'encodage du système ou bien celui spécifié en paramètre. Il peut également être changé à "chaud".

[Luc Hermitte]

Intéressant. Merci pour les infos.

[Kannagi]

On faite en lisant un peu se topic et ma réflexion personnelle sur pourquoi certain programmeurs 'bon' ont quelque fois des difficulté pour certain domaine je pense qu'on peut résumé la programmation par 3 catégories que chaqu'un trouve essentiel et d'autre un peu moins :
- le langage informatique
- l'algorithme
- l'architecture des ordinateurs

Donc si on ne prend que le langage en lui même le C et même l'assembleur reste très simple (je rappel qu'on assembleur on fait principalement que lire , calcul arithmétique ou logique,réécrire , n'importe qui est capable de comprendre ces notions).
Et le C aussi peu de mot clé mais le problème de ces deux langages sont qu'il demande une connaissance approfondie de l'ordinateur et de comment ça marche derrière.
Donc certain préfère proposé d'autre langage simple et dont on ne souci pas de la machine , en soit le Basic est bien il n'est pas complexe comme langage et pas vraiment proche de la machine.
Le C++ est un langage plus complexe et il a des notions assez poussé.
Pour l'algorithme n’importe quel langage est suffisant mais la aussi on préférera un langage qui permet de se concentré que sur l'algorithme est pas le reste , après algorithmie reste essentiel pour faire un programme.
L'architecture des ordinateurs c'est ce qui fait fuir les débutants j'imagine , mais qui reste assez essentiel a la compréhension de l'ordinateur , mais de nos jours ce n'est plus aussi obligatoire vu que pas mal de langage permet de s'y affranchir.

Je ne donne aucun avis sur quel langage choisir pour débuter , et j'ai omis de parler les autres langages java , python , ruby,c# mais vous l'avez compris chaqu'un met on une de ces 3 catégories.
Le seul point vraiment important pour moi c'est algo , je trouve certain programmeur très compétent sur un langage connait tout sur tout , même les petites spécificité du langage ou un qui connait parfaitement bien le fonctionnement d'un ordinateur mais aussi qu'on leur niveau on algorithmie n'est pas très élevé en terme de pratique il ne se débrouille pas vraiment mieux qu'un autre programmeur n'ayant pas autant de connaissance sur un langage ou sur la machine.

[bertome1]

Pour moi c'est l'assembleur. Pour plusieurs raisons :

1-Il donne des notions très bas niveau ce qui est nécessaire tôt ou tard dans n'importe quelle langage.
2-Il met en valeur le besoin d'abstraction pour construire des gros systèmes facilement.

Après, on peut passer rapidement au C puis à des langages encore plus abstrait. Mais pour moi, ne pas passer une petite semaine à apprendre les bases de l'assembleur à quelqu'un qui est destiné à faire de la programmation pendant plusieurs années c'est comme vouloir lui apprendre à courir sans lui avoir appris à marcher.

A l'époque de msdos, je m'étais initié à l'assembleur 8086 avec MASM et symdeb
Puis j'ai découvert A86+D86 , le révélation ! (avec déboguage symbolique sur un second écran ), + programmation structurée ! + fusion des autres sources
malheureusement A86 était limité à des programmes .COM et pas de préprocesseur objet, pas de version Windows, pas de bibliothèque de base
C'est là que j'ai découvert qu'apprendre l'assembleur, c'est une chose. Mais connaitre le systéme d'exploitation et toutes ses interruptions , c'est bien plus compliqué
Alors quand Windows est arrivé, je me suis découragé !
Peut être que ce sera différent avec ARM V6 de Raspberry Pi
mais je ne crois pas qu'il existe un macro-assembleur ( A86) pour ARM V6
de toutes façons, il n'existe pas quelque chose comme une liste des interruptions de Linux avec un exemple d'utilisation en assembleur ARM

[Kannagi]

Oui c'est pour cela que sur le forum assembleur en déconseille souvent la programmation sur un OS ,cela n'a plus intérêt et de plus cela est devenu en plus très difficile et fastidieux.
Par contre faire de l’assembleur sur une machine ou il n'y a pas OS cela devient beaucoup plus sympa et jouissif.

[ALT]

Aucun doute : l'assembleur peut être très sympa.
Mais pour débuter, j'ai des doutes.

[Gethile]

Bonjour à tous,

Je suis étonné par deux faits :
1) pas de Pascal ou Delphi !
2) présence de "Arduino" qui est un EDI utilisant C ou C++ !!

Cordialement