Vivi a écrit 819 commentaires

ça c'est la fondamentale, mais évidemment que sax et piano produisent des sons dans les fréquences supérieures.

[on peut mentionner Nyquist aussi à propos de ce théorème]

Ça me paraît gros quand même. Passer le signal à travers un filtre passe-bas avant d'échantillonner c'est un peu le B.A.-BA du traitement numérique du signal.

Oui, il devrait en faire une news.

Un prévenu qui arrive bourré à la barre...

je précise : poursuivi pour conduite en état d’ivresse !

recoder pour apprendre, oui. Mais parser du XML avec des regexp, ça n'apprend rien, ce n'est pas comme ça que fonctionnent les parsers XML. C'est pas adapté, point final.

t'as l'option all_squash donc c'est un utilisateur anonyme qui va effectuer l'écriture. Faut voir s'il a bien les droits d'écriture dans /home/ftp.

Les composants ne sont pas soumis au mêmes contraintes/garanties.

- Dans platform, tu as toutes les bibliothèques de base et pas d'application. Tu es supposé tout installer. Ces bibliothèques ont des fortes garanties de compatibilité au niveau binaire et source (ABI et API) cf. http://developer.gnome.org/dotplan/api_rules.html(...)

- Dans desktop, tu as d'autres bibliothèques et des applications, dépendant de platform. Ces composants n'ont pas les mêmes garanties de stabilité.

- Les bindings sont destinés aux développeurs et sont utilisés par d'autres applications qui ne sont pas dans le desktop.

non, c'est pas nouveau. Le split platform/desktop est là depuis longtemps (2.0 ?), les bindings sont arrivés avec le 2.6 il me semble.

Je cite http://developer.kde.org/documentation/library/kdeqt/dcop.html#sec2(...) :

DCOP is built on top of the Inter Client Exchange (ICE) protocol, which comes standard as a part of X11R6 and later.

moi j'utilise ça :

http://j3e.de/linux/convmv/(...)

Et voilà, j'ai une structure qui fait la taille d'un int qui s'utilise comme un int, etc...

gni ? le rapport ... ?

De plus la norme (oui oui), autorise :
(n_importe_quoi *) = (void *)
et
(void *) = (n_importe_quoi *)

la norme autorise la conversion d'un pointeur quelconque en un pointeur générique (void *), et réciproquement, sans perte d'information. De la même façon que tu peux convertir un int en long et tu retrouves la même valeur quand tu reconvertis le long en int. Pourtant int et long n'ont pas nécessairement la même taille.

Bref sizeof (void *) == sizeof (char *) >= sizeof (autre_chose *)

A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. [...] All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements.

pour malloc:

The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated

> sizeof(toto *) != sizeof (void *)

Non. sizeof(int*), sizeof(toto*), sizeof(n_importe_quoi *) est égale à sizeof(void *).

Bah, maintenant que tu as la norme tu vas pouvoir me montrer à quel chapitre/paragraphe ça dit ça :-D. Te fatigues pas, tu vas pas trouver, ça n'est pas le cas. Rien (dans la norme) n'indique que les pointeurs de différents types ont la même taille. Par exemple certaines implémentations tordues peuvent avoir un sizeof (char *) plus grand que sizeof (int *) parce que l'accés mémoire est plus compliqué pour adresser un byte tout seul plutôt qu'un int aligné. Ou un pointeur de fonction peut avoir une taille différente de celle des pointeurs de données.

Ceci marche car "struct list *" est connu en taille avant même sa déclaration
c'est parce que tous les pointeurs vers des struct ont la même taille

et la taille est sizeof (void *)
pas nécessairement.

> > static char* p ;
> p est un null pointer

Non, c'est initialisé à 0.

Si, section 6.5.8 'Initialization', paragraphe #10 :

If an object that has static storage duration is not initialized explicitly, then:

- if it has pointer type, it is initialized to a null
pointer;

pour la norme: http://www.vmunix.com/~gabor/c/draft.html(...)
j'en ai une version dans un .txt (je sais plus où je l'ai trouvée), compréssée, elle ne fait que 288K :) !


> > void * p = (void *)(p1 - p2) ;
> 0 pour p

Pourtant tu dis : '0' même signification que '(void *)0' même signification que null pointeur. Or ici j'ai bien '(void *)0' (c-à-d null pointeur) et tu dis que c'est 0. Pas claire.

NULL, c'est '0' ou '(void *)0' mais avec un zéro comme constante (le caractère 48 du charset US-ASCII si tu préfères :).
De la même façon,
int i = 0
char *p = (void *)i;
n'est pas forcèment un null pointer.

> 100%
Non. pour varargs, ça ne marche pas.
Heureusement, gcc a la délicatesse de le dire :
printf("%p\n", 0) ;
test.c:3: attention : l'argument de format n'est pas un pointeur (arg 2)
oui, gcc inspecte les chaîne de format pour faire la véréfication des types, c'est gentil de sa part.

avec :
fprintf("%p\n", NULL) ;
Pas de warning, c'est correct.

Parce que:
1) sur ta plateforme NULL est défini par '(void *)0'
2) la fonction attend un void * (à cause du %p)

Mais:
1) si tu compiles ça sur une autre implémentation avec NULL défini à 0 (ce qui est légal dixit la norme), ça va pas marcher
2) pour une vararg attendant un type (toto *), il faut caster le NULL de toutes façons, même s'il est défini par (void *)0 car il se peut que:
sizeof(toto *) != sizeof (void *)

static char* p ;
p est un null pointer

static char *p[10]
p est un tableau de 10 null pointer

static union {
long i[10] ;
void * p[10] ;
} titi ;
bits à 0 (pas forcèment null pointer) car le premier élément est initialisé, donc ici des longs.

char * p1 = "toto" ;
char * p2 = p1 ;
void * p = (void *)(p1 - p2) ;
0 pour p

La soustraction de deux trucs valide ne donne jamais NULL.
ça n'a pas de sens, NULL est une macro

Dans 99,9 % des cas, on peut remplacer NULL par 0
100%

> Pas du C, on ne peut pas additionner deux pointeurs.

Oui on peut (même si généralement c'est une très mauvaise idée). Il faut qu'il soit du même type et pas du type void* .

Non, on peut pas. Je vais pas te citer la norme, parce que c'est lourd, mais non on peut pas. On peut soustraire deux pointeurs par contre.

Sur l'aspect signification, ce n'est pas la même chose.
p = 0 // adresse 0
p = NULL // adresse invalide ou non renseigné, etc

Bon j'abandonne, c'est sans espoir. C'est deux instructions sont complètement équivalentes et ont exactement la même sémantique (pour peu que p soit un pointeur, hein).

voir http://www.eskimo.com/~scs/C-faq/q5.17.html(...) pour des exemples d'archi aux pointeurs bizarres.

char * f (char *p, char * t) {
return (p + t) -t ;
}

Pas du C, on ne peut pas additionner deux pointeurs.

De plus je ne fais jamais de "if (p)", "if (!p)" ou "if (p=malloc(2)) je fais toujours "if (p != NULL)", "if (p == NULL)" et "if ((p = malloc(2)) != NULL).
Notes que je ne suis pas le seul à faire comme ça (je ne parle pas de Linux).

Moi aussi je fais comme ça, mais les premières écritures sont aussi valide et ont le même sens.

If faut toujours utiliser NULL

C'est purement stylistique comme recommendation

et ne pas considérer que NULL est égale 0.

Effectivement, il faut pas (elle peut être égale à (void *)0.

Ça n'a pas la même signification qu'avec les autres types.

Si c'est pareil, on compare p avec 0, une 'null pointer constant'. http://www.eskimo.com/~scs/C-faq/q5.3.html(...)

Pour ceux que ça intéresse, la FAQ de comp.lang.c a des entrées trés trés complètes sur les pointeurs nuls :

http://www.eskimo.com/~scs/C-faq/s5.html(...)

La norme ne dit pas que ça doit être traité spécialement, mais que ça peut.

An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be properly aligned, and might not point to an entity of the referenced type.

(le previously defined, c'est ce que je cite plus haut)

Le cast d'un entier en pointeur est dépendant de l'implémentation, sauf pour le cas des 'null pointer constant'. Dans ce cas, ça produit un 'null pointer' et la norme spécifie alors plus de choses, notamment le résultat des comparaisons et conversions de null pointer entre eux ou avec des pointeurs valides.

Déréférencer un (char *)2, ça pourrais marcher, c'est pas incompatible avec la norme. Déréférencer un null pointer, c'est jamais valide, ça produit un UB (undefined behavior).

> C'est pas vraiment lié au compilateur.

Si.

> C'est la librairie C qui """gère""" ça. Si tu ne fais pas "#include
> <stdlib.h>", tu as une erreur de compilation :
> NULL : symbol non défini.

La norme dit que NULL est une macro. Si tu n'include pas stdlib.h, le préprocesseur laisse passer NULL et le compilo dit effectivement ça.

Maintentant la norme dit:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

The macro NULL is defined in <stddef.h> as a null pointer constant.

Le préprocesseur remplace NULL par 0 (ou (void *)0 ou 0L ou 0U, etc) et c'est bien le compilateur (ou le front-end, en tout cas c'est pas la lib) qui a la charge de convertir ce 'null pointer constant' en 'null pointer'.

Il y a confusion entre ce que la norme appelle 'null pointer constant' et 'null pointer'.

Un 'null pointer' est une adresse invalide, dépendant de la plateforme. C'est une valeur.
0 ou (void *)0 est une 'null pointer constant' (par définition), c'est une expression, un élément du langage.

Ces deux trucs n'appartienent pas au même monde: un 'null pointer' c'est un truc qui existe dans le programme compilé et lors de l'éxecution, un 'null pointer constant' ça existe dans le code source.

Le norme dit que quand tu stocke un 'null pointer constant' dans une variable de type pointeur, le compilateur utilise la valeur 'null pointer'. La norme ne donne pas la valeur d'un 'null pointer', mais elle donne la valeur de NULL: c'est une macro qui resprésente une 'null pointer constant'.

La taille des pointeurs (et ce jusqu'au niveau des registres qui les stoquent) peut varier en fonction du contexte CPU.

C'est pas le problème. Ça c'est la cuisine interne du compilateur, dépendant de la plateforme : ça ne se voit pas au niveau du source.

Effectivement l'adresse 0 peut être valable, c'est pourquoi la norme parle de 'null pointer constant', ie une syntaxe spéciale pour désigner une adresse invalide. Cette syntaxe est 0 ou (void *)0 (quelle que soit la plateforme). La norme dit ensuite que si on convertit ça en un type pointeur, par exemple en faisant char *p = 0; ou char *p = NULL;, le compilo doit remplacer ça par une adresse invalide pour la plateforme.

Le problème avec les vararg (ou avec une fonction sans prototype) est que la 'null pointer constant' ne va pas forcèment être convertie en un type pointeur à cause des règles de promotion.

De toutes façons, ça n'est pas l'argument de Linus :) Son problème, c'est que la syntaxe spéciale 0 pour désigner un pointeur invalide est débile : un pointeur n'est pas un entier, il veut une syntaxe qui montre bien qu'on a affaire à un pointeur. Il veut voir NULL partout pour des raisons de style.

Euh, tu le vois où ce package ?

Les responsables, ce sont qui ont affirme haut et fort que Corba etait parfaitement adapte comme modele de composant pour un desktop et ont continue sur ce choix technique.

Non désolé, pas d'accord. Le but de bonobo est de batîr des composants sur la couche de communication qu'est CORBA. Que CORBA en lui même ne soit pas adapté n'est pas le problème car de toutes façons Bonobo est construit selon des concepts assez différents (pas d'héritage multiple comme en CORBA mais aggrégation d'interfaces), avec des conventions d'utilisation. C'est pas trivial.

CORBA est bien documenté, (c'est un standard, blablabla) il est assez facile de trouver de la doc dessus. Par contre pratiquement rien pour Bonobo. S'ils voulaient que les dev. utilisent en masse Bonobo, ils auraient dû faire un effort sur la doc.

[ Moi aussi je pense que choisir CORBA a été une erreur (c'est trop complexe, ORBit a mis trop de temps à être opérationnel). ]

[renoncement de KDE a Corba]: les mecs de KDE ont rien compris aux composants, vous verrez que Corba, c'est vraiment de la balle. Celui que je plains le plus aujourd'hui, c'est Mickael Meeks. Alors qu'il a bosse pendant 3 ans sur bonobo pour le rendre vaguement utilisable en C, on est en train de le faire lentement passer a la trappe parce que trop complique a utiliser et trop lourd.

C'est vrai. Mais je pense que les dev. bonobo sont un peu responsables de cet état de fait. Il n'y a pratiquement aucune doc correcte là dessus, juste le manuel de référence, quelques tutoriels de 5 lignes et des indications genre "lisez tel bouquin, remplacez COM par CORBA, C++ par le C et voilà !". Bonobo, c'est un peu les gars de Ximian qui l'ont construit et utilisé dans leur coin et qui n'ont rien fait pour apprendre aux dev. amateurs à s'en servir.

Gnome se retrouve donc a pousser discretement le nouveau DBUS qui ressemble beaucoup au DCOP de KDE.

pas exactement, c'est freedesktop.org qui pousse DBus. Le fait que ça ressemble à DCOP n'est pas un hasard, l'intention est plus ou moins de pouvoir remplacer DCOP par DBus à terme.

La aussi, probleme de discours marketing car il semble difficile de mettre bonobo a la poubelle apres l'avoir pousse aussi longtemp. Et ceux qui y croyaient a fond sont decus.

Ouais.

Té, demain je fork KDE, je fais une page web à la vavite et je poste une news sur DLFP.
Pourquoi je forke ? parce que franchement utiliser le terme "Document" au lieu de "Fichier" dans les applications c'est vraiment anti-ergonomique.

Trop tard, déjà fait http://www.clarux.com/(...)

(bon en fait, c'est pour remplacer "Directory" par "Folder" mais c'est dans le même esprit)