C++

[C++] problème étrange

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [C++] problème étrange

Gurney_Halleck

dévisage des figures

rebonjour,
voilà, j'ai ça :

Code :

void traitement(int t,machine M[9],chariot C)
{
int tmp_attente=0;int tmp_machine=0;
int appel=0;
for(int i=0;i<9;i++)
{
if(M[i].etat_machine() == ATTENTE_PIECE)
{
M[i].alimenter_machine(t);
}
else if(M[i].etat_machine() == USINAGE_PIECE)
{
M[i].verification_usinage(t);
}
else if(M[i].etat_machine() == ATTENTE_CHARIOT)
{
M[i].incremente_attente();
if(M[i].attente()>tmp_attente)
{
tmp_attente=M[i].attente();
tmp_machine=i;
}
appel=1;
}
}
if(C.etat_chariot() == ATTENTE && appel != 0)
{
C.nouvelle_destination(M[tmp_machine]);
}
if(C.etat_chariot() == EN_ROUTE)
{
C.deplacer();
}
}

j'appelle la fonction traitement dans le main.
Lors de l'appel de C.nouvelle_destination() (en bas), cette fonction devrait changer une variable protected de la classe chariot (qui se nomme etat), et qui est retrouvée par C.etat_chariot().
Or, elle n'est pas mise à jour du tout.

si je recopie la fonction traitement dans le main, ça marche.

c'est très étrange, parce que je fais exactement la même chose avec la variable M[i] un peu plus haut, avec la fonction alimenter_machine(), et là ça marche ...

quelqu'un aurait une idée ? (dsl, j'arrive pas à exprimer très clairement le problème)

Merci d'avance ! :hello:

Message édité par Gurney_Halleck le 01-01-2004 à 21:44:11

Publicité

Taz

bisounours-codeur

ben ne passe pas ton chariot pas copie mais par référence.
sinon utilise plutot un switch et des bool

Gurney_Halleck

dévisage des figures

taz a écrit :

ben ne passe pas ton chariot pas copie mais par référence.
sinon utilise plutot un switch et des bool

euh :whistle:
tu peux juste m'expliquer ce qu'est "par référence" ?

Gurney_Halleck

dévisage des figures

j'ai trouver c bon

Gurney_Halleck

dévisage des figures

voilà ce que j'ai fait

Code :

void traitement(int t,machine M[9],chariot &C)
{
int tmp_attente=0;int tmp_machine=0;
bool appel=false;
for(int i=0;i<9;i++)
{
switch(M[i].etat_machine()){
case ATTENTE_PIECE:
M[i].alimenter_machine(t);
break;
case USINAGE_PIECE:
M[i].verification_usinage(t);
break;
case ATTENTE_CHARIOT:
M[i].incremente_attente();
if(M[i].attente()>tmp_attente)
{
tmp_attente=M[i].attente();
tmp_machine=i;
}
appel=true;
break;
}
}
if(C.etat_chariot() == ATTENTE && appel)
{
C.nouvelle_destination(M[tmp_machine]);
}
if(C.etat_chariot() == EN_ROUTE)
{
C.deplacer();
}
}

merci taz :hello:

c marrant, parce que le compilateur à l'air de considérer l'objet machine comme un pointeur, alors que le chariot, non...

y aurait une explication ?

Taz

bisounours-codeur

heink ?

schnapsmann

Zaford Beeblefect

Gurney_Halleck a écrit :

y aurait une explication ?

je vais essayer en deux lignes, parce que j'ai pas que ça à foutre:
machine M[9]: M contient l'addresse du tableau passé en paramètre
chariot &C: C est une référence (quasi pointeur) sur l'objet passé en paramètre (et non une recopie comme ca serait le cas si l'escargoulette '&' n'était pas utilisée)

Message édité par schnapsmann le 01-01-2004 à 22:53:23

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"

Taz

bisounours-codeur

non non et non. les tableaux ne sont pas des lvalues,
la vérité, c'est que t'es complètement perdu entre référence, pointeur, notation (*, [], et [N])

en clair: un tableau ne peut être copié, donc

T *tab, T tab[], et T tab[N] ont le même emploi : dans tous les cas, aucune recopie n'est effectuée,

Message édité par Taz le 01-01-2004 à 22:59:04

schnapsmann

Zaford Beeblefect

taz a écrit :

non non et non. les tableaux ne sont pas des lvalues,
la vérité, c'est que t'es complètement perdu entre référence, pointeur, notation (*, [], et [N])

tu te fous de qui?

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"

Gurney_Halleck

dévisage des figures

ce que je voulais dire :

en fait, le tableau avait l'air d'être, par défaut, considérer comme un pointeur, alors que je n'avais rien indiquer. Par contre, C était considéré comme un paramètre normal.

donc je voulais savoir si il y avait une raison, c tout

et je suis certainement perdu entre référence, pointeur, et notation...
vàlà

Message édité par Gurney_Halleck le 01-01-2004 à 23:02:14

Publicité

Taz

bisounours-codeur

Code :

#include <iostream>
#include <typeinfo>
template<typename T>
void info(const T &x)
{
std::cout << x << ' '
<< typeid(x).name() << '\n';
}
void un(int a[10])
{
info(a);
}
void deux(int a[])
{
info(a);
}
void trois(int *a)
{
info(a);
}
int main()
{
int a[10];
info(a); un(a); deux(a); trois(a);
int b[5];
info(b); un(b); deux(b); trois(b);
}

comme tu peux le voire, les trois appels aboutissent au même résultat : le paramètre a est un pointeur d'entiers

Taz

bisounours-codeur

Gurney_Halleck a écrit :

en fait, le tableau avait l'air d'être, par défaut, considérer comme un pointeur, alors que je n'avais rien d'indiquer. Par contre, C était considéré comme un paramètre normal.

tout ce qui est dit est valable également pour le C

gilou

Modérateur
Modzilla

taz a écrit :

Code :

#include <iostream>
#include <typeinfo>
template<typename T>
void info(const T &x)
{
std::cout << x << ' '
<< typeid(x).name() << '\n';
}
void un(int a[10])
{
info(a);
}
void deux(int a[])
{
info(a);
}
void trois(int *a)
{
info(a);
}
int main()
{
int a[10];
info(a); un(a); deux(a); trois(a);
int b[5];
info(b); un(b); deux(b); trois(b);
return 0; // <== il faudrait pas l'oublier, pour faire plaisir au compilo
}

comme tu peux le voire, les trois appels aboutissent au même résultat : le paramètre a est un pointeur d'entiers

[:chacal_one333]
A+,

Message édité par gilou le 02-01-2004 à 01:32:45

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Taz

bisounours-codeur

Citation :

return 0; // <== il faudrait pas l'oublier, pour faire plaisir au compilo

en C++ (et C99), la norme dit clairement que si on omet le return final (pourtant obligatoire puisque main doit retourner un int), le compilateur __doit__ générer ce qu'il faut pour qu'une valeur signifiant une terminaison correct du programme soit retournée au système.

gilou

Modérateur
Modzilla

Vi c'est pourquoi j'ai dit que c'etait pour faire plaisir au compilo: ca lui evite de faire le boulot et (surtout) de balancer un warning.
Moi je suis pour la minimisation des warnings, et pas a coup de pragmas
A+,

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Taz

bisounours-codeur

euh le warning c'est par ce que t'as un compilateur bouseux, c'est tout. N'importe quel compilateur capable de respecter une règle si simple n'emettra jamais aucun warning

gilou

Modérateur
Modzilla

La norme dit en effet:

Citation :

If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;

Au fait, apres avoir pas mal browse le draft iso, je suis preneur de la suite de regle etablissant que une une fonction (autre que main) declaree avec un type de retour different de void, mais sans statement return dans le corps de la fonction provoque une erreur a la compilation [les regles etablissant pourquoi ca provoque une erreur a l'execution par contre, je les vois]

Je ne trouve pas que l'emission d'un warning soit en quoi que ce soit le fait d'un compilo bouseux en ce cas precis. Au contraire, c'est l'exemple typique d'un warning utile:
Signaler quelque chose qui n'est pas une erreur effective pour le compilateur, mais est une erreur potentielle (ne pas mettre de valeur de retour a une fonction retournant un int peut etre le fait soit d'un programmeur qui le fait en connaissance de cause pour le main, soit le fait d'un programmeur qui a effectivement oublie de retourner un code d'erreur.)

De plus personnellement, je n'aime pas cette convention, bien que je voie clairement pourquoi elle a ete mise en place (un compromis). Autant prendre d'emblée de bonnes habitudes et mettre un return statement a toute fonction declaree avec un type de retour autre que void. Ce genre de convention ca ouvre la porte a plein de choses qui rapelle les debuts du C: pourquoi ne pas l'etendre a toute fonction retournant un int? ou tout autre type numerique? etc... (bon, je me fais l'avocat du diable, là)
A+,

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Taz

bisounours-codeur

non. c'est juste une petite facilité pour débuter les fouteurs de merde qui font du C et qui préfèrent (en < C99) void main, parce que soit disant int main/return 0; c'est trop long. donc on leur a fait une fleur, et ils font meme l'économie d'un caractère. en plus pour le cas de main, je trouve ça intelligent: le retour de main n'a d'importance qui si on souhaite signaler des erreurs au contexte appelant. au cas contraire, on se tourne les pouces et tout va bien.

gilou

Modérateur
Modzilla

J'escomptais surtout une reponse a ma question dans le premier paragraphe (parce que j'ai bien cherche dans le Draft ISO sans trouver la reponse)
A+,

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Taz

bisounours-codeur

j'ai un peu la flemme là :sweat:

gilou

Modérateur
Modzilla

[:totoz]
A+,

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Publicité

FORUM HardWare.fr

Programmation

C++

[C++] problème étrange

Sujets relatifs
problème de rafraîchissement	Probleme pour charger un fichier...
[CSS] probleme avec un filter.alpha	[HTML] Problème lié a un kit
problème de caractère...	Petit probleme tout bete (printf/scanf)
Probleme de PHP/MYSQL => je m'embrouille dans l'algo	Problème avec mon site web
Probleme avec semaphores	Problème exécution getText et setText
Plus de sujets relatifs à : [C++] problème étrange

Page générée en 0.136 secondes