Questions idiotes

En mn.85357d51be941554.15512@YOURBRAnoos.fr, Emmanuel Delahaye va escriure:

sizeof est un opérateur qui est évalué à la compilation. une
fonction est évaluée à l'exécution. Rien à voir.

Encore un qui n'a pas fait ses devoirs...
(c'est quoi la trombine pour les gros yeux ?)

Tu n'as pas suivi la LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGUE conversation de
cet été avec Vincent et Gaby sur l'évaluation à la compilation ? Tu aurais
vu qu'en fait, le compilateur n'est pas _obligé_ d'évaluer l'opérateur à la
compilation.

De la même façon, il est parfaitement permis de remplacer un appel à

int f() { return 1; }

par la constante, aucune variation n'est appréciable au niveau de la machine
virtuelle.


La vraie différence, c'est que la fonction vaut 1 tandis que sizeof vaut 3
(j'aurais préferé que ce soit 4, c'était plus drôle :-)).



Antoine

Antoine Leca wrote on 18/01/05 :

(c'est quoi la trombine pour les gros yeux ?)

8(

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

Vincent Lefevre wrote:

Dans l'article <mn.8d0e7d51b32b479a.15512@YOURBRAnoos.fr>,
Emmanuel Delahaye <emdel@yourbranoos.fr> écrit:

[FAQ] Les bytes ne font pas forcément 8 bits. sur certaines
machines (DSP TMS320C54, par exemple), sizeof (char) == sizeof
(short) == sizeof (int) == 1 (bien sûr). Ce '1' fait en fait
16 bits.

Mais signalons au passage que sur de telles machines, l'implémentation
ne peut pas être une implémentation hébergée.

En revanche, une implémentation pour un Unisys 2200 serait
prèsque sûrement hébergée. Et avec des bytes de 9 bits.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

"James Kanze" <kanze@none> wrote in message
news:41eeb235$0$18272$626a14ce@news.free.fr...

Vincent Lefevre wrote:

Dans l'article <mn.8d0e7d51b32b479a.15512@YOURBRAnoos.fr>,
Emmanuel Delahaye <emdel@yourbranoos.fr> écrit:

[FAQ] Les bytes ne font pas forcément 8 bits. sur certaines
machines (DSP TMS320C54, par exemple), sizeof (char) == sizeof
(short) == sizeof (int) == 1 (bien sûr). Ce '1' fait en fait
16 bits.

Mais signalons au passage que sur de telles machines, l'implémentation
ne peut pas être une implémentation hébergée.

En revanche, une implémentation pour un Unisys 2200 serait
prèsque sûrement hébergée. Et avec des bytes de 9 bits.

Et on peut dire que l'investissement personnel des developpeurs C sur de telles
architectures anachroniques (Unisys) tient de l'acharnement thérapeutique ou de
la passion nostalgique. Polluer systématiquement les réponses aux débutants
avec de telles considérations extrêmes est contre productif et crée une
confusion inutile là où les notions de base (pointeurs / tableaux, float /
double, malloc / free, integer promotion, ...) ne sont pas maitrisées.

L'élève conducteur au moniteur d'auto-école :
- avant un virage, faut-il freiner ?
- ça dépend : avec de l'effet de sol et des gommes tendres, il faut parfois
accélérer pour augmenter le poids apparent qui donne un rapport Cz favorable.
Mais il faut tenir compte de la latence du turbo et du report des masses.
- ha bon, mais avec la 206 ?
- la c'est différent, la WRC il faut la balancer en prenant des appuis avant
l'épingle : on contre-braque un peu et on freine de la pointe en laissant un
filet de gaz et tout de suite on prend la corde pour glisser sans perdre de
vitesse.
- ???

Chqlie.

Charlie Gordon wrote:

...
Et on peut dire que l'investissement personnel des developpeurs C sur de telles
architectures anachroniques (Unisys) tient de l'acharnement thérapeutique ou de
la passion nostalgique. Polluer systématiquement les réponses aux débutants
avec de telles considérations extrêmes est contre productif et crée une
...

Je suis complètement d'accord avec toi. C'est l'une des raisons du
fonctionnement dramatiquement fermé du groupe fclc (idem pour fclc++).
Il ne subsiste qu'un petit noyau de posteurs qui pinaillent entre eux
depuis des années, et rejettent la plupart des autres questions avec
une interprétation plus que restrictive de la charte.

Il y en a même un qui se prend pour dieu et insulte copieusement ceux
qui ne l'adulent pas comme ils le devraient, c'est pitoyable.

Trop souvent les réponses sont accompagnées de remarques humiliantes
pour l'hérétique qui a l'outrecuidance de n'avoir pas appris par coeur
le recueil complet des contributions des gourous autoproclamés. Il y a
de quoi rebuter tous les participants (et pas que les novices) qui
auraient la mauvaise idée de fouiller un peu dans l'historique pour
découvrir les coutumes du groupe... voire même de poser une question
concernant un programme qui devrait exister en vrai (la charte ne
l'interdit pas je crois).

La conséquence de tout ça est que le groupe est déserté par tous les
nouveaux... de quoi se pencher sérieusement vers d'autres langages,
rien que parce que les groupes dédiés sont incomparablement plus
accueillants :)

A+
Jacques

Charlie Gordon wrote:

"James Kanze" <kanze@none> wrote in message
news:41eeb235$0$18272$626a14ce@news.free.fr...

Vincent Lefevre wrote:

Dans l'article <mn.8d0e7d51b32b479a.15512@YOURBRAnoos.fr>,
Emmanuel Delahaye <emdel@yourbranoos.fr> écrit:

[FAQ] Les bytes ne font pas forcément 8 bits. sur certaines
machines (DSP TMS320C54, par exemple), sizeof (char) = >> >>sizeof (short) == sizeof (int) == 1 (bien sûr). Ce '1' fait
en fait 16 bits.

Mais signalons au passage que sur de telles machines,
l'implémentation ne peut pas être une implémentation
hébergée.

En revanche, une implémentation pour un Unisys 2200 serait
prèsque sûrement hébergée. Et avec des bytes de 9 bits.

Et on peut dire que l'investissement personnel des
developpeurs C sur de telles architectures anachroniques
(Unisys) tient de l'acharnement thérapeutique ou de la passion
nostalgique.

Je ne sais pas. Unisys continue à en vendre et en livrer. Ce
n'est pas une machine tirée du passée.

Polluer systématiquement les réponses aux débutants avec de
telles considérations extrêmes est contre productif et crée
une confusion inutile là où les notions de base (pointeurs /
tableaux, float / double, malloc / free, integer promotion,
...) ne sont pas maitrisées.

Développer des bonnes habitues chez les débutants est
contre-productif ? Compter sur une taille exacte pour un type,
quelqu'il soit, n'est pas une bonne habitude. Dans le cas de
char, c'est vrai qu'il n'y a que peu de chances qu'un débutant
aujourd'hui rencontre autre chose que 8 bits, mais la taille des
autres types varient encore.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

En 41f25308$0$22645$636a15ce@news.free.fr, jz va escriure:

Charlie Gordon wrote:

...
Polluer systématiquement les réponses aux débutants avec de
telles considérations extrêmes est contre productif et crée une

Je suis complètement d'accord avec toi. C'est l'une des raisons du
fonctionnement dramatiquement fermé du groupe fclc (idem pour
fclc++).
Il ne subsiste qu'un petit noyau de posteurs qui pinaillent entre
eux depuis des années, et rejettent la plupart des autres
questions avec une interprétation plus que restrictive de la
charte.

Je considère que Charlie est un posteur régulier. Donc tu es d'accord avec
lui, mais tu lui décernes ensuite le titre de pinailleur et j'en passe.

Il est vrai que certaines questions qui auraient dues être posées ailleurs
sont parfois rejetées dans un style humiliant (et je suis le premier à le
déplorer, même si je ne suis pas à même de pouvoir le corriger). Cependant,
il ne faudrait surtout pas aller dans l'autre sens et accepter toutes les
questions sur (liste non limitative) comment ouvrir une soquette ou comment
dessiner une ellipse dans un contexte. C'est un classique sur Usenet de
renvoyer un débutant chercher sur un autre groupe plus adapté, impossible de
couper court. Et plus le trafic est important (je crois que c'est bien pire
pour clc), plus les comportements ont tendance à devenir tranchants, pour
une simple question de manque de disponibilités.

Je suis aussi eclc (es.c.l.c) Le trafic doit être 10 à 20 fois plus faible.
Et bien sûr le spectre des questions est plus large. Mais le niveau
technique y est moindre, en d'autres termes tu as plus souvent une réponse
fausse qui reste non corrigée. Je ne suis pas sûr que ce soit un bien.


Antoine

jz <jz@jz.jz> writes:

[...]

| La conséquence de tout ça est que le groupe est déserté par tous les
| nouveaux... de quoi se pencher sérieusement vers d'autres langages,
| rien que parce que les groupes dédiés sont incomparablement plus
| accueillants :)

Bref, un tri naturel quoi ;-p

-- Gaby

"Charlie Gordon" <news@chqrlie.org> writes:

"James Kanze" <kanze@none> wrote in message
news:41eeb235$0$18272$626a14ce@news.free.fr...

Vincent Lefevre wrote:

Dans l'article <mn.8d0e7d51b32b479a.15512@YOURBRAnoos.fr>,
Emmanuel Delahaye <emdel@yourbranoos.fr> écrit:

[FAQ] Les bytes ne font pas forcément 8 bits. sur certaines
machines (DSP TMS320C54, par exemple), sizeof (char) == sizeof
(short) == sizeof (int) == 1 (bien sûr). Ce '1' fait en fait
16 bits.

Mais signalons au passage que sur de telles machines, l'implémentation
ne peut pas être une implémentation hébergée.

En revanche, une implémentation pour un Unisys 2200 serait
prèsque sûrement hébergée. Et avec des bytes de 9 bits.

Et on peut dire que l'investissement personnel des
developpeurs C sur de telles architectures anachroniques
(Unisys) tient de l'acharnement thérapeutique ou de la
passion nostalgique.

L'investissement personnel? Si on y touche c'est
vraissemblablement qu'on travaille pour une compagnie les
utilisant depuis 30 ans... et la raison pour laquelle elles
sont toujours en service: ça couterait trop cher de changer.

Polluer systématiquement les réponses aux débutants avec
de telles considérations extrêmes est contre productif

Il y a toujours un problème de savoir où se positionner et à
quel niveau de détail répondre. Ce qui est beaucoup plus
difficile sur usenet qu'en face à face.

De plus, dans le cas présent, la question appelait des
réponses érudies et James répondait à Vincent qui répondait
à Emmanuel... pas une partie du fil où prédominent les
débutants et inexpérimentés.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Antoine Leca wrote:

Je considère que Charlie est un posteur régulier. Donc tu es d'accord avec
lui, mais tu lui décernes ensuite le titre de pinailleur et j'en passe.

On peut bien être d'accord sur un point avec quelqu'un sans pour
autant l'être pour tout le reste.

Ma généralisation était bien sûr provocatrice et excessive... un peu :)

Il est vrai que certaines questions qui auraient dues être posées ailleurs
sont parfois rejetées dans un style humiliant (et je suis le premier à le
déplorer, même si je ne suis pas à même de pouvoir le corriger). Cependant,

On est d'accord.

il ne faudrait surtout pas aller dans l'autre sens et accepter toutes les
questions sur (liste non limitative) comment ouvrir une soquette ou comment

La socquette est justement le sujet emblématique dont le rejet
systématique me pose problème. Sa programmation en C fait appel à des
fonctions système, donc en dehors de la norme du langage, soit. Mais
quand le problème posé vient d'une variable mal déclarée ou non
initialisée je ne vois pas pourquoi envoyer promener le posteur, c'est
typiquement un problème de langage C, même s'il y a des types de
données liés aux système.

Par contre, et là je te rejoins, si la question est liée au protocole
de communication utilisé sur la socquette, il faut renvoyer vers un
autre groupe... mais en douceur, c'est tout aussi efficace.

De même quand un débutant commet l'erreur classique et récurrente de
confondre allégrement caractère, chaîne de caractères et pointeur de
caractère, c'est bien de lui répondre, mais ce n'est pas le moment de
l'embrouiller parce qu'en plus il a traduit char par octet, ni de lui
passer un savon parce qu'il a écrit main() sans void. Il verra cela
plus tard, quand il sera plus à l'aise ou bien s'il est confronté à
ces problèmes, ce qui a bien peu de chance d'arriver à un débutant.

Ce qui n'empêche pas d'avoir des discussions pointues entre
passionnés, mais pas à tout bout de champ pour épater la galerie ou en
espérant gonfler sa notoriété de consultant :)

dessiner une ellipse dans un contexte. C'est un classique sur Usenet de
renvoyer un débutant chercher sur un autre groupe plus adapté, impossible de
couper court. Et plus le trafic est important (je crois que c'est bien pire
pour clc), plus les comportements ont tendance à devenir tranchants, pour
une simple question de manque de disponibilités.

Nul n'est obligé de répondre à *tout* ce qui passe. Si quelqu'un se
sent investi de ce rôle, il doit assumer et se débrouiller pour avoir
la disponibilité nécessaire. Les autres n'ont qu'à choisir les fils
qui les intéressent, sans perdre de leur précieux temps à
systématiquement pleurnicher pour les sujets hors charte, selon leur
interprétation de celle-ci. Ils ne sont même pas obligés de lire.

A+
Jacques