Laden...

@ vor String

Erstellt von lebes vor 17 Jahren Letzter Beitrag vor 17 Jahren 4.459 Views
L
lebes Themenstarter:in
82 Beiträge seit 2006
vor 17 Jahren
@ vor String

Hallo,

bin ziemlicher C# Neuling. Hab jetzt schon öfter bei der Zuweisung eines Strings den Klammeraffen @ gesehen. Sicher eine banale Frage, aber wofür steht dieser?

Gruß

4.506 Beiträge seit 2004
vor 17 Jahren

Hallo lebes,

du brauchst innerhalb vom String keine Escape-Sequenzen mehr angeben, da alles als Text behandelt wird.

Das heißt, dass z.B. Pfadangaben nicht mehr mit einem Doppelbackslash angegeben werden müssen...

Gruß
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

A
217 Beiträge seit 2006
vor 17 Jahren

Gefunden im MSDN

Der Vorteil der @-Schreibweise besteht darin, dass Escapesequenzen nicht verarbeitet werden, wodurch z. B. das Schreiben vollqualifizierter Namen erleichtert wird:

@"c:\Docs\Source\a.txt"  // rather than "c:\\Docs\\Source\\a.txt"  

Gruß,
AtzeX

Edit:
Mist, zu langsam. 🙂
@norman_timo:
Klasse Signatur! 👍

T
243 Beiträge seit 2006
vor 17 Jahren

... außerdem sind somit mehrzeilige Strings möglich, wie:

string test = @"dies ist ein
mehrzeiliger
text";
C
103 Beiträge seit 2007
vor 17 Jahren

Guten Morgen,

der Thread ist zwar schon älter, aber ich habe eine Frage, die hier eigentlich genz gut mit rein passt. Also wie schon gesagt wurde kann ich mit dem @ vor einem String die Interpretation von ... verhindern. Jetzt möchte ich das gern auf Strings in Variablen anwenden, was mir bisher nicht gelang.

Konkretes Beispiel.


public void WriteInFile(string text, string file)
{
  FileStream handle = new FileStream(file, ...);
}

Ich bekomme per Parameter irgendeine Datei mit Pfad übergeben, z.B. "c:\temp\irgendwas.txt".
Diesen Parameter übergebe ich FileStream, was mir den Fehler "Illegales Zeichen im Pfad" bringt, weil er das \t von c:\temp und das \i von temp\irgendwas als Anweisung sieht. Ich könnte natürlich vorher den Parameter bearbeiten und z.B. mit


file = file.Replace(@"\", "/");

die Backslashes umdrehen.

KORREKTUR: Nicht mal das funktioniert. Bisher kriege ich den Code nur zum laufen, wenn ich den Dateinamen von vorne herein mit / statt \ übergebe.

Ich frage mich nur, ob es nicht eine einfachere Möglichkeit gibt, die quasi sowas entspräche:


public void WriteInFile(string text, string file)
{
  FileStream handle = new FileStream(@file, ...);
}

Also dass generell der String in der Variablen (wie er auch aussehen mag) nicht interpretiert wird. Gibt es sowas?

Danke für Eure Beiträge 🙂

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo capcom,

wenn in einer Variablen \ und t hintereinander stehen, dann wird daraus kein Tabzeichen. Es muss also in deinem Pfad schon echt ein Tabzeichen enthalten sein, wie immer das da rein gekommen ist. Du musst also verhindern, dass das Tabzeichen in die Variable überhaupt erst reinkommt. Das halte ich für die einzig sinnvolle Lösung. Das Tabzeichen durch @"\t" zu ersetzen, halte ich für gefährlich.

herbivore

C
103 Beiträge seit 2007
vor 17 Jahren

Hallo herbivore,

hm dann kann ich mir das Verhalten des Programms im Moment nicht logisch erklären. Übergebe ich als Datei statt "c:\temp..." nämlich "c:/temp/...", dann bekomme ich keinen Fehler.
Der "Trick" mit dem Replace, den ich vorher erwähnte, hat übrigens auch nicht funktioniert, also habe ich momentan keine Idee, wie man sowas universell ausschließen könnte. Mal sehen was ich noch entdecke.

Ich muß doch irgendwie nachträglich abfangen können wenn der Anwender später mal seine Pfade mit \ eingibt, wie er es unter Windows gewöhnt ist.

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo capcom,

wo übergibst du "c:\temp..." und wie? Als String-Literal? Wenn ja, dann musst du an der Stelle das @ davorsetzen.

herbivore

C
103 Beiträge seit 2007
vor 17 Jahren

Hallo herbivore,

ich bin ein Rindvieh 😉 Ich habe mir die ganze Zeit den Kopf über ein Problem zerbrochen, das scheinbar gar keins ist g Wenn ich den Pfad per ReadLine von der Konsole aus einlese, scheint das Verhalten von vornherein ein Anderes zu sein. Da wird irgendwie gar nix interpretiert.
Wenn mans wo hart codiert - wie ich es jetzt zum testen gemacht habe und die Probleme auftraten - muß man halt dran denken, aber dafür hat Dein vorheriger Vorschlag funktioniert.

Sorry für die Umstände 🙂