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 13-01-2011, Bruno Causse a écrit :
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
Le 13-01-2011, Bruno Causse <pasdespam@free.fr> a écrit :
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
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
Marc Boyer wrote:
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 ;-)
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
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 ;-)
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
On Jan 13, 4:15 pm, Marc Boyer wrote:
Le 13-01-2011, Bruno Causse a écrit :
> 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
On Jan 13, 4:15 pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
wrote:
Le 13-01-2011, Bruno Causse <pasdes...@free.fr> a écrit :
> 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).
> 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
James Kanze wrote:
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 :
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 :
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 :
> 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?
Bruno Causse <PasDeSpam@free.fr> wrote:
> 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?
> 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
On Jan 13, 9:17 pm, (Bruno Causse) wrote:
Bruno Causse wrote: > > 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
On Jan 13, 9:17 pm, PasDeS...@free.fr (Bruno Causse) wrote:
Bruno Causse <PasDeS...@free.fr> wrote:
> > 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.)
Bruno Causse wrote: > > 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 13-01-2011, James Kanze a écrit :
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
Le 13-01-2011, James Kanze <james.kanze@gmail.com> a écrit :
On Jan 13, 4:15 pm, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
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
> 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 Fri, 14 Jan 2011 09:05:57 +0000 (UTC), Marc Boyer a écrit (dans <news:igp3ll$o2r$, posté dans fr.comp.lang.c++) :
Le raisonnement partant d'un prémisse faux, il n'a plus de valeur.
On dit « une prémisse ».
<http://www.cnrtl.fr/lexicographie/pr%C3%A9misse>
-- ___________ _/ _ _`_`_`_) 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
Le Fri, 14 Jan 2011 09:05:57 +0000 (UTC), Marc Boyer a écrit
(dans <news:igp3ll$o2r$1@news.cict.fr>, posté dans fr.comp.lang.c++) :
Le raisonnement partant d'un prémisse faux, il n'a plus
de valeur.
On dit « une prémisse ».
<http://www.cnrtl.fr/lexicographie/pr%C3%A9misse>
--
___________
_/ _ _`_`_`_) 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
Le Fri, 14 Jan 2011 09:05:57 +0000 (UTC), Marc Boyer a écrit (dans <news:igp3ll$o2r$, posté dans fr.comp.lang.c++) :
Le raisonnement partant d'un prémisse faux, il n'a plus de valeur.
On dit « une prémisse ».
<http://www.cnrtl.fr/lexicographie/pr%C3%A9misse>
-- ___________ _/ _ _`_`_`_) 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 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
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 ;-)
