C++ question de débutant ^^ - Page 3

on ne peut pas faire

class instance {
      private:
           request* requests;
}
class request {
      public:
           request(instance*);

?

Si.
Comme en C (avec des structures), il faut que le compilo soit au courant de l'existence des types que tu utilises avant de les utiliser.
Donc tu dois déclarer quelque part class instance; avant la définition de ta classe request.

ah ok, c'est bon, ça marche merci

bon, dsl Flanker je squatte ton topic

imaginons que j'ai une classe "plop" templatée par deux types A et B, quelqun connaitrait la syntaxe pour déclarer une méthode "plip" de cette classe, donc l'implémentation diffère suivant que B est un pointeur ou non (déclarer les deux méthodes pour les deux implémentations, en fait; une dans le cas géneral, et la spécialisation pour un pointeur) ? impossible de tomber dessus en tâtonnant ... :/

je t'en prie, fais donc ^^ mais tu me le rends après, sinon ...

montre ton code pour voir...

quel code ce que je demande c'est précisement comment l'écrire

Zephyr :
impossible de tomber dessus en tâtonnant ... :/

Pour moi, c'est que tu as fait des essais

mwi enfin vu la question je pensais pas qu'il allait falloir un dessin... bon alors mettons un truc comme ça :

#include <map>

class	Test
{ };

template <typename A, typename B>
class MaClasse
{
public:
   B MaFonction (const A& ) const;
private:
   typedef std::map<A, B> t_map;
   t_map hash;
};

template <typename A, typename B>
B
MaClasse<A, B>::MaFonction (const A& a) const
{
   typename t_map::const_iterator i;

   if ((i = hash.find (a)) == hash.end ())
      return 0;
   return i->second;
}

int main ()
{
   MaClasse<int, Test*> mc;

   mc.MaFonction (0);
   return 0;
}

Voilà, dans ce cas ça marche puisque "return 0" est compatible avec le type "Test*" (même chose si il existe un constructeur à partir d'un entier pour le type choisi, d'ailleurs); mais ça ne marchera pas si je template avec "Test", par exemple.
Du coup je voudrais avoir deux implémentations de "MaFonction", dont l'une soit spécialisée pour les pointeurs (l'implémentation actuelle, du coup le "return 0" sera forcément valable), et une autre qui remplace le "return 0" par un throw, par exemple, mais je ne connais pas la syntaxe.

(hum ça n'a aucun rapport avec la question de bob mais avec ce qui se disait page précédente : c'est pas censé segfaulter quand on déréférence un pointeur nul )

./69> euh mal à la tête, je regarderai plus tard
./70> non, le comportement n'est pas spécifié ^^
Potentiellement s'il a envie de formater le disque à chaque déréférencement de pointeur nul, c'est un comportement tout à fait valide.

Zephyr
: Du coup je voudrais avoir deux implémentations de "MaFonction", dont l'une soit spécialisée pour les pointeurs (l'implémentation actuelle, du coup le "return 0" sera forcément valable), et une autre qui remplace le "return 0" par un throw, par exemple, mais je ne connais pas la syntaxe.

J'ai jamais entendu qu'on pouvait faire ce genre de truc avec les templates... donc a moins d'en faire deux différentes, je vois pas comment tu pourrais faire.

peut être avec une ruse de sioux à base de dynamic_cast

peut être par exemple si tu essayes de caster le parametre d'entree en void*, si tu obtiens NULL, c'est que tu as tenté de caster autrechose qu'un pointeur, sinon tu as bel et bien casté un pointeur (en s'assurant bien sur au réalabre de pas tenter de caster NULL sunon tu l'as dtc
enfin je ne sais pas du tout si ça marche et si c'est possible d'empecher des cas tordus de foirer

oh et oui c'est crade

Nan, mais ton truc, ca parle de l'implémentation, dans ce cas là, ca revient a faire un test RTTI, mais il veut un seul template pour ça d'apres ce que j'ai compris...

oui c'est runtime comme test :/

Bah la fonction ne peut pas retourner 0 si elle est templatée par un type non pointeur et non initialisable avec un entier, comme le compilo peut décider à la compilation si il accepte ou non un "templatage", il peut très bien déterminer laquelle choisir entre deux implémentations; je n'ai pas la réponse mais ça ne me semble pas tellement différent de n'importe quelle spécialisation de template ?

(accessoirement on m'a demandé de le faire, donc je pense que c'est faisable ^^)

Mais avec une spécialisation, tu es obligé de définir complètement le type, pas seulement que c'est un pointeur, non ?

Bah je sais pas, en fait je ne vois pas trop de raison logique pour que ce soit le cas (je ne dis pas que c'est pas possible hein, sans oublier que je suis nioob en C++, juste qu'a priori je ne vois pas de raison ^^)

Bah je vois pas comment l'écrire moi...
Car pour moi, la spécialisation est terminale... m'enfin, si ca se trouve, c'est tout à fait possible, je connais assez mal la spécialisation de templates...

hop, un petit up pour me réapproprier mon topic

j'utilise lp_solve_5.5 , un solveur de programmes linéaires, j'arrive à le recompiler sans trop de souci pour avoir le liblpsolve55 kivabien, mais quand je compile mon propre programme (qui est en C++), j'ai :

g++ -Wall --pedantic -o instance.o -c instance.cpp
In file included from simu.h:13,
                 from instance.cpp:1:
lp_solve_5.5/lp_lib.h:887: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:888: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:1401: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:1402: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:1403: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:1404: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:1563: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:2071: error: le C++ ISO ne permet pas « long long »
lp_solve_5.5/lp_lib.h:2072: error: le C++ ISO ne permet pas « long long »
make: *** [instance.o] Erreur 1

perso, je ne trouve pas ça très cool de la part de gcc :/

accessoirement, si ça peut aider, j'ai

$ gcc -v
Lecture des spécification à partir de /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configuré avec: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Modèle de thread: posix
version gcc 3.3.5 (Debian 1:3.3.5-13)

et comme ce n'est pas mon ordi, je ne peux pas le changer, évidemment.

personnellement, j'arrivais à le recompiler sur mon mac sans souci, mais je devais avoir un gcc 4, je ne sais pas si ça change beaucoup

En gros, si ça peu changer gcc3 et gcc4 ne doivent pas supporter la meme norme de C++, donc, le --pedantic le force a etre le plus proche possible de la norme

ah yes, supprimer le --pedantic répare le tout merci !

(il est bien lp_solve ? Par rapport a glpk & cplex en terme de rapidité et nombre de vars pour un MIP si tu sais ?)

nEUrOO :
(il est bien lp_solve ? Par rapport a glpk & cplex en terme de rapidité et nombre de vars pour un MIP si tu sais ?)

il marche, c'est tout ce que je lui demande (d'ailleurs, vu que mon iBook n'est pas assez puissant, je vais le faire tourner sur Grid5000 tout de suite, c'est la gamme au-dessus ))
après, c'est le premier solveur sur lequel je suis tombé, donc j'en sais rien

Je viens de me renseigner... Ca a l'air un peu vieillot, pas de possibilités de branchements spéciaux, coupes etc. :/

nEUrOO :
Je viens de me renseigner... Ca a l'air un peu vieillot, pas de possibilités de branchements spéciaux, coupes etc. :/

bah de toute façon, je pense que je ne m'en serais pas servi
je l'utilise de façon vraiment bourrin : j'écris mes équations dans un fichier, je lis le fichier, je résoud le système et je r écupère les données, c'est tout !

encore une question sûrement débile :
j'ai une classe scheduler avec

class scheduler {
public:
    void run(void);
    void eval(void);
    int objective(void);
}

et une sous-classe p_approx avec

class p_approx : public scheduler {
public:
    void run(void);
    void eval(void);
    int objective(void);
}

malheureusement, quand je fais

p_approx* machin = new p_approx();
machin->run();
machin->eval();
machin->objective();

le run qui est appelé est bien celui de p_approx, mais eval et objective sont ceux de scheduler y a un truc que j'ai pas sais

bon, bah un make clean puis make a résolu mon problème je dois avoir un pb de dépendances

->eval(); s->objective();

Par contre, si tu fais un scheduler *s = new p_approx();
s->run();
s

tu appelleras les fonctions de scheduler, parce que tu as un pointeur sur scheduler (ça marche pareil avec les références) et que le "choix de la fonction" est fait à la compilation (static binding). Si tu veux éviter ça, il faut rajouter virtual dans la classe mère pour que la fonction appelée soit celle qui correspond au type dynamique de s, soit p_approx (dynamic binding).

ça marche également le virtual en C++ ? je savais pas ^^ je connaissais le principe (en faisant un peu de java), mais j'avais rien lu dessus sur les qqes tutos C++ que j'ai regardé. merci