enum {Start, Working, End} state = Start;
...
state++;
struct {
char c;
Token tokType;
} uniCharTokDict[] = {
{'(', T_LEFTPAR},
{')', T_RIGHTPAR},
{'.', T_DOT},
...
};
c'te horreur
public class Anonymous {
public String toString() {
return "tits or gtfo, lulz";
}
}System.out.println(
new Object() {
public String toString() { return "M4demoiselle, veuillez avoir l'amabilité de montrer vos tits"; }
});
struct Object {
string toString();
};
int main() {
struct: Object {
string toString() { return "tits"; }
} obj;
cout << obj.toString();
return 0;
}Pen^2 (./1356) :
+@Override
?
class Test
{
int variablePrivée;
public int PropriétéPublique {
get { return variablePrivée; }
}
}
nomDeVariable -> C++ nomdevariable -> C Nom_De_Variable -> Ada NomDeVariable -> C# nom_de_variable -> C quand moi j'en fais nom.de.variable -> Java (troll)
GoldenCrystal (./1327) :
Ah, grâce à JackosKing, j'ai compris le problème \o/
Je sais toujours pas à quoi servent tes task et tes modules, mais en gros, les méthodes d'action devraient se situer dans une classe plus générale, disons une classe "Main" (parce que je comprends pas ton architecture de task et module), qui serait un singleton. (ça t'évite de passer l'instance de partout même si ça serait une manière plus propre de faire)
Dans ta classe Main tu as par exemple DoAddUnit(), DoKillSelectedUnits(), DoBuyItem(), etc. (ce sont des exemples, et je met le Do ici pour bien montrer que ce sont des actions, mais en vrai on s'en fout ^^).
Ensuite, tu peux avoir ton fichier de définition d'icônes. Par exemple:// Classe Icon de base class Icon { const std::string title; const std::string image; // En vrai il faudrait peut être stocker une ressource SDL à la place public: Icon(const std::string& title, const std::string& image) : title(title), image(image) { } const std::string& getTitle() { return title; } const std::string& getImage() { return image; } virtual void Action() = 0; }; #define REGISTER_ICON(title, image, action) class action ## Icon : public Icon { public: action ## Icon () : Icon(title, image) { } void Action() { Main::getInstance(). ## action ## (); } }; REGISTER_ICON("Buy Item", "buy.png", DoBuyItem) REGISTER_ICON("Kill Units", "kill.png", DoKillSelectedUnits) // Etc.Y'a moyen de faire mieux (c'est un exemple semi à l'arrache, idéalement tu pourrais même utiliser des classes anonymes pour les icônes, sous certaines conditions) et je suis pas complètement sur de pas m'être foiré sur la macro, mais bon
Brunni (./1363) :Et c'est vachement plus joli à lire aussi. Surtout qu'en général on commence les phrases en majuscules, donc je vois pas quelle raison logique il y a de faire l'inverse en mettant tout en majuscule sauf le premier mot
Si ça peut te dissuader, sache que c'est en C# qu'on utilise cette notation ^^ En fait tout ce qui est privé est en minuscule, et le reste en majuscule:
En gros si je ne me trompe pas on a:Que dalle oué. Jamais aucune notation n'est imposée. Sauf en Java parce que c'est un langage rigide et obsolète qui pleurniche si ses classes sont pas bien fichues exactement comme il faut au bon endroit dans le bon espace-temps.nomDeVariable -> C++ nomdevariable -> C Nom_De_Variable -> Ada NomDeVariable -> C# nom_de_variable -> C quand moi j'en fais nom.de.variable -> Java (troll)
C++ -> As you wish. C -> As you wish. C# -> Notation de la BCL (fortement) conseillée. Tu fais ce que tu veux de tes membres privées, on est pas sensé les voir. (À noter, que CLS interdit de distinguer deux membres juste par la casse des caractères. En fait, le C# n'est pas conforme CLS.) Java -> Attention faut bien nommer tes classes avec une grande majuscule et tes paquets avec que des minuscules, et tes membres de classes tous sans exception avec une minuscule au début.(Les autres langages j'en ai jamais fait donc je peux pas dire, mais je sais qu'il existe des trucs tordus partout, y'a bien des langages où l'indentation à une signification sémantique précise…)
) donc pas de « getSomething() » ou de « setSomething(int value) », on a juste « Something »typedef struct
{
struct
{
int (*init)(); /* Constructor */
void (*destroy)(); /* Destructor */
} *pVtbl;
} OBJECT;
typedef struct
{
struct
{
int (*init)(); /* Constructor */
void (*destroy)(); /* Destructor */
void (*Manage)(); /* Management handler */
} *pVtbl;
MODULE_DATA* Data; /* Used data */
} MODULE;JackosKing (./1366) :C'est pour réduire la redondance de code, et rendre le truc plus facilement modifiable. Ça te fait une macro à modifier (mais je suis d'accord on peut améliorer) au lieu de N classes. (Si jamais tu veux modifier quelque chose bien sûr)
Mouai déjà utiliser le preprocesseur pour ca c'est crade, mais en plus je vois pas ce qu'on y gagne:/
Folco (./1368) :
Alors tu peux me donner ton idée Jackos stp ?
Golden, oui, sûrement, mais je vais faire avec et ça me suffit
Brunni (./1374) :Ça décrit juste un système permettant l'inter-opérabilité entre différents langages. CLS != CLR.
CLS c'est la Common Language Specification de MS c'est juste? Si même eux ne sont pas foutus de respecter leurs standards avec C# je ne crois pas qu'on puisse en tenir compte le moins du monde
) => CLS suit cette règle. De même les pointeurs ne sont pas conformes CLS. (Tout cela étant malgré tout supporté par le CLR et utilisé en C#. Le C# peut générer du code conforme CLS, mais il peut aussi facilement en générer qui ne l'est pas… Le compilateur sait vérifier ça. ^^)
GoldenCrystal (./1367) :
Sauf en Java parce que c'est un langage rigide et obsolète qui pleurniche si ses classes sont pas bien fichues exactement comme il faut au bon endroit dans le bon espace-temps.C++ -> As you wish. C -> As you wish. C# -> Notation de la BCL (fortement) conseillée. Tu fais ce que tu veux de tes membres privées, on est pas sensé les voir. (À noter, que CLS interdit de distinguer deux membres juste par la casse des caractères. En fait, le C# n'est pas conforme CLS.) Java -> Attention faut bien nommer tes classes avec une grande majuscule et tes paquets avec que des minuscules, et tes membres de classes tous sans exception avec une minuscule au début.
GoldenCrystal (./1367) :
Java -> Attention faut bien nommer tes classes avec une grande majuscule et tes paquets avec que des minuscules, et tes membres de classes tous sans exception avec une minuscule au début.
Uther (./1377) :
Personnellement je trouve que c'est le mieux. Il y a des recommandations officielles (pas trop mauvaises à mon gout) et plutôt bien respectées par les bibliothèques tierces, mais aucune obligation de les utiliser.
public void Constructeur(int genre) {
this.genre = genre;
}public void Constructeur(int inGenre) {
fGenre = inGenre;
}GoldenCrystal (./1376) :
Folco > Qui sait ce que les gens seraient prêt à payer pour avoir un authentique Folcoâ„¢ encadré dans leur salle de séjour…
