Maintenant, il me semble que dans ce thread, on a aussi débattu de concept comme d'oeillères et d'ouverture d'esprit..
Désolé d'avoir relancé la machine (virtuelle) à troll... qui elle ne rame pas comme du Java ;-)
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand même de faire d'éviter la main mise de MS et c'est ce que j'essaye de faire comprendre à d'autres (y compris sur microsoft.public.fr.dotnet.csharp)
Si les gens veulent du multiplateforme qu'il se limite aux fonctionnalités de Mono... et donc qu'ils codent sous Linux pour ne pas être tenté...
Le risque c'est de voir apparaitre des développeurs disant : "je fais du .Net donc ça marchera sous Linux grâce à Mono"... je pense qu'il faut qu'ils prennent le problème dans l'autre sens : "je veux faire du multiplateforme, je veux pas trop m'emmerder, je fais du C# et j'utilise Mono et Linux pour développer... de toute façon ça tournera sous Windows puisque Mono y est porté..."
Le problème est le même avec Java : il faut se restreindre aux (très/trop nombreuses) implémentations libres et surtout à ce qu'elles nous propose...
Maintenant, il me semble que dans ce thread, on a aussi débattu de
concept comme d'oeillères et d'ouverture d'esprit..
Désolé d'avoir relancé la machine (virtuelle) à troll... qui elle ne
rame pas comme du Java ;-)
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand
même de faire d'éviter la main mise de MS et c'est ce que j'essaye de
faire comprendre à d'autres (y compris sur
microsoft.public.fr.dotnet.csharp)
Si les gens veulent du multiplateforme qu'il se limite aux
fonctionnalités de Mono... et donc qu'ils codent sous Linux pour ne pas
être tenté...
Le risque c'est de voir apparaitre des développeurs disant : "je fais du
.Net donc ça marchera sous Linux grâce à Mono"... je pense qu'il faut
qu'ils prennent le problème dans l'autre sens : "je veux faire du
multiplateforme, je veux pas trop m'emmerder, je fais du C# et j'utilise
Mono et Linux pour développer... de toute façon ça tournera sous Windows
puisque Mono y est porté..."
Le problème est le même avec Java : il faut se restreindre aux
(très/trop nombreuses) implémentations libres et surtout à ce qu'elles
nous propose...
Maintenant, il me semble que dans ce thread, on a aussi débattu de concept comme d'oeillères et d'ouverture d'esprit..
Désolé d'avoir relancé la machine (virtuelle) à troll... qui elle ne rame pas comme du Java ;-)
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand même de faire d'éviter la main mise de MS et c'est ce que j'essaye de faire comprendre à d'autres (y compris sur microsoft.public.fr.dotnet.csharp)
Si les gens veulent du multiplateforme qu'il se limite aux fonctionnalités de Mono... et donc qu'ils codent sous Linux pour ne pas être tenté...
Le risque c'est de voir apparaitre des développeurs disant : "je fais du .Net donc ça marchera sous Linux grâce à Mono"... je pense qu'il faut qu'ils prennent le problème dans l'autre sens : "je veux faire du multiplateforme, je veux pas trop m'emmerder, je fais du C# et j'utilise Mono et Linux pour développer... de toute façon ça tournera sous Windows puisque Mono y est porté..."
Le problème est le même avec Java : il faut se restreindre aux (très/trop nombreuses) implémentations libres et surtout à ce qu'elles nous propose...
Eric Jacoboni
"" writes:
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand même de faire d'éviter la main mise de MS et c'est ce que j'essaye de faire comprendre à d'autres (y compris sur microsoft.public.fr.dotnet.csharp)
Sauf que pour disposer de GTK# t'es bon pour installer la moitié des bibliothèques de Gnome... si elles veulent bien se compiler sur ton système, ce qui n'est pas joué.
Et tout ça pour avoir une interface moche.
-- Éric Jacoboni, né il y a 1420912886 secondes
"noone@nowhere.com" <noone@nowhere.com> writes:
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet
quand même de faire d'éviter la main mise de MS et c'est ce que
j'essaye de faire comprendre à d'autres (y compris sur
microsoft.public.fr.dotnet.csharp)
Sauf que pour disposer de GTK# t'es bon pour installer la moitié des
bibliothèques de Gnome... si elles veulent bien se compiler sur ton
système, ce qui n'est pas joué.
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand même de faire d'éviter la main mise de MS et c'est ce que j'essaye de faire comprendre à d'autres (y compris sur microsoft.public.fr.dotnet.csharp)
Sauf que pour disposer de GTK# t'es bon pour installer la moitié des bibliothèques de Gnome... si elles veulent bien se compiler sur ton système, ce qui n'est pas joué.
Et tout ça pour avoir une interface moche.
-- Éric Jacoboni, né il y a 1420912886 secondes
remi_inconnu
L'objectif n'est pas le produit final mais l'apprentissage de la programmation.
Alors le C, c'est pas mal.
Il y a a peu près unanimité sur fclc pour dire NON à cette affirmat ion. « Le C n'est pas un langage pour débutant » y est souvent affirm é. Manipuler correctement les I/O et les chaines de caractères est extraordinairement difficile, et c'est souvent ce que souhaite manipuler en premier un débutant. Une fois tout cela appris, on peut aussi être déçu des possibilités limités du langage.
La programmation en C, j'ai vu ce que cela donnait chez une personne non informaticienne (ma femme), et je dois dire que c'est catastrophique, le C est rempli de peau de bananes (c'est pire encore avec le C++), il faut vraiment avoir une formation sur ce langage pour parfaitement le comprendre, il peut sembler facile au premier abord, mais quand l'application grandit et que l'on n'a pas fait été propre dans la programmation, alors les bugs seront nombreux, imprévisibles et très très difficiles à localiser.
Pour l'apprentissage/enseignement, il est presque aussi bien que le Pascal. Par contre, il faut commencer par un bouquin *didactique* (et pas le K&R, qui est, certes, la référence du langage, mais qui n'a rien de pédagogique).
Là aussi, je pense le contraire. Le K&R est d'une telle qualité qu'il justifie à lui seul l'intérêt d'apprendre le C. C'est un livre tr ès concis et pourtant très riche algorithmiquement parlant.
Les langages genre Python ou Java sont trop complexes pour être appréhendés sans une première approche de la programmation par un langage non-objet. Commencer par eux, ce serait risquer d'appliquer des recettes sans comprendre les choses.
Je suis assez d'accord pour Java, mais pas pour Python. Java nécessite de comprendre un nombre important de concept avant de pouvoir démarrer un premier programme. Par contre Python est un langage avec une excellente scalabilité d'apprentissage. On n'a même pas besoin du concept de fonction/routine pour commencer à faire des programmes qui marchent. Ensuite, on peut, petit à petit apprendre quasiment tous les concepts de la programmation : programmation structurée, modulaire, objet, générique, fonctionnel avec un même langage. Ajouter à cel a une syntaxe très simple, des bibliothèques riches, un langage de haut niv eau très expressif, on a tout pour plaire au débutant. Le seul défaut de Python est dans les performances obtenues, mais est-ce important pour débuter à programmer ?
Les performances sont loin d'être aussi mauvaise que tu le dis, généralement les goulots d'étranglement sont connus, notament la concaténation de chaines, de plus le langage intègre un profiler, très simple à mettre en oeuvre, et quand tu localises le goulot, tu arrives alors facilement à le faire sauter.
A titre d'info j'avais un programme dont le temps de traitement pouvais atteindre plusieurs heures, après passage au profiler et optimisation, j'ai réussi à le faire passer à quelques minutes. Si je l'avais écrit directement en C++, je n'aurais pas une performance meilleure (si l'on manipule des chaines avec les STL les performances ne sont pas mirobolante en C++), mais par contre un temps 10 fois supérieur pour le développer, c'est aussi cela la performance du langage python : diviser le temps de développement d'une appli par 5 ou 10 par rapport à une appli en C++ ou Java... ;-)
-- Richard
L'objectif n'est pas le produit final mais l'apprentissage de la
programmation.
Alors le C, c'est pas mal.
Il y a a peu près unanimité sur fclc pour dire NON à cette affirmat ion.
« Le C n'est pas un langage pour débutant » y est souvent affirm é.
Manipuler correctement les I/O et les chaines de caractères est
extraordinairement difficile, et c'est souvent ce que souhaite manipuler
en premier un débutant. Une fois tout cela appris, on peut aussi être
déçu des possibilités limités du langage.
La programmation en C, j'ai vu ce que cela donnait chez une personne
non informaticienne (ma femme), et je dois dire que c'est
catastrophique, le C est rempli de peau de bananes (c'est pire encore
avec le C++), il faut vraiment avoir une formation sur ce langage pour
parfaitement le comprendre, il peut sembler facile au premier abord,
mais quand l'application grandit et que l'on n'a pas fait été propre
dans la programmation, alors les bugs seront nombreux, imprévisibles
et très très difficiles à localiser.
Pour l'apprentissage/enseignement, il est presque aussi bien que le
Pascal. Par contre, il faut commencer par un bouquin *didactique* (et
pas le K&R, qui est, certes, la référence du langage, mais qui n'a rien
de pédagogique).
Là aussi, je pense le contraire. Le K&R est d'une telle qualité qu'il
justifie à lui seul l'intérêt d'apprendre le C. C'est un livre tr ès
concis et pourtant très riche algorithmiquement parlant.
Les langages genre Python ou Java sont trop complexes pour être
appréhendés sans une première approche de la programmation par
un langage non-objet. Commencer par eux, ce serait risquer d'appliquer
des recettes sans comprendre les choses.
Je suis assez d'accord pour Java, mais pas pour Python. Java nécessite
de comprendre un nombre important de concept avant de pouvoir démarrer
un premier programme. Par contre Python est un langage avec une
excellente scalabilité d'apprentissage. On n'a même pas besoin du
concept de fonction/routine pour commencer à faire des programmes qui
marchent. Ensuite, on peut, petit à petit apprendre quasiment tous les
concepts de la programmation : programmation structurée, modulaire,
objet, générique, fonctionnel avec un même langage. Ajouter à cel a une
syntaxe très simple, des bibliothèques riches, un langage de haut niv eau
très expressif, on a tout pour plaire au débutant. Le seul défaut de
Python est dans les performances obtenues, mais est-ce important pour
débuter à programmer ?
Les performances sont loin d'être aussi mauvaise que tu le dis,
généralement les goulots d'étranglement sont connus, notament la
concaténation de chaines, de plus le langage intègre un profiler,
très simple à mettre en oeuvre, et quand tu localises le goulot, tu
arrives alors facilement à le faire sauter.
A titre d'info j'avais un programme dont le temps de traitement pouvais
atteindre plusieurs heures, après passage au profiler et optimisation,
j'ai réussi à le faire passer à quelques minutes. Si je l'avais
écrit directement en C++, je n'aurais pas une performance meilleure
(si l'on manipule des chaines avec les STL les performances ne sont pas
mirobolante en C++), mais par contre un temps 10 fois supérieur pour
le développer, c'est aussi cela la performance du langage python :
diviser le temps de développement d'une appli par 5 ou 10 par rapport
à une appli en C++ ou Java... ;-)
L'objectif n'est pas le produit final mais l'apprentissage de la programmation.
Alors le C, c'est pas mal.
Il y a a peu près unanimité sur fclc pour dire NON à cette affirmat ion. « Le C n'est pas un langage pour débutant » y est souvent affirm é. Manipuler correctement les I/O et les chaines de caractères est extraordinairement difficile, et c'est souvent ce que souhaite manipuler en premier un débutant. Une fois tout cela appris, on peut aussi être déçu des possibilités limités du langage.
La programmation en C, j'ai vu ce que cela donnait chez une personne non informaticienne (ma femme), et je dois dire que c'est catastrophique, le C est rempli de peau de bananes (c'est pire encore avec le C++), il faut vraiment avoir une formation sur ce langage pour parfaitement le comprendre, il peut sembler facile au premier abord, mais quand l'application grandit et que l'on n'a pas fait été propre dans la programmation, alors les bugs seront nombreux, imprévisibles et très très difficiles à localiser.
Pour l'apprentissage/enseignement, il est presque aussi bien que le Pascal. Par contre, il faut commencer par un bouquin *didactique* (et pas le K&R, qui est, certes, la référence du langage, mais qui n'a rien de pédagogique).
Là aussi, je pense le contraire. Le K&R est d'une telle qualité qu'il justifie à lui seul l'intérêt d'apprendre le C. C'est un livre tr ès concis et pourtant très riche algorithmiquement parlant.
Les langages genre Python ou Java sont trop complexes pour être appréhendés sans une première approche de la programmation par un langage non-objet. Commencer par eux, ce serait risquer d'appliquer des recettes sans comprendre les choses.
Je suis assez d'accord pour Java, mais pas pour Python. Java nécessite de comprendre un nombre important de concept avant de pouvoir démarrer un premier programme. Par contre Python est un langage avec une excellente scalabilité d'apprentissage. On n'a même pas besoin du concept de fonction/routine pour commencer à faire des programmes qui marchent. Ensuite, on peut, petit à petit apprendre quasiment tous les concepts de la programmation : programmation structurée, modulaire, objet, générique, fonctionnel avec un même langage. Ajouter à cel a une syntaxe très simple, des bibliothèques riches, un langage de haut niv eau très expressif, on a tout pour plaire au débutant. Le seul défaut de Python est dans les performances obtenues, mais est-ce important pour débuter à programmer ?
Les performances sont loin d'être aussi mauvaise que tu le dis, généralement les goulots d'étranglement sont connus, notament la concaténation de chaines, de plus le langage intègre un profiler, très simple à mettre en oeuvre, et quand tu localises le goulot, tu arrives alors facilement à le faire sauter.
A titre d'info j'avais un programme dont le temps de traitement pouvais atteindre plusieurs heures, après passage au profiler et optimisation, j'ai réussi à le faire passer à quelques minutes. Si je l'avais écrit directement en C++, je n'aurais pas une performance meilleure (si l'on manipule des chaines avec les STL les performances ne sont pas mirobolante en C++), mais par contre un temps 10 fois supérieur pour le développer, c'est aussi cela la performance du langage python : diviser le temps de développement d'une appli par 5 ou 10 par rapport à une appli en C++ ou Java... ;-)
-- Richard
Antonio Bravo
Den Mon, 30 May 2005 18:02:55 +0200, skrev Eric Jacoboni:
"" writes:
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand même de faire d'éviter la main mise de MS et c'est ce que j'essaye de faire comprendre à d'autres (y compris sur microsoft.public.fr.dotnet.csharp)
Sauf que pour disposer de GTK# t'es bon pour installer la moitié des bibliothèques de Gnome...
enfin! je l'attendais celle-la, et elle est venue. Si Mono avait ete ecrit par un kdesien, mais alors que c'est bieaux comme tout, que magnifique, que etc Mais c'est Icaza, alors c'est pas bien. Il y a un qt# de toutes facons.
si elles veulent bien se compiler sur ton système, ce qui n'est pas joué.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde. Par contre prends NetBSD-2, lance make dans "devel/mono" et ca plante, essaye a la main et ca plante aussi.Faut bricoler un moment pour que ca compile. Oh, pardon, netbsd c'est pas linusque!
-- "Men alt dette er ikke begyndelsen.", Knut HAMSUN,"Mysterier"- 1892 ____________________GPG/PGP key ID:0x24ADF724______________________
Den Mon, 30 May 2005 18:02:55 +0200, skrev Eric Jacoboni:
"noone@nowhere.com" <noone@nowhere.com> writes:
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet
quand même de faire d'éviter la main mise de MS et c'est ce que
j'essaye de faire comprendre à d'autres (y compris sur
microsoft.public.fr.dotnet.csharp)
Sauf que pour disposer de GTK# t'es bon pour installer la moitié des
bibliothèques de Gnome...
enfin! je l'attendais celle-la, et elle est venue.
Si Mono avait ete ecrit par un kdesien, mais alors que c'est bieaux comme
tout, que magnifique, que etc
Mais c'est Icaza, alors c'est pas bien.
Il y a un qt# de toutes facons.
si elles veulent bien se compiler sur ton
système, ce qui n'est pas joué.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Par contre prends NetBSD-2, lance make dans "devel/mono" et ca plante,
essaye a la main et ca plante aussi.Faut bricoler un moment pour que ca
compile.
Oh, pardon, netbsd c'est pas linusque!
--
"Men alt dette er ikke begyndelsen.", Knut
HAMSUN,"Mysterier"- 1892
____________________GPG/PGP key ID:0x24ADF724______________________
Den Mon, 30 May 2005 18:02:55 +0200, skrev Eric Jacoboni:
"" writes:
Sérieusement... choisir Mono et GTK# (et pas les Winforms) permet quand même de faire d'éviter la main mise de MS et c'est ce que j'essaye de faire comprendre à d'autres (y compris sur microsoft.public.fr.dotnet.csharp)
Sauf que pour disposer de GTK# t'es bon pour installer la moitié des bibliothèques de Gnome...
enfin! je l'attendais celle-la, et elle est venue. Si Mono avait ete ecrit par un kdesien, mais alors que c'est bieaux comme tout, que magnifique, que etc Mais c'est Icaza, alors c'est pas bien. Il y a un qt# de toutes facons.
si elles veulent bien se compiler sur ton système, ce qui n'est pas joué.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde. Par contre prends NetBSD-2, lance make dans "devel/mono" et ca plante, essaye a la main et ca plante aussi.Faut bricoler un moment pour que ca compile. Oh, pardon, netbsd c'est pas linusque!
-- "Men alt dette er ikke begyndelsen.", Knut HAMSUN,"Mysterier"- 1892 ____________________GPG/PGP key ID:0x24ADF724______________________
Antonio Bravo
Den Mon, 30 May 2005 18:25:04 +0200, skrev :
Et tout ça pour avoir une interface moche.
moche... mais libre ;-)
quoi que je préfère le dépouillement de GNOME au KDEzeries....
Encore un troll ?
non, un trolltech :)
Non il faut arrêter on n'est qu'en début de semaine ;-)
-- "Men alt dette er ikke begyndelsen.", Knut HAMSUN,"Mysterier"- 1892 ____________________GPG/PGP key ID:0x24ADF724______________________
Den Mon, 30 May 2005 18:25:04 +0200, skrev noone@nowhere.com:
Et tout ça pour avoir une interface moche.
moche... mais libre ;-)
quoi que je préfère le dépouillement de GNOME au KDEzeries....
Encore un troll ?
non, un trolltech :)
Non il faut arrêter on n'est qu'en début de semaine ;-)
--
"Men alt dette er ikke begyndelsen.", Knut
HAMSUN,"Mysterier"- 1892
____________________GPG/PGP key ID:0x24ADF724______________________
quoi que je préfère le dépouillement de GNOME au KDEzeries....
Encore un troll ?
non, un trolltech :)
Non il faut arrêter on n'est qu'en début de semaine ;-)
-- "Men alt dette er ikke begyndelsen.", Knut HAMSUN,"Mysterier"- 1892 ____________________GPG/PGP key ID:0x24ADF724______________________
Eric Jacoboni
Antonio Bravo writes:
enfin! je l'attendais celle-la, et elle est venue.
Service...
Si Mono avait ete ecrit par un kdesien, mais alors que c'est bieaux comme tout, que magnifique, que etc Mais c'est Icaza, alors c'est pas bien. Il y a un qt# de toutes facons.
Je ne trouve pas QT plus beau que Gnome, hein... Les bureaux sous Unix m'ont toujours fait gerber et je ne les ait jamais utilisé.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde. Par contre prends NetBSD-2, lance make dans "devel/mono" et ca plante, essaye a la main et ca plante aussi.Faut bricoler un moment pour que ca compile.
C'est bien un avantage de Java, pour le coup : l'interface de base est moche, mais au moins elle fait partie du paquet. Après il existe des thèmes assez simplement installables pour choisir son aspect.
Oh, pardon, netbsd c'est pas linusque!
Heureusement...
-- Éric Jacoboni, né il y a 1420914553 secondes
Antonio Bravo <tonio_fuckspam@portalen.no> writes:
enfin! je l'attendais celle-la, et elle est venue.
Service...
Si Mono avait ete ecrit par un kdesien, mais alors que c'est bieaux
comme tout, que magnifique, que etc Mais c'est Icaza, alors c'est
pas bien. Il y a un qt# de toutes facons.
Je ne trouve pas QT plus beau que Gnome, hein... Les bureaux sous Unix
m'ont toujours fait gerber et je ne les ait jamais utilisé.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Par contre prends NetBSD-2, lance make dans "devel/mono" et ca plante,
essaye a la main et ca plante aussi.Faut bricoler un moment pour que ca
compile.
C'est bien un avantage de Java, pour le coup : l'interface de base est
moche, mais au moins elle fait partie du paquet. Après il existe des
thèmes assez simplement installables pour choisir son aspect.
enfin! je l'attendais celle-la, et elle est venue.
Service...
Si Mono avait ete ecrit par un kdesien, mais alors que c'est bieaux comme tout, que magnifique, que etc Mais c'est Icaza, alors c'est pas bien. Il y a un qt# de toutes facons.
Je ne trouve pas QT plus beau que Gnome, hein... Les bureaux sous Unix m'ont toujours fait gerber et je ne les ait jamais utilisé.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde. Par contre prends NetBSD-2, lance make dans "devel/mono" et ca plante, essaye a la main et ca plante aussi.Faut bricoler un moment pour que ca compile.
C'est bien un avantage de Java, pour le coup : l'interface de base est moche, mais au moins elle fait partie du paquet. Après il existe des thèmes assez simplement installables pour choisir son aspect.
Oh, pardon, netbsd c'est pas linusque!
Heureusement...
-- Éric Jacoboni, né il y a 1420914553 secondes
Miod Vallat
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Vraiment ?
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Vraiment ?
jul
Le Mon, 30 May 2005 16:50:09 +0000, Miod Vallat a écrit :
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Vraiment ?
Un gnome et un troll c'est pas le même volume. Il est clair que le gnome se compile plus aisément. Si tu veux compiler encore plus vite, passe aux gobelins.
-- Happiness isn't having what you want, it's wanting what you have.
Le Mon, 30 May 2005 16:50:09 +0000, Miod Vallat a écrit :
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Vraiment ?
Un gnome et un troll c'est pas le même volume. Il est clair que le gnome
se compile plus aisément. Si tu veux compiler encore plus vite, passe aux
gobelins.
--
Happiness isn't having what you want, it's wanting what you have.
Le Mon, 30 May 2005 16:50:09 +0000, Miod Vallat a écrit :
allons on a plus vite fait de compiler gnomelibs que le monstre qt/kde.
Vraiment ?
Un gnome et un troll c'est pas le même volume. Il est clair que le gnome se compile plus aisément. Si tu veux compiler encore plus vite, passe aux gobelins.
-- Happiness isn't having what you want, it's wanting what you have.
Denis Beauregard
Le Mon, 30 May 2005 00:29:06 +0200, "Nicolas S." écrivait dans fr.comp.os.linux.debats:
D'après vous, quel langage de programmation convient le mieux pour _débuter_ dans le domaine de l'applicatif sous Linux?
À l'époque, on apprenait avec le Basic. Je suis surpris qu'on ne trouve pas l'équivalent sous Linux (sauf les macros de Open Office).
Denis
Le Mon, 30 May 2005 00:29:06 +0200, "Nicolas S."
<ni.s-heh@laposte.net> écrivait dans fr.comp.os.linux.debats:
D'après vous, quel langage de programmation convient le mieux pour _débuter_
dans le domaine de l'applicatif sous Linux?
À l'époque, on apprenait avec le Basic. Je suis surpris qu'on ne
trouve pas l'équivalent sous Linux (sauf les macros de Open Office).
Le Mon, 30 May 2005 00:29:06 +0200, "Nicolas S." écrivait dans fr.comp.os.linux.debats:
D'après vous, quel langage de programmation convient le mieux pour _débuter_ dans le domaine de l'applicatif sous Linux?
À l'époque, on apprenait avec le Basic. Je suis surpris qu'on ne trouve pas l'équivalent sous Linux (sauf les macros de Open Office).
Denis
Richard Delorme
Richard Delorme écrivait
int main() { int c = 'ÿ';
Ça dépend du jeu de caractères utilisé par le fichier non ?
Ben oui, j'ai dit que ça dépendait de l'implémentation.
En clair, cela veut dire que le caractère 'ÿ' n'a pas la même valeur s'il est lu depuis un flux ou s'il s'agit du caractère littéral.
Ben ça dépend du dépend du jeu de caractères du flux. Ça ne concerne pas que le C ce genre de gag, c'est général.
Non, non. Le jeu de caractères du flux et du source est le même (iso-8859-1 p.ex.). Dans l'exemple que j'ai donné, si on rempace "%d %dn" par "%c %cn", on aura bien "ÿ ÿ" affiché. Le problème vient de la nature signé ou non du type char, du fait que le type du caractère littéral est un entier signé, et à l'interprétation de la façon dont la conversion doit être faite.
-- Richard
Richard Delorme écrivait
int main() {
int c = 'ÿ';
Ça dépend du jeu de caractères utilisé par le fichier non ?
Ben oui, j'ai dit que ça dépendait de l'implémentation.
En clair, cela veut dire que le caractère 'ÿ' n'a pas la même valeur
s'il est lu depuis un flux ou s'il s'agit du caractère littéral.
Ben ça dépend du dépend du jeu de caractères du flux.
Ça ne concerne pas que le C ce genre de gag, c'est général.
Non, non. Le jeu de caractères du flux et du source est le même
(iso-8859-1 p.ex.). Dans l'exemple que j'ai donné, si on rempace "%d
%dn" par "%c %cn", on aura bien "ÿ ÿ" affiché. Le problème vient de la
nature signé ou non du type char, du fait que le type du caractère
littéral est un entier signé, et à l'interprétation de la façon dont la
conversion doit être faite.
Ça dépend du jeu de caractères utilisé par le fichier non ?
Ben oui, j'ai dit que ça dépendait de l'implémentation.
En clair, cela veut dire que le caractère 'ÿ' n'a pas la même valeur s'il est lu depuis un flux ou s'il s'agit du caractère littéral.
Ben ça dépend du dépend du jeu de caractères du flux. Ça ne concerne pas que le C ce genre de gag, c'est général.
Non, non. Le jeu de caractères du flux et du source est le même (iso-8859-1 p.ex.). Dans l'exemple que j'ai donné, si on rempace "%d %dn" par "%c %cn", on aura bien "ÿ ÿ" affiché. Le problème vient de la nature signé ou non du type char, du fait que le type du caractère littéral est un entier signé, et à l'interprétation de la façon dont la conversion doit être faite.
