C++ et XCode

Bonjour tout l'monde, c'est encore moi, j'viens encore vous embêter...


 


Je travaille actuellement sur de l'Audio et je m'inspire fortement du sample d'Apple ExtAudioFileConvertTest.


 


J'aimerais donc importer directement des fichiers en C++ dans mon application.

Il s'agit de CAMaths.h, CAXException.h (et .cpp), CADEbugMacros.h, CAStreamBasicDescription.h (et .cpp).


Je mets donc les fichiers dans mon application, dans le Search Header Paths, je rajoute /Developer/Extras/CoreAudio/PublicUtility, vu que y'a un fichier qui a en besoin.

Sauf que je me retrouve avec quelques soucis.


En effet, XCode ne veut pas comprendre que c'est du C++ et me sort donc les erreurs du type :


"Unknow type name 'class'; did you mean 'Class'? (notez la majuscule, ce qui est normal).



Soit. Je choisis mon projet, je vais dans Build Settings, et dans Apple LlVM compiler 4.1 - Language, je vois que sur le sample, c'est Compile Source As Objective-C++.

Ok, je dis donc la même chose sur mon application (bien que cela m'étonne que "According to file type") ne fonctionne pas sur mon projet.


Et là , j'me prends une nouvelle erreur au Build :

J'ai cette ligne qui pose problème :         



NSInteger bytesWritten = [[_session outputStream] write:[_writeData bytes] maxLength:[_writeData length]]; 

Avec comme erreur la suivante :


Cannot initialize a parameter of type 'const uint8 *' (aka 'const unsigned char*') with a rvalue fo type 'const void*'.

Code qui marche très bien sinon.


J'avouerais volontiers que les options de compilation et moi, ça fait deux...


 


Voilà  ce que j'ai essayé : J'ai mis le .m utilisant les fichiers CPP en .mm, mais même problème.



Donc, l'un de vous aurait une idée ?


Mots clés:

Réponses

  • Il me semble que uint8 n'est pas défini. Dans les frameworks on trouve UInt8 il me semble. Le compilateur doit être sensible à  la casse. J'ai un problème de ce type pour uint8, uint16 et uint32 dans un projet mixte C & Obj-C.


    Bon, ce n'est peut être pas ça!


  • LarmeLarme Membre
    juin 2013 modifié #3

    C'est bien zoli, mais j'vais pas modifier la méthode write:maxLenght donnée par le SDK pour un NSOutputStream, non ?

    Ou j'vais devoir faire des cast sauvages :o


  • Des cast c'est bien cela que tu dois faire. Le C++ est plus intransigeant que le C. Ainsi la méthode bytes de NSData est du type 'const void *' et la méthode write de NSOutputStream attend un 'const uint8_t *'... de souvenirs C++ n'aime pas ça.

  • MalaMala Membre, Modérateur
    juin 2013 modifié #5

    Est-ce que la bascule d'Obj-C à  Obj-C++ est bien prise en compte sous Xcode 4 lorsqu'on renomme une extension d'un fichier? Que dit le "File Type" dans "Indentity and Type" lorsque tu sélectionnes un fichier source? Avant d'aller plus loin, je regarderais déjà  ça.


     


    J'ai déjà  eu des déconvenues avec des noyaux OpenCL qui merdaient lors d'une migration d'Xcode 3 à  Xcode 4. Il voulait à  tout prix me les compiler alors que c'était de simples ressources de mon App.


  • tabliertablier Membre
    juin 2013 modifié #6

    Si c'est bien ça le problème, tu pourrais faire un fichier de définition du genre:


     


    #define uint8  UInt8


    #define uint16 UInt16


    ..


    ..


    .. etc


     


    Puis tu importes le fichier dans le nom_projet.pch de ton projet.


    Cela devrait marcher pour l'ensemble des fichiers du projet et les cast deviennent inutiles.


     


    Peut-être que les pro du forum auront une autre astuce!


  • LarmeLarme Membre
    juin 2013 modifié #7

    @Mala : Oui, il est bien reconnu comme fichier Objective-C++ dans le file type après l'avoir renommé en .mm


     


    Toujours bloqué cependant...

    J'ai essayé en mettant tes 2 #define @tablier, mais que nenni...


     


    Je me demande, si dans le BuildPhase/Compile Sources, je devrais lui rajouter dans le Compiler Flags quelque chose pour les .cpp


     


    à‰dit :


    Bon, j'ai fait un cast (comme un gros porc ?) juste devant l'erreur précédent sur la méthode de NSStream...


    ça a l'air de marcher.


  • Personnellement, j'ai rencontré souvent des problèmes, non pour compiler C++ dans un projet audio, mais plutôt pour utiliser les classes non core audio, telles que celles que tu indiques. Il semble qu'une sérieuse mise à  jour devrait être faite par Apple suite aux modifications de Core Audio dans Mac OS depuis Lion. 


     


    J'ai eu des problèmes avec une partie des classes complémentaires de Core Audio (les "PublicUtility" par exemple) jusqu'à  ce que je les supprime de mon projet. Quelqu'un m'avait aidé à  réécrire les classes les plus essentielles au fonctionnement d'un plug-in via Internet. Tu noteras au passage que XCode ne propose plus de template "Audio Unit"...


     


    Par ailleurs, Core Audio fonctionne avec des structures C pour l'essentiel. Autant un plug-in Audio Unit va avoir sa partie audio écrite en C++ (et sa partie graphique en Objectiv-C), autant quand je fais de l'audio dans une appli, j'utilise Objectiv-C, avec dans la méthode  "-(void)setUp"  et des "static OSStatus MyAURenderCallback{ //le code de mon synthé}dans le .m


     


    Peut-être devrais-tu voir si tu peux recopier le code qui t'intéresse dans les classes que tu veux utiliser et le réécrire? Comme beaucoup dérivent les unes des autres, ce ne sera pas simple, mais bon... coder de l'audio, une fois compris la logique, n'est pas si difficile.


Connectez-vous ou Inscrivez-vous pour répondre.