Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ std::string

std::string

87 réponses
Avatar
JBB
J'ai lu dans ce forum (je retrouve plus ou) que personne n'aimait
std::string .
Pourquoi donc?
A part le fait que chaque librairie utilise son propre type CString,
QString ... et que du coup ça fait moche d'utiliser std::string.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
5 6 7 8 9
Avatar
Matthieu Moy
writes:

En fait, sous Linux (et sous la dernière version
de Solaris, et je crois aussi sous Windows), il n'y a pas de
processus au sens classique ; il n'y a que des threads.


C'est encore vrai en Linux 2.6, ça ?

--
Matthieu

Avatar
kanze
Gabriel Dos Reis wrote:
Fabien LE LEZ writes:

[...]

| Et d'après le même dictionnaire, le mot "truck" existe en
| français, mais a un autre sens ("wagon en plate-forme pour
| le transport des objets encombrants et pesants").

Ici, « truck » existe aussi en Americain (devrais-je dire «
Texan » ?) et il a tout un autre sens :-) :-)


Le mot « truck » est un bon mot américain (non seulement texan),
avec deux significations fréquentes : camion, et bogie. En
l'anglais d'Angleterre, lorry et bogie. Le mot a aussi des
significations moins fréquentes, y compris celle qu'il a en
français ; je crois qu'il est aussi utilisé dans l'anglais
d'Angleterre avec certaines de ses significations.

Dans la passée (et peut-être encore aujourd'hui à certains
endroits), le mot servait aussi comme verbe, avec le sens de
troquer -- ce qui doit donner une bonne idée sur ses origines.

(Dans le sud-est des États-unis, et peut-être jusqu'en Texas, on
entend aussi des expressions du genre « I ain't got no truck
for » pour signifier « je ne peux pas supporter ».)

--
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

Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote:
| > Fabien LE LEZ writes:
|
| > [...]
|
| > | Et d'après le même dictionnaire, le mot "truck" existe en
| > | français, mais a un autre sens ("wagon en plate-forme pour
| > | le transport des objets encombrants et pesants").
|
| > Ici, « truck » existe aussi en Americain (devrais-je dire «
| > Texan » ?) et il a tout un autre sens :-) :-)
|
| Le mot « truck » est un bon mot américain (non seulement texan),
| avec deux significations fréquentes : camion, et bogie. En

Au Texas, cela a une autre signification. Et je suis bien placé pour
le savoir ;-p

-- Gaby
Avatar
kanze
Gabriel Dos Reis wrote:
writes:

| Gabriel Dos Reis wrote:
| > writes:

| > | Michel Michaud wrote:

| > | [...]
| > | > Non, ici je dirais multi-processus (ou multi « fiss » si
| > | > tu veux), mais certainement pas multi « file » comme dans
| > | > multithread... Et ce n'est pas nécessairement avec fork
| > | > (qui est très unixien).

| > | > > la même chose que le multithreading (oops, pardon ;)

| > | > Effectivement c'est loin d'être la même chose que le
| > | > multithread et je suis heureux que ce soit plus
| > | > simple, car c'est ce que j'ai à enseigner :-) (ce
| > | > n'est pas moi qui enseigne vraiment la programmation
| > | > multithread).

| > | Attention. Si les utilisatoins naïves des threads et des
| > | processus sont différentes, dans un bon système
| > | d'exploitation (et je crois qu'à cet égard, les Windows
| > | modernes sont de bons systèmes d'exploitation), il n'y a
| > | pas vraiment de différence.

| > Des experts en la matière sont en profond désaccord avec
| > ton assertion.

| Quels experts ?

Tanenbaum, les développeurs de NPTL.


Ce n'était pas mon impression quand j'ai lu Tanunbaum, mais ça
date. Je ne sais pas ce que c'est que le NPTL, donc, je ne peux
pas dire.

| Et pour quelles raisons ?

Bah, déjà si on commence par la base la gestion des processus
(ressources, signaux, exceptions, etc.) n'est pas la même
chose au niveaux des threads qu'au niveau des processus.


Je ne vois pas où il doit y avoir vraiment une gestion de
ressources au niveau de processus. Chaque ressource appartient à
un ou à plusieurs threads -- quand le dernier thread auquels
elles appartiennent le libère (soit explicitement, soit parce
qu'il a terminé), elle est libéré. Dans la pratique, il est
souvent commode, au niveau utilisateur, de regrouper un certain
nombre de threads qui partagent tous un grand nombre de
ressources. Mais c'est une commodité, non un aspect fondamental,
et si ce partage est souvent un défaut, il y a prèsque toujours
des moyens d'aller au-delà : j'ai déjà cité la mémoire partagée,
et le fait que sous Unix (ou au moins Solaris), les choses comme
un mutex ou un rwlock peuvent être partagé entre des threads
dans différents processus. Dans l'autre direction, plus d'un
système supporte de la mémoire qui est propre à un seul thread,
et non à tout le processus.

| > À moins que ton assertion soit une auto-définition. Dans ce
| > cas, je préfère ne pas utiliser ton package de thread ;-}

| Je ne suis pas l'auteur, mais Linux utilise exactement les
| principes que je viens de décrire ;

De fait, ce n'est pas exactement ça. En tout mon système que
j'utilise pour écrire ce message n'utilise pas le système que
tu viens de décrire. Je suppose que tu es au courant de la
saga LinuxThreads vs. NGPT vs. NPTL, quand même ?


Pas vraiment. J'ai regardé comment fait Linux, par curiosité. Je
constate que Solaris suit le même chemin, après avoir commencé
par une autre route. Logiquement, c'est certainement la bonne
solution si on commençait de zéro. Pratiquement, il y a certains
problèmes à le faire co-habiter avec les normes Unix --
probablement parce qu'Unix n'est pas le résultat d'une
conception rigueureuse qui prenait en compte tous ces aspects.

De toute façon, mon but n'était pas de lancer une dispute. Il y
a beaucoup de façons de regarder le sujet, et selon ce qu'on
fait, la façon la plus utile peut varier. Tout ce que je voulais
dire, c'est que la distinction thread - processus est d'une
certaine façon arbitraire, parce qu'il n'y a pas une dicotomie
absolue. Parfois, il n'y a pas de distinction de tout, et à
l'autre extrème, on peut aussi avoir des groupes de processes,
ou tous les threads de tous les processus partagent certaines
ressources.

--
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

Avatar
Matthieu Moy
"Stan" ( remove the dots )> writes:

Avant ça ne pouvait pas être le cas, Linux ne supportant pas les threads !


J'ai fait un programme multithreadé sous Linux avant la sortie du 2.6.
J'ai du rêver alors.

Aujourd'hui, la 2.6 gére les threads et comme le fait remarquer James, un
process
est en fait un (super) thread.


Ben justement, en 2.4, chaque thread a un PID différent. La création
d'un thread est grosso-modo un fork() + partage de la mémoire et
autres ressources. En 2.6 avec la NPTL, le kernel fait une nette
différence entre un thread et un processus.

--
Matthieu

Avatar
kanze
Michel Michaud wrote:
Dans le message
,
Michel Michaud wrote:
Effectivement c'est loin d'être la même chose que le
multithread et je suis heureux que ce soit plus simple, car
c'est ce que j'ai à enseigner :-) (ce n'est pas moi qui
enseigne vraiment la programmation multithread).


Attention. Si les utilisatoins naïves des threads et des
processus sont différentes, dans un bon système
d'exploitation (et je crois qu'à cet égard, les Windows
modernes sont de bons systèmes d'exploitation), il n'y a pas
vraiment de différence.


Je dirais plutôt que c'est complètement différent, en tout
cas, dans les systèmes courants, mais j'imagine qu'on peut
dire n'importe quoi, selon le point de vue choisi, surtout si
on dit « dans un bon système d'exploitation »... Tu as un
exemple d'un de ces « bons » SE ?


Ma première question sera : quelles sont ces différences ? Ou
plutôt, qu'est-ce que tu entends par « processus » ? Parce que
les threads d'aujourd'hui sont exactement les processus d'hier.

Le système connaît en premier lieu des threads (dans la
terminologie moderne). À chaque thread est associé un
certain nombre de ressources, qui peuvent être partagé ou
non. Et en fin de compte, même pour l'utilisateur, où est la
différence entre un processus multithread avec de la mémoire
spécifique à chaque thread, et des processus avec de la
mémoire partagée.


Il y a tout plein de différences, en tout cas, si tu as bien
écrit ce que tu voulais écrire...


C-à-d ? Dans l'ensemble, quelles sont ses différences ?

Ou plutôt, qu'est-ce que c'est qu'un processus aujourd'hui ?
C'est un étiquette qui permet à s'adresser à plusieurs threads à
la fois. Mais plus que ça ? Je sais partager des ressources
entre des threads dans différents processus, et je sais créer
des ressources qui ne sont pas visibles à tous les threads dans
un seul processus.

Mais il va falloir repartir du début et s'entendre sur une
définitions de thread (et je ne sais pas si tu connais les «
fibers » de Windows ?).


Jamais entendu parlé.

En fait, quand on me dit « multithread », je m'attends à ce
que la mémoire où se trouve les piles fassent partie des
ressources partagée, et quand on parle de plusieurs
processus, qu'elle n'en fasse pas partie.


Bien, tu contredis toi-même tes affirmations qu'il n'y a pas
de différences...


Je parle ici d'une attente, non d'une différence fondamentale.
Sous Unix, au moins, je peux très bien faire des piles qui sont
visibles depuis plusieurs processus.

Je cherche, en fait, une bonne définition d'un processus.

Mais même là -- au moins sous Posix (et ça m'étonnera que ce
ne soit pas le cas sous Windows aussi), je peux créer des
threads avec des piles dans de la mémoire partagée,
accessibles depuis d'autres processus.


Si tu veux écrire du code en assembleur, j'imagine que tu
pourras faire n'importe quoi, mais la pile C++ ne sera pas
partagée par des threads de processus différents...


Sous Unix, au moins, je n'ai même pas besoin de l'assembleur. Je
ne vois pas trop l'intérêt, mais on peut très bien créer des
threads dont la pile est dans la mémoire partagée ou mmappée.

Logiquement, on devait aussi pouvoir créer des threads dont la
pile n'est pas accessible depuis les autres threads dans le même
processus. Sous Unix, au moins, ce n'est pas possible, à cause
des contraintes d'ordre : il faut que la pile existe pour
pouvoir créer le thread, et on ne peut créer de la mémoire
propre au thread qu'une fois le thread existe. Mais ce n'est pas
une contrainte fondamentale.

Note bien aussi que sous Posix (et probablement sous Windows
aussi), si un mutex, un rwlock, une condition variable ou un
semaphore se trouve dans la mémoire partagée, il peut
synchroniser des threads dans des processus différents.


Dans Windows, on ne sait pas où sont les mutex (etc.), mais on
peut les partager (ça me semble bien évident que ça peut
servir à des threads, qu'ils soient n'importe où).

Je me demande si tu as la même vision générale que moi des
processus/thread/IPC offerts par les systèmes d'exploitation
modernes. Pour moi, Unix était tellement faible sur ce niveau
avant Posix, que tu as peut-être été biaisé dans ta
compréhension de ce qui est offert par les autres. Mon
impression est que Unix est un très mauvais exemple de système
d'exploitation quand il faut apprendre les principes des
services qu'un SE peut offrir aux programmeurs... Posix
ressemble plus à une « patch » qu'à ce qu'on veut vraiment,
mais, clairement, c'est utilisable :-)


Je suis tout à fait d'accord avec ton évaluation d'Unix. Il y
arrive, peu à peu. À un niveau qu'avait des bons systèmes d'il y
a 25 ans. (Je pense, par exemple, à RMX 86.)

--
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



Avatar
Arnaud Meurgues
wrote:

différents processus. Une des applications sur laquelle je
travaille ici utilise bien de la mémoire partagée (au moyen de
mmap), et synchronise ses « processus » au moyen des mutex situé
dans cette mémoire. Du coup, je me sers des moyens de
communication traditionnellement associés à des threads pour la
communication entre processus.


Sauf qu'ils sont gérés dans de la mémoire partagée, qui, elle, dispose
d'une gestion spécifique adaptée à de la communication entre processus.

C'est simplement par une bonne séparation des couches (la mutex d'une
part et la mémoire partagée d'autre part) que l'on a le sentiment de
gérer la communication entre threads de la même manière que la
communication entre processus.

En somme, la distiction thread-processus est plus
conventionnelle que fondamentale.


Je dirais que dans ton cas, elle reste fondamentale, mais que la mémoire
partagée te donne un moyen de t'abstraire de cette distinction. En tout
cas, c'est plutôt comme ça que je le vois.

Mais il y a une chose qui, je crois, ressort de ce que tu dis (notamment
ton expérience avec certains systèmes temps-réel), c'est que les notions
de thread et de processus sont éminemment conventionnelles.

Arnaud

Avatar
Richard Delorme

|
| Le mot « truck » est un bon mot américain (non seulement texan),
| avec deux significations fréquentes : camion, et bogie. En

Au Texas, cela a une autre signification. Et je suis bien placé pour
le savoir ;-p


Les gros pick-up américains ? Ou une autre signification bizarroïde ?

--
Richard

Avatar
Arnaud Meurgues
Michel Michaud wrote:

Et la vôtre, probablement tout aussi fausse, est que vous êtes
trop en admiration devant le fait anglais, ce qui vous pousse
à admirer les mots anglais anormalement... ça fait « cool »...


Je crois que nos situations ne sont pas comparables. Au Québec, il y a
une pression anglophone forte à laquelle vous réagissez par une attitude
de défense. Défense pas tout-à-fait efficace : si vous arrivez à ne pas
utiliser les mots anglais, il vous arrive de leur en prendre les
tournure (vous « tombez en amour », par exemple).

Chez nous, l'anglais n'est pas ressenti autant comme une agression car
il n'y a pas d'autre enjeu que la langue (au Québec, il y a un enjeu
politique aussi). On s'en défend moins et, probablement, pas assez (il
n'y a qu'à voir le nombre de publicités dont les slogans ne sont qu'en
anglais. C'est impressionnant), mais l'invasion de l'anglais n'est pas
un danger important (après tout, la langue française a fortement
imprégné l'anglais il y a quelques siècles sans que cela ne lui soit
particulièrement préjudiciable).

Je crois que notre différence essentielle est là : le Québec
(probablement pas à tort) fait de sa langue un enjeu politique. Ce n'est
absolument pas le cas en France.

Arnaud

Avatar
Michel Michaud
Dans le message ,
Oui et non. Toutes les primitives de communication
« inter-processus » sont aussi disponibles pour la communication
entre threads.


Oui, mais on ne fait pas des threads pour ça, plutôt pour faire
ce qu'on ne peut pas faire avec des processus séparés...

En fait, sous Linux (et sous la dernière version
de Solaris, et je crois aussi sous Windows), il n'y a pas de
processus au sens classique ; il n'y a que des threads.


Alors nous n'avons plus à discuter des différences, puisque
tout dépend de ce point de vue de départ... Si tu pars du
principe que c'est la même chose alors oui, ce sera la même
chose ! Pour moi, quand il y a des appels systèmes différents,
c'est différent.

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

5 6 7 8 9