pthread_mutex_t et std::vector

Le
pasdespam
bonjour,

soit une classe

class objectShared
{

/
pthread_mtex_t lock;
/

}

que j'aimerai mettre dans une collection (std::vector), taille connue a
l'execution.

le pthread_mutex_t n'etant surement pas copiable assignable, quelle
solution elegante me conseillez vous?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
pasdespam
Le #23018001
Bruno Causse
bonjour,

soit une classe

class objectShared
{

.../...
pthread_mtex_t lock;
.../...

}

que j'aimerai mettre dans une collection (std::vector), taille connue a
l'execution.

le pthread_mutex_t n'etant surement pas copiable assignable, quelle
solution elegante me conseillez vous?




pour faire suite:

le fait que le "mon" vector est "immuable" (ne change pas de taille,
aucun ajout/retrait d'elements apres la creation) change t'il quelque
chose?

fonctionne sous gcc et icc
Marc Boyer
Le #23018181
Le 13-01-2011, Bruno Causse
class objectShared
{

.../...
pthread_mtex_t lock;
.../...

}

que j'aimerai mettre dans une collection (std::vector), taille connue a
l'execution.

le pthread_mutex_t n'etant surement pas copiable assignable, quelle
solution elegante me conseillez vous?



Comme tu le dis dans ton autre message, "en pratique, ça marche",
puisque tant que tu ne demandes pas à agrandir, et que tu ne fais
pas de copie du vector, il ne fait pas appel à l'opérateur
de copie.
Et comme le mécanisme de template ne cherche pas à instancier
les fonctions non utilisées, ça passe à la compilation.
Mais ça pourrait planter avec une implantation différente
(dont je ne saurait juger du réalisme), avec une fonction
dont le code comporte une branche avec une affectation,
branche que ton code n'utiliserait pas.

Je ne sais pas si la norme entre dans des détails tels que
"si vous n'utilisez pas ces opérations, votre paramètre
n'a pas besoin d'être copiable/assignable". J'imagine que non,
que ce serait beaucoup de travail de décortiquer comme ça
les sous-usages d'une conteneur.

Après, la solution la plus élégante, c'est d'écrire un conteneur
élegant qui satisfasse tes besoins. ;-)
Mais c'est du travail.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
pasdespam
Le #23018301
Marc Boyer


Après, la solution la plus élégante, c'est d'écrire un conteneur
élegant qui satisfasse tes besoins. ;-)
Mais c'est du travail.





un simple tableau a la C suffit, mais ca taille doit etre connue a la
compilation. on ne peut pas tout avoir ;-)
James Kanze
Le #23018851
On Jan 13, 4:15 pm, Marc Boyer wrote:
Le 13-01-2011, Bruno Causse
> class objectShared
> {

> .../...
> pthread_mtex_t lock;
> .../...

> }

> que j'aimerai mettre dans une collection (std::vector),
> taille connue a l'execution.

> le pthread_mutex_t n'etant surement pas copiable assignable,
> quelle solution elegante me conseillez vous?

Comme tu le dis dans ton autre message, "en pratique, ça
marche", puisque tant que tu ne demandes pas à agrandir, et
que tu ne fais pas de copie du vector, il ne fait pas appel
à l'opérateur de copie.



Selon la norme Posix, seulement le mutex passé à l'appel
pthread_mutex_init peut servir à des appels de synchronisation.
Ce qui se passe quand on en passe une copie n'est pas défini.
Alors, il suffiera de n'appeler pthread_mutex_init qu'une fois
le vector rempli.

Et si on veux utiliser l'initialisation statique du mutex, AMA,
ça doit marcher, parse que l'initialisation statique ne peut que
définir la valeur des bits dans l'objet, ce que la copie
préserve.

Et comme le mécanisme de template ne cherche pas à instancier
les fonctions non utilisées, ça passe à la compilation.



Je ne suis pas sûr de suivre. De quelles fonctions parles-tu ?
pthread_mutex_t est un type C ; il n'a pas de fonctions membres.
(En revanche, il a un constructeur de copie et un opérateur
d'affectation, fournis par le compilateur.)

Mais ça pourrait planter avec une implantation différente
(dont je ne saurait juger du réalisme), avec une fonction
dont le code comporte une branche avec une affectation,
branche que ton code n'utiliserait pas.



Ni l'affectation ni la copie ne pose de problème; un
pthread_mutex_t n'a pas d'opérateur d'affection ni de
constructeur (parce que sinon, le compilateur C ne sera pas bien
content) ; donc, le compilateur en fournit.

Je ne sais pas si la norme entre dans des détails tels que
"si vous n'utilisez pas ces opérations, votre paramètre
n'a pas besoin d'être copiable/assignable". J'imagine que non,
que ce serait beaucoup de travail de décortiquer comme ça
les sous-usages d'une conteneur.



Pour appartenir à une collection, la norme est claire : il faut
être copiable et affectable. Sinon, c'est un comportement
indéfini (et g++, au moins, s'en plaidra).

--
James Kanze
PasDeSpam
Le #23019091
James Kanze
Et si on veux utiliser l'initialisation statique du mutex, AMA,
ça doit marcher, parse que l'initialisation statique ne peut que
définir la valeur des bits dans l'objet, ce que la copie
préserve.



je vais faire cela.

Pour appartenir à une collection, la norme est claire : il faut
être copiable et affectable. Sinon, c'est un comportement
indéfini (et g++, au moins, s'en plaidra).



le mutex etait dans une classe wrapper, sans constructeur de copie, ni
operateur d'affectation, donc gcc etait content.

je viens de regarder la classe std::mutex et comprendre :

mutex(mutex const&)Þlete;
mutex& operator=(mutex const&)Þlete;

merci
PasDeSpam
Le #23019261
Bruno Causse
> Et si on veux utiliser l'initialisation statique du mutex, AMA,
> ça doit marcher, parse que l'initialisation statique ne peut que
> définir la valeur des bits dans l'objet, ce que la copie
> préserve.

je vais faire cela.



peut on initialiser un mutex "membre" avec l'initialiseur statique?
James Kanze
Le #23020131
On Jan 13, 9:17 pm, (Bruno Causse) wrote:
Bruno Causse > > Et si on veux utiliser l'initialisation statique du mutex, AMA,
> > a doit marcher, parse que l'initialisation statique ne peut que
> > d finir la valeur des bits dans l'objet, ce que la copie
> > pr serve.

> je vais faire cela.

peut on initialiser un mutex "membre" avec l'initialiseur statique?



Non. (Sinon que par copie d'un autre mutex, lui statique.)

--
James Kanze
Marc Boyer
Le #23020191
Le 13-01-2011, James Kanze
On Jan 13, 4:15 pm, Marc Boyer wrote:
> le pthread_mutex_t n'etant surement pas copiable assignable,
> quelle solution elegante me conseillez vous?



Et comme le mécanisme de template ne cherche pas à instancier
les fonctions non utilisées, ça passe à la compilation.



Je ne suis pas sûr de suivre. De quelles fonctions parles-tu ?
pthread_mutex_t est un type C ; il n'a pas de fonctions membres.
(En revanche, il a un constructeur de copie et un opérateur
d'affectation, fournis par le compilateur.)



Désolé, j'ai inféré de l'affirmation de l'OP

le pthread_mutex_t n'etant surement pas copiable assignable,
quelle solution elegante me conseillez vous?







le fait qu'il travaillait avec une classe C++ ni
copiable ni assignable.

Le raisonnement partant d'un prémisse faux, il n'a plus
de valeur.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Serge Paccalin
Le #23023031
Le Fri, 14 Jan 2011 09:05:57 +0000 (UTC), Marc Boyer a écrit
(dans 
Le raisonnement partant d'un prémisse faux, il n'a plus
de valeur.



On dit « une prémisse ».


--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Lucas Levrel
Le #23025491
Le 13 janvier 2011, Bruno Causse a écrit :

un simple tableau a la C suffit, mais ca taille doit etre connue a la
compilation. on ne peut pas tout avoir ;-)



En C89, mais pas en C99, si ?

--
LL
Publicité
Poster une réponse
Anonyme