Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Matériel Ordinateur Mac Programmation erreurs (???) dans headers

erreurs (???) dans headers

31 réponses
Avatar
pere.noel
bon, je continue et ai ajouté comme heaer :

#include "/Developer/Headers/FlatCarbon/Files.h"

car j'utilise :

FSRef theRef;
if (CFURLGetFSRef(url, &theRef)) {
printf("From C => CFURLGetFSRef(url, &theRef)\n");
}

et au make j'ai :

In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.
framework/Headers/OSServices.h:45,
from
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h
:25,
from /Developer/Headers/FlatCarbon/Files.h:1,
from RAliasFile.c:10:
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.
framework/Headers/OpenTransport.h:723: error: parse error before numeric
constant

alors que j'ai positionné :

require 'mkmf'

$CFLAGS << " -I
/System/Library/Frameworks/CoreFoundation.framework/Headers "
$CFLAGS << " -I
/System/Library/Frameworks/CoreServices.framework/Headers "
$CFLAGS << " -I
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.
framework/Headers "

$LDFLAGS << " -framework CoreFoundation CoreServices OSServices"

# Give it a name
extension_name = 'raliasfile'

# The destination
dir_config(extension_name)

# Do the work
create_makefile(extension_name)

dans mon "extconf.rb"

je pense d'ailleurs que le "$CFLAGS << " -I
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.
framework/Headers "
"
vu ce qui précède...
--
une bévue
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
luc
Eric Levenez wrote:

Très mauvaise habitude. Cela doit être dans la FAQ du C : ne jamais essayer
de cacher un pointeur que ce soit par un define ou par un typedef.


Intéressant ça. Et quelle est la raison exacte ? Parceque "cacher des
pointeurs" c'est un peu ce qui est fait dans la quasi intégralité de
CoreFoundation avec les type opaques CF...Ref, par exemple:

typedef const struct __CFString * CFStringRef;
typedef const struct __CFURL * CFURLRef;

etc, etc... :)

<http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFDe
signConcepts/Concepts/ObjectReferences.html#//apple_ref/doc/uid/20001107



--
Luc Heinrich

Avatar
Eric Levenez
Le 17/08/06 9:03, dans <1hk7hws.1a54veu1cz7ujsN%, « Luc
Heinrich » a écrit :

Eric Levenez wrote:

Très mauvaise habitude. Cela doit être dans la FAQ du C : ne jamais essayer
de cacher un pointeur que ce soit par un define ou par un typedef.


Intéressant ça. Et quelle est la raison exacte ?


Parce que cacher un pointeur par un typedef entraîne toujours des problèmes.
Si tu veux t'en convaincre va lire les forums sur le C. Les débutants en C
typiquement mettent un typedef pour définir une structure, puis un autre
typedef pour définir un pointeur sur cette structure et encore un autre pour
le pointeur de pointeur. Après ils ont 40 types de typedef pour le même type
d'objets et ils mettent des casts ou des "&" partout pour arriver à
compiler. Pour les defines, c'est la même chose, on a un type bien propre et
on va appeler une macro cachée pour réaliser une tâche simple et on va
trouver des trucs comme :

DEFREF(INCPTR(p))

à la place d'un :

*p++

Qu'Apple propage ce genre de comportement (typedef pulitple) n'est pas très
étonnant. Sûrement des traces d'anciennes habitudes.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
Eric Levenez
Le 17/08/06 1:17, dans , « Pascal
Bourguignon » a écrit :

Eric Levenez writes:

Le 16/08/06 22:50, dans ,
« Pascal Bourguignon » a écrit :

#define PTR(x) (&(x))
#define DEREF(x) (*(x))
etc...


Très mauvaise habitude. Cela doit être dans la FAQ du C : ne jamais essayer
de cacher un pointeur que ce soit par un define ou par un typedef.


Il n'est pas caché, il est mis en ÉVIDENCE, avec trois ou cinq
caractères majuscules au lieu d'un seul. ;-)


En règle générale, les macros sont la plaie du langage C. Ils apportent une
illisibilité du code et des effets de bord toujours surprenant. J'ai déjà vu
du code (C je le précise) du type

DECLARE(int, i);

/* ... */

FOREVER

if (IS_ZERO(i))
EXIT_LOOP;

/* ... */

ENDFOREVER

Comme tu le vois, là aussi tout est en ÉVIDENCE, mais ce n'est pas lisible à
mon goût.

Quand on commence à maquiller le langage c'est qu'on ne se l'est pas
approprié et qu'on essaye de le faire coller à autre chose. Le problème est
alors que cette autre chose est différente pour chaque personne (d'où des
problèmes), alors que le langage de départ est lui identique pour chacun.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.



Avatar
Eric Levenez
Le 17/08/06 0:28, dans
<1hk6tzp.14f379fm9qgquN%, « Une bévue »
a écrit :

Eric Levenez wrote:
Et bien si, il suffit de regarder tout le thread sur le true/false
pour s'en convaincre.


dans ce cas certains devs d'Apple ferait bien de lire les bases...
dans une des pages Apple il y a un mélange de BOOL ObjC et de Boolean
CF###... coup de pot il passe NO.


Oh oui, même Apple programme de façon spéciale et se permet beaucoup de...
fantaisies je dirais.

contrairement à ce que tu crois je me suis posé des questions à ce sujet
mais comme Apple le faisait je me suis dit : ça doit rouler, si ça
déconne je verrais plus tard.

d'ailleurs dans les tutaux que j'ai lu, ils ne parlent pas ou peu de ces
conversions de valeur logique et pour cause, ils écrivent dans un C
homogène, ce qui n'est pas mon cas.


La gestion des booléens en C est un problème depuis les origines car il
n'était pas défini dans le K&R et que chaque programmeur le redéfini dans
son bout de code. Si on mélange 2 bouts de code de 2 programmeurs différents
on a potentiellement des problèmes. Maintenant on a le type "bool" en C99,
mais cela n'est pas encore bien accepté par tous les programmeurs. Sans
parler des anciennes API qui ne peuvent pas changer.

Bref Apple ne fait pas, ou ne peut pas faire pour des raisons historiques,
les choses proprement. Et c'est bien dommage.

La gestion des booléens est très compliquée car elle semble simple. On t'a
indiqué sur fr.comp.lang.c certains pièges liés aux tests (impliquant des
hideux define). Et on trouve encore hélas du code avec des choses du genre :

if (not_present != false)


Comment bien utiliser les includes, et comment les inclure dans le bon
ordre, c'est la pratique du C. Quand on a saisi le principe, on peut adapter
cela à n'importe quelle plate-forme.


j'ai lu des tutaux sur les includes, ils ne parlaient pas de "bon
ordre", dans la même veine,


L'ordre des includes est _très_ important en C.

Dans les API système il y a des fonctions ou appels système qui ne
nécessitent qu'un include, alors là oui, aucune importance de l'ordre. Par
contre il y a beaucoup d'API qui nécessitent plusieurs includes (donnés dans
le "man"), et là l'ordre est primordial car le premier include définit des
choses que le deuxième utilisera et ce deuxième défini des choses que le
troisième utilisera. Ce n'est peut-être pas joli, mais c'est historique.

Pour gérer ces problèmes dans un fichier include, on utilise typiquement un
define et ifdef en tête pour savoir s'il a déjà été inclus ou non et pour
inclure les defines que le fichier a besoin. C'est du bricolage, et c'est
pour cela que Objective-C a défini le "import" pour contourner ce problème.

j'ai lu un tutau qui disait que l'ordre des
méthodes était indifférent. J'ai constaté que ce n'est pas vrai.


Je ne parlais pas des méthodes mais des includes.

perso, tout ce que je voulais faire c'est une extension ruby en C,
l'ayant déjà réalisée en ObjC (facilement), c'est ma motivation. je ne
ferai peut-être rien d'autre en C.


--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
luc
Eric Levenez wrote:

Parce que cacher un pointeur par un typedef entraîne toujours des problèmes.


Toujours ? Ce qui voudrait dire que l'utilisation de CoreFoundation va
*toujours* entrainer des problemes ?

Si tu veux t'en convaincre va lire les forums sur le C. Les débutants en C
typiquement mettent un typedef pour définir une structure, puis un autre
typedef pour définir un pointeur sur cette structure et encore un autre pour
le pointeur de pointeur. Après ils ont 40 types de typedef pour le même type
d'objets et ils mettent des casts ou des "&" partout pour arriver à
compiler.


Personnellement je pense qu'il y a une *large* différence entre un
débutant qui fait des conneries parcequ'il ne connait pas le langage et
ses pièges dans ces moindres recoins, et des gens un peu compétents qui
savent ce qu'ils font *à priori*. Pour CoreFoundation en l'occurence je
trouve que la sémantique du pointeur n'a strictement aucun intérêt et
que le typedef permet de renforcer le principe d'opacité.

Pour les defines, c'est la même chose


Oui, ok, les defines c'est porc, on est bien d'accord la dessus.

--
Luc Heinrich

Avatar
Eric Levenez
Le 17/08/06 11:42, dans <1hk7phl.c91m9v12tl6piN%, « Luc
Heinrich » a écrit :

Eric Levenez wrote:

Parce que cacher un pointeur par un typedef entraîne toujours des problèmes.


Toujours ? Ce qui voudrait dire que l'utilisation de CoreFoundation va
*toujours* entrainer des problemes ?


Quand je disais toujours, c'était pour dire qu'il y aura toujours quelqu'un
qui aura des problèmes à cause des typedefs. Cela ne voulait pas dire que
tout le monde aura des problèmes.

Si tu veux t'en convaincre va lire les forums sur le C. Les débutants en C
typiquement mettent un typedef pour définir une structure, puis un autre
typedef pour définir un pointeur sur cette structure et encore un autre pour
le pointeur de pointeur. Après ils ont 40 types de typedef pour le même type
d'objets et ils mettent des casts ou des "&" partout pour arriver à
compiler.


Personnellement je pense qu'il y a une *large* différence entre un
débutant qui fait des conneries parcequ'il ne connait pas le langage et
ses pièges dans ces moindres recoins, et des gens un peu compétents qui
savent ce qu'ils font *à priori*. Pour CoreFoundation en l'occurence je
trouve que la sémantique du pointeur n'a strictement aucun intérêt et
que le typedef permet de renforcer le principe d'opacité.


L'opacité c'est bien à condition de savoir un peu ce que l'on manipule. On
arrive parfois à du code du type :

a = fct(b, c, d);

où a et c sont des structures et b et d des pointeurs. Cela marche, et un
jour, à force d'empiler des grosses structures dans la pile, celle-ci
explose.

Comme je travaille beaucoup en embarqué, savoir le type des objets que
j'utilise est primordial.

Pour les defines, c'est la même chose


Oui, ok, les defines c'est porc, on est bien d'accord la dessus.


Oh ! :-)

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
Eric Levenez
Le 17/08/06 11:55, dans <44e43d27$0$870$, « Lionel
Mychkine » a écrit :

Le problème est que le type bool défini par le C99 est dépendant de
l'architecture. Il est parfois implanté en 8 bits et parfois (c'est le
cas pour MacOS X) en 32 bits.


Oui effectivement. Mais le "enum { FALSE, TRUE }" utilisé typiquement par
les programmeurs ne fait pas mieux. Le problème est aussi que "bool" n'a
souvent pas de typage fort (un simple int par exemple). Mais au moins "bool"
est standard.

C'est pourquoi, il est hors de question de
le sauvegarder en l'état dans un fichier


De toute façon, dès que l'on veut sauvegarder une valeur binaire dans un
fichier on a des problèmes de portabilité. Et une bonne idée est toujours de
transcoder la représentation interne du programme en quelque chose de
lisible partout. Les fichiers texte (XML ou autre) deviennent ainsi de plus
en plus utilisés, au détriment de la taille prise bien sûr.

voire de l'utiliser dans une
structure, ce qui réduit considérablement son intérêt et c'est bien
dommage.


Dans une structure il y a toujours le problème de l'alignement. Si l'on a
des problèmes de place mémoire, alors oui, il peut être utilise de redéfinir
des types plus compacts et d'utiliser des char ou des short. Mais là encore
il ne faut pas croire que cela soit toujours bien. Je travaille sur DSP et
un char est un 32 bits, alors l'optimisation que l'on pense faire au
détriment de la lisibilité et de la portabilité ne sert à rien.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
pere.noel
Eric Levenez wrote:

La gestion des booléens en C est un problème depuis les origines car il
n'était pas défini dans le K&R et que chaque programmeur le redéfini dans
son bout de code. Si on mélange 2 bouts de code de 2 programmeurs différents
on a potentiellement des problèmes. Maintenant on a le type "bool" en C99,
mais cela n'est pas encore bien accepté par tous les programmeurs. Sans
parler des anciennes API qui ne peuvent pas changer.

Bref Apple ne fait pas, ou ne peut pas faire pour des raisons historiques,
les choses proprement. Et c'est bien dommage.

La gestion des booléens est très compliquée car elle semble simple. On t'a
indiqué sur fr.comp.lang.c certains pièges liés aux tests (impliquant des
hideux define). Et on trouve encore hélas du code avec des choses du genre :

if (not_present != false)



ce pb de boolean en C (versus ce qui existe en assembleur) m'a vraiment
déconcerté...
curieux car pour toutes les machines (qq soit le proc) c'est "built-in"
...

ça date de quand exactement C (il y a un C89 donc début années 80 ?)

[...]

j'ai lu un tutau qui disait que l'ordre des
méthodes était indifférent. J'ai constaté que ce n'est pas vrai.


Je ne parlais pas des méthodes mais des includes.


oui, je savais ça...
--
une bévue


Avatar
Pascal Bourguignon
Eric Levenez writes:

Le 17/08/06 1:17, dans , « Pascal
Bourguignon » a écrit :

Eric Levenez writes:

Le 16/08/06 22:50, dans ,
« Pascal Bourguignon » a écrit :

#define PTR(x) (&(x))
#define DEREF(x) (*(x))
etc...


Très mauvaise habitude. Cela doit être dans la FAQ du C : ne jamais essayer
de cacher un pointeur que ce soit par un define ou par un typedef.


Il n'est pas caché, il est mis en ÉVIDENCE, avec trois ou cinq
caractères majuscules au lieu d'un seul. ;-)


En règle générale, les macros sont la plaie du langage C. Ils apportent une
illisibilité du code et des effets de bord toujours surprenant. J'ai déjà vu
du code (C je le précise) du type

DECLARE(int, i);

/* ... */

FOREVER

if (IS_ZERO(i))
EXIT_LOOP;

/* ... */

ENDFOREVER

Comme tu le vois, là aussi tout est en ÉVIDENCE, mais ce n'est pas lisible à
mon goût.

Quand on commence à maquiller le langage c'est qu'on ne se l'est pas
approprié et qu'on essaye de le faire coller à autre chose. Le problème est
alors que cette autre chose est différente pour chaque personne (d'où des
problèmes), alors que le langage de départ est lui identique pour chacun.



Je mentionnerais simplement qu'un des gros intérêt de Lisp, c'est ses
macros, qui permettent de concevoir un tel "vocabulaire", de réaliser
en fait un DSL (Domain Specific Language), véritable langage "métier",
qui permet de décrire le problème à un plus haut niveau que le langage
machine.

Voir par exemple cet article, "Runnable pseudo-code":
http://groups.google.com/group/comp.lang.lisp/msg/a827235ce7466a92?hl=en


Les macros C sont extrêmement rudimentaires comparés aux macros Lisp,
mais si on peut concevoir un langage de plus haut niveau avec elles,
sans avoir à modifier le compilateur ou le pré-processeur, c'est déjà
ça. Un bon exemple, c'est les exceptions en Objective-C:

NX_DURING
...
if(error){ NX_RAISE(error); }
...
NX_HANDLER
...
NX_ENDHANDLER

Un autre exemple: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html



Il y a toute une école parmis les programmeurs "C" (unix en fait), qui
ne fait que ça, développer des DSL, en utilisant lex et yacc, et
écrivant des méta-programmes. Seulement avec un langage comme C,
c'est compliqué (il faut passer par des outils externes comme lex,
yacc, et make, et des préprocesseurs (Objective-C, C++, ProC, etc)).
Avec Lisp et ses macros insupérables, on fait tout dans le même
environment, toujours avec le même langage, même si chaque macro
(comme chaque fonction), c'est un nouveau mot du langage.



Enfin, pour bien voir qu'il n'y a aucune raison d'ostraciser les
macros, il faut se rendre compte qu'elles ne représentent qu'un type
d'abstraction de plus. On a :

- les abstraction de données (types),
- les abstractions procédurales (fonctions),
- les abstractions syntaxiques (macros), et
- les abstractions meta-linguistiques (eval, yacc).

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://www.gustavus.edu/+max/concrete-abstractions.html


--
__Pascal Bourguignon__ http://www.informatimago.com/

WARNING: This product warps space and time in its vicinity.




Avatar
Pascal Bourguignon
(Une bévue) writes:

Eric Levenez wrote:

La gestion des booléens en C est un problème depuis les origines car il
n'était pas défini dans le K&R et que chaque programmeur le redéfini dans
son bout de code. Si on mélange 2 bouts de code de 2 programmeurs différents
on a potentiellement des problèmes. Maintenant on a le type "bool" en C99,
mais cela n'est pas encore bien accepté par tous les programmeurs. Sans
parler des anciennes API qui ne peuvent pas changer.

Bref Apple ne fait pas, ou ne peut pas faire pour des raisons historiques,
les choses proprement. Et c'est bien dommage.

La gestion des booléens est très compliquée car elle semble simple. On t'a
indiqué sur fr.comp.lang.c certains pièges liés aux tests (impliquant des
hideux define). Et on trouve encore hélas du code avec des choses du genre :

if (not_present != false)



ce pb de boolean en C (versus ce qui existe en assembleur) m'a vraiment
déconcerté...
curieux car pour toutes les machines (qq soit le proc) c'est "built-in"
...


C'est "built-in", mais c'est dépendant du processeur!

Par exemple, le 680x0 a un "type" booléen. Quand on utilise les
instructions SF, ST, Scc (cc pouvant être n'importe laquelle des 14
autres conditions), on obtient un octet valant 0 ou 255.

Donc, le booléen natif sur un processeur 680x0, ce serait:

typedef enum { false=0x00, true=0xFF } bool;

Maintenant, les compilateurs peuvent facilement passer de ces valeurs
à d'autres, comme: (char)0 et (char)1 [neg.b], ou: (int)0 et (int)-1
[ext.w + ext.l].


ça date de quand exactement C (il y a un C89 donc début années 80 ?)


L'histoire n'est pas ton fort, hein! C, ça date de 1969, il a été
inventé pour programmer unix, en évolution de BPCL et B. (Voir le
site d'Éric Levenez).

--
__Pascal Bourguignon__ http://www.informatimago.com/

CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.


1 2 3 4