Embedded weblog - Tag - programmation - Commentaires

slides de la conférence GCC par Basile Starynkevitch - OlivierJ

2011-02-16T19:21:43+01:00

Très intéressante, la présentation de Basile Starynkevitch, ne serait-ce que le premier tiers sur les langages et les processeurs et leurs évolutions.

cours de kernel Linux en ligne - Gilles Blanc

2010-08-24T12:04:17+02:00

@Yoann Sculo: c'est loin d'être complet par rapport au catalogue, mais il y a déjà de quoi faire... :)

@Bedo: mais de rien, c'est toujours un plaisir ;)

cours de kernel Linux en ligne - Bedo

2010-07-13T15:21:33+02:00

Merci de faire ainsi de la pub pour mes œuvres ;-)

cours de kernel Linux en ligne - Yoann Sculo

2010-06-26T12:21:55+02:00

Ah merci pour l'info ! J'étais passé à côté de la discussion linkedIn.
Sinon c'est super, je ne savais pas que Linagora publiait ses supports de formation comme Free Electrons

slides de la conférence GCC par Basile Starynkevitch - Frédéric

2010-02-26T12:29:19+01:00

Merci pour l'info. Les slides sont très intéressants.

le code qui fait mal aux yeux du jour - Gilles Blanc

2009-12-04T15:09:31+01:00

Pointeur de fonction, quand tu nous tiens...

le code qui fait mal aux yeux du jour - Samuel Tardieu

2009-12-02T19:13:35+01:00

Faire clignoter une led ? Je ne m'étais jamais posé la question, mais c'est trivial : http://paste.factorcode.org/paste?i...

Note la capture de "led" et "on" dans la closure du premier argument de setInterval(). Je ne trouve pas le code particulièrement inélégant. Même si je ne pratique que très rarement le Javascript, je pense que c'est un plutôt beau langage.

le code qui fait mal aux yeux du jour - Gilles Blanc

2009-12-02T16:00:40+01:00

Je vais demander un DIF Erlang, on m'en parle tellement... :p

Bref, on aura deviné que si j'avais besoin de ça, c'est que je suis en train de faire du crasseux pour passer outre des bugs, qui sont induits... par un langage crasseux... Et je ne t'explique même pas l'idée de substitution pour résoudre le problème, elle est pire encore (n'empêche que pour le moment : bug IE non résolu, client pas content). Mais faire une tempo dans un langage de prog graphique, je ne vois pas le problème : la prog par callback au timeout, ça rappelle fortement Motif, et ses fabuleuses boucles de procédures faisant des callbacks sur elles-mêmes (oh, sans tenir compte du délai d'exécution, que j'avais en plus, miam les désynchros...). Comment fait-on clignoter simplement une LED en JS ? :D (puisque je faisais du GPIO jeudi dernier en Python ; ça au moins, je connais...).

le code qui fait mal aux yeux du jour - Samuel Tardieu

2009-12-02T12:46:07+01:00

Le problème ici ne concerne pas les créateurs de Javascript, mais les utilisateurs qui ici utilisent du busy waiting.

D'autres très beaux langages comme Erlang ne disposent pas d'une fonction "sleep" non plus. L'idiome consiste à attendre un message qui ne peut pas arriver avec un timeout positionné sur le délai qui nous intéresse.

En Javascript, il suffit, si on a *vraiment* besoin d'attendre un temps donné, d'utiliser les fonctions de synchronisation idoines et les fonctionalités de gestion du temps comme les alarmes. C'est tout aussi propre que "sleep" et peut souvent révéler qu'en fait il n'y en a pas du tout besoin.

au détour d'une macro crasseuse - Gilles Blanc

2009-08-28T18:59:46+02:00

Eh bien, tu t'es lâché dis-moi ! ^^ Tiens, v'la le code, la fonction setthetime qui utilise cette horreur vaut aussi le coup d'oeil...

au détour d'une macro crasseuse - Patrick Foubet

2009-08-28T17:25:01+02:00

En fait, comme toujours sur un blog, on va à l'essentiel et on néglige les détails, c'est pourquoi souvent les commentaires qu'on y trouve sont mals perçus.
Donc là, comme c'est le tien (de blog), j'ai un remords et je vais essayer de réparer mon manque d'explication (si j'y arrive) ;-)

Voici un petit programme, que j'appelle e.c, dans lequel j'ai défini :
- la macro ATOI2 vue ci-dessus
- la macro ATOI2a que j'ai proposée en échange
- la macro ATOI2b qui est encore une autre version
Dans un premier temps je n'utilise pas ces macros mais "atoi" de la librairie standard.

#define ATOI2(ar) ((ar) += 2, ((ar)[-2] - '0') * 10 + ((ar)[-1] - '0'))
#define ATOI2a(ar) ((ar)[0] - '0') * 10 + ((ar)[1] - '0')
#define ATOI2b(ar) (((ar++)[0] - '0') * 10 + ((ar++)[0] - '0') )

#include <stdio.h>

int main(int N, char*P[])
{
char t[10], *b;
int i,j,k;
strcpy(t,"256789");
b=t;
i = atoi(t); /* ligne 13 */
j = atoi(b);
k = atoi("791234"); /* ligne 15 */
printf(" i=%d j=%d k=%d t=<%s> b=<%s> ",i, j, k, t, b);
}

Je compile :
$ cc -o e e.c
Pas de problème particulier.
J'exécute :
$ ./e
i=256789 j=256789 k=791234 t=<256789> b=<256789>
Rien que du classique.

Maintenant je remplace dans les lignes 13 à 15, atoi par ATOI2, macro qui ne travaille que sur les deux premiers caractères et qui en plus fait progresser le pointeur de 2 crans.

Je compile :
$ cc -o e e.c
e.c: Dans la fonction « main »:
e.c:13: error: incompatible types in affectation
e.c:15: error: affectation of read-only location
e.c:15: error: incompatible types in affectation

Hé oui ! car une des raisons est que l'on essaie d'accéder aux éléments d'une chaîne de caractère définie comme une constante (ligne 15).
Ceci avec gcc peut se résoudre (bien que ce soit fortement déconseillé) par :
$ cc -o e -fwritable-strings e.c
e.c: Dans la fonction « main »:
e.c:13: error: incompatible types in affectation
e.c:15: error: incompatible types in affectation

Il reste quand même que, selon l'implémentation faite par le compilateur, un tableau de caractères et une chaîne constante ne sont pas toujours assimilables à un pointeur !! (cf K&R pour les détails). On peut les utiliser pour initialiser un pointeur mais pas pour faire des opérations dessus.
Certains compilateurs le permettent (comme par exemple le cc d'un Aix que j'ai utilisé dans les années 90) mais il ne faut pas compter dessus !!

Par contre, si on remplace, entre les lignes 13 et 15, atoi par ATOI2a on a bien le résultat sur les 2 premiers caractères mais le pointeur n'est pas décallé de 2 !! Il faut le faire à la main.

Pour bien enfoncer le clou, je propose une seconde alternance, qui fait la même chose que ATOI2 mais sans l'instruction ','. Si on remplace atoi par ATOI2b, on a, à la compilation :
$ cc -o e e.c
e.c: Dans la fonction « main »:
e.c:13: error: wrong type argument to increment
e.c:13: error: wrong type argument to increment
e.c:15: error: wrong type argument to increment
e.c:15: error: wrong type argument to increment

Ce qui confirme bien la raison décrite ci-dessus.
On remarque au passage que l'utilisation des index négatifs ne perturbe pas le compilateur, et c'est normal.

Et voilà tout ce qui se cachait derrière mon laconique "avec un gcc 3.3.5 le code que tu signales ne passe pas" !

Comme quoi, on veut dire deux mots en passant et on y passe la soirée ...

Bien à toi

au détour d'une macro crasseuse - Gilles Blanc

2009-08-27T11:40:28+02:00

Pourtant, c'est un gcc3.3.5 qu'il y a sur BSD 4.2 ; mais il faut dire qu'ils l'ont tellement bidouillé, aussi...

au détour d'une macro crasseuse - Patrick Foubet

2009-08-27T11:15:26+02:00

Autant pour moi !! Je voulais écrire :
#define ATOI2(ar) ((ar)[0] - '0') * 10 + ((ar)[1] - '0')
Comme quoi la critique est une arme à double tranchant ;-)

En tous cas, avec un gcc 3.3.5 le code que tu signales ne passe pas !!

au détour d'une macro crasseuse - Patrick Foubet

2009-08-26T17:43:00+02:00

Je ne sais pas ce que le programmeur d'OpenBSD a fumé avant d'écrire cela mais :
#define ATOI2(ar) ((ar)[-2] - '0') * 10 + ((ar)[-1] - '0')
est quand même plus simple, plus rapide et fonctionne avec tous les compilateurs ;-)

au détour d'une macro crasseuse - Gilles Blanc

2009-05-28T16:38:24+02:00

Aaaahhh, bien vu l'expert ! :)

au détour d'une macro crasseuse - Sam

2009-05-27T18:45:08+02:00

Cela dit, aujourd'hui, il n'y aurait aucune raison de ne pas le coder comme une fonction :

static inline unsigned char atoi2(const char **ar);

Mais nous sommes en 2009, les compilateurs n'étaient probablement pas aussi efficace à l'époque où cette macro a été codée.

au détour d'une macro crasseuse - Sam

2009-05-27T18:31:41+02:00

Pourtant, tu as probablement déjà utilisé la virgule comme opérateur, par exemple dans "i++, j++" comme troisième argument d'un "for".

Ce genre d'utilisations est assez fréquente si on ne veut pas utiliser les extensions de GCC qui permettent d'avoir des blocs "{}" renvoyant un résultat, similaires à une lambda expression et permettant même d'y mettre des boucles du coup.