Bonsoir,
 
Je voudrais simplement savoir si il existe un équivalent d'un #define du C/C++ en java ?
 
Merci  

Ba ça dépend de ce que tu veux faire, mais a priori je te dirais que non.

Je ne souhaite pas faire de define du type :
 
#define RELEASE(a) if (a!=NULL) {a->Release(), a=NULL; }
 
mais plutot du type :
 
#define ma_constante_qui_apparait_souvent  16354324;
 
est-ce possible ? ou est-on oblige d'allouer une variable en memoire ?

faut passer par une variable
ça semble logique, étant donné que le compilo va sortir du bytecode qui devra être lu partout

 
 
le " #define toto 16;  " consiste a remplacer toutes les occurences de "toto" dans le prog par "16" AVANT compilation, ca n'a rien avoir. tanpis merci quand meme
 

merci, je sais ce qu'est un #define et précompilateur, c'est mon métier
et moi je te dis que ça ne peut pas exister par rapport à la philosophie java, c est tou

 
Je n'avais pas compris ta réponse en fait. Désolé  
 
Je vais utiliser :
 
private final static int toto = 16 ;
 
qu'est ce que tu en penses ?
 
Je suis perdu avec les "final" "static" je comprends vaguement a quoi ils servent, suis-je en train de faire n'importe quoi ?

Pour ce que tu veux faire, c'est OK.
final signifie que tu ne pourras pas modifier ta variable dans la suite du code. Genre si t'essaies de faire un toto = 12 dans une fonction quelconque, t'auras une erreur à la compil.
static, c'est pour dire que ta variable peut (et à la limite doit) être appelée sans passer par une instance de ta classe. Exemple (on suppose que ta classe s'appelle JolieClasse ) :

 
Vala. Donc pour ton utilisation, t'es pas obligé de passer par un static mais le final semble logique.

ok merci  

Si tu as beaucoup de constantes comme ça, je te conseille de faire une classe exprès, que tu appelles constantes par exemple.
Après dans le code tu peux y aller à grands coups de constantes.TOTO, constanes.TITI etc.

pour info si tu fais un  
private static final int XXX = 5;  
dans une classe, il sera remplacé au moment de la compilation (enfin ça depend peut etre du compilo?), si tu veux des preuves, décompile ta classe après
edit: enfin, c'est l'utilisation de cette variable qui sera remplacée par "5", hein

ouais et moi je lui conseillerais plutot de voir s'il a pas envie de faire de la programmation objet plutot  

Et ben quoi, c'est objet, une classe Constantes qui encapsule toutes les valeurs constantes

Ta classe sans instance ?
Si tu avait un objet instance de cette classe :
Et tu écris quoi sur sa fiche de rôle ?
Il interragit avec quels autres objets ?
 
Une classe c'est pas un truc dans lequel on regroupe les fonction par ordre d'idée, le C, ADA, le fonctionnel etc. c'est fini en java.

HS
 
pour revenir au C: sauf cas extremement precis, dus a des contraintes extérieures, il faut faire __sans__ macro
 
les récentes revisions du C ont donné jour au mot clef const
 
donc on remplace avangateusement un  
 
#define N 16
 
par
 
const int N=16;
 
si mes souvenirs sont bons, la seule contrainte est que la valeur de variable const doit pouvoir etre calculée à la compilation
 
 
quand au macro destinées à faire des petites fonctions rapides, typiquement
 
#define SQUARE(X) (X)*(X)
 
le C99 apporte également des améliorations avec le mot clef inline
 
inline int square(int x)
{
   return x*x;
}
 
qui comem son nom l'indique, permet au compilateur de faire de l'inlining plus judicieusement.
 
tout cela donne des perfs équivalents aux macros, avec le typage en plus, les problème s à la con des macros (définitons multiples, shawdoing, ifndef, etc,) en moins.
 
 
on a utilisé ces mécanismes en C pour pallier aux faiblesse du langage, ce ne sont que des grosses astuces, maintenant que les problèmes sont résolus, on devrait oublier tout ça... reste plsuq u'à avertir les enseignants...

 je confirme tout ça on me la dit en cours cette anéée...:jap:

sans deconner? un prof de C qui dit ça? je croyais que ça existait pas... t'es sur de pas avoir un prof qui adore VC++ pour qui C et C++ c'est bonnet blanc et blanc bonnet, d'ou le const et le inline?

 
y a plus elegant, enfin depend du truc, par exemple si ces constantes sont similaires à une enumeration il peut utiliser un truc du style  
 

 
 
y a aussi moyen de faire une classe Configuration dérivé d'un Properties, enfin y a plein de solutions pour faire mumuse    
 

Je sais pas pourquoi mais j'aurais mis un Map ... peut être parce que ça a la même interface sans nécessiter de réecrire le moindre code lorsqu'on ajoute un jeu.

 
c'est une solution, mais ds mon esprit l'enumeration n'etait pas evolutive qd j'ai ecris le code.

y a tout un tas de techniques pour les safe enums en Java

alors types le bordel statiquement avec une sous-classe par valeur et une super-classe commune.

pourquoi des sous-classe... c'est pas trés lisible et c la merde à maintenir  

gné? j'aurais le contraire moi

un package,un fichier ... une classe c beau non?

Des sous-classes : c'est le compilo qui se démerde avec le typage, si le typage statique de gonfle, tu peux faire du C++ void * powered ou du Smalltalk.
 
c'est moins lisible : pour moi donner un nom aux choses permet de mieux les apréhender.
 
La merde à maintenir : étendre sans revalider la moindre méthode existante et validée me parraît nettement plus viable que de haxoriser une série de if à chaque modification.

ça c'est un peu de l'intégrisme

 
pour moi la creation d'une classe est la traduction de la definition d'un entite bien defini au niveau de l'analyse, donc la je trouve que cela se justifie pas

UML et les Design patterns (version française) Craig Larman CampusPress  2002 p.359 :

 
on est pas obligé d'aimer toutes les recettes de cuisines existantes    (même si ce sont des recettes de grands chefs)

Par contre on a pas le droit de faire un travail de porc uniquement pour contourner un pattern. Surtout que travailler uniquement avec des objets du domaines ça veut dire : pas de Factorys, pas d'interface graphique, un niveau de conception au raz des paquerettes ... En fait j'arrive même pas à imaginer jusqu'où va ce genre de comportement.
 
Alors que transformer les types énumérés en une classe abstraite possédant autant de sous-classes que de valeurs possibles est vraiment la base de la hiérarchie de types (2 étages).

 
j'ai jamais ecris ça que je sache   , bien sur qu'il faut utiliser les Factory, etc ... je parlais juste du cas de figure cité ci-dessus

 
c un peu de la base de java ca :  
 
Static : la variable devient membre de la classe...et est existe indépendament des instances de cette classe
 
Final : idem, mais pour une constante
 
T pas obligé de mettre ta constante en private, vu l'attribut final elle est pas modifiable de toute façon...mais ca te permet d'y accéder plus facielement...

 
Pitié non, g une interro dessus le 14..;arghhh

T'as bien de la chance d'avoir une interro sur les Design-patterns, beaucoup de gens n'ont de cours que sur les diagrammes de classes et les Use-case. Alors que se sont des parties très "technique" qui n'ont rien d'intéressantes en soit mais les modèles sous-jacents il est rare de les étudier.

le programme en design c l'ensemble de son bouquin...mais en anglais (erasmus roulaize)
 
ca et de l'analyse de ce qui fait un information system...

ski le prof??

 
Bein euh... Nous les DP on les donne dans le cadre de programmation objet, avec une breve intro a UML. Je ne sais pas comment ca se passe "ailleurs" mais je n'attends pas de mes etudiants qu'ils sachent coder une application (j'entends par la qu'on va tres peu voir du cote des APIs existantes) a la fin du semestre, mais qu'ils sachent penser objet, et manipuler la puissance de ce paradigme en l'appliquant a Java.
 
Bref premier semestre on apprend a reflechir, concevoir, gribouiller, inventer, deuxieme semestre ca code sec en utilisant ce qu'on a appris...