Est-ce qu'il y a une détection des fichiers en erreur ?
Mon cas d'usage est celui de copies multiples de répertoire contenant mes archives photos (sauvegardes sur différent support faites au cours du temps). Parfois des images sont corrompues. Comment faire pour "remerger" toutes ces copies en un seul répertoire propre de référence.
J'ai compris qu'un beau code n'est pas un code ultra générique, mais un code qui se lit comme une histoire. J'ai compris ça en lisant du code de hocwp, je ne sais pas si il est encore sur le site. C'était juste limpide. Un code comme ça, peut vivre longtemps.
En informatique, ce n'est pas le code l'important, mais la fonction a réaliser, la maintenabilité, l'absence de bug, la vitesse d’exécution.
J'ai vu une fois du beau code bien générique d'un code "professionnel". Il s'agissait de faire des filtres numériques (type O = I(n)a + I(n-1)*b +I(n+2)*c…), c'était généralisé avec une gestion de liste et des fonctions utilitaire. Or la plus part des filtres était d'ordre 2, ce qui aurait du faire des équations du genre "return ab+c*d;"…
Pour arriver un peu à la même chose, je raisonne en cas de testes. Dans un monde rêvé, où tous les cas seraient testés, combien de tests cela fait ? Cela détermine le nombre d'état possible du code, et autant de problèmes potentiels, surtout après modification (non régression plus complexe).
Cela permet de se rendre compte de la qualité d'un code "stateless", ce qui évite une grande quantité de teste finalement inutile. Cela permet de séparer très clairement les données du logiciel, des données temporaires inutiles. Cela permet d'identifier des "états stables" qui permet d'y retourner en cas de plantage ou d'exception non prévu, voir d'avoir un "reset()" propre, qui évite de recréer toujours le même objet. Cela permet de limiter les données du logiciel aux stricts nécessaire aux traitements, ce qui évite de trainer toutes les entrées et ne plus savoir ce qui est valide ou non, modifier ou non, etc… Pour faire cela, cela impose de gérer les erreurs avant le traitement, cela simplifie le traitement qui considère les entrées juste, et cela permet de faire de très joli message d'erreur, car on est très proche de l'entrée de pipeline de traitement (on dispose de tous les fichiers et leur numéro de ligne).
Surtout que la plus part du temps, c'est plus simple de réécrire le code que de jongler avec la "souplesse" de l'architecture complexe, qui de toute façon ne serait jamais assez souple pour les besoins futurs.
Tu opposes un remote desktop dans le cloud et un PC. Si internet tombe, 99% de tes taches peuvent continuer sur PC. Et je vais t'apprendre un truc dingue, la sauvegarde existe aussi pour certain document sur PC. Le mail est coincé, mais tu peux toujours trouver une connexion 3G ou freewifi, au cas ou.
Je ne sais pas d'ou tu sors, mais la plus part des tâches ne nécessite pas forcément internet.
Ton archi est tout à fait comparable à la machine à papi Sun et tu ne t'en rend même pas compte. La seul chose que tu proposes est la duplication de serveur.
Mais tu oublis tout les autres spof : comme la liaison internet, la configuration réseau, les éléments type firewall ou switch managé,… Il y un tas de raisons que le truc tombe en panne. Beaucoup plus que pour un simple PC.
C'est ce dont je parlais dans un autre commentaire. Si tu prends la définition classique d'un "modèle", tu as un diagramme de classe, avec des "références" et des "liens de contenance" qui gère aussi le "lifetime". Dans un modèle objet classique, tous les objets sont créé dans les racines et se référencent entre eux. Dans un modèle, il y a une hiérarchie et une contenance d'objet explicite. Il y a de l'information pour beaucoup simplifier un GC.
Tu peux donc imaginer un système qui alloue toutes la mémoire très tôt, et qui n'alloue plus rien ensuite, en fonction de la taille des entrées.
Tu prends un hello world de chacun pour une application web http et tu utilises "ab".
J'avais fais un crash test, que je prenais pour la vitesse maximum absolu pour faire un server de web application.
Test sur mon portable sur un “hello wolrd” avec “ab -n 1000 -c 100”
- 1300 req/s en ocsigen
- 20 000 req/s avec go
- 15 000 req/s en pure apache
- 1900 re/s avec 2 ocsgen + haproxy
Et puis, un jour, ils vont se rendre compte que le taux de disponibilité de ce genre de chose est faible.
Un PC est moins fiable, mais faire tomber 10 000 PC en même temps est impossible, ce qui n'est pas le cas avec le client/server. J'ai encore les souvenirs de serveurs de fichiers SUN en rade, et la demi-journée perdu qui va avec, tous les 3 mois.
"Il n'existe aucune méthode 100% fiable scientifiquement pour garantir ces conditions."
Il existe un moyen, c'est la blockchain. Il doit être possible d'injecter les données comptables dans le système ethereum.org. Mais c'est en gros 80€/Mo d'écriture.
"C'est vrai. Mais c'est quelque chose d'assez dure à mesurer, les I/O font toujours parti des aspects les plus dure à benchmarker d'un programme car elles sont très sensibles au effets de bords ( cache du kernel, utilisation de la mémoire, block size, … ) "
C'est toujours pareil. Tu ne peux mesurer l'effet d'un seul chose, que toute chose étant égal par ailleurs. C'est vrai dans tout bench.
"La même chose concernant le taux de request par seconde sur un seul et même socket: le classique C10K problem."
C'est vieux :) Un "hello world" de 5 ligne en Go, te livre 20 000 req/s.
Mesurer l'I/O c'est principalement mesurer l'OS, ça a très peu d’intérêt pour un bench qui veut évaluer un langage.
Ce n'est pas si vrai que ça. C'est surtout un bench du sous système IO de la lib du langage. Et cela peut être très mal fait.
Il suffit de voir la variété énorme d'appel système sous Linux, qui selon le cas d'usage ne sont pas les plus performant (mmap qui bouffe la mémoire, et ne peut agrandir un fichier; le read/write qui bufferise et donc ajoute une copie, mais permet de diminuer drastiquement la latence dû au noyau; splice() qui permet de partager un buffer noyau interne; la gestion d'un thread par disque augmente aussi les performances; les ios asynchrones masquent les latences mais peuvent être un cauchemar à utiliser)
Disons que cela pourrait être un bon benchmark en soi. Devoir lire une grande quantité de fichier (10 000 ?) de taille moyenne (1 Mo ?) dans une arborescence, et d'écrire autant de fichiers (avec un checksum bidon dedans par exemple).
C'est une charge hautement parallélisable, mais qui est complètement "IO bound".
SCADE est un outil top pour n'importe quel code embarqué. Peu de bug, facile à modifier. Et le code généré est rapide (code C "propre").
Mais comme le compilateur est certifié comme peut l'être un code aéronautique, il coute une blinde. Les clients ont du mal à justifier son cout par rapport à un GCC gratuit. Mais on a une boite brésilienne qui a préféré acheter du SCADE, car il ne trouvait de codeur en techno classique pour faire des petits drones. Et en équipe réduite, il refait son code beaucoup plus rapidement.
Dans l'automobile, c'est sans doute le cas. Dans l'aéronautique, les contrôleurs ont fait jeter des codes complets pour mauvaises traçabilités (par exemple, le 1er fadec de l'A400M, de mémoire).
"Je ne connaissais pas le principe, l'idée est intéressante ça mérite réflexion. L'idée est de déterminer « statiquement » les besoins en mémoire, non à la compilation, mais le plus tôt possible à l'exécution et ne plus faire d'allocations par la suite ?"
Oui, c'est l'idée. Cela peut s'appliquer souvent. Je crois que haproxy fonctionne ainsi. Tu as un modèle de mémoire qui ne se croit pas infini. Il faut donc en demander au début une certaine quantité, et ne plus en bouger. En plus, cela évite les problèmes de fragmentation.
"Ce que tu décris sur la gestion des objets, n'est-ce pas justement le principe du RAII ?"
Cela y ressemble un peu. Mais tu peux imaginer des cas supplémentaires qui détruisent une arborescence d'objet en dehors du RAII. Et il faut gérer en plus les pointeurs qui ciblent un objet détruit.
Dans le domaine, dans l'embarqué, c'est quand même du C ou du C++, et la bite et le couteau avec des tests unitaire à taux de couverture MCDC. SCADE est vu souvent comme un canon pour écraser une mouche(sauf DO178 niveau A, évidement).
Ariane 5, c'est surtout un handler d'exception sur dépassement de capacité d'une variable qui ne servait à rien, qui lance un code d'autotest, le problème. J'imagine que c'est pour cela qu'il y a une chasse au code "mort" depuis.
L'outil génère un "metafichier" par fichier dans le répertoire ./list/ ce fichier contient la taille et un path vers le fichier réel. Si un fichier meta n'est pas dans ./list/ le binaire va tenter de le replacer par son fichier d'origine et va ajouter son path dans le fichier meta de ./list/.
Il faut voir. Les listes sont ridicules dans 99% des cas. Il y a 1 ou 2 éléments. Pour des tailles inférieurs à 100, c'est très rares d'avoir un container qui bas une liste. Les surcouts statiques sont souvent très couteux (la constante derrière, le O(1))
Il existe un paradigme que je n'ai quasiment jamais vu utiliser. SCADE s'interdit toute allocation et utilise de gros buffer statique, et cela marche très bien pour 99% du code embarqué.
Le problème d'absence d'allocation se pose si la taille des entrées n'est pas connu. C'est le cas dans la norme ARINC 661 qui est un serveur graphique dont les widgets sont connu à l'init déclaré dans un fichier de définition.
Je pense que l'allocation à l'init permet de gérer pas mal de cas, ou au moins, à un temps précis, ce qui permet de gérer l'erreur le plus tôt possible. Un système à gestion automatique de mémoire, pourrait calculer les besoins mémoire au démarrage (selon la taille d'un fichier par exemple) et ensuite ne plus faire d'allocation du tout.
Une autre vois serait de mieux gérer l'appartenance des objets. Dans un système classique, un objet est créé en vrac et on fait des références dessus. Dans l'ingénierie des modèles, si on définit un diagramme de classe, on a clairement une notion d'appartenance à un arbre, et "des" références. Mais cela veut clairement dire que la destruction de la racine de l'arbre entraine toutes les feuilles. Je ne connais pas non plus de gestion de mémoire automatique qui utilise cette propriété.
# fichier en erreur ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 8.
Est-ce qu'il y a une détection des fichiers en erreur ?
Mon cas d'usage est celui de copies multiples de répertoire contenant mes archives photos (sauvegardes sur différent support faites au cours du temps). Parfois des images sont corrompues. Comment faire pour "remerger" toutes ces copies en un seul répertoire propre de référence.
"La première sécurité est la liberté"
[^] # Re: Moi aussi !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 2.
Oui, mais à la fin, tu dois avoir moins de code, et ne pas le garder juste parce que tu t'es fait chier à l'écrire.
"La première sécurité est la liberté"
[^] # Re: Un chouia simpliste ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 4.
J'ai compris qu'un beau code n'est pas un code ultra générique, mais un code qui se lit comme une histoire. J'ai compris ça en lisant du code de hocwp, je ne sais pas si il est encore sur le site. C'était juste limpide. Un code comme ça, peut vivre longtemps.
En informatique, ce n'est pas le code l'important, mais la fonction a réaliser, la maintenabilité, l'absence de bug, la vitesse d’exécution.
J'ai vu une fois du beau code bien générique d'un code "professionnel". Il s'agissait de faire des filtres numériques (type O = I(n)a + I(n-1)*b +I(n+2)*c…), c'était généralisé avec une gestion de liste et des fonctions utilitaire. Or la plus part des filtres était d'ordre 2, ce qui aurait du faire des équations du genre "return ab+c*d;"…
"La première sécurité est la liberté"
[^] # Re: chi va piano va sano
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
Pour arriver un peu à la même chose, je raisonne en cas de testes. Dans un monde rêvé, où tous les cas seraient testés, combien de tests cela fait ? Cela détermine le nombre d'état possible du code, et autant de problèmes potentiels, surtout après modification (non régression plus complexe).
Cela permet de se rendre compte de la qualité d'un code "stateless", ce qui évite une grande quantité de teste finalement inutile. Cela permet de séparer très clairement les données du logiciel, des données temporaires inutiles. Cela permet d'identifier des "états stables" qui permet d'y retourner en cas de plantage ou d'exception non prévu, voir d'avoir un "reset()" propre, qui évite de recréer toujours le même objet. Cela permet de limiter les données du logiciel aux stricts nécessaire aux traitements, ce qui évite de trainer toutes les entrées et ne plus savoir ce qui est valide ou non, modifier ou non, etc… Pour faire cela, cela impose de gérer les erreurs avant le traitement, cela simplifie le traitement qui considère les entrées juste, et cela permet de faire de très joli message d'erreur, car on est très proche de l'entrée de pipeline de traitement (on dispose de tous les fichiers et leur numéro de ligne).
"La première sécurité est la liberté"
[^] # Re: Moi aussi !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 4.
Quand tu commences à écrire du code en plus, au lieu d'en effacer, tu va dans le mauvais sens. C'est un peu le principe de la factorisation.
"La première sécurité est la liberté"
[^] # Re: Un chouia simpliste ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 7.
Surtout que la plus part du temps, c'est plus simple de réécrire le code que de jongler avec la "souplesse" de l'architecture complexe, qui de toute façon ne serait jamais assez souple pour les besoins futurs.
"La première sécurité est la liberté"
[^] # Re: blockchain
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Point d'étape sur loi française de finances 2016 (article 88) et les logiciels libres de caisse. Évalué à 2.
La loi a changé, si un vendeur de machine est pris, il est solidaire des fraudes faites avec… Je ne suis pas sûr que cela en vaut la peine.
"La première sécurité est la liberté"
[^] # Re: C'est merveilleux l'informatique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 3.
En France.
Au USA, on rémunère mieux les "makers" que les "sellers". Sinon, ils n'existeraient pas de salaires à 100k$ pour les ingénieurs.
"La première sécurité est la liberté"
[^] # Re: dispo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 5.
Tu lis un peu ce à quoi tu réponds ?
Tu opposes un remote desktop dans le cloud et un PC. Si internet tombe, 99% de tes taches peuvent continuer sur PC. Et je vais t'apprendre un truc dingue, la sauvegarde existe aussi pour certain document sur PC. Le mail est coincé, mais tu peux toujours trouver une connexion 3G ou freewifi, au cas ou.
Je ne sais pas d'ou tu sors, mais la plus part des tâches ne nécessite pas forcément internet.
"La première sécurité est la liberté"
[^] # Re: dispo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 1.
Ton archi est tout à fait comparable à la machine à papi Sun et tu ne t'en rend même pas compte. La seul chose que tu proposes est la duplication de serveur.
Mais tu oublis tout les autres spof : comme la liaison internet, la configuration réseau, les éléments type firewall ou switch managé,… Il y un tas de raisons que le truc tombe en panne. Beaucoup plus que pour un simple PC.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
C'est ce dont je parlais dans un autre commentaire. Si tu prends la définition classique d'un "modèle", tu as un diagramme de classe, avec des "références" et des "liens de contenance" qui gère aussi le "lifetime". Dans un modèle objet classique, tous les objets sont créé dans les racines et se référencent entre eux. Dans un modèle, il y a une hiérarchie et une contenance d'objet explicite. Il y a de l'information pour beaucoup simplifier un GC.
Tu peux donc imaginer un système qui alloue toutes la mémoire très tôt, et qui n'alloue plus rien ensuite, en fonction de la taille des entrées.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Tu prends un hello world de chacun pour une application web http et tu utilises "ab".
J'avais fais un crash test, que je prenais pour la vitesse maximum absolu pour faire un server de web application.
Test sur mon portable sur un “hello wolrd” avec “ab -n 1000 -c 100”
- 1300 req/s en ocsigen
- 20 000 req/s avec go
- 15 000 req/s en pure apache
- 1900 re/s avec 2 ocsgen + haproxy
"La première sécurité est la liberté"
# dispo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à -2.
Et puis, un jour, ils vont se rendre compte que le taux de disponibilité de ce genre de chose est faible.
Un PC est moins fiable, mais faire tomber 10 000 PC en même temps est impossible, ce qui n'est pas le cas avec le client/server. J'ai encore les souvenirs de serveurs de fichiers SUN en rade, et la demi-journée perdu qui va avec, tous les 3 mois.
"La première sécurité est la liberté"
# blockchain
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Point d'étape sur loi française de finances 2016 (article 88) et les logiciels libres de caisse. Évalué à 0.
Il existe un moyen, c'est la blockchain. Il doit être possible d'injecter les données comptables dans le système ethereum.org. Mais c'est en gros 80€/Mo d'écriture.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
C'est toujours pareil. Tu ne peux mesurer l'effet d'un seul chose, que toute chose étant égal par ailleurs. C'est vrai dans tout bench.
C'est vieux :) Un "hello world" de 5 ligne en Go, te livre 20 000 req/s.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Ce n'est pas si vrai que ça. C'est surtout un bench du sous système IO de la lib du langage. Et cela peut être très mal fait.
Il suffit de voir la variété énorme d'appel système sous Linux, qui selon le cas d'usage ne sont pas les plus performant (mmap qui bouffe la mémoire, et ne peut agrandir un fichier; le read/write qui bufferise et donc ajoute une copie, mais permet de diminuer drastiquement la latence dû au noyau; splice() qui permet de partager un buffer noyau interne; la gestion d'un thread par disque augmente aussi les performances; les ios asynchrones masquent les latences mais peuvent être un cauchemar à utiliser)
Disons que cela pourrait être un bon benchmark en soi. Devoir lire une grande quantité de fichier (10 000 ?) de taille moyenne (1 Mo ?) dans une arborescence, et d'écrire autant de fichiers (avec un checksum bidon dedans par exemple).
C'est une charge hautement parallélisable, mais qui est complètement "IO bound".
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
SCADE est un outil top pour n'importe quel code embarqué. Peu de bug, facile à modifier. Et le code généré est rapide (code C "propre").
Mais comme le compilateur est certifié comme peut l'être un code aéronautique, il coute une blinde. Les clients ont du mal à justifier son cout par rapport à un GCC gratuit. Mais on a une boite brésilienne qui a préféré acheter du SCADE, car il ne trouvait de codeur en techno classique pour faire des petits drones. Et en équipe réduite, il refait son code beaucoup plus rapidement.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
On peut aussi parler de Rust, le langage de Mozilla, qui offre le choix concernant la gestion de mémoire (GC ou pas GC, utilisation de pile, etc…).
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Dans l'automobile, c'est sans doute le cas. Dans l'aéronautique, les contrôleurs ont fait jeter des codes complets pour mauvaises traçabilités (par exemple, le 1er fadec de l'A400M, de mémoire).
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Oui, c'est l'idée. Cela peut s'appliquer souvent. Je crois que haproxy fonctionne ainsi. Tu as un modèle de mémoire qui ne se croit pas infini. Il faut donc en demander au début une certaine quantité, et ne plus en bouger. En plus, cela évite les problèmes de fragmentation.
Cela y ressemble un peu. Mais tu peux imaginer des cas supplémentaires qui détruisent une arborescence d'objet en dehors du RAII. Et il faut gérer en plus les pointeurs qui ciblent un objet détruit.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Dans le domaine, dans l'embarqué, c'est quand même du C ou du C++, et la bite et le couteau avec des tests unitaire à taux de couverture MCDC. SCADE est vu souvent comme un canon pour écraser une mouche(sauf DO178 niveau A, évidement).
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
Ariane 5, c'est surtout un handler d'exception sur dépassement de capacité d'une variable qui ne servait à rien, qui lance un code d'autotest, le problème. J'imagine que c'est pour cela qu'il y a une chasse au code "mort" depuis.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
L'outil génère un "metafichier" par fichier dans le répertoire ./list/ ce fichier contient la taille et un path vers le fichier réel. Si un fichier meta n'est pas dans ./list/ le binaire va tenter de le replacer par son fichier d'origine et va ajouter son path dans le fichier meta de ./list/.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Il faut voir. Les listes sont ridicules dans 99% des cas. Il y a 1 ou 2 éléments. Pour des tailles inférieurs à 100, c'est très rares d'avoir un container qui bas une liste. Les surcouts statiques sont souvent très couteux (la constante derrière, le O(1))
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 5.
Je ne suis pas sûr.
Il existe un paradigme que je n'ai quasiment jamais vu utiliser. SCADE s'interdit toute allocation et utilise de gros buffer statique, et cela marche très bien pour 99% du code embarqué.
Le problème d'absence d'allocation se pose si la taille des entrées n'est pas connu. C'est le cas dans la norme ARINC 661 qui est un serveur graphique dont les widgets sont connu à l'init déclaré dans un fichier de définition.
Je pense que l'allocation à l'init permet de gérer pas mal de cas, ou au moins, à un temps précis, ce qui permet de gérer l'erreur le plus tôt possible. Un système à gestion automatique de mémoire, pourrait calculer les besoins mémoire au démarrage (selon la taille d'un fichier par exemple) et ensuite ne plus faire d'allocation du tout.
Une autre vois serait de mieux gérer l'appartenance des objets. Dans un système classique, un objet est créé en vrac et on fait des références dessus. Dans l'ingénierie des modèles, si on définit un diagramme de classe, on a clairement une notion d'appartenance à un arbre, et "des" références. Mais cela veut clairement dire que la destruction de la racine de l'arbre entraine toutes les feuilles. Je ne connais pas non plus de gestion de mémoire automatique qui utilise cette propriété.
"La première sécurité est la liberté"