Hallo.

Weiss jemand, wie ich String.Concat überladen kann?

Ich hab ein Programm und möchte nicht immer String.Concat schreiben, um Strings zu verknüpfen.

Wie kann ich String.Concat überladen/verkürzen?

Kurz: Nein.
Lang: Nein, man kann Methoden nur überladen, wenn man der Klasse, in der die Methode deklariert ist, die Überladung hinzufügt (was nicht geht, denn die String-Klasse ist eine Framework-Klasse).
Ausführlich: Es macht keinen Sinn, String.Concat zu überladen. Für triviale Stringverknüpfung verwendet man den &-Operator. Die String.Concat-Methode ist für das direkte Verknüpfen einer Liste von Strings sinnvoll. Für nicht-triviale Sachen verwende String.Format.

Welche Funktionalität fehlt denn deiner Meinung nach in der Concat-Funktion?
Sie nimmt bereits beliebig viele Argumente sowie jegliche Arten von Auflistungen entgegen. Damit erfüllt sie mmn bereits vollständig ihre Aufgabe.

Artentus schrieb:

Welche Funktionalität fehlt denn deiner Meinung nach in der Concat-Funktion?
Sie nimmt bereits beliebig viele Argumente sowie jegliche Arten von Auflistungen entgegen.

Es geht nicht darum, sie zu erweitern. Mein Vorhaben ist, weniger Schreibarbeit dadurch zu haben.

Anstatt String.Concat wäre es cool, wenn ich nur Cnc(Arg1, Arg2, Arg3) schreiben müsste..

Verschoben. Das hat nichts im OffTopic-Bereich zu suchen.

Zum Thema: Du musst einfach nur eine entsprechende Funktion schreiben, wo ist das Problem? Das solltest Du doch mittlerweile eigentlich können...

Grüße

Siehe Niko Ortners Lösung, der Stringverknüpfungsoperator ist nicht umsonst da.
Eine solche Funktion im VB6-Style widerspricht vollkommen den Guidelines, auf denen das Framework basiert, alleine deshalb wirst du sowas nicht finden. Und ich kann auch nicht empfehlen, es selber "nachzurüsten".

Das kommt dazu. Zumal der Aufwand hundert mal größer ist, als wenn Du einfach String.Concat aufrufst oder den String anderweitig verbindest.
Und schön sieht sowas auch nicht aus.

Grüße

Mal eine Frage von mir in die Runde;
Der Unterschied zwischen String.Join und String.Concat.. Worin liegt der unterschied?

Concat verkettet die übergebene Liste an Strings direkt hintereinander, Join fügt zwischen alle Elemente noch einen angegebenen String an, z.B. nützlich wenn man mehrere Strings mit Kommata oder Zeilenumbrüchen getrennt ausgeben möchte.

Okay. Verstehe. Also wäre String.Join sinnvoll, wenn ich immer ein Zeilenumbruch nach meinem String haben möchte und .Concat an dieser Stelle nicht, weil ich jedesmal nach dem String meinen Zeilenumbruch einfügen müsste..? Okay, habe verstanden.
Danke

2 Saublöde ideen:
1. Schreibe eine Extension für die string Klasse, in der es die Funktion Cnc gibt, die nach deinen Wünschen concateniert.
2. zumindest in C# kann man mit einer Using anweisung einer Klasse einen anderen namen geben:

so könnte man dann solches Verwirklichen:

oder gar:

Aber wie schon gesagt, sowas sollte man lieber sein lassen...

Wer nicht viel tippen will, sollte sich den Umgang mit der Tab-Taste angewöhnen:
str->Tab->.con->Tab->( und schon kann man in die Klammern schreiben was man will.

Hi
viel wichtiger als das Wie würde ich das Warum ansehen. Warum meinst du, dass du eine solche Methode benötigst, bzw. was genau stellst du damit an?

Viele Grüße
~blaze~

ich hab so eine Extension, benutze ich sehr oft, weil ich statische Methoden umständlich finde:

@ErfinderDesRades Was ein Schrott. Sorry.

Machs besser

Erzeuge du dieselbe Messagebox ohne Sorry-Schrott.

Edit: Eiglich bin ich recht verärgert - Diffamierungen ohne inhaltliche Begründungen - jämmerlich findich sowas.

Also nix gegen Kritik - bin ich sehr für. Aber Kritik ohne Begründung - sollte man eiglich zur Löschung melden sowas (aber jetzt habich schon drauf geantwortet).

Deine Extension bildet das Verhältnis zwischen den einzelnen Objekten falsch ab. Es ist nämlich nicht das erste String-Objekt, das etwas mit den restlichen Argumenten macht, stattdessen wird auf allen String-Objekten inklusive des ersten eine gemeinsame Operation durchgeführt.
Ein Zusammenfügen von mehreren Strings ist sinngemäß keine Operation irgend eines dieser Strings und hat deswegen keine Objektmethode zu sein. Objektmethoden (und auch Extensions, die wie Objektmethoden verwendet werden), werden als Operationen entweder durch das Objekt auf die Argumente oder auf das Objekt durch die Argumente verstanden, niemals jedoch als Operationen an einem außenstehenden Objekt durch sowohl das Objekt alsauch die Argumente.

Und sorry für die maximal verwirrende Ausdrucksweise.

Verzeih mir.

Unwesentlich länger, trotzdem wesentlich leserlicher, kein VisualBasic-Namespace. Plus was Artentus sagte.
Übrigens: Nutze ich deine Variablen, also ​LF und ​Date.Today.ToString(), dann ist meine Variante sogar kürzer.

Grüße

@Artentus: jo, das ist ein architektonischer Gesichtspunkt, den ich verstehen kann.

Aber da setze ich mich einfach drüber weg, weil ich find das so praktisch, es schreibt sich schnell, ist gut veränderlich (das ist bei String.Format ja immer sone Sache) und kurz.
Und es ist nicht unleserlicher als anderes - wie gesagt: Wenn wir drüber reden wollen, dann am liebsten anhand von Gegenbeispielen, dass man praktisch vergleichen kann.

@Nikx: ok.
Jo, das ist die String.Format-Alternative, und die findich immer lästig, wenn man da die Reihenfolge der Argumente ändert, was einfügt oder so, dann muss man da immer lausig mit den Platzhaltern aufpassen, nachbessern.
Dann schon lieber String.Concat, da schreibt man alles so hinternander weg, wie's rauskommen soll.

Also hätten wir 3 Alternativen - ach 4, nehmen wir olle & noch dazu:

Bitte liefere mir doch ein Beispiel für das "gut veränderlich". Ich habe bei String.Format ein einfach erweiterbares System, kann den String als Ganzes lesen und brauche keine 100 Kommas,
um meinen String zusammenzubauen. Ich kann so gesagt frei darin herumschreiben, wie ich grade möchte. Bei dir ist das etwas schwieriger.

Grüße

Naja, sowas:Neue Argumente eingefügt, andere Argumente gelöscht.
Das geht mit Copy & Paste und Delete.
Der Unterschied ist halt, dass man nur die Argumente selbst anfassen muss, nicht noch zusätzliche Platzhalter.

Aber ich will da auch kein Glaubenskrieg von machen, ich halte das eher für Geschmacksache.

Edit: Aber ich hab noch mehr so String-Helpers:Extensions und mehr. (obwohl - FormatX habich nochmal geändert).

Die beiden sind jetzt glaub auch architektonisch vertretbar