Recherche du dernier caractere d'une chaine

Bonjour à tous,

Voila je ne comprend pas trop comment fonctionne ce bout de code:

char*str="Vive l'OpenGL"
char*EndOfStr;

EndOfStr = str + strlen(str);

while (str < EndOfStr)
{
...
}

"EndOfStr = str + strlen(str);" Cette ligne semble permettre de trouver le dernier caractere de str. Cela marche car EndOfStr est utilisée dans la boucle while mais comment un chaine peut elle être concaténée à un int ?
Lorsque je regarde EndOfStr au debbug il vaut tjs (il me semble) "".
Comment 2 chaines peuvent-elles être ainsi comparées dans la boucle while?

merci d'avance

Ce n'est pas de la manipulation de chaînes, mais simplement de l'arithmétique de pointeurs. Lorsque tu ajoutes un entier N à un pointeur, cela va décaler celui-ci de N éléments. Donc pointeur sur ta chaîne + taille de la chaîne = pointeur sur le dernier élément de ta chaîne.

Ensuite la conditions du while ne compare pas les chaînes, mais seulement les valeurs des pointeurs, et signifie "tant que le caractère actuel n'est pas le dernier".

http://loulou.developpez.com/pointeurs.png

PS : ça devrait être des const char* et non des char*
PPS : pas la peine de chercher un pointeur sur la fin de la chaîne, il suffit de s'arrêter lorsque l'on tombe sur le caractère nul ('\0') ; c'est ce que fait d'ailleurs strlen

Ok compris
Merci pour ta réponse

est-ce que c'est plus efficace d'utiliser un tableau de char si on peut utiliser carrément la classe string ?

Citation:

---

Envoyé par hitomidoaxbv

est-ce que c'est plus efficace d'utiliser un tableau de char si on peut utiliser carrément la classe string ?

---

Si c'était le cas la classe string ne servirait à rien.

Je me permet de m'immiscer pour dire que le bout de code ci-dessus a une utilité.
Le caractère 0 est bien la marque de fin de chaine, mais l'octet 0 non...
S'arrêter au premier octet 0 rencontré risque de ne pas marcher...

Par exemple:

Code:

---

1 2 3 4

Octets: 89 243 0 99 88 0 -- ----- -- -- - Chars: 0 1 2 3 4

---

strlen, si je souviens bien, utilise la locale par défaut pour strlen(), et rien ne dit que celle-ci utilise bien un code-page single-byte (chaque caractère encodé sur un seul octet).

Code:

---

1 2 3

const char* str; const char* eos = str + strlen(str);

---

Avec ce code, eos pointent toujours sur le dernier caractère de la chaine quelque soit la locale.

J'aimerai qu'un jour quelqu'un m'explique pourquoi en 2007 les gens continuent d'utiliser des chars au lieu de wchar_t !
C'est un vrai mystère pour moi... UTF existe depuis combien de temps maintenant ? 20 ans ? Et on trouve encore du code compliqué pour gérer les chaînes de caractères (haaa les joies du Shift-JIS, ou encore du CP1252 vs ISO-8859-2) alors qu'il existe un standard pour le faire proprement...

Quand on pensse que meme std::string utilise des char* !!!

Citation:

---

Avec ce code, eos pointent toujours sur le dernier caractère de la chaine quelque soit la locale.

---

strlen ne fait rien de plus que boucler jusqu'au premier caractère nul, je ne pense pas qu'elle prenne en compte la locale pour distinguer caractères nuls et octets nuls.

Citation:

---

Quand on pensse que meme std::string utilise des char* !!!

---

std::string n'est qu'une spécialisation de std::basic_string<> pour le type char.
Il me semble même que la spécialisation pour wchar_t existe : std::wstring.

Salut,

Citation:

---

Envoyé par nicroman

J'aimerai qu'un jour quelqu'un m'explique pourquoi en 2007 les gens continuent d'utiliser des chars au lieu de wchar_t !
C'est un vrai mystère pour moi... UTF existe depuis combien de temps maintenant ? 20 ans ? Et on trouve encore du code compliqué pour gérer les chaînes de caractères (haaa les joies du Shift-JIS, ou encore du CP1252 vs ISO-8859-2) alors qu'il existe un standard pour le faire proprement...

---

Tout simplement parce que certains programmes/bibliotheques/parties de code sont basés sur des choses qui sont potentiellement écrites depuis bien plus de vingt ans, et que demander de passer le tout en UTF/iso demanderait de reprendre plus de vingt ans de développement...

C'est exactement la meme raison qui fait que les banques et les assurances continuent à utiliser COBOL, que le programme Ariane continue à utiliser l'ADA et autres cas similaires

Il faut bien comprendre que l'informatique n'a pas commencé à exister avec le PC tel que tu le connais depuis 1987, que, meme au niveau du PC, il y a eu d'énormes évolutions avant le 3x86, et que, avant meme l'apparition du PC, il y a eu d'autres ordinateurs encore actuellement en service

Passer à l'utilisation généralisée de l'UTF nécessiterait, non seulement, de réécrire l'ensemble des programmes, mais, aussi, de réécrire l'ensemble des fichiers de données qui sont utilisés par ces programmes...

On perdrait, à peu de chose pres, toute une génération de programmeurs (et peut etre meme plus) à le faire :P

Citation:

---

strlen, si je souviens bien, utilise la locale par défaut pour strlen(), et rien ne dit que celle-ci utilise bien un code-page single-byte (chaque caractère encodé sur un seul octet).

---

strlen n'utilise aucune locale et ne fait que compter les bytes d'une chaîne C-style.

Citation:

---

J'aimerai qu'un jour quelqu'un m'explique pourquoi en 2007 les gens continuent d'utiliser des chars au lieu de wchar_t !
C'est un vrai mystère pour moi... UTF existe depuis combien de temps maintenant ? 20 ans ? Et on trouve encore du code compliqué pour gérer les chaînes de caractères (haaa les joies du Shift-JIS, ou encore du CP1252 vs ISO-8859-2) alors qu'il existe un standard pour le faire proprement...

---

La raison est simple : wchar_t ne résout aucunement les problématiques liées à l'usage d'Unicode. Il n'y a en fait aucun outil qui permette actuellement de bien gérer l'Unicode, et ce quel que soit le langage de programmation.
Ce qui est marrant, c'est que tu parles de code compliqué pour gérer les chaînes de caractères. Avec un encodage de type ISO-8859-*, et certaines restrictions sur le support des langues globalement assez bien acceptées, toute gestion de chaîne est triviale.
La gestion de chaînes de caractères en Unicode (et ce, quel que soit l'encodage -- la partie encodage d'Unicode étant facile à gérer) est extrêmement complexe, en plus d'avoir un coût en performance conséquent.
Si tu veux faire de l'Unicode, je conseillerais même d'éviter wchar_t (et std::wstring) à tout prix. L'interface ne peut tout simplement aucunement espérer pouvoir supporter Unicode, et l'implémentation encore moins. D'autant plus que ce qu'est wchar_t dépend de la plate-forme.
Microsoft essaie néanmoins de duper les gens et de faire croire qu'en utilisant wchar_t leur application sera "Unicode-aware", alors qu'en fait, elle sera juste capable de stocker de l'UTF-16 et de très mal le gérer, puisqu'en fait on a juste un accès aux code units, même pas aux code points, et encore moins aux caractères. Et il faut pas non plus espérer non plus avoir des algorithmes de recherche etc. qui font les bonnes choses et qui n'invalident pas potentiellement la chaîne.

Bien entendu, pour comprendre la complexité d'Unicode, encore faut-il réellement connaître Unicode.
Par exemple, si tu ne sais pas ce qu'est un grapheme cluster, les différentes normalisations canoniques et de compatibilité, et les algorithmes de collation et de text boundaries, tu as une compréhension très réduite.
Pour bien faire il faudrait aussi connaître les problématiques liées aux différents scripts, mais surtout aussi aux différents langages supportés par Unicode.

Tu peux déjà regarder ça, c'est l'explication de l'algorithme de collation. Ça fait appel à pas mal de choses compliquées d'Unicode, c'est une bonne introduction à sa complexité.
http://www.unicode.org/reports/tr10/