* je modéliserais les registres d'un processeur par des unsigned et pas des int. Une union serait pas mal, non ?
Non. Dans une union on ne peut lire que le type qui a été écrit. En écrivant un émulateur ou un simulateur -- on ne sait pas assez de l'OP pour dire -- on veut vraissemblablement pouvoir interpréter la valeur tantot comme signée, tantot comme non signée (et peut-être tantot comme un float). Unsigned est meilleur pour cela. Un tableau d'unsigned char serait encore plus clair, mais trop pénible à manipuler.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
* je modéliserais les registres d'un processeur par des
unsigned et pas des int.
Une union serait pas mal, non ?
Non. Dans une union on ne peut lire que le type qui a été
écrit. En écrivant un émulateur ou un simulateur -- on ne
sait pas assez de l'OP pour dire -- on veut
vraissemblablement pouvoir interpréter la valeur tantot
comme signée, tantot comme non signée (et peut-être tantot
comme un float). Unsigned est meilleur pour cela. Un
tableau d'unsigned char serait encore plus clair, mais trop
pénible à manipuler.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
* je modéliserais les registres d'un processeur par des unsigned et pas des int. Une union serait pas mal, non ?
Non. Dans une union on ne peut lire que le type qui a été écrit. En écrivant un émulateur ou un simulateur -- on ne sait pas assez de l'OP pour dire -- on veut vraissemblablement pouvoir interpréter la valeur tantot comme signée, tantot comme non signée (et peut-être tantot comme un float). Unsigned est meilleur pour cela. Un tableau d'unsigned char serait encore plus clair, mais trop pénible à manipuler.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ici, je n'ai pas compris l'utilisation d'une exception. As-tu essayé une des autres réponses qu'il t'a été données ? J'aurais tendence à utiliser celle de James. Elle ne te convient pas ?
Je prefaire faire des truc simple que je comprend a peut près... On vera pour les complications plus tard, quand je serai meilleur
Mais le code de James est simple. Peut-être aborde-t-il un point ou l'autre que tu ne comprends pas, mais c'est alors l'occasion de déceler des lacunes, car il ne comporte rien d'extraordinaire.
Je dirais plutôt qu'écrire du code correct avec des exceptions est compliqué. Mais si ici, l'exercice est un peu biaisé ...
--drkm
PtitMat <toto@toto.fr> writes:
drkm wrote:
Ici, je n'ai pas compris l'utilisation d'une exception. As-tu
essayé une des autres réponses qu'il t'a été données ? J'aurais
tendence à utiliser celle de James. Elle ne te convient pas ?
Je prefaire faire des truc simple que je comprend a peut près...
On vera pour les complications plus tard, quand je serai meilleur
Mais le code de James est simple. Peut-être aborde-t-il un point ou
l'autre que tu ne comprends pas, mais c'est alors l'occasion de
déceler des lacunes, car il ne comporte rien d'extraordinaire.
Je dirais plutôt qu'écrire du code correct avec des exceptions est
compliqué. Mais si ici, l'exercice est un peu biaisé ...
Ici, je n'ai pas compris l'utilisation d'une exception. As-tu essayé une des autres réponses qu'il t'a été données ? J'aurais tendence à utiliser celle de James. Elle ne te convient pas ?
Je prefaire faire des truc simple que je comprend a peut près... On vera pour les complications plus tard, quand je serai meilleur
Mais le code de James est simple. Peut-être aborde-t-il un point ou l'autre que tu ne comprends pas, mais c'est alors l'occasion de déceler des lacunes, car il ne comporte rien d'extraordinaire.
Je dirais plutôt qu'écrire du code correct avec des exceptions est compliqué. Mais si ici, l'exercice est un peu biaisé ...
--drkm
drkm
Jean-Marc Bourguet writes:
_Exit() avec un lib c99
C'est quoi ce nom exotique ? Je ne connaissais pas. D'après ce que j'ai vu dans la norme, il s'agit juste de quitter, le plus simplement possible, sans appeler les gestionnaires atexit. Y a-t-il autre chose ?
--drkm
Jean-Marc Bourguet <jm@bourguet.org> writes:
_Exit() avec un lib c99
C'est quoi ce nom exotique ? Je ne connaissais pas. D'après ce que
j'ai vu dans la norme, il s'agit juste de quitter, le plus simplement
possible, sans appeler les gestionnaires atexit. Y a-t-il autre
chose ?
C'est quoi ce nom exotique ? Je ne connaissais pas. D'après ce que j'ai vu dans la norme, il s'agit juste de quitter, le plus simplement possible, sans appeler les gestionnaires atexit. Y a-t-il autre chose ?
--drkm
PtitMat
Jean-Marc Bourguet wrote:
* Les exceptions, c'est fait pour sortir de la fonction qui les lance -- et bien souvent pour dépiler plusieurs fonctions par la même occasion car sinon il y a des chances qu'un autre moyen de rapporter l'erreur soit meilleur.
Il y a peut-etre meilleur mais la sa fonctionne.
* Pourquoi les pRx ne forment-ils pas un tableau (je pourrais comprendre s'ils portaient d'autres noms -- et encore, on peut faire un tableau avec des copies des pointeurs puisque c'en est --, mais ici c'est vraiment criant) ?
Voici ma nouvelle fonction: int * Ccpu::dToR( int dx ) { try { static int* pRx[] = { pR0, pR1, pR2, pR3}; return pRx[dx]; } catch (int Rx) { int lPc; lPc = getPc(); cerr << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl; abort (); } }
* exit() dans du C++ est presque toujours une erreur. Ou bien on veut faire du clean-up et alors c'est une exception qu'il faut jeter et qui doit arriver jusqu'à main(), ou bien on n'en veut pas et c'est abort() (ou _exit() pour Unix, _Exit() avec un lib c99) éventuellement précédé d'un fflush(0) si on veut vider les tampons.
C fait (voir extrait plus haut)
* je modéliserais les registres d'un processeur par des unsigned et pas des int.
Piur ce que j'ai a fair int me va tres bien. Ce que je fais ca doit marché, mon cahier des charge n'est pas précis. Si je peux améliorer apres on verat quand tout marchera bien.
A+
Jean-Marc Bourguet wrote:
* Les exceptions, c'est fait pour sortir de la fonction qui
les lance -- et bien souvent pour dépiler plusieurs
fonctions par la même occasion car sinon il y a des chances
qu'un autre moyen de rapporter l'erreur soit meilleur.
Il y a peut-etre meilleur mais la sa fonctionne.
* Pourquoi les pRx ne forment-ils pas un tableau (je
pourrais comprendre s'ils portaient d'autres noms -- et
encore, on peut faire un tableau avec des copies des
pointeurs puisque c'en est --, mais ici c'est vraiment
criant) ?
Voici ma nouvelle fonction:
int * Ccpu::dToR( int dx )
{
try
{
static int* pRx[] = { pR0, pR1, pR2, pR3};
return pRx[dx];
}
catch (int Rx)
{
int lPc;
lPc = getPc();
cerr << "Instruction number " << lPc << " Try to acces to register R"
<< Rx << " which doesn't exist" << endl;
abort ();
}
}
* exit() dans du C++ est presque toujours une erreur. Ou
bien on veut faire du clean-up et alors c'est une exception
qu'il faut jeter et qui doit arriver jusqu'à main(), ou bien
on n'en veut pas et c'est abort() (ou _exit() pour Unix,
_Exit() avec un lib c99) éventuellement précédé d'un
fflush(0) si on veut vider les tampons.
C fait (voir extrait plus haut)
* je modéliserais les registres d'un processeur par des
unsigned et pas des int.
Piur ce que j'ai a fair int me va tres bien.
Ce que je fais ca doit marché, mon cahier des charge n'est pas précis.
Si je peux améliorer apres on verat quand tout marchera bien.
* Les exceptions, c'est fait pour sortir de la fonction qui les lance -- et bien souvent pour dépiler plusieurs fonctions par la même occasion car sinon il y a des chances qu'un autre moyen de rapporter l'erreur soit meilleur.
Il y a peut-etre meilleur mais la sa fonctionne.
* Pourquoi les pRx ne forment-ils pas un tableau (je pourrais comprendre s'ils portaient d'autres noms -- et encore, on peut faire un tableau avec des copies des pointeurs puisque c'en est --, mais ici c'est vraiment criant) ?
Voici ma nouvelle fonction: int * Ccpu::dToR( int dx ) { try { static int* pRx[] = { pR0, pR1, pR2, pR3}; return pRx[dx]; } catch (int Rx) { int lPc; lPc = getPc(); cerr << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl; abort (); } }
* exit() dans du C++ est presque toujours une erreur. Ou bien on veut faire du clean-up et alors c'est une exception qu'il faut jeter et qui doit arriver jusqu'à main(), ou bien on n'en veut pas et c'est abort() (ou _exit() pour Unix, _Exit() avec un lib c99) éventuellement précédé d'un fflush(0) si on veut vider les tampons.
C fait (voir extrait plus haut)
* je modéliserais les registres d'un processeur par des unsigned et pas des int.
Piur ce que j'ai a fair int me va tres bien. Ce que je fais ca doit marché, mon cahier des charge n'est pas précis. Si je peux améliorer apres on verat quand tout marchera bien.
A+
drkm
PtitMat writes:
Voici ma nouvelle fonction: int * Ccpu::dToR( int dx ) { try { static int* pRx[] = { pR0, pR1, pR2, pR3}; return pRx[dx]; } catch (int Rx) { int lPc; lPc = getPc(); cerr << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl; abort (); } }
Puisque tu ne lances plus d'exception, l'utilisation de try est inutile (de même, évidemment, que le gestionnaire le suivant) :
int * Ccpu::dToR( int dx ) { static int * pRx[] = { pR0 , pR1 , pR2 , pR3 } ; return pRx[ dx ] ; }
Si tu ajoutes le contrôle de l'inclusion de l'indice dans les bornes, au moyen d'une assertion, ben ... tu obtiens exactement le code de James ...
--drkm
PtitMat <toto@toto.fr> writes:
Voici ma nouvelle fonction:
int * Ccpu::dToR( int dx )
{
try
{
static int* pRx[] = { pR0, pR1, pR2, pR3};
return pRx[dx];
}
catch (int Rx)
{
int lPc;
lPc = getPc();
cerr << "Instruction number " << lPc << " Try to acces to register R"
<< Rx << " which doesn't exist" << endl;
abort ();
}
}
Puisque tu ne lances plus d'exception, l'utilisation de try est
inutile (de même, évidemment, que le gestionnaire le suivant) :
int * Ccpu::dToR( int dx )
{
static int * pRx[] = { pR0 , pR1 , pR2 , pR3 } ;
return pRx[ dx ] ;
}
Si tu ajoutes le contrôle de l'inclusion de l'indice dans les
bornes, au moyen d'une assertion, ben ... tu obtiens exactement le
code de James ...
Voici ma nouvelle fonction: int * Ccpu::dToR( int dx ) { try { static int* pRx[] = { pR0, pR1, pR2, pR3}; return pRx[dx]; } catch (int Rx) { int lPc; lPc = getPc(); cerr << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl; abort (); } }
Puisque tu ne lances plus d'exception, l'utilisation de try est inutile (de même, évidemment, que le gestionnaire le suivant) :
int * Ccpu::dToR( int dx ) { static int * pRx[] = { pR0 , pR1 , pR2 , pR3 } ; return pRx[ dx ] ; }
Si tu ajoutes le contrôle de l'inclusion de l'indice dans les bornes, au moyen d'une assertion, ben ... tu obtiens exactement le code de James ...
--drkm
Jean-Marc Bourguet
drkm writes:
Jean-Marc Bourguet writes:
_Exit() avec un lib c99
C'est quoi ce nom exotique ?
La version C99 de _exit.
Je ne connaissais pas. D'après ce que j'ai vu dans la norme, il s'agit juste de quitter, le plus simplement possible, sans appeler les gestionnaires atexit. Y a-t-il autre chose ?
En C++ il y a de bonne chances qui ca n'executerait aucun destructeurs. Le probleme de exit, c'est qu'il execute les gestionnaires atexit, les destructeurs des objets statiques mais pas ceux de la pile. C'est totalement incoherant.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
drkm <usenet.fclcxx@fgeorges.org> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
_Exit() avec un lib c99
C'est quoi ce nom exotique ?
La version C99 de _exit.
Je ne connaissais pas. D'après ce que j'ai vu dans la norme, il
s'agit juste de quitter, le plus simplement possible, sans appeler
les gestionnaires atexit. Y a-t-il autre chose ?
En C++ il y a de bonne chances qui ca n'executerait aucun
destructeurs. Le probleme de exit, c'est qu'il execute les
gestionnaires atexit, les destructeurs des objets statiques mais pas
ceux de la pile. C'est totalement incoherant.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je ne connaissais pas. D'après ce que j'ai vu dans la norme, il s'agit juste de quitter, le plus simplement possible, sans appeler les gestionnaires atexit. Y a-t-il autre chose ?
En C++ il y a de bonne chances qui ca n'executerait aucun destructeurs. Le probleme de exit, c'est qu'il execute les gestionnaires atexit, les destructeurs des objets statiques mais pas ceux de la pile. C'est totalement incoherant.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
PtitMat writes:
Voici ma nouvelle fonction: int * Ccpu::dToR( int dx ) { try { static int* pRx[] = { pR0, pR1, pR2, pR3}; return pRx[dx]; } catch (int Rx) { int lPc; lPc = getPc(); cerr << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl; abort (); } }
Il n'y a plus d'exceptions lancees, pourquoi mettre un try{}catch?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
PtitMat <toto@toto.fr> writes:
Voici ma nouvelle fonction:
int * Ccpu::dToR( int dx )
{
try
{
static int* pRx[] = { pR0, pR1, pR2, pR3};
return pRx[dx];
}
catch (int Rx)
{
int lPc;
lPc = getPc();
cerr << "Instruction number " << lPc << " Try to acces to
register R" << Rx << " which doesn't exist" << endl;
abort ();
}
}
Il n'y a plus d'exceptions lancees, pourquoi mettre un try{}catch?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Voici ma nouvelle fonction: int * Ccpu::dToR( int dx ) { try { static int* pRx[] = { pR0, pR1, pR2, pR3}; return pRx[dx]; } catch (int Rx) { int lPc; lPc = getPc(); cerr << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl; abort (); } }
Il n'y a plus d'exceptions lancees, pourquoi mettre un try{}catch?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Thu, 18 Nov 2004 20:44:49 +0000, PtitMat :
int * Ccpu::dToR( int dx ) { try { switch( dx ) { case 0: return pR0; break; case 1: return pR1; break; case 2: return pR2; break; case 3: return pR3; break;
default: throw( dx ); } } catch (int Rx) {
Non. Si j'ai parlé de lancer une exception, c'est pour qu'elle soit interceptée bien plus haut dans la hiérarchie d'appel (voire carrément dans le main() ). Auquel cas une exception doit être plus explicite qu'un simple entier.
Si tu comptes gérer l'erreur directement dans la fonction, lancer une exception ne sert à rien.
int lPc; lPc = getPc();
Ce genre de truc, c'est du C. En C++ on écrira plutôt int lPc= getPc();
exit (0);
Non plus. exit(0) indique une sortie avec renvoi d'un code EXIT_SUCCESS. Il vaudrait mieux renvoyer EXIT_FAILURE, voire même appeler abort().
int * Ccpu::dToR( int dx ) { switch( dx ) { case 0: return pR0; break; case 1: return pR1; break; case 2: return pR2; break; case 3: return pR3; break; }
int lPc; lPc = getPc();//Prend la valeur de Program Counter cout << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl;
exit (EXIT_FAILURE); }
-- ;-)
On Thu, 18 Nov 2004 20:44:49 +0000, PtitMat <toto@toto.fr>:
int * Ccpu::dToR( int dx )
{
try
{
switch( dx )
{
case 0: return pR0; break;
case 1: return pR1; break;
case 2: return pR2; break;
case 3: return pR3; break;
default: throw( dx );
}
}
catch (int Rx)
{
Non. Si j'ai parlé de lancer une exception, c'est pour qu'elle soit
interceptée bien plus haut dans la hiérarchie d'appel (voire carrément
dans le main() ). Auquel cas une exception doit être plus explicite
qu'un simple entier.
Si tu comptes gérer l'erreur directement dans la fonction, lancer une
exception ne sert à rien.
int lPc;
lPc = getPc();
Ce genre de truc, c'est du C. En C++ on écrira plutôt
int lPc= getPc();
exit (0);
Non plus. exit(0) indique une sortie avec renvoi d'un code
EXIT_SUCCESS. Il vaudrait mieux renvoyer EXIT_FAILURE, voire même
appeler abort().
int * Ccpu::dToR( int dx )
{
switch( dx )
{
case 0: return pR0; break;
case 1: return pR1; break;
case 2: return pR2; break;
case 3: return pR3; break;
}
int lPc;
lPc = getPc();//Prend la valeur de Program Counter
cout << "Instruction number " << lPc
<< " Try to acces to register R" << Rx
<< " which doesn't exist" << endl;
int * Ccpu::dToR( int dx ) { try { switch( dx ) { case 0: return pR0; break; case 1: return pR1; break; case 2: return pR2; break; case 3: return pR3; break;
default: throw( dx ); } } catch (int Rx) {
Non. Si j'ai parlé de lancer une exception, c'est pour qu'elle soit interceptée bien plus haut dans la hiérarchie d'appel (voire carrément dans le main() ). Auquel cas une exception doit être plus explicite qu'un simple entier.
Si tu comptes gérer l'erreur directement dans la fonction, lancer une exception ne sert à rien.
int lPc; lPc = getPc();
Ce genre de truc, c'est du C. En C++ on écrira plutôt int lPc= getPc();
exit (0);
Non plus. exit(0) indique une sortie avec renvoi d'un code EXIT_SUCCESS. Il vaudrait mieux renvoyer EXIT_FAILURE, voire même appeler abort().
int * Ccpu::dToR( int dx ) { switch( dx ) { case 0: return pR0; break; case 1: return pR1; break; case 2: return pR2; break; case 3: return pR3; break; }
int lPc; lPc = getPc();//Prend la valeur de Program Counter cout << "Instruction number " << lPc << " Try to acces to register R" << Rx << " which doesn't exist" << endl;
exit (EXIT_FAILURE); }
-- ;-)
Fabien LE LEZ
On Thu, 18 Nov 2004 21:57:00 +0100, drkm :
Je ne te suis pas ...
C'est un cas d'école : on a un ensemble de données (ici, un tableau de pointeurs), auquel on ne doit accéder que via une fonction. Dans un tel cas, on met les données et la fonction dans une classe dont la seule fonction est de limiter l'accès aux données.
-- ;-)
On Thu, 18 Nov 2004 21:57:00 +0100, drkm <usenet.fclcxx@fgeorges.org>:
Je ne te suis pas ...
C'est un cas d'école : on a un ensemble de données (ici, un tableau de
pointeurs), auquel on ne doit accéder que via une fonction. Dans un
tel cas, on met les données et la fonction dans une classe dont la
seule fonction est de limiter l'accès aux données.
C'est un cas d'école : on a un ensemble de données (ici, un tableau de pointeurs), auquel on ne doit accéder que via une fonction. Dans un tel cas, on met les données et la fonction dans une classe dont la seule fonction est de limiter l'accès aux données.
