Discussion :

[blaise_laporte]

Bonjour les gens.

Développeur débutant, je suis en dernière année d’école d’ingé en informatique et électronique.

Pour mon projet, je voudrais faire une application sur mac.
Le but récupérer les mouvement de la main via iSight et interagir avec OS X ; mais l’objectif est surtout d’apprendre à développer sur mac et de s’initier au traitement d’image.

Peut être m’avez vous déjà croisé sur le forum java. Pour mon entreprise (mon école est un alternance ! L’alternance, c’est bon, mangez en!) j’ai développer des petite application dans ce langage et je commence à pas trop mal le connaître (sans être un pros, loin de la!).

Pour en revenir au projet, je pensais utiliser l’Objectif-C et Cocoa (je suis pas fan du C et C++, j’ai donc laissé de coté Carbon), ainsi que le java pour faire des test de faisabilité (et parce que j’ai acheter le bouquin “introduction au traitement d’image” où exemples sont en java). Le tout sous X-Code. Pensez vous que ce soit un bon choix?

Coté matos, je programme sous macBook core2duo 2Ghz et 1Go de RAM.
Juste pour vous prévenir que je risque d’être assez présent sur le forum ces prochains jour pour posé des question, demander conseil et autre ; et que vous sachiez de quoi je parle.

Merci

Blaise

[AuraHxC]

Ton projet est très intéressant
Je ne connais pas du tout objective-c donc je peux pas te dire si c'est une bonne idée... Mais je crois que c'est pas très compliqué comme langage, enfin si tu connais déjà la programmation
Perso je suis plus Java, C et C++.

Tiens nous au courant de ton avancé, ça m'intéresse en tout cas.

[Mala]

Bienvenue à toi.

Bonjour les gens.
...ainsi que le java pour faire des test de faisabilité (et parce que j’ai acheter le bouquin “introduction au traitement d’image” où exemples sont en java).

Donc si c'est pas faisable en Java ça le sera pas non plus dans un autre langage? Je plaisante bien sûr. C'est important de rentabiliser ses investissements.

Si tu as des questions n'hésites pas. On trouvera bien deux/trois bricolos qui ont des connaissances en Obj-C dans le coin.

[blaise_laporte]

Donc si c'est pas faisable en Java ça le sera pas non plus dans un autre langage? Je plaisa

Disons plutot : si je ne suis pas capable de le faire en java, peut probable que je sache le faire dans un autre langage...

Merci des encouragement

[kOrt3x]

Salut, il est très interresant ton projet, bon courage.

Si ça peut d'aider, je connais un économiseur d'écran qui fait des effets avec iSight (http://www.stone.com/)
Au cas où.

bon courage.

[Mala]

Bonjour les gens.
Pour en revenir au projet, je pensais utiliser l’Objectif-C et Cocoa (je suis pas fan du C et C++, j’ai donc laissé de coté Carbon),

Tu sais qu'à la base Objectve-C est basé sur le langage C?
Donc cela veux dire être familier avec les notions de pointeurs et de gestion mémoire. Ce qui n'est pas l'apanache des Javayens en général.

Le tout sous X-Code. Pensez vous que ce soit un bon choix?

Objective-C/Xcode est un très bon choix. Le plus déroutant au début est surtout l'intéraction entre Interface Builder et Xcode pour concevoir des IHM.

[blaise_laporte]

Tu sais qu'à la base Objectve-C est basé sur le langage C?
Donc cela veux dire être familier avec les notions de pointeurs et de gestion mémoire. Ce qui n'est pas l'apanache des Javayens en général.

Bouuuuuuuh j'vais bouder!

en faite, plus que les pointeur et la gestion de la mémoire (parfois trop absencte dans java...) ce sont les fichier .h que je n'arrive jamais à utilisé correctement. Ca, et le principe des commande préprocesseur! Mais bon, aprés quelque lecture, je constate que les fichier header sont aussi présent dans Objectif-C, faudrat que je fasse avec.

j'avais entendue dire que Objectif-c, ça se programmait comme du java... Si je remet la main sur ce guss!

[Voyvode]

Donc cela veux dire être familier avec les notions de pointeurs et de gestion mémoire. Ce qui n'est pas l'apanache des Javayens en général.

Détrompe-toi, Objective-C a un ramasse-miette ! La différence c'est qu'en Java il est autonome, ici faut l'appeler manuellement, c'est tout.
Donc si t'aimes bien les pointeurs, tu seras pas trop dépaysés . Mais crois-moi, sur un gros projet ça t'évitera bien des ulcères !

Ca, et le principe des commande préprocesseur! Mais bon, aprés quelque lecture, je constate que les fichier header sont aussi présent dans Objectif-C, faudrat que je fasse avec.

Etant très inspiré de Java, il ne me semble pas que Objective-C ait de commandes préprocesseurs. Quant aux headers, c'est du raisonnement objet je crois : Headers = Champs (edit : enfin ça doit être comme ça en C++ non ? ^^).

[AuraHxC]

En général les headers servent a mettre les prototypes des fonctions et les structures que tu vas utiliser (en langage C).
En C++, les .h te permette de déclarer tes classes ou plus souvent un classe avec dedans les champs et les prototypes des méthodes... et dans le .c du .h tu va implémenter concrètement les méthodes de ta classe.

Enfin moi j'ai toujours fait comme ça --> j'ai juste fait du C++ avec wxwidgets et OpenGL donc je sais pas quand tu fais du C++ simplement si il faut faire comme ca mais a mon avis si

[Mala]

Détrompe-toi, Objective-C a un ramasse-miette !

Ce n'est pas parcequ'on dispose d'un pool d'autorelease en Obj-C qu'on l'utilise systématiquement. Son utilité est avant tout destinée à partager des ressources. Comme j'ai un peu la flemme de réexpliquer, voir mes interventions ici. Faire l'amalgame "autrorelease pool" = "Garbage collector" est un raccourci dangereux.

Obj-C 2.0 intégrera un véritable ramasse miette avec Léopard. Les dévelopeurs pourront ainsi choisir.

Donc si t'aimes bien les pointeurs, tu seras pas trop dépaysés .

Quel rapport entre utilisation d'un GC et pointeurs???

Mais crois-moi, sur un gros projet ça t'évitera bien des ulcères !

- soupir de consternation -

Etant très inspiré de Java, il ne me semble pas que Objective-C ait de commandes préprocesseurs.

Obj-C est inspiré de SmalTalk. A ce titre il offre une approche dynamique que l'on ne retrouve pas dans Java ou C++. Il est fondé sur du C donc bien sûr on peut utiliser des commandes préprocesseurs (un simple #include est déjà une commande préprocesseur).

Quant aux headers, c'est du raisonnement objet je crois : Headers = Champs (edit : enfin ça doit être comme ça en C++ non ? ^^).

headers = entête. Cela n'a rien à voir avec une approche objet au sens strict du terme. On les utilisent pour dissocier la partie déclaration de la partie implémentation. Cela fait partie des "bonnes pratiques" (car rien ne nous y oblige fondamentalement) qui permettent de structurer le code, d'accéder aux fonctions de notre fichier sources en incluant le .h souhaité dans d'autres fichiers. On utilise aussi le fichier d'entête pour y introduire la documentation (ainsi nul besoin d'aller voir le source pour comprendre le fonctionnement de telle ou telle fonction/méthode/classe). Cela fait aussi partie des "bonnes pratiques" en C++.

[Tarul]

Ce n'est pas parce qu'on dispose d'un pool d'autorelease en Obj-C qu'on l'utilise systématiquement. Son utilité est avant tout destinée à partager des ressources. Comme j'ai un peu la flemme de réexpliquer, voir mes interventions ici. Faire l'amalgame "autrorelease pool" = "Garbage collector" est un raccourci dangereux.

Tient, tu es aussi chez macg toi?

Obj-C 2.0 intègrera un véritable ramasse miette avec Léopard. Les développeurs pourront ainsi choisir.

Es-tu sûr que l'on aura le choix? Je n'ai pas vu qu'il laissé la possibilité d'utiliser le GC ou "à la mano" la gestion de la mémoire.

Quel rapport entre utilisation d'un GC et pointeurs???


- soupir de consternation -


Obj-C est inspiré de SmalTalk. A ce titre il offre une approche dynamique que l'on ne retrouve pas dans Java ou C++. Il est fondé sur du C donc bien sûr on peut utiliser des commandes préprocesseurs (un simple #include est déjà une commande préprocesseur).


headers = entête. Cela n'a rien à voir avec une approche objet au sens strict du terme. On les utilisent pour dissocier la partie déclaration de la partie implémentation. Cela fait partie des "bonnes pratiques" (car rien ne nous y oblige fondamentalement) qui permettent de structurer le code, d'accéder aux fonctions de notre fichier sources en incluant le .h souhaité dans d'autres fichiers. On utilise aussi le fichier d'entête pour y introduire la documentation (ainsi nul besoin d'aller voir le source pour comprendre le fonctionnement de telle ou telle fonction/méthode/classe). Cela fait aussi partie des "bonnes pratiques" en C++.

Sans compter que c'est par les headers que l'on voit quelles méthodes et quelles classes (enfin dans le cas Objc et c++) que l'on peut utiliser lorsqu'on importe un framework.


Lorsque l'on utilise Xcode+IB, IB peut lire un header pour rajouter par exemple les outlet qui auraient été modifiés par xcode.

[Voyvode]

Obj-C 2.0 intégrera un véritable ramasse miette avec Léopard. Les dévelopeurs pourront ainsi choisir.

Nan nan, je ne fais pas d'amalgame, j'ai clairement vu "manual garbage collector" ou un truc dans ce goût la dans la doc Xcode.
T'es sûr que c'est dans la 2.0 ? Parce que je suis certain d'avoir vu ça dans Xcode (dernière version stable d'il y a quelques mois).

Quel rapport entre utilisation d'un GC et pointeurs???

Je plaisantais. Je voulais dire que s'il aime bien trifouiller la mémoire, au moins avec le GC manuel il aura l'impression d'y toucher encore un tout chti peu.

Willy_XIII a écrit :
Mais crois-moi, sur un gros projet ça t'évitera bien des ulcères !
- soupir de consternation -

Ulcer addicts really like C a lot... (Bruce Eckel, Thinking in Java)
Et ouais pro-Apple et pro-Java... Tous les défauts ().

Obj-C est inspiré de SmalTalk. A ce titre il offre une approche dynamique que l'on ne retrouve pas dans Java ou C++. Il est fondé sur du C donc bien sûr on peut utiliser des commandes préprocesseurs (un simple #include est déjà une commande préprocesseur).

C'est vrai, ça je ne m'en souvenais pas. Mais il me semble qu'il ne soit pas forcément nécessaire de manipuler ces commandes (du moins pas autant qu'en C) ?

headers = entête. Cela n'a rien à voir avec une approche objet au sens strict du terme

Hey ! Mon anglais n'est pas si mauvais que ça ! Non mais...
Autant pour moi pour les champs... grosses bêtises. Mais même si ça n'a rien d'objet, un .h est une interface et en objet c'est assimilable à des méthodes (puisqu'elles constituent l'interface de l'objet). Effectivement comme tu () le dit, c'est juste une "bonne pratique" car même étant peu familiarisé au C, je sais que ce langage part du principe que le programmeur sachant ce qu'il est fait, il y a peu de limites à tel point qu'on peu vraiment avoir son style de programmation (et son style de grosses conneries aussi ).

[Mala]

Nan nan, je ne fais pas d'amalgame, j'ai clairement vu "manual garbage collector" ou un truc dans ce goût la dans la doc Xcode.
T'es sûr que c'est dans la 2.0 ? Parce que je suis certain d'avoir vu ça dans Xcode (dernière version stable d'il y a quelques mois).

Je n'ai pas souvenir d'avoir lu une telle référence dans les doc d'Apple. Le terme n'est pas mauvais en soit.

il aura l'impression d'y toucher encore un tout chti peu.

En fait, il ne faut pas oublier qu'OS X est loin d'avoir été codé à 100% Obj-C. De nombreuses API (sur les bases de bsd) induisent de passer par du pure C. Et là la mémoire il faut bien la gérer.

Ulcer addicts really like C a lot... (Bruce Eckel, Thinking in Java)
Et ouais pro-Apple et pro-Java... Tous les défauts ().

Chaque langage a ses adeptes.

C'est vrai, ça je ne m'en souvenais pas. Mais il me semble qu'il ne soit pas forcément nécessaire de manipuler ces commandes (du moins pas autant qu'en C) ?

Mis à part avec les #include, on ne les utilisent pas tant que ça que ce soit en Obj-c, en C ou en C++.

Hey ! Mon anglais n'est pas si mauvais que ça ! Non mais...

Oeuf corse! Loin de moi cette idée folle!

Autant pour moi pour les champs... grosses bêtises. Mais même si ça n'a rien d'objet, un .h est une interface et en objet c'est assimilable à des méthodes (puisqu'elles constituent l'interface de l'objet).

Tout a fait.

Effectivement comme le dit Tarul c'est juste une "bonne pratique"

C'est Tarul qui a dit ça???

car même étant peu familiarisé au C, je sais que ce langage part du principe que le programmeur sachant ce qu'il est fait, il y a peu de limites à tel point qu'on peu vraiment avoir son style de programmation (et son style de grosses conneries aussi ).

Ca c'est un long débat.

Tarul, et oui aussi sur MacGé. Faut bien s'instruire et se tenir informé tout de même!
Sinon, je te confirme, il sera possible de choisir le mode de gestion mémoire au niveau du projet (appli,framework,etc). Je ne me rappelle plus ou j'ai vu ça si c'était dans des specs ou bien dans les vidéos de la WWDC de l'année dernière.

[Tarul]

C'est Tarul qui a dit ça???

Oui je sais, je suis trop fort.

Ca c'est un long débat.

Tarul, et oui aussi sur MacGé. Faut bien s'instruire et se tenir informé tout de même!

On se retrouve vraiment partout en ce moment je trouve.

Sinon, je te confirme, il sera possible de choisir le mode de gestion mémoire au niveau du projet (appli,framework,etc). Je ne me rappelle plus ou j'ai vu ça si c'était dans des specs ou bien dans les vidéos de la WWDC de l'année dernière.

Bonne nouvelle alors. C'est bien d'avoir le choix. Le GC va me permettre d'aller plus vite pour les petites application(et je suis un gros flemmard et ni très doué au niveau gestion de mémoire).

[Voyvode]

Willy_XIII a écrit :
Effectivement comme le dit Tarul c'est juste une "bonne pratique"

C'est Tarul qui a dit ça???

Heu, j'ai jamais dit que c'était Tarul... Relis bien. (merci le bouton Edit ^^).

Mala (alias Tarul ) a écrit :
En fait, il ne faut pas oublier qu'OS X est loin d'avoir été codé à 100% Obj-C.

Ouais ça je le savais plus ou moins. Un bon schéma vaut mieu qu'un long discours .