On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
Un langage qui interdirait de planter une machine ne permet pas la réalisation d'un systeme d'exploitation
Le plantage fait donc parti des fonctonnalités de tout bon OS (ce qui est faux, bien sûr).
Pas dit ca ;-) Relire, comprendre :-D
UN système d'exploitation doit utiliser un langage qui peut faire planter la machine, c'est donc pour la faire planter, sinon on en choisirais un qui ne peut pas faire planter la machine.
"La conception d'un OS necessite des fonctionalités qui détournées de leur philosophie peuvent conduire à un plantage de la machine". C'est plus clair pour toi ?
un while(1); dans une section ininterruptible suffit. Et si tu n'as pas de notion d'ininterruptibilité, tu vas avoir du mal a faire un OS...
Qui à besoin d'un while ? Ceux qui ne connaissent rien d'autre que le C et les langages du même tonneau.
j'ai mis ca comme j'aurai mis un appel autorecursif ou autre saloperie. La notion d'exemple te dépasse aussi ? ;-)
Joe Cool a exprimé avec précision :
Joe Cool a émis l'idée suivante :
Un langage qui interdirait de planter une machine ne permet pas la
réalisation d'un systeme d'exploitation
Le plantage fait donc parti des fonctonnalités de tout bon OS (ce qui est
faux, bien sûr).
Pas dit ca ;-) Relire, comprendre :-D
UN système d'exploitation doit utiliser un langage qui peut faire planter la
machine, c'est donc pour la faire planter, sinon on en choisirais un qui ne
peut pas faire planter la machine.
"La conception d'un OS necessite des fonctionalités qui détournées de
leur philosophie peuvent conduire à un plantage de la machine". C'est
plus clair pour toi ?
un while(1); dans une section ininterruptible suffit. Et si tu n'as pas de
notion d'ininterruptibilité, tu vas avoir du mal a faire un OS...
Qui à besoin d'un while ?
Ceux qui ne connaissent rien d'autre que le C et
les langages du même tonneau.
j'ai mis ca comme j'aurai mis un appel autorecursif ou autre saloperie.
La notion d'exemple te dépasse aussi ? ;-)
Un langage qui interdirait de planter une machine ne permet pas la réalisation d'un systeme d'exploitation
Le plantage fait donc parti des fonctonnalités de tout bon OS (ce qui est faux, bien sûr).
Pas dit ca ;-) Relire, comprendre :-D
UN système d'exploitation doit utiliser un langage qui peut faire planter la machine, c'est donc pour la faire planter, sinon on en choisirais un qui ne peut pas faire planter la machine.
"La conception d'un OS necessite des fonctionalités qui détournées de leur philosophie peuvent conduire à un plantage de la machine". C'est plus clair pour toi ?
un while(1); dans une section ininterruptible suffit. Et si tu n'as pas de notion d'ininterruptibilité, tu vas avoir du mal a faire un OS...
Qui à besoin d'un while ? Ceux qui ne connaissent rien d'autre que le C et les langages du même tonneau.
j'ai mis ca comme j'aurai mis un appel autorecursif ou autre saloperie. La notion d'exemple te dépasse aussi ? ;-)
JustMe
JKB avait énoncé :
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
Se placer dans un cas de comportement indéfini _est_ une erreur.
Montre-moi un seul bout de code où il n'y a pas en C une seule instruction à comportement indéfini (au moins sur un ensemble).
a = 0;
JKB avait énoncé :
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
Se placer dans un cas de comportement indéfini _est_ une erreur.
Montre-moi un seul bout de code où il n'y a pas en C une seule
instruction à comportement indéfini (au moins sur un ensemble).
Le 08-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
JKB avait énoncé :
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
Se placer dans un cas de comportement indéfini _est_ une erreur.
Montre-moi un seul bout de code où il n'y a pas en C une seule instruction à comportement indéfini (au moins sur un ensemble).
a = 0;
On ne va pas loin, avec ça...
JKB
Nicolas George
Joe Cool , dans le message <422e07d2$0$16915$, a écrit :
Ce qui oblige à se confiner dans les cas particuliers pour éviter les erreurs.
Un programme est toujours un cas particulier. On peut même dire : un programme utile est forcément dans un cas qui in fine est décidable, puisqu'on attend de lui qu'il fasse quelque chose d'utile, justement.
Joe Cool , dans le message <422e07d2$0$16915$636a15ce@news.free.fr>, a
écrit :
Ce qui oblige à se confiner dans les cas particuliers pour éviter les
erreurs.
Un programme est toujours un cas particulier. On peut même dire : un
programme utile est forcément dans un cas qui in fine est décidable,
puisqu'on attend de lui qu'il fasse quelque chose d'utile, justement.
Joe Cool , dans le message <422e07d2$0$16915$, a écrit :
Ce qui oblige à se confiner dans les cas particuliers pour éviter les erreurs.
Un programme est toujours un cas particulier. On peut même dire : un programme utile est forcément dans un cas qui in fine est décidable, puisqu'on attend de lui qu'il fasse quelque chose d'utile, justement.
JustMe
JKB avait écrit le 08/03/2005 :
Le 08-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
JKB avait énoncé :
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
Se placer dans un cas de comportement indéfini _est_ une erreur.
Montre-moi un seul bout de code où il n'y a pas en C une seule instruction à comportement indéfini (au moins sur un ensemble).
a = 0;
On ne va pas loin, avec ça...
base de la logique: pour prouver qu'une proposition est fausse, il suffit de trouver un contre-exemple, meme trivial
:-D
JKB avait écrit le 08/03/2005 :
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
JustMe écrivait dans fr.comp.os.linux.debats :
JKB avait énoncé :
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
Se placer dans un cas de comportement indéfini _est_ une erreur.
Montre-moi un seul bout de code où il n'y a pas en C une seule
instruction à comportement indéfini (au moins sur un ensemble).
a = 0;
On ne va pas loin, avec ça...
base de la logique: pour prouver qu'une proposition est fausse, il
suffit de trouver un contre-exemple, meme trivial
Je laisse en exercice au lecteur le fait de démontrer que toutes les opérations arithmétiques restent dans les intervalles de validité.
C'est tout sauf portable d'une architecture à l'autre, mais c'est vous qui voyez...
JKB
Sam Hocevar
On Tue, 08 Mar 2005 20:24:53 +0100, Joe Cool wrote:
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
#include <stdlib.h>
int main(int argc, char **argv) { int a[10];
a[11] = 3; return EXIT_SUCCESS; }
On dirait que tu ne comprends pas très bien. Je vais te faire un dessin pour t'expliquer. Voici une représentation d'un tableau a[10] : ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ | | | | | | | | | | | |a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]| |____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et la 10e case est a[9]. On se rend immédiatement compte que la 11e case de ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans ton exemple.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
On Tue, 08 Mar 2005 20:24:53 +0100, Joe Cool wrote:
Comment se fait il qu'on puisse écrire dans la 11e case d'un
tableau de 10 éléments.
On ne peut pas, tu te trompes.
#include <stdlib.h>
int main(int argc, char **argv)
{
int a[10];
a[11] = 3;
return EXIT_SUCCESS;
}
On dirait que tu ne comprends pas très bien. Je vais te faire un
dessin pour t'expliquer. Voici une représentation d'un tableau a[10] :
____ ____ ____ ____ ____ ____ ____ ____ ____ ____
| | | | | | | | | | |
|a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]|
|____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et
la 10e case est a[9]. On se rend immédiatement compte que la 11e case de
ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans
ton exemple.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/
On Tue, 08 Mar 2005 20:24:53 +0100, Joe Cool wrote:
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
#include <stdlib.h>
int main(int argc, char **argv) { int a[10];
a[11] = 3; return EXIT_SUCCESS; }
On dirait que tu ne comprends pas très bien. Je vais te faire un dessin pour t'expliquer. Voici une représentation d'un tableau a[10] : ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ | | | | | | | | | | | |a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]| |____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et la 10e case est a[9]. On se rend immédiatement compte que la 11e case de ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans ton exemple.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
Nicolas George
JKB , dans le message , a écrit :
C'est tout sauf portable d'une architecture à l'autre, mais c'est vous qui voyez...
Ça fonctionnera et donnera un résultat valide (au sens des affirmations méthématiques qu'il affiche) sur toute architecture. Et si je remplace la constante INT_MAX par 32767, qui est sa plus petite valeur possible, ce code fonctionnera parfaitement à l'identique sur toute architecture C.
JKB , dans le message <slrnd2s39k.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
C'est tout sauf portable d'une architecture à l'autre, mais c'est
vous qui voyez...
Ça fonctionnera et donnera un résultat valide (au sens des affirmations
méthématiques qu'il affiche) sur toute architecture. Et si je remplace la
constante INT_MAX par 32767, qui est sa plus petite valeur possible, ce code
fonctionnera parfaitement à l'identique sur toute architecture C.
C'est tout sauf portable d'une architecture à l'autre, mais c'est vous qui voyez...
Ça fonctionnera et donnera un résultat valide (au sens des affirmations méthématiques qu'il affiche) sur toute architecture. Et si je remplace la constante INT_MAX par 32767, qui est sa plus petite valeur possible, ce code fonctionnera parfaitement à l'identique sur toute architecture C.
JKB
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
C'est tout sauf portable d'une architecture à l'autre, mais c'est vous qui voyez...
Ça fonctionnera et donnera un résultat valide (au sens des affirmations méthématiques qu'il affiche) sur toute architecture. Et si je remplace la constante INT_MAX par 32767, qui est sa plus petite valeur possible, ce code fonctionnera parfaitement à l'identique sur toute architecture C.
Votre code en tant que tel ne donnera pas le même résultat en fonction des architectures. Maintenant, remplacez INT_MAX par ce que vous voudrez, je vous fais le pari de trouver une architecture où il ne fonctionnera pas (au hasard une architecture douze bits). Vous pouvez faire ce que vous voulez à un code C, il y aura toujours des "implementation defined" qui traînent, sauf à le restreindre drastiquement et à utiliser ses propres routines pour tout ce qui est "implementation defined". Je l'ai fait, c'est horrible (et je dois être l'un des seuls).
Maintenant, si vous voulez vous amuser, j'ai un compilo C de TSC qui suis _parfaitement_ la norme. Vous seriez surpris de compiler un code C _standard_ avec lui, parce que tout ce qui est "implementation defined" est surréaliste, et il n'y a plus de qualificatif pour ce qui est "undefined".
Fin de la discussion.
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2s39k.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
C'est tout sauf portable d'une architecture à l'autre, mais c'est
vous qui voyez...
Ça fonctionnera et donnera un résultat valide (au sens des affirmations
méthématiques qu'il affiche) sur toute architecture. Et si je remplace la
constante INT_MAX par 32767, qui est sa plus petite valeur possible, ce code
fonctionnera parfaitement à l'identique sur toute architecture C.
Votre code en tant que tel ne donnera pas le même résultat en
fonction des architectures. Maintenant, remplacez INT_MAX par ce que
vous voudrez, je vous fais le pari de trouver une architecture où il
ne fonctionnera pas (au hasard une architecture douze bits).
Vous pouvez faire ce que vous voulez à un code C, il y aura toujours
des "implementation defined" qui traînent, sauf à le restreindre
drastiquement et à utiliser ses propres routines pour tout ce qui
est "implementation defined". Je l'ai fait, c'est horrible (et je
dois être l'un des seuls).
Maintenant, si vous voulez vous amuser, j'ai un compilo C de TSC qui
suis _parfaitement_ la norme. Vous seriez surpris de compiler un
code C _standard_ avec lui, parce que tout ce qui est
"implementation defined" est surréaliste, et il n'y a plus de
qualificatif pour ce qui est "undefined".
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
C'est tout sauf portable d'une architecture à l'autre, mais c'est vous qui voyez...
Ça fonctionnera et donnera un résultat valide (au sens des affirmations méthématiques qu'il affiche) sur toute architecture. Et si je remplace la constante INT_MAX par 32767, qui est sa plus petite valeur possible, ce code fonctionnera parfaitement à l'identique sur toute architecture C.
Votre code en tant que tel ne donnera pas le même résultat en fonction des architectures. Maintenant, remplacez INT_MAX par ce que vous voudrez, je vous fais le pari de trouver une architecture où il ne fonctionnera pas (au hasard une architecture douze bits). Vous pouvez faire ce que vous voulez à un code C, il y aura toujours des "implementation defined" qui traînent, sauf à le restreindre drastiquement et à utiliser ses propres routines pour tout ce qui est "implementation defined". Je l'ai fait, c'est horrible (et je dois être l'un des seuls).
Maintenant, si vous voulez vous amuser, j'ai un compilo C de TSC qui suis _parfaitement_ la norme. Vous seriez surpris de compiler un code C _standard_ avec lui, parce que tout ce qui est "implementation defined" est surréaliste, et il n'y a plus de qualificatif pour ce qui est "undefined".
