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
Une bévue wrote:

Bingo ! ça change tout, plus d'erreur depuis que j'ai mis mon "void
Init_raliasfile()" à la fin de mon *.c (c'est ton mettre <ruby.h> à la
fin + supprimer mes protos qui m'y a fait penser...)


Heu, mettre un prototype à la fin (après l'implémentation de la fonction
en question donc j'imagine) c'est totalement inutile.

c'est dingue ce changement en déplaçant <ruby.h>...
euh, c'est une question de collision entre nom de constantes/variables
???


Oui, ça m'en a tout l'air.

il n'y a pas de namespace ???


Eh non. C est très primitif de ce coté là, idem pour Objective-C qui
contourne le problème en suggérant d'utiliser un préfixe dans les noms
de classes, ce qui n'est rien d'autre qu'un gros hack puant.

--
Luc Heinrich

Avatar
pere.noel
Luc Heinrich wrote:


Heu, mettre un prototype à la fin (après l'implémentation de la fonction
en question donc j'imagine) c'est totalement inutile.


ce n'et pas ce que j'ai dit, j'ai supprimé mes protos, et du coup dans
mon init, qui déclare toutes les méthodes, j'avais une erreur par
méthode, il m'a suffit de mettre l'init à la fin pour régler ça.

D'ailleurs dans un tuto j'ai lu qqpart que l'ordre des méthodes était
indifférent, mon expérience dit que c'est le contraire ???

Who knows ???


c'est dingue ce changement en déplaçant <ruby.h>...
euh, c'est une question de collision entre nom de constantes/variables
???


Oui, ça m'en a tout l'air.

il n'y a pas de namespace ???


Eh non. C est très primitif de ce coté là, idem pour Objective-C qui
contourne le problème en suggérant d'utiliser un préfixe dans les noms
de classes, ce qui n'est rien d'autre qu'un gros hack puant.


ouais je suis très surpris par C, ma première formation est ingé
électronicien, donc j'ai fait pas mal d'assembleur, à part une certaine
portabilité, je trouve que C n'apporte pas grand chose de plus qu'un
macro-assembleur + une bonne lib pour les fonctions usuelles (???)


--
une bévue


Avatar
Eric Levenez
Le 16/08/06 17:26, dans
<1hk6atj.1qi5wwx1qfidtlN%, « Une bévue »
a écrit :

ouais je suis très surpris par C,


Évidemment, tu utilises ce langage à tâtons, sans l'avoir appris et sans
avoir lu le moindre livre ou même la norme. De ce que j'ai lu de tes posts,
tu penses que quand ton programme C ne plante pas c'est qu'il est bon, et
quand il plante tu postes aussitôt une question.

ma première formation est ingé
électronicien, donc j'ai fait pas mal d'assembleur, à part une certaine
portabilité,


Pour faire du C portable, il faut bien connaître le langage et donc la
norme.

je trouve que C n'apporte pas grand chose de plus qu'un
macro-assembleur + une bonne lib pour les fonctions usuelles (???)


Cette impression vient de la façon dont tu essayes d'apprendre les bases du
langage C.

--
É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:


Évidemment, tu utilises ce langage à tâtons, sans l'avoir appris et sans
avoir lu le moindre livre ou même la norme. De ce que j'ai lu de tes posts,
tu penses que quand ton programme C ne plante pas c'est qu'il est bon, et
quand il plante tu postes aussitôt une question.


pas du tout je n'ai d'ailleurs aucune ambition en C, mais, je me répète
les problèmes que j'ai ont été nettement moins du à ma méconnasissance
de C en lui-même, ce que je suis pêt à accorder très facilement, qu'à
l'environnement.

le dernier pb qu'a résolu Luc Heinrich (ie mettre #include <Ruby.h> à la
fin de mes includes) n'a pas grand chose à voir avec C, mais plutôt à
des collisions de noms entre les différents include.

ma première formation est ingé
électronicien, donc j'ai fait pas mal d'assembleur, à part une certaine
portabilité,


Pour faire du C portable, il faut bien connaître le langage et donc la
norme.


je doute vraiment que du C "portable" ça existe ;-)

déjà les devs qui font du MacIntel (donc en ObjC ont quelques soucis...)


je trouve que C n'apporte pas grand chose de plus qu'un
macro-assembleur + une bonne lib pour les fonctions usuelles (???)


Cette impression vient de la façon dont tu essayes d'apprendre les bases du
langage C.


c'est quoi les "bases" ?
les pointeurs, c'est une notion immédiate pour qq'un qui a programmé en
assembleur, ce qui est moins immédiat ce sont les conventions d'écriture
adoptées par C. Là oui j'ai encore des difficultés à repérer dans le
code si j'ai affaire à un pointeur ou pas, question d'expérience je
pense.

j'ai fait des exos C standard, je continuerai à en faire mais en aucun
cas il ne m'ont été utiles pour le petit bout de code que j'ai écrit.

quant à la doc je me suis rendu compte que la doc Apple est
contradictoire sur certaines fonctions CF### que j'ai utilisées à tel
point qu'un type sur CocoaDev m'a prétendu que ce n'était pas possible à
faire sauf en AppleScript, qu'il avait lu ça sur une page Apple qu'il
m'a filé en ref. Je lui ai filé une autre page en ref, tjs d'Apple,
disant le contraire en donnant un exemple comment le réaliser...
Il a fait un bugg report à ce sujet.

ça ne m'étonne pas jadis j'ai été dir tech dans une boite où une grande
partie du catalogue était faux, au détriment de la boite d'ailleurs, ils
annoncaient des specs pour leurs produits qui étaient les specs des
intruments de mesure, les produits étant nettement meilleurs.

j'ai travaillé aussi dans une grosse boite (américaine) et là le
département qui s'occupait de la doc était clairement un "placard à
balais"...
--
une bévue


Avatar
Pascal Bourguignon
(Une bévue) writes:
c'est quoi les "bases" ?
les pointeurs, c'est une notion immédiate pour qq'un qui a programmé en
assembleur, ce qui est moins immédiat ce sont les conventions d'écriture
adoptées par C. Là oui j'ai encore des difficultés à repérer dans le
code si j'ai affaire à un pointeur ou pas, question d'expérience je
pense.


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

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

CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.

Avatar
Eric Levenez
Le 16/08/06 21:34, dans
<1hk6lxx.4173apedxfb1N%, « Une bévue »
a écrit :

Eric Levenez wrote:

Évidemment, tu utilises ce langage à tâtons, sans l'avoir appris et sans
avoir lu le moindre livre ou même la norme. De ce que j'ai lu de tes posts,
tu penses que quand ton programme C ne plante pas c'est qu'il est bon, et
quand il plante tu postes aussitôt une question.


pas du tout


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

je n'ai d'ailleurs aucune ambition en C, mais, je me répète
les problèmes que j'ai ont été nettement moins du à ma méconnasissance
de C en lui-même, ce que je suis pêt à accorder très facilement, qu'à
l'environnement.


Il y a certes l'environnement, mais i y a aussi les bases du C.

le dernier pb qu'a résolu Luc Heinrich (ie mettre #include <Ruby.h> à la
fin de mes includes) n'a pas grand chose à voir avec C, mais plutôt à
des collisions de noms entre les différents include.


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.

ma première formation est ingé
électronicien, donc j'ai fait pas mal d'assembleur, à part une certaine
portabilité,


Pour faire du C portable, il faut bien connaître le langage et donc la
norme.


je doute vraiment que du C "portable" ça existe ;-)


Et bien si, cela existe. Cela se fait à plusieurs niveaux et cela peut se
faire plus ou moins bien. Cela va de l'utilisation d'une norme bien définie
à l'écriture propre d'un programme multi-platforme. Mais la base c'est le
C99 (certains utilisent même la norme précédente prétextant des problèmes de
compilateur).

déjà les devs qui font du MacIntel (donc en ObjC ont quelques soucis...)


Oui certains développeurs sur Mac Intel en Objective-C ou C++ peuvent avoir
des problèmes s'ils n'ont pas pensé à la portabilité. Si tu prends un
programme C sur GNU/Linux il a de grande chance de tourner sur plusieurs
types de CPU car le programmeur connaît les contraintes liées à la
portabilité. Sur Mac, la notion de portabilité est une notion qui commence à
voir le jour, mais c'est en cours grâce aux changements 32/64 bits et
big/little endian.

je trouve que C n'apporte pas grand chose de plus qu'un
macro-assembleur + une bonne lib pour les fonctions usuelles (???)


Cette impression vient de la façon dont tu essayes d'apprendre les bases du
langage C.


c'est quoi les "bases" ?


Que veux tu comme définition ? Les bases sont les bases. Il n'existe pas une
définition qui dise ça c'est dans les bases et cela ne l'est pas.

les pointeurs, c'est une notion immédiate pour qq'un qui a programmé en
assembleur, ce qui est moins immédiat ce sont les conventions d'écriture
adoptées par C. Là oui j'ai encore des difficultés à repérer dans le
code si j'ai affaire à un pointeur ou pas, question d'expérience je
pense.


Voilà, les pointeurs font partie des bases.

j'ai fait des exos C standard, je continuerai à en faire mais en aucun
cas il ne m'ont été utiles pour le petit bout de code que j'ai écrit.


Il faut commencer par lire un bon livre sur le C. Regarde la FAQ de
fr.comp.lang.c pour des titres.

quant à la doc je me suis rendu compte que la doc Apple est
contradictoire sur certaines fonctions CF### que j'ai utilisées


Cela arrive.

Tiens un simple exemple : si tu cherches à "convertir un int en char" (sic)
tu trouveras sur Internet 36 sites tous plus pourris les uns que les autres
qui donnent des solutions qui marchent parfois. On trouve aussi des
solutions fausses ou incomplètes ou non portables ou...

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



Avatar
Eric Levenez
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.

--
É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:
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.

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.

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, 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.


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.
--
une bévue

Avatar
Pascal Bourguignon
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. ;-)

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

WARNING: This product attracts every other piece of matter in the
universe, including the products of other manufacturers, with a
force proportional to the product of the masses and inversely
proportional to the distance between them.


Avatar
JM Marino
Le Thu, 17 Aug 2006 01:17:54 +0200, 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. ;-)
je suis d'accord avec Eric Levenez, tu prends un risque ENORME avec les

define de passer pas mal de temps à trouver un bug lié à un effet de
bord induit...

pourquoi cacher ce qui est BEAU et PERFORMANT...



1 2 3 4