string

[WTF]

object Obj = new object();
string Temp = "Hallo" + Obj + "Welt!";

WTF???

[BioStar]

Wo ist das Problem?
Der Compiler meldet doch schon alles was man wissen muss:
"Fehler 13 Eine implizite Konvertierung vom Typ "object" in "string" ist nicht möglich."
Du könntest folgendes verwenden, dann tut es:

string Temp = "Hallo" + Obj.ToString() + "Welt!";

Gern geschehen!

[WTF]

BioStar schrieb:

"Fehler 13 Eine implizite Konvertierung vom Typ "object" in "string" ist nicht möglich."

Kommt bei mir aber nicht! Ich benutze das VS2008, liegt es daran?

Danke für die schnelle Antwort, du Affe! Hat nix geholfen!!!!

[O.o]

Dann wird VS08 wohl so "schlau" sein und beim "zusammenbasteln" eines strings automatisch object.ToString() aufrufen.

PS: Selbst nachdenken erwünscht, du Affe!

[David_pb]

Object.String hat einen "+"-Operator der ein Objekt akzeptiert und automatisch die Methode ToString aufruft, die ja ohnehin jedes Objekt in .NET hat...

[WTF]

David_pb schrieb:

Object.String hat einen "+"-Operator der ein Objekt akzeptiert und automatisch die Methode ToString aufruft, die ja ohnehin jedes Objekt in .NET hat...

Aber was soll der Driss? Typsicherheit am Arsch. Setze den String "Hallo" mit einem System.Windows.Forms.Cursor zusammen! So'n Scheiß!

[David_pb]

Das hat garnichts mit der Typsicherheit zu tun. Jedes Objekt kann zu einem String konvertiert werden, das ist so festgelegt und da ist nichts falsches dran...
Wenn du ein Problem mit .NET hast, dann benutz es doch einfach nicht.

[WTF]

David_pb schrieb:

Das hat garnichts mit der Typsicherheit zu tun. Jedes Objekt kann zu einem String konvertiert werden, das ist so festgelegt und da ist nichts falsches dran...

Explizit wäre es in Ordnung. Aber implizit? Ich hatte ursprünglich eine string-Variable, die ich in eine Datenbank schreibe. Dann hab ich aus dem String im Programm eine richtige Klasse gemacht. Jetzt, ein halbes Jahr danach, bekam das Programm einen Bug, weil die ToString-Funktion umgeschrieben wurde und nun nicht mehr nur das in die Datenbank zu Schreibende zurück gibt, sondern einen kompletten, ausgeschriebenen Namen. Und einige Strings wurden immer noch mit Objekten dieser Klasse addiert. Hätten die .Net richtig gemacht, hätte mir der Compiler damals schon gesagt, dass man ein Objekt von meiner Klasse nicht auf einen String addieren kann und ich hätte gleich MeinString += MeinObjekt.ID geschrieben.

[David_pb]

Ich seh schon was du meinst und man kann sich mit sicherheit auch darüber streiten, warum Object eine ToString() Methode hat. Aber, dass ist nicht das Problem von String.

[WTF]

David_pb schrieb:

Ich seh schon was du meinst und man kann sich mit sicherheit auch darüber streiten, warum Object eine ToString() Methode hat. Aber, dass ist nicht das Problem von String.

Dass object eine ToString-Methode hat, ist nicht mein Problem. Gegen explizite Konvertierungen hab ich nichts. Mich stört nur, dass der +-Operator von string objects entgegennehmen kann. Das hätte nicht sein müssen. Den hätte man so programmieren können, dass er ausschließlich strings entgegennimmt. Wenn ich einen String mit einem Objekt verbinden möchte, könnte ich ja dann das ToString benutzen. Aber dass so etwas implizit funktioniert, ist eben Dreck. Oder gibt es einen sinnvollen Anwendungsbereich, wo die implizite Konvertierung von allen Objekten in string Sinn macht? ToString gibt per default sowieso nur den Klassennamen zurück, und der geht den Benutzer ja letztendlich gar nichts an. Und wenn man eben in ToString etwas Sinnvolles stehen hat, kann man auch ToString aufrufen, wenn man es braucht. Oder auch einen implicit operator string deklarieren.

Es ist ja auch nicht so, dass object generell immer implizit in string umgewandelt werden kann. Das hier funktioniert zum Beispiel nicht:

object o = new object();

MessageBox.Show(o);

Und warum nicht? Weil die implizite Umwandlung von object in string eben kein generelles Feature von .Net ist, sondern nur, weil der Parameter des +-Operators von string object ist.

[noob camper]

WTF schrieb:

Oder gibt es einen sinnvollen Anwendungsbereich, wo die implizite Konvertierung von allen Objekten in string Sinn macht?

Der Debugger zeigt das Ergebnis davon an. Selbstverständlich gehört auch in jeder Klasse ToString() überschrieben.

Anfänger.

[WTF]

if (User.Name == "noob camper")
{
    while (true)
    {
        User.ReadPost(@"

noob camper schrieb:

Der Debugger zeigt das Ergebnis davon an.

Ooooh, da dann ist es ja gerechtfertigt: Weil der Debugger dann etwas Schönes zum Anzeigen hat. Das ist natürlich ein Grund, eine Programmierentscheidung zu treffen: Wie gut sieht es im Debugger aus?

noob camper schrieb:

Selbstverständlich gehört auch in jeder Klasse ToString() überschrieben.

Ach ja? Interessant, dass die meisten .Net-Klassen das trotzdem nicht tun und nur den Klassennamen anzeigen.

Was würdest du hier für ToString bei einer Klasse, die eine Videospielfigur repräsentiert, vorschlagen?

noob camper schrieb:

Anfänger.

b00n!!!!!!!!!einseinseinself

ωτƒ ι∫ ςσσζεΓ τΠΛπ γσμ.

");
    }
}

[Merle]

Du solltest Dir nochmal die Grundlagen von Net zu Gemüte ziehen, du Mettwurst...

[geeky]

Das Problem lässt sich mit parametrisierten SQL-Queries umgehen

[WTF]

Merle schrieb:

Du solltest Dir nochmal die Grundlagen von Net zu Gemüte ziehen, du Mettwurst...

Na, dann gib mir mal einen Tipp, wonach ich suchen soll. Grundlagen gibt es viele.

geeky schrieb:

Das Problem lässt sich mit parametrisierten SQL-Queries umgehen

Das mit der Datenbank war nur Hintergrundwissen. Darum ging es nicht. Es ging mehr darum, dass ich folgendes gemacht habe:

string[] meineDaten...

for (int i = 0; i < meineDaten.Length; i++)
    label.Text += meineDaten[i] + ";";

label.Text = label.Text.Trim(';');

Und wenn meineDaten zu einer eigenen Klasse werden, hätte ich eigentlich gehofft, dass mir der Compiler an jeder Stelle, wo sowas vorkommt, einen Fehler liefert, damit ich überall schreiben kann:

MeineKlasse[] meineDaten...

for (int i = 0; i < meineDaten.Length; i++)
    label.Text += meineDaten[i].ID + ";";

label.Text = label.Text.Trim(';');

und nicht implizit den String-Operator nimmt, der ja unter Umständen etwas ganz anderes beinhaltet als das, was ich da auflisten will.

[loks]

WTF schrieb:

Und wenn meineDaten zu einer eigenen Klasse werden, hätte ich eigentlich gehofft, dass mir der Compiler an jeder Stelle, wo sowas vorkommt, einen Fehler liefert, damit ich überall schreiben kann:
[cs]MeineKlasse[] meineDaten...

Es ist nicht die Aufgabe des Compilers deine logischen Fehler oder Design Fehler zu finden. Es ist DEINE Aufgabe Klassen so zu designen das solche Fehler entweder gar nciht erst passieren oder z.B. durch Unit Tests gefunden werden können. Also gib nicht dem Compiler die Schuld dafür das Dein Design schwach ist... Versuch lieber aus den Fehlern zu lernen und es beim nächsten Mal besser zu machen...

Ich schätze Du hast früher C++ programmiert und versuchst jetzt im gleichen Stil C# zu proggen (die for-Schleife ist ein deutliches Give-away für Ex-C++ler, jeder C#ler würde hier ne foreach nehmen). Das geht idr schief weil C# eben NICHT C++ ist. Entscheidender Unterschied ist das SOM das C++ bis heute nicht kennt, C# dagegen schon....

[WTF]

loks schrieb:

Es ist nicht die Aufgabe des Compilers deine logischen Fehler oder Design Fehler zu finden. Es ist DEINE Aufgabe Klassen so zu designen das solche Fehler entweder gar nciht erst passieren oder z.B. durch Unit Tests gefunden werden können.

Was hat das mit dem Klassendesign zu tun? Hätte ich statt += einfach = genommen, hätte es komischerweise einen Fehler gegeben.
Ich sehe immer noch keinen Grund, auf einen String implizit alles addieren zu können. Nach dieser Logik könnte man auch rechtfertigen, dass man einem int alles übergeben kann und das int dann den string aus der ToString-Methode parst.

loks schrieb:

Also gib nicht dem Compiler die Schuld dafür das Dein Design schwach ist...

Das liegt überhaupt nicht am Design, sondern an der fehlenden Typprüfung. Es ist nicht logisch, jeden Datentyp implizit auf einen string aufzuaddieren. Erst recht nicht, wenn die gewöhnliche Zuweisung auch nicht funktioniert. (text = meinObjekt geht nicht, was auch logisch ist, aber text += meinObjekt lässt er zu)

loks schrieb:

Ich schätze Du hast früher C++ programmiert

Und? Das, worum es hier geht, ist lediglich Typsicherheit, und das ist ja wohl in C++ und C# gefragt. Wie gesagt: Man kann kein object implizit in einen int umwandeln, man kann ja nichtmal b = i schreiben wenn b ein byte und i ein int ist. Man kann auch kein object auf einen string belegen. Aber kurioserweise kann man jedes object implizit auf einen string aufaddieren. Danke, .Net, das macht Sinn und ist konsistent!

[loks]

WTF schrieb:

loks schrieb:

Es ist nicht die Aufgabe des Compilers deine logischen Fehler oder Design Fehler zu finden. Es ist DEINE Aufgabe Klassen so zu designen das solche Fehler entweder gar nciht erst passieren oder z.B. durch Unit Tests gefunden werden können.

Was hat das mit dem Klassendesign zu tun? Hätte ich statt += einfach = genommen, hätte es komischerweise einen Fehler gegeben.
Ich sehe immer noch keinen Grund, auf einen String implizit alles addieren zu können. Nach dieser Logik könnte man auch rechtfertigen, dass man einem int alles übergeben kann und das int dann den string aus der ToString-Methode parst.

loks schrieb:

Also gib nicht dem Compiler die Schuld dafür das Dein Design schwach ist...

Das liegt überhaupt nicht am Design, sondern an der fehlenden Typprüfung. Es ist nicht logisch, jeden Datentyp implizit auf einen string aufzuaddieren. Erst recht nicht, wenn die gewöhnliche Zuweisung auch nicht funktioniert. (text = meinObjekt geht nicht, was auch logisch ist, aber text += meinObjekt lässt er zu)

loks schrieb:

Ich schätze Du hast früher C++ programmiert

Und? Das, worum es hier geht, ist lediglich Typsicherheit, und das ist ja wohl in C++ und C# gefragt. Wie gesagt: Man kann kein object implizit in einen int umwandeln, man kann ja nichtmal b = i schreiben wenn b ein byte und i ein int ist. Man kann auch kein object auf einen string belegen. Aber kurioserweise kann man jedes object implizit auf einen string aufaddieren. Danke, .Net, das macht Sinn und ist konsistent!

q.e.d

[WTF]

loks schrieb:

q.e.d

Ja, ja, lustig. Aber wirklich konkret erklären kannst du mir die folgende Diskrepanz nicht, oder?

object o = new object();
string s;

// Nicht jeder beliebige Datentyp kann implizit
// in einen String umgewandelt werden:

s = o;             // Fehler!
s = new string(o); // Fehler!

// Selbst eine explizite Konvertierung würde
// nicht funktionieren:

s = (string)o;     //Absturz!

// Das einzige, was funktioniert: Ein simpler
// Aufruf einer Funktion, die ganz normal einen
// String zurückliefert:

s = o.ToString();

// Andererseits:

// Bei einer Stringverknüpfung ist ein expliziter
// Aufruf nicht mehr nötig, weil der +-Operator,
// im Gegensatz zum Konstruktor, Daten vom Typ
// object annehmen kann:

s = "Hallo, " + o;

Was bitteschön ist daran logisch? Die Umwandlung in einen String ist nicht mal ein eingebautes Sprachfeature. Sie funktioniert weder implizit noch explizit. Und string besitzt noch nicht einmal einen Konstruktor, der ein object entgegen nimmt. Und trotzdem wurde beim +-Operator die Ausnahme gemacht und für ihn als Parameter nicht nur string, sondern object festgelegt.

Kann mir jemand das erklären:
- Implizite Umwandlung von object in string --> Nicht möglich
- Explizite Umwandlung von object in string --> Stürzt bei nicht kompatiblen Typen ab./Wirft eine Exception.
- string-Konstruktor, der ein object entgegen nimmt --> Nicht vorhanden
- +-Operator bei string, der ein object entgegen nimmt --> Vorhanden!!!

[loks]

WTF schrieb:

// Andererseits:

// Bei einer Stringverknüpfung ist ein expliziter
// Aufruf nicht mehr nötig, weil der +-Operator,
// im Gegensatz zum Konstruktor, Daten vom Typ
// object annehmen kann:

s = "Hallo, " + o;

_oder_ weil automatisch o.ToString() aufgerufen wird...