différents segements de la mémoire

Bonjour, une petite question pour laquelle j’aimerais avoir vos réponses.
L’utilisateur a une vision sur le partage de la mémoire en segments :
Il existe différents types de segments :
• Les segments de données statiques
• Les segments de données globales
• Les segments de code
• Tas
……
1- je sais qu’à ce niveau, il s’agit d’un adressage logique. Ce qui m’intéresse c’est de savoir si cette séparation en segments est physiquement respectée dans l’implémentation dans la mémoire physique.
2- le compilateur tient compte de cette segmentation dans la production du fichier en langage machine même s’il s’agit d’adresses logiques. Qu’en pensez vous ?
3-

Citation:

---

La segmentation permet la séparation des données et du programme (entre autres segments) dans des espaces logiquement indépendants facilitant alors la programmation, l'édition de liens et le partage interprocessus. La segmentation permet également d'offrir une plus grande protection grâce au niveau de privilège de chaque segment

---

Cela me prouverait que le compilateur tient compte de la segmentation puisque l'éditeur de lien l'utilise!

Citation:

---

La segmentation permet également d'offrir une plus grande protection grâce au niveau de privilège de chaque segment

---

Ce qui prouverait que la segmentation est tenue en compte dans l'exécution!


Merci à vous

Bonjour,
Ceci est juste mon avis.
Dans les machines actuelles, un grand nombre de processus peuvent s'exécuter en même temps et sans aucune intervention extérieure.
Lorsqu'un processus se lance, une "certaine" mémoire lui est réservée. Donc, théoriquement, que le programme s'exécute correctement ou non, il ne devrait jamais sortir de cette zone qui lui a été allouée. Malheureusement il s'avère que de temps en temps un programme "plante" la machine. Cela signifie naturellement que ce programme fautif a été mettre son nez là où il ne devait pas.
Corollaire, je pense que c'est en utilisant ce principe que des gens malveillants arrivent à faire faire n'importe quoi aux machines.
Je suis sûr que des spécialistes système expliqueront tout cela bien mieux.
Cordialement.

Bonjour,
Ok. Néanmoins, cela ne répond pas à la question posée et qui concerne la segmentation.
Cordialement

Je pense qu'au niveau de la compilation et de l'édition de lien, la segmentation est un problème secondaire.
La compile et l'édition de lien fabriquent un exécutable qui sera utilisé par d'autre machines même si la structure et l'organisation de la mémoire est différente, tant qu'on rentre dans un cadre donné.
A la question "la segmentation est-elle physiquement respectée", à mon avis certainement pas. Déjà ce n'était pas vrai il y a 30 ans, c'est ce qui distinguait à l'époque les ordinateurs des calculateurs à adressage fixe.
Au moment du lancement, puis de l'exécution d'un programme, la machine dispose d'une certaine quantité de mémoire, à un instant t. Presque toute la mémoire disponible est disponible pour le programme. A cet instant t la segmentation est définie, mais connue seulement par la machine. A l'instant t+1, la segmentation sera certainement différente, d'autres processus seront lancés, la mémoire nécessaire pour le programme sera différente, etc.

Mais seul un spécialiste système pourra donner des réponse plus précises et plus détaillées.

Citation:

---

A cet instant t la segmentation est définie, mais connue seulement par la machine. A l'instant t+1, la segmentation sera certainement différente

---

Que veux tu dire par là? Je ne parle pas des inter-processus! c'est une affaire du SE.

Soit un processus P1, dans le cas d'une pagination segmentée, ce dernier peut avoir les segments cités éparpillés sur les pages. Un segment donné, par exemple, peut s'étaler sur plusieurs pages.
En fait, j'ai du mal à admettre qu'une segmentation est intéressante pour l'éditeur des liens par exemple et à la fin, conclure, qu'en fait, qu'elle n'est plus là dans l'exécutable. Dans ce cas, c'est l'anarchie totale dans le fichier binaire produit. D'autre part, en dehors de la structure du gestionnaire de la mémoire, l'exécutable peut tourner sur tous, ou presque, les processeurs courants.

En tout cas, je vais méditer sur ce que tu m'as écrit en reprenant mes notes sur la gestion de la mémoire en assembleur que j'ai déjà eu l'occasion de bien étudier; le problème c'est que cela fait une vingtaine d'année.
Merci à toi

Entre temps, j'ai pensé à une façon de le visualiser.
Si, dans le programme, on imprime la valeur d'une adresse, un pointeur en particulier (format %p). Entre deux exécutions, à moins de se trouver strictement dans les mêmes conditions de mémoire, l'adresse, donc la position physique de la variable sera normalement différente.
Ce n'est pas pour autant que c'est l'anarchie dans le binaire. Au lancement du programme, celui-ci a une adresse 0 logique et une adresse A physique. Tout se passe par translation d'adresses. Quant il faut allouer une zone mémoire, la machine (et non le programme) se débrouille.
Il est fort probable et même certain, qu'avec un programme évolué, ce que permet le C++, à un instant donné où aucune fenêtre n'est ouverte, aucun traitement en cours, sauf l'attente d'un évènement, la partie du programme résident en mémoire est réduite au minimum. Quand l'utilisateur active un menu, ouvre une fenêtre, le programme se met à travailler et charge ce dont il à besoin.
Ce n'a rien à voir avec les dll, dont le but principal est de pouvoir adresser les mêmes parties de binaire à partir de plusieurs exécutable différents. Mais là je ne connais pas les détails.
Bonne réflexion pour le week-end :D

Bien vu! Je suis maintenant convaincu que toute cette segmentation peut être purement conceptuelle et que l'éditeur de lien peut transformer les segments conceptuels en adressage linéaire puis ensuite filer le bébé à la plate-forme OS/ matériel.
Il n'y a pas de doute!!
Je te remercie en tout cas d'avoir déclenché cette piste de réflexion.
Bon week-end mérité.
Bien à toi

ET oui je reviens avec la réponse. J'aimerais avoir vos avis.

Voila le lien considéré :
http://deptinfo.cnam.fr/Enseignement...ire/gestio.htm

Citation:

---

Cette notion de mémoire segmentée peut ou non être prise en compte par le matériel. Lorsqu'elle ne l'est pas, l'éditeur de liens ou le chargeur place les segments dans un espace linéaire, avant de lancer l'exécution du processus.Ce placement est alors statique, et la taille des segments est souvent invariable.
Certains matériels prennent en compte un tel espace, en assurant dynamiquement la traduction d'une adresse segmentée en une adresse dans un espace linéaire, au moyen de tables spécifiques qui contiennent les informations de localisation de chaque segment, encore appelés descripteurs de segment.

---

Dans cette citation, il y a le passage :

Citation:

---

Ce placement est alors statique, et la taille des segments est souvent invariable.

---

Pourquoi parle on de segments alors qu'il ne doit pas y avoir dans ce cas.

Citation:

---

Voici quelques exemples de processeurs disposant de l'adressage segmenté:

* Dans Multics, un processus peut avoir 32768 segments, chacun des segments pouvant atteindre 256 Kmots de 36 bits.
* Dans l'intel iAPX286 (le processeur des PC-AT), la table des descripteurs de segments d'un processus est divisée en deux parties, une table des segments communs à tous les processus, et une table propre à chaque processus. Chacune de ces tables peut avoir 8192 segments, et chaque segment peut avoir jusqu'à 64 Koctets. La mémoire linéaire est la mémoire physique, et peut atteindre 16 Moctets.
* L'intel iAPX386 (et suivants) est assez voisin de l'iAPX286, du point de vue adressage segmenté, si ce n'est que les segments peuvent atteindre 4 Goctets. La mémoire linéaire peut atteindre 4 G octets et peut, de plus, être paginée (voir ci-dessous).

---

Pour les spécialistes du C++, serait il possible de savoir où se situe ce langage par rapport à la segmentation, est ce que son partage descend côté matériel ou c'est purement conceptuel ????

La segmentation est une question liée à l'OS et sans doute aux outils que tu vas utiliser. Le C++ "pur" n'a pas notion de segment, de pagination ou what ever. Au mieux on dispose de la notion de "données contiguës en mémoire".

La question est donc à déplacer dans un autre forum (OS sans doute).

Quand tu fais de la prog "standard" tu n'as pas à te soucier des segments, le compilateur et le linker s'en occupent pour toi.

Si tu linkes en mode PIC (Position Independent Code, lors du chargement du programme, le loader ajuste toutes les adresses dans ton code compilé pour que ça aille bien, quelles que soient les adresses des différents segments. Si tu linke pas en mode PIC, tu auras des adresses en dur.

Dans tous les cas, les appels à des libraries partagées (donc chargées à des adresses non déterminées à l'avance) sont remplacés par les bonnes adresses au chargement de l'exécutable.

Une chose à savoir cependant : quand un segment est marqué en lecture seule, il est chargé par l'OS dans des pages marquées en lecture seule, donc le CPU est au courant, et par exemple si tu as plusieurs cores, le core 1 sait que le core 2 n'est pas en train de modifier ces données là pendant qu'il les lit, ce qui économise beaucoup d'opérations de synchronisation inter-core ou inter-CPU et permet de ne pas perdre de temps.

En embarqué, c'est différent. Par exemple sur un FPGA j'avais une plateforme avec un CPU tout pourri (Microblaze), 16 Ko de RAM statique rapide (1 cycle) et plusieurs Mo de Flash très lente (14 cycles).

Avec plusieurs dizaines de Ko de code d'init (sert qu'une fois, rapidité pas importante) et de debug, plus printf() qui prend plus de 10 Ko, le logo pour le LCD, etc, il faut bien savoir où tu mets tes segments...

Dans ce cas, tu expliques au compilateur dans quel segment doit aller quelle fonction (GCC a des macros pour ça) et ensuite tu configures le linker pour que le segment qui contient les petites fonctions utilisées fréquemment soit chargé à une adresse fixe qui correspond à de la RAM rapide, et les gros machins utilisés rarement soient dans la mémoire lente.

En résumé, si tu fais de l'embarqué sur un système avec tellement pas de RAM que ça rentre qu'avec un chausse-pied lubrifié, c'est important de savoir écrire un script de linker, sinon c'est un peu de la culture générale...

Citation:

---

Le C++ "pur" n'a pas notion de segment,

---

avec tout mon respect :
et qu'est ce que tu fais de segments de données, de code, tas et compagnie même si cela reste conceptuel et n'intervient pas dans la programmation.
C'est une vision fournie à l'utilisateur tout de même!.

Citation:

---

Quand tu fais de la prog "standard" tu n'as pas à te soucier des segments, le compilateur et le linker s'en occupent pour toi.

---

Je le sais. C'est juste une curiosité! néanmoins, j'aimerai bien avoir une réponse à cela!

Citation:

---

Si tu linkes en mode PIC (Position Independent Code, lors du chargement du programme, le loader ajuste toutes les adresses dans ton code compilé pour que ça aille bien,

---

Je comprend par cela que les segments cités peuvent être considérés par le compilateur et le linker et pourquoi pas garder cette représentation en segments dans la gestion de la mémoire physique. je parle d'une possibilité!. C'est le genre de réponse que j'aimerais avoir car tout ce qui a été dit est super intéressant mais aucune réponse n'ose confirmer la possibilité de l'existence de ce que j'ai avancé.
Le truc simple par exemple: le code est considéré regroupé, de façon contiguë, dans un espace mémoire logique (pour ne pas dire segment de données) par le compilateur et le linker; ce même code est regroupé en segment en mémoire physique si le matériel le permet. c'est aussi simple que cela. Je n'arrive pas à avoir une réponse directe!!!

En tout cas, un grand Merci à vous

Citation:

---

Envoyé par wafiwafi

et qu'est ce que tu fais de segments de données, de code, tas et compagnie même si cela reste conceptuel et n'intervient pas dans la programmation.

---

Je n'ai pourtant pas souvenir d'avoir vu ces notions dans la norme C++.

Citation:

---

Envoyé par wafiwafi

C'est le genre de réponse que j'aimerais avoir car tout ce qui a été dit est super intéressant mais aucune réponse n'ose confirmer la possibilité de l'existence de ce que j'ai avancé.
Le truc simple par exemple: le code est considéré regroupé, de façon contiguë, dans un espace mémoire logique (pour ne pas dire segment de données) par le compilateur et le linker; ce même code est regroupé en segment en mémoire physique si le matériel le permet. c'est aussi simple que cela. Je n'arrive pas à avoir une réponse directe!!!

---

Si tu n'as pas de réponses directes et simples à ces questions, c'est peut être tout simplement car il n'y en a pas.

Comme l'ont précédemment fait remarquer Davidbrcz et peufeu, la segmentation et la pagination sont des notions dépendantes de la plateforme et de l'OS. La réponse est donc variable en fonction de l'environnement concerné.

Merci pour ta réponse.

Citation:

---

Je n'ai pourtant pas souvenir d'avoir vu ces notions dans la norme C++.

---

J'ai vu un livre du C++ dont le titre m'échappe, et d'autres cours, qui présentent ce schéma de segments pour l'utilisateur. Il n'y a qu'à se souvenir du segment qui héberge la pile pour les variables locales globales....
Donc cette séparation conceptuelle en zones existe bien en C++.

Pour le reste, tu as peut être raison; le compilateur/linker doivent s'adapter à l'OS tout simplement.
Cordialement

Je précise ma réponse précédente. Tu vas trouver dans le C++ notions de "données allouées sur la pile" , "sur le tas", "données statiques" et enfin "données contiguës en mémoire"

Mais ces notions sont des garanties que le langage apporte au programmeur au niveau de la portée des variables (principalement).

Derrière, comment c'est géré, c'est dépendant de chaque architecture.

Sur un PC classique, tout est mis en RAM et c'est l'OS qui gère le tout. Mais on peut imaginer (et je crois qu'il a existé, je ne préfère ne pas trop m'avancer) des systèmes où il y avait un type de mémoire différent pour chaque besoin.

Mais dans tous les cas, ce sont des détails qui sont cachés par l'OS.
Si tu veux mettre les mains dans le cambouis, il faut faire de l'ASM.

Oui; c'est bien clair.
C'est purement Conceptuel! C'est super important pour le pointage par exemple: on ne peut pas pointer ce qu'on veut comme on veut.
Je mets le sujet résolu.
Merci beaucoup

Citation:

---

C'est purement Conceptuel! C'est super important pour le pointage par exemple: on ne peut pas pointer ce qu'on veut comme on veut.

---

?

Tu peux créer un pointeur sur ce que tu veux. Après, il faut faire attention à la durée de vie et à sa destruction (ou pas, justement) d'où les risques classiques liés aux pointeurs mais qui ont presque totalement disparu du C++

Citation:

---

Envoyé par Davidbrcz

Si tu veux mettre les mains dans le cambouis, il faut faire de l'ASM.

---

Et encore, y a pas mal de chose pour lesquelles on n'a pas de contrôle directe (je pense à la MMU et autre joyeusetés). Le principe de l'adressage mémoire virtuelle et justement de pas à chercher à gérer ces trucs casse-peids par soit même.

Bonjour,

Citation:

---

d'où les risques classiques liés aux pointeurs mais qui ont presque totalement disparu du C++

---

Les mots clé new et delete seraient donc obsolète? :cry:
Je dois être drôlement en retard :oops:

Il y a au moins trois notions différentes mais pas indépendantes de segments.

Tout d'abord le segment peut etre une unite utilisee par l'edition de liens. Celui-ci mettra alors de maniere contigue en memoire ce qui fait partie d'un meme segment et un compilateur peut offrir comme extension le moyen de controler ce qui va dans quel segment ou faire une assignation par defaut.

L'OS peut avoir sa notion de segment, zone de memoire contigue qui est geree d'un bloc (p.e. tout le segment est swappe sur disque en meme temps, la gestion des droits -- ecriture/lecture/execution/... se fait par segment, etc). Si l'OS a une notion de segment, il y a de forte chance que d'editeur de liens aussi. De toute maniere, il va falloir repartir le programme en segments pour l'OS (un segment de l'OS correspondant a un ensemble de segment pour l'editeur de liens; je ne vois a priori aucun sens a decouper un segment de l'editeur de liens en plusieurs segment de l'OS). Cette construction de la gestion de la memoire l'OS en segment s'oppose a une vision paginee ou la memoire est decoupee en pages de taille fixe plutot qu'en segment de taille variable et ayant une unite logique. Naturellement, un OS peut melanger les deux visions si ca lui convient.

Troisieme notion, celle du processeur (ou d'une couche supplementaire de hard). Il s'agit de decouper les adresses logiques en deux parties: le segment et l'offset et d'appliquer un controle de validite sur le type d'acces et l'offset en fonction du segment. Dans les cas les plus connus, le segment est stocke dans des registres speciaux. A nouveau, c'est en opposition avec une gestion de la memoire paginee ou la memoire est decoupee en pages de taille fixe (ou d'un petit nombre de tailles possibles). Et a nouveau, un processeur peut proposer les deux, de maniere combinee ou independante. Et un OS qui a une notion de segment ou de page va utiliser ce que fournit le processeur pour aider a son implementation -- ca me semble assez difficile, au minimum ce sera couteux, de fournir dans l'OS ce genre de concepts sans aide hard.

Citation:

---

Envoyé par Pierre Dolez

Les mots clé new et delete seraient donc obsolète?

---

Non, ils sont simplement un peu plus encapsule.

Il y a deux problematiques dans la gestion de la memoire. La definition d'une politique adaptee aux structures de donnees choisies et le respect de ces politiques.

L'utilisation de pointeurs intelligents permet de faciliter ce dernier point (au pire, juste en documentant dans le type quelle politique est utilisee, mais en pratique pas mal d'aspects peuvent etre geres automatiquement) pour pas mal de politiques.

Cette facilite d'implementation influence naturellement le choix des politiques lors de la conception. Cette influence est telle chez certains qu'ils n'envisagent meme plus de politiques en dehors de deux ou trois pour lesquelles ils ont deja le pointeur intelligent qui va bien.

Citation:

---

Envoyé par Pierre Dolez

Bonjour,

Les mots clé new et delete seraient donc obsolète? :cry:
Je dois être drôlement en retard :oops:

---

Comme le fait remarquer Jean-Marc.Bourguet , ils sont encapsulés.
En C++, on ne manipule presque plus de pointeur brut, on préfère des pointeurs intelligents (boost, ceux de C++1x) qui garantissent une destruction transparente via le RAII et assure un code exception-safe.

De même, on ne manipule ni new[] pour les tableaux (ni des maillons pour les listes) mais std::vector et std::list qui garantissent un code exception-safe et offrent de nombreuses facilités pour la gestion de la mémoire (en gros, tu n'as plus à t'en soucier).

Si tu veux approfondir cela, regarde la FAQ C++.

Merci,
J'ai pas tout lu dans la FAQ, mais je n'ai que C++ Builder 6.
Je ne peux qu'en déduire que je suis un (void*)NULL.
En matière de développement, ça va pas mal, merci, en matière de programmation, par contre, j'ai certainement beaucoup à apprendre. Mais les langues, ça n'a jamais été mon fort.
D'une façon générale, je considère qu'on ne doit pas demander à une machine de faire ce qu'on ne saurait pas faire à la main, ou qu'on ne saurait pas expliquer. C'est surtout vrai dans un domaine que je connais un peu (CAO - SIG) mais c'est vrai aussi en informatique. Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.
Cordialement.

Citation:

---

Envoyé par Davidbrcz

Tu vas trouver dans le C++ notions de "données allouées sur la pile" , "sur le tas", "données statiques" et enfin "données contiguës en mémoire"

---

Je peux me tromper mais il me semble que la norme ne parle jamais de tas ou de pile. Ce qui est précisé ce sont les durées de vie, les appels (automatique ou non) aux constructeurs/destructeurs. En revanche, en théorie, rien n'oblige d'avoir un tas et une pile (certains systèmes embarqués ne travaillent qu'avec une pile et n'ont pas de tas).

Citation:

---

Envoyé par Pierre Dolez

D'une façon générale, je considère qu'on ne doit pas demander à une machine de faire ce qu'on ne saurait pas faire à la main, ou qu'on ne saurait pas expliquer. C'est surtout vrai dans un domaine que je connais un peu (CAO - SIG) mais c'est vrai aussi en informatique. Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.

---

A un moment il faut savoir travailler avec des concepts donnés comme tels. On apprend à compter (au CP) avant de définir les nombres (bac + des bananes) 'mathématiquement'. Une fois qu'on a assimilé un certain nombre de ces concepts, effectivement, il est enrichissant d'aller plus loin. Mais c'est toujours le vieux débat bottom/up vs up/bottom.

Il est possible de ne pas avoir de tas, dans ce cas tu n'as ni malloc() ni new, et donc toutes tes variables et objets sont soit sur la pile (variables locales, plus alloca()) soit globales (vraies globales, ou static dans un fichier, une classe ou une fonction). Il est courant en embarqué de ne pas avoir de tas. Par exemple le CPU qui est dans ta souris a probablement quelque chose comme 128 octets de RAM et pas vraiment besoin d'allocation dynamique (ni de C++ d'ailleurs !...)

Ne pas avoir de pile ne permettrait pas de faire d'appels de fonctions et t'interdirait les variables locales, par conséquent les programmes que tu pourrais écrire seraient quelque peu limités :mrgreen:

Citation:

---

Je comprend par cela que les segments cités peuvent être considérés par le compilateur et le linker et pourquoi pas garder cette représentation en segments dans la gestion de la mémoire physique.

---

Raisons diverses, entre autres le CPU gère la mémoire sous forme de pages (généralement 4k) et les segments de ton exécutables ne sont pas en multiples de 4k. Aussi ce sont 2 choses différentes, l'OS gère toute la RAM pas juste celle où tu charges ton exécutable.

Citation:

---

Envoyé par peufeu

Ne pas avoir de pile ne permettrait pas de faire d'appels de fonctions et t'interdirait les variables locales, par conséquent les programmes que tu pourrais écrire seraient quelque peu limités :mrgreen:

---

Il y a eu un certain nombre de processeurs sans pile hard. Une partie du folklore sur le cout de la recursivite vient de ces processeurs -- sur lesquels une fonction recursive doit gerer "manuellement" une pile tandis qu'une fonction non recursive peut utiliser d'autres techniques mieux supportees par le processeur. Il y a toujours des processeurs RISC qui n'ont pas de pile, juste une convention bien etablie (et parfois imposee par l'OS) d'utiliser un registre donne comme pointeur de pile; mais ce registre n'a rien de special par rapport aux autres.

> Il y a toujours des processeurs RISC qui n'ont pas de pile

Quelle que soit l'implémentation (registre spécifié par le hard ou la convention), à partir du moment où tu empiles des trucs dessus, c'est une pile :mrgreen:

Citation:

---

Envoyé par peufeu

> Il y a toujours des processeurs RISC qui n'ont pas de pile

Quelle que soit l'implémentation (registre spécifié par le hard ou la convention), à partir du moment où tu empiles des trucs dessus, c'est une pile :mrgreen:

---

Rien ne t'oblige a faire une pile. C'est juste une convention et en embarque particulièrement, on peut désirer ne pas la suivre. Mais on ne concevra vraisemblablement plus des processeurs sur lesquels avoir une pile est beaucoup plus coûteux que les autres choix.

Salut,

Citation:

---

Envoyé par Pierre Dolez

<snip>Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.
Cordialement.

---

Il ne faut pas oublier non plus que les notions même d'allocation dynamique, de pointeur ou de 0 terminal sont propres au C et aux autres langages qui s'en sont plus ou moins inspiré.

La notion d'entier elle-même n'est jamais qu'une manière de voir les choses que les développeurs originels de ces langages ont décidé d'utiliser / de reprendre.

Je sais que c'est un vieux langage de niche, mais, si tu venais à t'intéresser un peu à cobol, par exemple, tu aurais de grandes chances de tomber des nues si tu considères ces quelques concepts comme inébranlables et "universels" :aie:

Citation:

---

Il me parait choquant qu'on apprenne à des étudiants à utiliser std::string s'ils ne savent pas ce qu'est une chaine, un 0 terminal etc.

---

Pour conduire, on te donne une formation complète sur comment marche un moteur ? ;)

Et ben pour la programmation c'est pareil. Pas besoin de savoir comment marche une chose pour l'utiliser, suffit de savoir lire un mode d'emploi. Pour utiliser std::string, il suffit de lire la documentation.

Je suis assez d'accord avec la comparaison du permis de conduire, et je crois me souvenir que le code de la route utilisé par mes enfants comportait un chapitre sur les moteurs, la direction et je ne sais quoi.
Mais comme il y a bien longtemps que l'ai passé, je ne me souviens plus les détails, mais je savais très bien comment fonctionnait un moteur.

Pour en revenir à l'informatique, j'ai utilisé beaucoup de langages, mais pas le Cobol. Par contre, je ne crois pas qu'on aurait réussi à me faire écrire une instruction si je ne savais pas ce que ça voulait dire.
Pour vérifier que ma façon de voir les choses n'est pas tout à fait débile, il suffit de lire les questions posées, en particulier à propos de chaines de caractères.

Citation:

---

Il ne faut pas oublier non plus que les notions même d'allocation dynamique, de pointeur ou de 0 terminal sont propres au C et aux autres langages qui s'en sont plus ou moins inspiré.

---

... et le langage C++ est une extension du C (citation d'un modérateur sur ce forum) cf réponse précédente, mais qu'on ne me demande pas de nouveau l'url :mouarf:

C'est un sujet auquel j'attache de l'importance, en programmation comme en utilisation, mais cela fait l'objet d'un autre forum.:(
J'ai des exemples très précis, mais je ne les expliquerai pas en public.

Bonne soirée.

Citation:

---

... et le langage C++ est une extension du C (citation d'un modérateur sur ce forum) cf réponse précédente, mais qu'on ne me demande pas de nouveau l'url

---

Les modérateurs ne disent pas que des choses vraie... la preuve ici :).
Non le langage C++ n'est pas le C. Ni même une extension. (cf le Père).
Y'a déjà eu des tonnes de discussion sur ça ici.