J'ai donc commenc=E9 =E0 =E9tudier la question des casts, et je commence
par le const_cast.
1=2E) J'ai lu que cet 'op=E9rateur' ne fonctionnait que sur les types :
pointeurs, r=E9f=E9rences, et pointeurs sur membre...
a.) c'est quoi un pointeur sur membre
b.) pourquoi a t'on d=E9cid=E9 que =E7a fonctionnerait pas sur des
types tout betes ? o=F9 est le probl=E8me dans l'ecriture const_cast<A> ?
2=2E) J'ai ensuite test=E9 sur un exemple :
class A {
public:
void f(){std::cout<<"A::f()"<<std::endl;};
A(){;}; // (*)
};
int main()
{
const A a;
const_cast<A&>(a).f();
}
a.) la notation const_cast<A&> pour 'moralement' signifier
const_cast<A> me trouble un peu... y'a un truc que je vois pas ?
b.) si je commente la ligne marqu=E9e d'une at=E9risque (*), =E7a ne
compile pas : g++ pr=E9tend que je n'initialise pas mon "const A a;"...
Y'a pas de constructeur (vide) par d=E9faut ? M'aurait-t'on menti ?
il n'y a aucun cas où tu risques de l'utiliser ou de le voir (sauf peut-être dans un handleur de signal, et encore).
Je n'ai encore jamais touché à la programmation avec des thread, mais je me demaneds dans quelle mesure volatile ne pourrait pas trouver son emploie aussi dans ce cadre là si on a deux threads qui jouenty avec une meme variable... Non ?
Non. L'effet de volatile tel que decrit par la norme est vague et en pratique les compilateurs ne font pas ce qu'il faut pour que ca marche pour le multi-thread. Plus subtil que ca, ce qu'ils font est generalement suffisant pour faire marcher un programme sur une machine uni-processeur mais pas sur certaines machines multi-processeurs.
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
"meow" <ben@agat.net> writes:
volatile :
il n'y a aucun cas où tu risques de l'utiliser ou de le voir (sauf
peut-être dans un handleur de signal, et encore).
Je n'ai encore jamais touché à la programmation avec des thread, mais
je me demaneds dans quelle mesure volatile ne pourrait pas trouver son
emploie aussi dans ce cadre là si on a deux threads qui jouenty avec
une meme variable... Non ?
Non. L'effet de volatile tel que decrit par la norme est vague et en
pratique les compilateurs ne font pas ce qu'il faut pour que ca marche
pour le multi-thread. Plus subtil que ca, ce qu'ils font est
generalement suffisant pour faire marcher un programme sur une machine
uni-processeur mais pas sur certaines machines multi-processeurs.
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
il n'y a aucun cas où tu risques de l'utiliser ou de le voir (sauf peut-être dans un handleur de signal, et encore).
Je n'ai encore jamais touché à la programmation avec des thread, mais je me demaneds dans quelle mesure volatile ne pourrait pas trouver son emploie aussi dans ce cadre là si on a deux threads qui jouenty avec une meme variable... Non ?
Non. L'effet de volatile tel que decrit par la norme est vague et en pratique les compilateurs ne font pas ce qu'il faut pour que ca marche pour le multi-thread. Plus subtil que ca, ce qu'ils font est generalement suffisant pour faire marcher un programme sur une machine uni-processeur mais pas sur certaines machines multi-processeurs.
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
kanze
Jean-Marc Bourguet wrote:
"meow" writes:
volatile :
il n'y a aucun cas où tu risques de l'utiliser ou de le voir (sauf peut-être dans un handleur de signal, et encore).
Je n'ai encore jamais touché à la programmation avec des thread, mais je me demaneds dans quelle mesure volatile ne pourrait pas trouver son emploie aussi dans ce cadre là si on a deux threads qui jouenty avec une meme variable... Non ?
Non. L'effet de volatile tel que decrit par la norme est vague et en pratique les compilateurs ne font pas ce qu'il faut pour que ca marche pour le multi-thread.
À la décharge des compilateurs : la norme Posix ne fait aucune distinction entre ce qu'on peut faire avec un objet volatile, et ce qu'on peut faire avec un objet non volatile, en ce qui concerne les threads. Les compilateurs ne font que suivre Posix ici.
Plus subtil que ca, ce qu'ils font est generalement suffisant pour faire marcher un programme sur une machine uni-processeur mais pas sur certaines machines multi-processeurs.
Au moins en principe, ce que font les compilateurs Sparc ne suffit pas pour faire des I/O mappée mémoire, dans un pilote de périphérique, par exemple. Dans la pratique, en revanche, je ne sais pas. J'imagine que la plupart des portes I/O se trouvent sur un processeur donné. (Mais j'avoue ne pas être vraiment au courant des évolutions récentes. Ça fait au moins quinze ans que je n'ai plus écrit de pilote de périphérique.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
"meow" <ben@agat.net> writes:
volatile :
il n'y a aucun cas où tu risques de l'utiliser ou de le
voir (sauf peut-être dans un handleur de signal, et
encore).
Je n'ai encore jamais touché à la programmation avec des
thread, mais je me demaneds dans quelle mesure volatile ne
pourrait pas trouver son emploie aussi dans ce cadre là si
on a deux threads qui jouenty avec une meme variable... Non
?
Non. L'effet de volatile tel que decrit par la norme est
vague et en pratique les compilateurs ne font pas ce qu'il
faut pour que ca marche pour le multi-thread.
À la décharge des compilateurs : la norme Posix ne fait aucune
distinction entre ce qu'on peut faire avec un objet volatile, et
ce qu'on peut faire avec un objet non volatile, en ce qui
concerne les threads. Les compilateurs ne font que suivre Posix
ici.
Plus subtil que ca, ce qu'ils font est generalement suffisant
pour faire marcher un programme sur une machine uni-processeur
mais pas sur certaines machines multi-processeurs.
Au moins en principe, ce que font les compilateurs Sparc ne
suffit pas pour faire des I/O mappée mémoire, dans un pilote de
périphérique, par exemple. Dans la pratique, en revanche, je ne
sais pas. J'imagine que la plupart des portes I/O se trouvent
sur un processeur donné. (Mais j'avoue ne pas être vraiment au
courant des évolutions récentes. Ça fait au moins quinze ans que
je n'ai plus écrit de pilote de périphérique.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
il n'y a aucun cas où tu risques de l'utiliser ou de le voir (sauf peut-être dans un handleur de signal, et encore).
Je n'ai encore jamais touché à la programmation avec des thread, mais je me demaneds dans quelle mesure volatile ne pourrait pas trouver son emploie aussi dans ce cadre là si on a deux threads qui jouenty avec une meme variable... Non ?
Non. L'effet de volatile tel que decrit par la norme est vague et en pratique les compilateurs ne font pas ce qu'il faut pour que ca marche pour le multi-thread.
À la décharge des compilateurs : la norme Posix ne fait aucune distinction entre ce qu'on peut faire avec un objet volatile, et ce qu'on peut faire avec un objet non volatile, en ce qui concerne les threads. Les compilateurs ne font que suivre Posix ici.
Plus subtil que ca, ce qu'ils font est generalement suffisant pour faire marcher un programme sur une machine uni-processeur mais pas sur certaines machines multi-processeurs.
Au moins en principe, ce que font les compilateurs Sparc ne suffit pas pour faire des I/O mappée mémoire, dans un pilote de périphérique, par exemple. Dans la pratique, en revanche, je ne sais pas. J'imagine que la plupart des portes I/O se trouvent sur un processeur donné. (Mais j'avoue ne pas être vraiment au courant des évolutions récentes. Ça fait au moins quinze ans que je n'ai plus écrit de pilote de périphérique.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
