Y a-t-il une raison à cela ? Je pose la question parce que si vous deviez utiliser beaucoup de caractères vides, vous vous retrouveriez dans la même situation que si vous utilisiez beaucoup de chaînes de caractères vides.
Edit : La raison de cette utilisation était la suivante :
myString.Replace ('c', '')Supprimez donc toutes les instances de 'c' de maChaîne.
Il n'y a pas de char vide. Le plus proche que vous puissiez obtenir est '\0' le caractère "null" d'Unicode. Étant donné qu'il est très facile d'intégrer ce caractère dans les chaînes de caractères ou de l'exprimer seul, pourquoi vouloir un champ distinct pour lui ? De même, l'argument "il est facile de confondre "" y " " "Ces arguments ne s'appliquent pas aux '\0' .
Si vous pouviez donner un exemple de l'endroit où vous voudriez l'utiliser et pourquoi vous pensez qu'il serait meilleur, cela pourrait aider...
N'est-ce pas le \0 le caractère de "fin du tableau d'octets" ? Ou est-ce que je confonds avec quelque chose d'autre ?
@Bertvan : Pourquoi y aurait-il un caractère à la fin d'un octet réseau ? C'est utilisé pour les chaînes de caractères "null terminated", oui.
La raison de cet usage était la suivante :
myString.Replace ('c', '')Supprimez donc toutes les instances de'c'de maChaîne.
Pour supprimer un caractère spécifique d'une chaîne, vous pouvez utiliser la surcharge string :
myString = myString.Replace ("c", String.Empty);Votre déclaration
myString.Replace ('c', '\0')Il ne supprimera aucun caractère. Il les remplacera simplement par '\0' (End-Of-String, EOS), avec des conséquences variables. Certaines opérations sur les chaînes de caractères peuvent s'arrêter lorsqu'elles rencontrent un EOS, mais dans .NET, la plupart des actions le traiteront comme n'importe quel autre caractère. Le mieux est d'éviter '\0' autant que possible.
@OrenMazor, non, ça ne l'est pas. Cette réponse n'essaie même pas de répondre à la question. La question était "Pourquoi n'y a-t-il pas Char.Empty comme String.Empty ?"
C'est tout à fait exact. Il est logique de demander si un conteneur est vide ou non. Cela n'a aucun sens de demander si un int, un float ou un char est vide.
@Joe : Alors comment une chaîne peut-elle être vide si une chaîne est une collection de caractères (non vides) ? Probablement stupide, désolé...
Parce qu'une chaîne n'est pas constituée d'objets individuels, mais d'une collection. Pensez à un seau de pierres. Je ne peux pas avoir une pierre vide. Mais je peux avoir un seau vide.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Oui, j'ai utilisé ce mot par manque d'un meilleur mot. C'est-à-dire la manière recommandée d'utiliser String.Empty au lieu de "".
0 votes
Merci, savez-vous pourquoi il n'est plus recommandé ? Est-ce à cause du compilateur qui le fait pour vous ?
3 votes
Si vous craignez de faire des fautes de frappe dans certains cas, pourquoi ne pas tout simplement envelopper la fonctionnalité dans une méthode d'extension sur le modèle de
RemoveAll(this string s, params char[] toRemove)? L'intention sera clairement communiquée et vous ne risquerez pas de faire des fautes de frappe.12 votes
@Henk - La seule raison pour laquelle j'utilise string.Empty est que je trouve que l'objet nul fourni par Empty exprime mieux l'intention que les guillemets vides. Les guillemets vides pourraient résulter d'un problème de fusion, ou d'une pensée bâclée, ou encore être l'intention réelle de ce code, alors que Empty m'indique explicitement que le développeur avait l'intention que cette chaîne n'ait pas de données.
3 votes
Il y a une différence entre "" et string.Empty. Non pas que quelqu'un s'en soucie, vraiment, mais "" crée un objet, alors que string.Empty utilise un objet déjà créé. Mais encore une fois, c'est si petit, que seules des situations spéciales peuvent faire la différence.
4 votes
@marcelo-ferrazm, sur
""crée un objet : Non, ce n'est pas le cas.