A supposer qu'une entreprise veuille mettre son parc sous Linux.
Et qu'elle reçoive des documents venant d'Access, Excel,... peut-elle
les lire , les travailler et les renvoyer de manière que le
destinantaire sur produits Microsoft puisse les lire, etc...
?
Pourquoi ceux qui font frontpage et Cie se soucieraient de faire des trucs légers qui peuvent même être vus sur des petites configs? Leur but est de vendre. Or le tiers-monde n'a pas de fric pour payer...
Bah, si tu cherches les sites médicaux sur la polio - qui est très "tendance" en Afrique en ce moment - tu vas tomber sur des trucs imbitables avec une petite configuration. Pourtant, ils n'ont rien à vendre.
Rien que de penser aux institutions qui te proposent de télécharger des fichiers word, au lieu de pdf ou ps...
Pourtant, il suffit de rechercher dans les archives des trucs du genre "abandonwares", "logiciels pour ms-dos" etc. et tu vois que le posteur vit en Afrique. Il semble donc y avoir un réel problème.
Tu mets plein de contrôles BSA sur les particuliers afin qu'ils virent ce qu'ils ont piraté, et le sujet du light et du libre va vite apparaître comme fondamental :)
costaclt
Denis BRAUSSEN wrote:
Pourquoi ceux qui font frontpage et Cie se soucieraient de faire des
trucs légers qui peuvent même être vus sur des petites configs? Leur
but est de vendre. Or le tiers-monde n'a pas de fric pour payer...
Bah, si tu cherches les sites médicaux sur la polio - qui est très
"tendance" en Afrique en ce moment - tu vas tomber sur des trucs
imbitables avec une petite configuration. Pourtant, ils n'ont rien à
vendre.
Rien que de penser aux institutions qui te proposent de télécharger des
fichiers word, au lieu de pdf ou ps...
Pourtant, il suffit de rechercher dans les archives des trucs du genre
"abandonwares", "logiciels pour ms-dos" etc. et tu vois que le posteur
vit en Afrique. Il semble donc y avoir un réel problème.
Tu mets plein de contrôles BSA sur les particuliers afin qu'ils virent
ce qu'ils ont piraté, et le sujet du light et du libre va vite
apparaître comme fondamental :)
Pourquoi ceux qui font frontpage et Cie se soucieraient de faire des trucs légers qui peuvent même être vus sur des petites configs? Leur but est de vendre. Or le tiers-monde n'a pas de fric pour payer...
Bah, si tu cherches les sites médicaux sur la polio - qui est très "tendance" en Afrique en ce moment - tu vas tomber sur des trucs imbitables avec une petite configuration. Pourtant, ils n'ont rien à vendre.
Rien que de penser aux institutions qui te proposent de télécharger des fichiers word, au lieu de pdf ou ps...
Pourtant, il suffit de rechercher dans les archives des trucs du genre "abandonwares", "logiciels pour ms-dos" etc. et tu vois que le posteur vit en Afrique. Il semble donc y avoir un réel problème.
Tu mets plein de contrôles BSA sur les particuliers afin qu'ils virent ce qu'ils ont piraté, et le sujet du light et du libre va vite apparaître comme fondamental :)
costaclt
Michel BILLAUD
j writes:
Le Sat, 26 Jun 2004 09:35:34 +0200 après l'an de grâce, inspiré(e) David MAREC écrivait la plume légère :
Bon, revenons au troll de base: Le «C» est-il un langage évolué ? -Ah, je vois que ça a pris assez rapidement sur ce fil.-
Pffff, il n'y a pas de langages évolués, il n'y a que des developpeurs évolués:) Le développeur évolué choisis son langage en fonction des objectifs à atteindre, - le C pour avoir un code proche de la machine ou aller vite, (...)
Et si les objectifs à atteindre c'est de faire du code qui soit maintenable par l'équipe de bras cassés qui ne sait programmer qu'en X ou Y, alors que Z lui paraitrait infiniment mieuxsi il n'y avait que lui, il choisit X ou Y.
Est-ce vraiment un choix ?
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
j <constern@tiOn.net> writes:
Le Sat, 26 Jun 2004 09:35:34 +0200 après l'an de grâce, inspiré(e)
David MAREC <dmarec.spam@spambox.invalid> écrivait la plume légère :
Bon, revenons au troll de base:
Le «C» est-il un langage évolué ?
-Ah, je vois que ça a pris assez rapidement sur ce fil.-
Pffff, il n'y a pas de langages évolués, il n'y a que des developpeurs
évolués:)
Le développeur évolué choisis son langage en fonction des objectifs à
atteindre,
- le C pour avoir un code proche de la machine ou aller vite,
(...)
Et si les objectifs à atteindre c'est de faire du code qui soit
maintenable par l'équipe de bras cassés qui ne sait programmer qu'en X
ou Y, alors que Z lui paraitrait infiniment mieuxsi il n'y avait que
lui, il choisit X ou Y.
Est-ce vraiment un choix ?
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Le Sat, 26 Jun 2004 09:35:34 +0200 après l'an de grâce, inspiré(e) David MAREC écrivait la plume légère :
Bon, revenons au troll de base: Le «C» est-il un langage évolué ? -Ah, je vois que ça a pris assez rapidement sur ce fil.-
Pffff, il n'y a pas de langages évolués, il n'y a que des developpeurs évolués:) Le développeur évolué choisis son langage en fonction des objectifs à atteindre, - le C pour avoir un code proche de la machine ou aller vite, (...)
Et si les objectifs à atteindre c'est de faire du code qui soit maintenable par l'équipe de bras cassés qui ne sait programmer qu'en X ou Y, alors que Z lui paraitrait infiniment mieuxsi il n'y avait que lui, il choisit X ou Y.
Est-ce vraiment un choix ?
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
j
Le 27 Jun 2004 19:01:13 +0200 après l'an de grâce, inspiré(e) Michel BILLAUD écrivait la plume légère :
j writes:
Le Sat, 26 Jun 2004 09:35:34 +0200 après l'an de grâce, inspiré (e) David MAREC écrivait la plume légèr e :
Bon, revenons au troll de base: Le «C» est-il un langage évolué ? -Ah, je vois que ça a pris assez rapidement sur ce fil.-
Pffff, il n'y a pas de langages évolués, il n'y a que des developpeurs évolués:) Le développeur évolué choisis son langage en fonction des objecti fs à atteindre, - le C pour avoir un code proche de la machine ou aller vite, (...)
Et si les objectifs à atteindre c'est de faire du code qui soit maintenable par l'équipe de bras cassés qui ne sait programmer qu'en X ou Y, alors que Z lui paraitrait infiniment mieuxsi il n'y avait que lui, il choisit X ou Y.
Est-ce vraiment un choix ? Ben, ça s'appelle le métier, le meilleur choix dans l'absolu n'existant
pas, on demande au «professionnel» de prendre même ces facteurs là en compte pour trouver un optimum, qui est rarement le meilleur choix «technique».
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
-- The reason people sweat is so they won't catch fire when making love. -- Don Rose
Le 27 Jun 2004 19:01:13 +0200 après l'an de grâce, inspiré(e) Michel
BILLAUD <billaud@labri.u-bordeaux.fr> écrivait la plume légère :
j <constern@tiOn.net> writes:
Le Sat, 26 Jun 2004 09:35:34 +0200 après l'an de grâce, inspiré (e)
David MAREC <dmarec.spam@spambox.invalid> écrivait la plume légèr e :
Bon, revenons au troll de base:
Le «C» est-il un langage évolué ?
-Ah, je vois que ça a pris assez rapidement sur ce fil.-
Pffff, il n'y a pas de langages évolués, il n'y a que des
developpeurs évolués:)
Le développeur évolué choisis son langage en fonction des objecti fs
à atteindre,
- le C pour avoir un code proche de la machine ou aller vite,
(...)
Et si les objectifs à atteindre c'est de faire du code qui soit
maintenable par l'équipe de bras cassés qui ne sait programmer qu'en X
ou Y, alors que Z lui paraitrait infiniment mieuxsi il n'y avait que
lui, il choisit X ou Y.
Est-ce vraiment un choix ?
Ben, ça s'appelle le métier, le meilleur choix dans l'absolu n'existant
pas, on demande au «professionnel» de prendre même ces facteurs là en
compte pour trouver un optimum, qui est rarement le meilleur choix
«technique».
Et perso je trouve que du fortran 77 de physicien encore en
vie, est plus une preuve de professionnalisme que du camel ou du lisp
d'informaticien univiersitaire qui est à la poubelle.
--
The reason people sweat is so they won't catch fire when making love.
-- Don Rose
Le 27 Jun 2004 19:01:13 +0200 après l'an de grâce, inspiré(e) Michel BILLAUD écrivait la plume légère :
j writes:
Le Sat, 26 Jun 2004 09:35:34 +0200 après l'an de grâce, inspiré (e) David MAREC écrivait la plume légèr e :
Bon, revenons au troll de base: Le «C» est-il un langage évolué ? -Ah, je vois que ça a pris assez rapidement sur ce fil.-
Pffff, il n'y a pas de langages évolués, il n'y a que des developpeurs évolués:) Le développeur évolué choisis son langage en fonction des objecti fs à atteindre, - le C pour avoir un code proche de la machine ou aller vite, (...)
Et si les objectifs à atteindre c'est de faire du code qui soit maintenable par l'équipe de bras cassés qui ne sait programmer qu'en X ou Y, alors que Z lui paraitrait infiniment mieuxsi il n'y avait que lui, il choisit X ou Y.
Est-ce vraiment un choix ? Ben, ça s'appelle le métier, le meilleur choix dans l'absolu n'existant
pas, on demande au «professionnel» de prendre même ces facteurs là en compte pour trouver un optimum, qui est rarement le meilleur choix «technique».
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
-- The reason people sweat is so they won't catch fire when making love. -- Don Rose
costaclt
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran (CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
costaclt
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en
vie, est plus une preuve de professionnalisme que du camel ou du lisp
d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran
(CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran (CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
costaclt
JKB
Le 28-06-2004, à propos de Re: Fichier Windows et matériel Linux, costaclt écrivait dans fr.comp.os.linux.debats :
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran (CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Normal, c'est fait pour... Et c'est un peu plus fiable que inénarrable C++, car il est très difficile de se tirer une balle dans le pied en Fortran (même 9x) !
JKB
Le 28-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
costaclt écrivait dans fr.comp.os.linux.debats :
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en
vie, est plus une preuve de professionnalisme que du camel ou du lisp
d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran
(CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Normal, c'est fait pour... Et c'est un peu plus fiable que
inénarrable C++, car il est très difficile de se tirer une balle
dans le pied en Fortran (même 9x) !
Le 28-06-2004, à propos de Re: Fichier Windows et matériel Linux, costaclt écrivait dans fr.comp.os.linux.debats :
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran (CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Normal, c'est fait pour... Et c'est un peu plus fiable que inénarrable C++, car il est très difficile de se tirer une balle dans le pied en Fortran (même 9x) !
JKB
talon
costaclt wrote:
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran (CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Sans parler des physiciens, qui n'utilisent guère que ça. L'un des avantages est qu'il existe d'énormes librairies de programmes trés efficaces et parfaitement débuggués, donc inutile de dire qu'il vaut mieux éviter de réinventer la roue. Il est trés possible d'utiliser ces librairies sans pour autant programmer en Fortran. Par exemple scilab est constitué d'un langage de commande plus des wrappers autour de tels programmes, et permet de faire des calculs sans écrire une ligne de Fortran, et je suppose que Matlab c'est exactement pareil. Plus intéressant il y a une forte communauté qui utilise python pour "enrober" les programmes Fortran classiques. Ce qui permet d'utiliser le formidable langage qu'est python, tout en laissant la partie intensive en calcul à des programme de librairie. Python a des outils trés bien pour faire cet enrobage tels que f2py. Le site principal est http://www.scipy.org/ qui donne d'ailleurs l'exemple d'un site en plone, bien naturel pour des gens qui pratiquent python. Pour ceux qui douteraient de la différence de performance entre un langage interprété et un langage compilé (voire compilé jit), http://www.scipy.org/documentation/weave/weaveperformance.html est fort intéressant:
Type of solution Time taken (sec) Slow python (estimate) 1897.0 Numeric 29.0 Blitz 10.2 Inline 4.3 Fast Inline 2.9 Python/Fortran 3.2 Pure C++ 2.4
Il s'agit là d'un calcul simple mais réaliste ... Mis à part le "slow python" où le calcul est entièrement effectué en python interprété, tout le reste correspond à des choses plus ou moins précompilées, le python/fortran correspondant à la boucle principale de calcul en fortran, tout le reste en python, tandis que Inline et FastInline ont la boucle principale en C.
costaclt
--
Michel TALON
costaclt <costaclt@wanadoo.fr> wrote:
j wrote:
Et perso je trouve que du fortran 77 de physicien encore en
vie, est plus une preuve de professionnalisme que du camel ou du lisp
d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran
(CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Sans parler des physiciens, qui n'utilisent guère que ça. L'un des
avantages est qu'il existe d'énormes librairies de programmes trés
efficaces et parfaitement débuggués, donc inutile de dire qu'il vaut
mieux éviter de réinventer la roue. Il est trés possible d'utiliser ces
librairies sans pour autant programmer en Fortran. Par exemple
scilab est constitué d'un langage de commande plus des wrappers autour
de tels programmes, et permet de faire des calculs sans écrire une ligne
de Fortran, et je suppose que Matlab c'est exactement pareil. Plus
intéressant il y a une forte communauté qui utilise python pour
"enrober" les programmes Fortran classiques. Ce qui permet d'utiliser le
formidable langage qu'est python, tout en laissant la partie intensive
en calcul à des programme de librairie. Python a des outils trés bien
pour faire cet enrobage tels que f2py. Le site principal est
http://www.scipy.org/
qui donne d'ailleurs l'exemple d'un site en plone, bien naturel pour des
gens qui pratiquent python.
Pour ceux qui douteraient de la différence de performance entre un
langage interprété et un langage compilé (voire compilé jit),
http://www.scipy.org/documentation/weave/weaveperformance.html
est fort intéressant:
Type of solution
Time taken (sec)
Slow python (estimate)
1897.0
Numeric
29.0
Blitz
10.2
Inline
4.3
Fast Inline
2.9
Python/Fortran
3.2
Pure C++
2.4
Il s'agit là d'un calcul simple mais réaliste ...
Mis à part le "slow python" où le calcul est entièrement effectué en
python interprété, tout le reste correspond à des choses plus ou moins
précompilées, le python/fortran correspondant à la boucle principale de
calcul en fortran, tout le reste en python, tandis que Inline et
FastInline ont la boucle principale en C.
Et perso je trouve que du fortran 77 de physicien encore en vie, est plus une preuve de professionnalisme que du camel ou du lisp d'informaticien univiersitaire qui est à la poubelle.
Et le Forth. Pourquoi il est en rade ce langage ?
Effectivement, je vois encore beaucoup de gens travailler en Fortran (CEA, Pétrochimie etc.). Ca tourne, c'est rapide.
Sans parler des physiciens, qui n'utilisent guère que ça. L'un des avantages est qu'il existe d'énormes librairies de programmes trés efficaces et parfaitement débuggués, donc inutile de dire qu'il vaut mieux éviter de réinventer la roue. Il est trés possible d'utiliser ces librairies sans pour autant programmer en Fortran. Par exemple scilab est constitué d'un langage de commande plus des wrappers autour de tels programmes, et permet de faire des calculs sans écrire une ligne de Fortran, et je suppose que Matlab c'est exactement pareil. Plus intéressant il y a une forte communauté qui utilise python pour "enrober" les programmes Fortran classiques. Ce qui permet d'utiliser le formidable langage qu'est python, tout en laissant la partie intensive en calcul à des programme de librairie. Python a des outils trés bien pour faire cet enrobage tels que f2py. Le site principal est http://www.scipy.org/ qui donne d'ailleurs l'exemple d'un site en plone, bien naturel pour des gens qui pratiquent python. Pour ceux qui douteraient de la différence de performance entre un langage interprété et un langage compilé (voire compilé jit), http://www.scipy.org/documentation/weave/weaveperformance.html est fort intéressant:
Type of solution Time taken (sec) Slow python (estimate) 1897.0 Numeric 29.0 Blitz 10.2 Inline 4.3 Fast Inline 2.9 Python/Fortran 3.2 Pure C++ 2.4
Il s'agit là d'un calcul simple mais réaliste ... Mis à part le "slow python" où le calcul est entièrement effectué en python interprété, tout le reste correspond à des choses plus ou moins précompilées, le python/fortran correspondant à la boucle principale de calcul en fortran, tout le reste en python, tandis que Inline et FastInline ont la boucle principale en C.
costaclt
--
Michel TALON
Alain Labarthe
Le 25-06-2004, Emmanuel Florac écrivait:
Le Fri, 25 Jun 2004 08:14:42 +0000, Michel Talon a écrit :
Et même si tu es Emmanuel l'extra lucide, quid si ton client veut foutre lui même son nez dans ton programme?
Merde, dire que j'ai deux clients qui mettent le nez dans ce foutu code presque aussi souvent que moi et me proposent parfois des modifs, ça doit être de vrais surhommes.
Ouais mais toi aussi t'es tricheur, chuis sûr que tu commentes ton code, petit joueur !
-- apt-get --purge remove Bush
Le 25-06-2004, Emmanuel Florac écrivait:
Le Fri, 25 Jun 2004 08:14:42 +0000, Michel Talon a écrit :
Et même si tu es Emmanuel l'extra lucide, quid si ton client
veut foutre lui même son nez dans ton programme?
Merde, dire que j'ai deux clients qui mettent le nez dans ce foutu code
presque aussi souvent que moi et me proposent parfois des modifs, ça doit
être de vrais surhommes.
Ouais mais toi aussi t'es tricheur, chuis sûr que tu commentes ton
code, petit joueur !
Le Fri, 25 Jun 2004 08:14:42 +0000, Michel Talon a écrit :
Et même si tu es Emmanuel l'extra lucide, quid si ton client veut foutre lui même son nez dans ton programme?
Merde, dire que j'ai deux clients qui mettent le nez dans ce foutu code presque aussi souvent que moi et me proposent parfois des modifs, ça doit être de vrais surhommes.
Ouais mais toi aussi t'es tricheur, chuis sûr que tu commentes ton code, petit joueur !
-- apt-get --purge remove Bush
Alain Labarthe
Le 24-06-2004, Michel Talon écrivait:
Michel BILLAUD wrote:
C'est ce qui sert à faire ton bulletin de paie.
Oui, et? Ca prouverait que l'éducation nationale ou le CNRS ont des services administratifs antédiluviens, et quoi d'autre? En tout cas je peux te dire que là où travaille ma femme la totalité de la comptabilité est sous SAP(*), et que personne n'y a jamais vu une ligne de COBOL.
Antédiluviens peut-être mais si ça marche ?
(*) ce qui ne veut pas dire que SAP est le fin du fin, bien entendu.
Non, SAP c'est le top of the top, tout le monde sait cela !
-- apt-get --purge remove Bush
Le 24-06-2004, Michel Talon écrivait:
Michel BILLAUD <billaud@labri.u-bordeaux.fr> wrote:
C'est ce qui sert à faire ton bulletin de paie.
Oui, et? Ca prouverait que l'éducation nationale ou le CNRS ont des
services administratifs antédiluviens, et quoi d'autre? En tout cas je
peux te dire que là où travaille ma femme la totalité de la comptabilité
est sous SAP(*), et que personne n'y a jamais vu une ligne de COBOL.
Antédiluviens peut-être mais si ça marche ?
(*) ce qui ne veut pas dire que SAP est le fin du fin, bien entendu.
Non, SAP c'est le top of the top, tout le monde sait cela !
Oui, et? Ca prouverait que l'éducation nationale ou le CNRS ont des services administratifs antédiluviens, et quoi d'autre? En tout cas je peux te dire que là où travaille ma femme la totalité de la comptabilité est sous SAP(*), et que personne n'y a jamais vu une ligne de COBOL.
Antédiluviens peut-être mais si ça marche ?
(*) ce qui ne veut pas dire que SAP est le fin du fin, bien entendu.
Non, SAP c'est le top of the top, tout le monde sait cela !
-- apt-get --purge remove Bush
Manuel Leclerc
Pure mauvaise fois. Comportement indéfini, concrètement ça veut dire par exemple écriture de n'importe quoi n'importe où dans la mémoire adressable et writable du process sans aucune segmentation fault, exécution de n'importe quel bout de code exécutable du process, etc...
Il y a des débuggers pour protéger ça.
Pour debugger, les debuggers, ça peut aider. Oui. Dans tous les langages. Et alors ?
Le fait qu'une bug dans un source puisse se traduire par "n'importe quoi, n'importe où, n'importe quand" EXCLUE définitivement, et sans appel, le C de la catégorie "langage évolué".
Je résume : on s'en tape.
On commence à le savoir, que tu te fous de l'efficacité des programmes. Heureusement, tout le monde n'est pas comme toi.
Ca vole bas. On parle de C et de langage "évolué". Tu me causes du coût des vérifications d'indices. Je réponds "on s'en tape". Je maintiens.
Pour ce qui est de l'efficacité, maintenant, n'importe quel programme un peu gros manipulant des chaînes de caractères en C est truffé de code comptant les caractères pour vérifier que ça va passer et/ou utilise l'allocation dynamique. Que ce soit plus "efficace" qu'un mécanisme "built-in" se discute, pour le moins.
D'autant plus que l'efficacité est une notion bien vague. Bref, dire que je m'en fous, c'est un peu à côté de la plaque.
-- As to whether DRM is bad for Microsoft, I will leave that to Microsoft to decide. --Jerry Pournelle
Pure mauvaise fois. Comportement indéfini, concrètement
ça veut dire par exemple écriture de n'importe quoi
n'importe où dans la mémoire adressable et writable du
process sans aucune segmentation fault, exécution de
n'importe quel bout de code exécutable du process, etc...
Il y a des débuggers pour protéger ça.
Pour debugger, les debuggers, ça peut aider. Oui. Dans tous
les langages. Et alors ?
Le fait qu'une bug dans un source puisse se traduire par
"n'importe quoi, n'importe où, n'importe quand" EXCLUE
définitivement, et sans appel, le C de la catégorie
"langage évolué".
Je résume : on s'en tape.
On commence à le savoir, que tu te fous de l'efficacité des
programmes. Heureusement, tout le monde n'est pas comme toi.
Ca vole bas. On parle de C et de langage "évolué". Tu me
causes du coût des vérifications d'indices. Je réponds "on s'en
tape". Je maintiens.
Pour ce qui est de l'efficacité, maintenant, n'importe quel
programme un peu gros manipulant des chaînes de caractères
en C est truffé de code comptant les caractères pour
vérifier que ça va passer et/ou utilise l'allocation dynamique.
Que ce soit plus "efficace" qu'un mécanisme "built-in" se
discute, pour le moins.
D'autant plus que l'efficacité est une notion bien vague.
Bref, dire que je m'en fous, c'est un peu à côté de la plaque.
--
As to whether DRM is bad for Microsoft, I will leave that to Microsoft
to decide.
--Jerry Pournelle
Pure mauvaise fois. Comportement indéfini, concrètement ça veut dire par exemple écriture de n'importe quoi n'importe où dans la mémoire adressable et writable du process sans aucune segmentation fault, exécution de n'importe quel bout de code exécutable du process, etc...
Il y a des débuggers pour protéger ça.
Pour debugger, les debuggers, ça peut aider. Oui. Dans tous les langages. Et alors ?
Le fait qu'une bug dans un source puisse se traduire par "n'importe quoi, n'importe où, n'importe quand" EXCLUE définitivement, et sans appel, le C de la catégorie "langage évolué".
Je résume : on s'en tape.
On commence à le savoir, que tu te fous de l'efficacité des programmes. Heureusement, tout le monde n'est pas comme toi.
Ca vole bas. On parle de C et de langage "évolué". Tu me causes du coût des vérifications d'indices. Je réponds "on s'en tape". Je maintiens.
Pour ce qui est de l'efficacité, maintenant, n'importe quel programme un peu gros manipulant des chaînes de caractères en C est truffé de code comptant les caractères pour vérifier que ça va passer et/ou utilise l'allocation dynamique. Que ce soit plus "efficace" qu'un mécanisme "built-in" se discute, pour le moins.
D'autant plus que l'efficacité est une notion bien vague. Bref, dire que je m'en fous, c'est un peu à côté de la plaque.
-- As to whether DRM is bad for Microsoft, I will leave that to Microsoft to decide. --Jerry Pournelle
Richard Delorme
Après, que le programme meure sur une segmentation fault ou une out-of-bounds-exception, c'est bonnet blanc et blanc bonnet.
Pure mauvaise fois. Comportement indéfini, concrètement ça veut dire par exemple écriture de n'importe quoi n'importe où dans la mémoire adressable et writable du process sans aucune segmentation fault, exécution de n'importe quel bout de code exécutable du process, etc...
3.4.3 1 *undefined behavior* behavior, upon use of a nonportable or erroneous program construct or of erroneous data for which this International Standard imposes no requirements
En clair et en français, un comportement indéfini veut juste dire que le Standard n'en a rien à battre des programmes erronés ou des programmes non portables. Maintenant, si on écrit un programme correct, où est le problème ?
-- Richard
Après, que le programme meure sur une segmentation fault
ou une out-of-bounds-exception, c'est bonnet blanc et
blanc bonnet.
Pure mauvaise fois. Comportement indéfini, concrètement
ça veut dire par exemple écriture de n'importe quoi
n'importe où dans la mémoire adressable et writable du
process sans aucune segmentation fault, exécution de
n'importe quel bout de code exécutable du process, etc...
3.4.3
1 *undefined behavior*
behavior, upon use of a nonportable or erroneous program
construct or of erroneous data for which this International
Standard imposes no requirements
En clair et en français, un comportement indéfini veut juste dire que le
Standard n'en a rien à battre des programmes erronés ou des programmes
non portables.
Maintenant, si on écrit un programme correct, où est le problème ?
Après, que le programme meure sur une segmentation fault ou une out-of-bounds-exception, c'est bonnet blanc et blanc bonnet.
Pure mauvaise fois. Comportement indéfini, concrètement ça veut dire par exemple écriture de n'importe quoi n'importe où dans la mémoire adressable et writable du process sans aucune segmentation fault, exécution de n'importe quel bout de code exécutable du process, etc...
3.4.3 1 *undefined behavior* behavior, upon use of a nonportable or erroneous program construct or of erroneous data for which this International Standard imposes no requirements
En clair et en français, un comportement indéfini veut juste dire que le Standard n'en a rien à battre des programmes erronés ou des programmes non portables. Maintenant, si on écrit un programme correct, où est le problème ?
