#pragma mark

Céroce

Vous pouvez utiliser le #pragma mark nomDuMarqueur pour placer des points de repères dans votre code; ils apparaà®tront alors dans la liste des méthodes de xCode. Regardez la copie d'écran jointe pour comprendre.

No

Un topic en parlait déjà  ici.
Mais avec la capture d'écran ci-dessus, c'est bien plus parlant !

Céroce

Exact, j'aurais dû faire une recherche avancée au lieu d'une recherche simple... 

schlum

Attention en cas de code portable (C++ etc...), ce pragma n'est pas reconnu par le compilateur de Windows.
Il faut donc l'entourer par #ifdef __APPLE__ et #endif

Céroce

Non, ce n'est pas nécessaire: Les #pragma non reconnus sont ignorés (dixit le Kernighan et Ritchie).

Philippe49

dans 1220464512:

Non, ce n'est pas nécessaire: Les #pragma non reconnus sont ignorés (dixit le Kernighan et Ritchie).

Confirmé en c99

Paisible.fr

dans 1220464512:

Non, ce n'est pas nécessaire: Les #pragma non reconnus sont ignorés (dixit le Kernighan et Ritchie).

Oui c'est ce que dit le " Kernighan et Ritchie" (je viens de regarder) maintenant c'est pas forcement ce que fait microsoft...
Ce serait pas la première fois qu'ils s'assoient sur un "standard", ou une "norme"

Maintenant je suis peut-être mauvaise langue car je n'ai pas testé... ::)

NseaProtector

J'adore les mauvaises langues  lol

schlum

dans 1220464512:

Non, ce n'est pas nécessaire: Les #pragma non reconnus sont ignorés (dixit le Kernighan et Ritchie).

Ignorés, c'est possible... mais ça fait au moins des tonnes de warnings parasites ! (surtout quand c'est dans les .h)

NseaProtector

Si je comprends bien leurs utilité toute relative,il est préférable pour les programmeurs multiplateformes de s'en passer tout simplement, non ?
Ou bien je ne vois pas dans quel cas c'est indispensable ? Il est aussi possible de les retirer avant la compilation en vue de distribution, non ?

schlum

dans 1220468703:

Si je comprends bien leurs utilité toute relative,il est préférable pour les programmeurs multiplateformes de s'en passer tout simplement, non ?
Ou bien je ne vois pas dans quel cas c'est indispensable ? Il est aussi possible de les retirer avant la compilation en vue de distribution, non ?

Pour organiser une classe C++ c'est très pratique...
Et si j'en parle c'est parce que j'ai eu le problème 

Je bosse sur un projet débuté sur Mac dans XCode mais qui doit rester portable (hors couches d'abstraction)...

Paisible.fr

dans 1220466388:

J'adore les mauvaises langues  lol

Ouais, et moi j'aime pas avancer des trucs en l'air en général.
J'ai donc lancé mon Visual C++ 7.1 (Visual Studio 2003 Pro) au travail.
Et j'ai fait le test avec le petit bout de code suivant :

<br />// TstPragma.cpp : Defines the entry point for the console application.<br />//<br /><br />#include &quot;stdafx.h&quot;<br />#include &lt;stdio.h&gt;<br /><br />//int _tmain(int argc, _TCHAR* argv&#91;])<br />main() {<br /><br />	#pragma mark TestDeMarqueurAvecVisualC++<br />	printf(&quot;Bonjour&#092;n&quot;);<br /><br />	return 0;<br />}

Au build ça donne :

------ Build started: Project: TstPragma, Configuration: Debug Win32 ------<br /><br />Compiling...<br />TstPragma.cpp<br />d:&#092;Documents&#092;==Tests==&#092;TstPragma&#092;TstPragma.cpp(10) : warning C4068: unknown pragma<br />Linking...<br /><br />Build log was saved at &quot;file://d:&#092;Documents&#092;==Tests==&#092;TstPragma&#092;Debug&#092;BuildLog.htm&quot;<br />TstPragma - 0 error(s), 1 warning(s)<br /><br /><br />---------------------- Done ----------------------<br /><br />&nbsp; &nbsp; Build: 1 succeeded, 0 failed, 0 skipped<br />

Voila, chacun sait à¡ quoi s'en tenir maintenant 

schlum

Vala 
Maintenant tu prends un gros projet avec des pramga mark un peu partout, parfois dans des .h, et tu comprendras vite que dans ce cas vaut mieux les entourer de #if  :P
(d'ailleurs j'ai dit des bêtises, même pas besoin de #ifdef __APPLE__ ; #if 0 suffit !)

Parce que retrouver un " vrai " warning au milieu de 10 000 du genre...

AliGator

Si on ne veux pas entourer tous les [tt]#pragma mark[/tt] d'un [tt]#if[/tt]... On peut aussi utiliser [tt]#pragma warning(disable:4068)[/tt] sous Visual pour qu'il ignore les pragmas non reconnus ^^
Comment ça on tourne en rond ?

...

Quoique remarque... en fait c'est pas si con... parce que du coup si on met ça dans notre Precompiled-Header inclus dans tous nos fichiers .h on n'a plus qu'à  entourer juste lui d'un [tt]#if[/tt], mais pas chaque #pragma mark ensuite ^^ arf

#ifndef __APPLE__<br />#pragma warning(disable:4068) /* Ignore unknown pragmas */<br />#endif

Une meilleure condition de [tt]#if[/tt] genre un truc caractérisant MS Visual Studio ou les compilos qui supportent [tt]#pragma warning(disable:...)[/tt] serait évidemment à  trouver, mais ça peut être un moyen rapide si vous avez à  porter votre code sous Visual pour éviter d'entourer tous vos [tt]#pragma mark[/tt]...

schlum

Bonne remarque... Moi j'y connais rien à  Visual, c'est juste le mec qui a voulu compiler le projet avec qui m'a engueulé 

Mais du coup c'est 4068 ou 4069 ?

warning C4068: unknown pragma

AliGator

4068 bien sûr, mon doigt a glissé :P

AliGator

Je déterre ce thread pour y rajouter quelques nouveautés que j'ai apprises :

1) Plutôt que d'utiliser "#pragma mark xxx" on peut utiliser "// MARK: xxx" qui marche exactement pareil... sauf que c'est un commentaire au lieu d'être une directive #pragma, donc du coup c'est portable
2) Dans la foulée en cherchant un peu sur le net j'en ai trouvé d'autres : "[tt]// TODO: xxx[/tt]", "[tt]// FIXME: xxx"[/tt], "[tt]// ???: xxx[/tt]" et "[tt]// !!!: xxx[/tt]"

Double avantage de la notation "commentaire" par rapport à  la notation "#pragma", c'est qu'en plus d'être portable, cela peut être mis à  la fin d'une ligne au lieu de prendre une ligne dédié à  ça. Exemple : (rendu dans le menu fourni en image jointe à  ce post)

/////////////////////////////////////////////////////////////////////////////<br />// MARK: -<br />// MARK: Init/Dealloc<br />/////////////////////////////////////////////////////////////////////////////<br />- (id) initWithFrame:(CGRect)frame<br />{<br />	self = [super initWithFrame:frame]; // ???: Is &quot;self = ...&quot; really useful ?<br />	if (self != nil) { <br />		[self initVariables]; // TODO: find a better name for this<br />	}<br />	return self;<br />}<br />- (id)initWithCoder:(NSCoder *)decoder<br />{<br />	self = [super initWithCoder:decoder]; // ???: Is &quot;self = ...&quot; really useful ?<br />	if (self != nil) {<br />		[self initVariables]; // TODO: find a better name for this<br />	}<br />	return self;<br />}<br />- (void) initVariables<br />{<br />	// TODO: init instance variables here<br />}<br />- (void) dealloc<br />{<br />	// FIXME: We forgot to release instance variables, there is a leak here !<br />	[super dealloc]; // !!!: Don&#39;t forget to call this one!<br />}

Le truc c'est que pour "[tt]TODO:[/tt]","[tt]FIXME:[/tt]", "[tt]???:[/tt]" et "[tt]!!!:[/tt]" on a un résultat... équivalent à  "[tt]// MARK: xxx[/tt]", ça s'affiche pareil. Plus exactement même "[tt]// TODO: xxx[/tt]" est exactement équivalent à  "[tt]// MARK: TODO: xxx[/tt]", "[tt]// !!!: yyy[/tt]" est exactement équivalent à  "[tt]// MARK: !!!: yyy[/tt]"...
Du coup je trouve ça dommage (quoique TODO et FIXME sont des classiques souvent vus dans les commentaires de codes, Obj-C/Xcode ou non)...
En effet autant les "MARK" servent souvent pour groupes/séparer les méthodes entre elles, donc c'est pratique de les voir s'afficher ainsi dans le menu... Mais les "[tt]TODO/FIXME/???/!!![/tt]" par contre autant les avoir dans le menu c'est pratique car on peut ainsi y "sauter" directement aussi pour y accéder... mais c'est un peu dommage de pas par exemple les avoir mis en couleur ou en gris pâle et/ou plus décalés que ça dans le menu du coup...


En tout cas je n'ai vu aucune trace de toutes ces astuces dans la documentation de Xcode (même pas les "#pragma mark" qui pourtant maintenant sont très courants et utilisé par bcp de monde vu que l'astuce s'est bien répandue), même dans la partie "Xcode Text Editor de la doc"... d'autant que d'après ce que je vois sur les quelques rares sites où j'ai trouvé cette astuce, ça y était avant (ils fournissent un lien vers la doc... mais qui est 404)

Donc si vous avez d'autres astuces dans le genre, des mots-clés/commentaires aux pouvoirs magiques non documentés...

---

[EDIT]/PS : Si vous êtes comme moi aussi utilisateur des TextMacros, je vous conseille d'en rajouter une qui vous permet de rapidement insérer des "séparateurs" dans votre code et dans le menu de méthodes, du style une TextMacro qui insère ceci :

/////////////////////////////////////////////////////////////////////////////
// MARK: -
// MARK: <#name#>
/////////////////////////////////////////////////////////////////////////////

(où "<#name#>" est vu comme un placeholder par l'éditeur de texte de Xcode, permettant d'y aller/de le sélectionner et remplacer par du vrai texte très rapidement aussi)... Moi je trouve ça très pratique aussi, tant qu'on est dans les astuces :P

Philippe49

ClicCool

Merci 




(et un petit up au passage pour ceux qu'auraient loupé ça )

System

Bha.. j'avais loupé 
Merci pour ces précisions que je ne connaissais pas  :-*