Dois je remplacer l'héritage privé par une instante de X dans Y ?

 
Il y a des chances oui. D'ailleurs souvent, on a tendance à mettre un héritage privé alors qu'il s'agit d'une composition.

Alors j'ai bel et bien révé, je croyais qu'il etait possible de rendre un classe de base mutable !

tu fais quoi avec ton mutable là ?
on utilise l'héritage privé pour exprimer la relation 'est implémenté en terme de'

C'est bien le cas, taz. Mais j'ai un pb de constness. J'aimerais que fy soit const pour signaler qu'elle ne change pas l'état de Y...
 
Je retire le const de fy... dommage.

attend, si ça modifie quelque chose, c'est pas const. Il faut utiliser mutable parcimonieusement. Explique un peu ce que fait ta classe.

La seule bonne utilisation de mutable que je connaisse correspond à la mise en oeuvre d'un cache dans un objet (cf stroustrup).
 
Du point de vue du compilo, je suis entièrement d'accord avec toi.
 
Cela dit, il faut aussi considérer le point de vue de l'utilisateur de l'objet. Les const placés au niveau de l'interface publique de l'objet donnent des indications interessantes.
 
La classe de base :

 
La classe dérivée :

 
et la ou est le problème ...

moi il me semble pas ici que ton héritage soit adéquate.

Partir sur quelque chose du genre....
 

j'espère que tu maitrises bien que des constructions comme
 
if(!q.is_empty())
{
  T t = q.get();
}
 
sont peu fiables. Il vaut mieux utiliser des exceptions et des mécanismes tel que des scopedLock où le destructeur a la charge de relacher le verrou.

C'est clair que... non, je vois pas ou est le problème dans ton exemple.

Compare ça:

 
et ça:

 
 
D'où l'habitude de toujours utiliser des scoped-lock, à moins que tu ne maîtrises à la perfection l'exception-safety de ton code (ce dont je doute).

en fait je parlais du fait qu'entre le moment ou tu regardes si ta file a quelque chose pour toi, et le moment tu prend ce quelque chose, il peut se passer des opérations dans d'autres thread. Comme tu fais 2 oopérations distinctes, sans verrou global, il se peut qu'au moment ou tu veux faire un .get, ta file soit vide !

 
L'abus de Java est dangereux pour la santé    
 

http://boost.org/libs/thread/doc/lock_concept.html

 
En principe, un seul et unique thread réalise un "get". Tandis que plusieurs threads realisent un "put". Donc, je pense ne pas avoir ce genre de probleme.

 
Pourquoi dis tu ça ? ;-)

fais attention. Si tu décides de conserver ce comportement, documente le. C'est une sacré limitation. Consière également que ton is_empty + get crée 2 sections critiques là où une seule est nécéssaire.
 
Vois aussi que
 
while(true)
{
  if(!q.is_empty())
     q.get()
}
 
 
bouffe beaucoup de CPU. si tu introduit une temporisation, tu perds en réactivité
 
while(true)
{
 if(!q.is_empty())
     q.get()
 else
    wait(t);
}
 
pour remédier à ce problème de réactivité, tu sera tenté de donner une petite valeur à t. Tu retombes alors dans le premier problème.
 
la solution est d'utiliser des constructions de types événement.
 
while(true)
{
  try {
  q.get(timeout);
  } except(TimeOut & ) { }
}
 
cette construction te permet également de mettre fin à ta boucle
 
 
while(true)
{
  try {
  q.get(timeout);
  } except(TimeOut & ) {
    if(stop) break
  }
}
 
à toi d'explorer tout ça : exceptions et événements.

Parce qu'en Java, toute classe dérive de java.lang.Object, et que Object contient un mutex, c'est ce qui te permet de faire des locks sur n'importe quel objet, etc.
 
Le code que tu as essayé de faire au début ressemble beaucoup à ce concept, mais comme tu l'as compris, c'est pas comme ça qu'on fait en C++ .
 

t'as déjà vu de l'héritage privée en Java ? moi c'est la première chose que je vois dans le code de xterm

 
Toute la difficulté n'est elle pas de coder la fonction "get(TimeOut)", sans se baser sur les deux premiers cas que tu as documenté ?
 
Interessante utilisation du block try catch. Mais est-ce vraiment un cas d'usage recommandé ?

appuie toi sur des choses déjà existante pour coder ça. Cet usage est recommandé et très utilisé. À voir au cas par cas, mais c'est usage sur.
 
Très utilisé, en python notemment, ce qui explique mon erreur de try..except à la place de try..catch.
 
Comme déjà dit, les événement te permettent d'introduire des temporisation (attente passive) et de ne pas bloquer dans un sommeil ininterruptible.
 
Si je me souviens bien, il y a une version du stroustrup où il débat de la pertinence de cet usage

http://python.org/dev/doc/devel/lib/QueueObjects.html
 
regarde donc un peu comment c'est fichu