Anfänger: Array aus Strings (System::String)



  • Hi ans Forum,

    ich bin blutiger C++ Anfänger, und kämpfe noch sehr mit den ganzen Begrifflichkeiten und (v.a.) Bezügen - habe im Prinzip aber schon Programmiererfahrung.

    Ganz allgemein gesprochen benötige ich programmintern für meine Aufgabe eine Art Excel-Sheet mit unterschiedlichen Datentypen pro "Spalte". Eine solche Struktur kann man ja mit einer definierten Structure bereitstellen; aus dieser Structure soll dann später ein Array werden.

    Mein Problem ist: Innerhalb dieser Structure hätte ich auch gerne Strings definiert, auf die ich einigermaßen komfortabel zugreifen will (ergo: Keine Einzelarrays innerhalb, die nur aus "Char"s bestehen)

    Wenn ich allerdings in die Structure-Definition "String" aufnehme, beschwert sich der Compiler. Ich nutze Visual Studio 2010, und habe die struct-Definition habe ich in den Code meines Formulars ganz oben eingebaut.

    namespace Zweiter_Versuch {
    	using namespace System;
    	using namespace System::ComponentModel;
    	using namespace System::Collections;
    	using namespace System::Windows::Forms;
    	using namespace System::Data;
    	using namespace System::Drawing;
    
    	struct datentyp
    				{String zeichenfolge;};
    

    Ich bekomme folgenden Fehler:

    ' "System::String": Dieser Typ kann ohne "^" der obersten Ebene hier nicht verwendet werden. '

    Wirkliche Anfängerfrage 1: Was genau heisst das, warum ist das so? "String" ist offensichtlich ja irgendwo definiert, warum kann ich das also nicht ohne ^ einfach hinschreiben?
    Sitzt die Strukturdefinition an der falschen Stelle?

    Wenn ich ein ^ hinzufüge, bekomme ich:

    ' Ein verwalteter 'zeichenfolge' kann nicht in einem nicht verwalteten 'Zweiter_Versuch::datentyp' deklariert werden '

    Frage 2: Was genau heisst diese Meldung, warum ist das so?

    Frage 3: Geht das prinzipiell, was ich da vorhabe? (Objekt in Structure einbinden) Oder muß ich die Objekte erst unabhängig von der Structure erzeugen, und muß dann innerhalb der Structure auf die Objekte referenzieren?

    Ich weiß, diese Fragen demonstrieren wirklich deutlich, daß ich Anfänger bin. Ich bitte euch also um Gnade... 🙂

    Viele Grüße
    Maugli



  • maugli schrieb:

    ich bin blutiger C++ Anfänger,...

    Besonders bist du ein Anfänger in der Bestimmung der Sprache 😉
    Das ist kein C++, sondern wenn C++/CLI (eine eigene Sprache).

    @moderatoren: Bitte entsprechend verschieben.



  • "System::String" ist eine .Net Klasse, und ist managed Code (C++/CLI).
    "struct datentyp" ist wiederum unmanaged Code (C++ oder C++/CLI).



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x) in das Forum C++/CLI mit .NET verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • asc schrieb:

    maugli schrieb:

    ich bin blutiger C++ Anfänger,...

    Besonders bist du ein Anfänger in der Bestimmung der Sprache 😉
    Das ist kein C++, sondern wenn C++/CLI (eine eigene Sprache).

    Aha, wusste ich bisher noch nicht 🙂 Danke für den Hinweis!

    asc schrieb:

    "System::String" ist eine .Net Klasse, und ist managed Code (C++/CLI).
    "struct datentyp" ist wiederum unmanaged Code (C++ oder C++/CLI).

    Heisst das, kurz gesagt, das darf/sollte man besser nicht kombinieren?

    Falls das so ist: Welche .Net Klasse ist empfehlenswert für das, was ich brauche? ('eine Art Excel-Sheet mit unterschiedlichen Datentypen pro "Spalte"', die per Zeilen/Spaltenindizes aufgerufen werden kann) Cool wäre natürlich auch, wenn man "Zeilen" automatisch per Elementfunktionen löschen und einfügen könnte, und das gesamte Ding nach einer bestimmten Spalte sortieren könnte, etc..



  • maugli schrieb:

    Heisst das, kurz gesagt, das darf/sollte man besser nicht kombinieren?

    Die erste Frage ist, welche Programmiersprache du tatsächlich anwenden willst. C++/CLI würde ich niemanden empfehlen. Wenn du mit dem .Net Framework arbeiten willst, wäre C# oder VB.Net eine deutlich bessere Wahl.



  • @asc: Ist das nicht ne ziemliche krasse Grundsatzfrage an jemanden, der ein Array aus Strings basteln will? Mit dem, was er eben nunmal angefangen hat? 🙂

    Versteh mich nicht falsch: Ich weiß natürlich nicht, was besser oder empfehlenswert ist, wie denn auch, ich kenne die Unterschiede nicht.
    Aber ich will ziemlich triviale Dinge programmieren - nur eben mit einer grafischen Oberfläche, und einer aktuellen Sprache. Ist es bei solchen einfacheren Dingen nicht ziemlich egal, ob man das nun mit C++, C# oder VB-Net macht?

    Falls es nicht egal sein sollte, klär mich bitte auf, warum sollte ich C# statt C++/CLI lernen? Denn nur mit Deinem bisherigen Hinweis - so wichtig mir Dein Input auch ist - kann ich nunmal nichts anfangen...



  • Wenns Dir egal ist: nimm C# oder VB.NET und nicht C++/CLI, denn das hat soviele Fallstricke, dass Du dauernd unnötige Probleme hast.



  • maugli schrieb:

    @asc: Ist das nicht ne ziemliche krasse Grundsatzfrage an jemanden, der ein Array aus Strings basteln will? Mit dem, was er eben nunmal angefangen hat? 🙂

    C++/CLI ist jedenfalls jenseits von gut und böse, und hat eigentlich nur Sinn als Brücke zwischen "nativer" und "managed" Welt. Entweder programmierst du C++ oder C#/VB.net, aber bitte nicht C++/CLI, gerade nicht als Anfänger.

    maugli schrieb:

    Versteh mich nicht falsch: Ich weiß natürlich nicht, was besser oder empfehlenswert ist, wie denn auch, ich kenne die Unterschiede nicht.
    Aber ich will ziemlich triviale Dinge programmieren - nur eben mit einer grafischen Oberfläche, und einer aktuellen Sprache.

    Eine Excelansteuerung ist keine triviale Aufgabe, auch wenn .Net das ganze erleichtert. C++ fällt für dich raus, wenn du Klicki-Bundi-Programmierung willst; böse Gesprochen: UI sollte für einen Anfänger, unabhängig von der Programmiersprache, nicht das wichtigste Ziel sein. Auch wenn einige Programmiersprachen dir hier weniger Steine in den Weg legen als Andere, arbeiten selbst C# Einstiegsbücher in der Regel in den ersten paar Kapiteln ohne eine GUI, und das auch nicht ohne Grund, da man erst mal die Programmiergrundlagen (dazu gehören auch Arrays oder Container) lernen sollte.

    maugli schrieb:

    Ist es bei solchen einfacheren Dingen nicht ziemlich egal, ob man das nun mit C++, C# oder VB-Net macht?

    Wenn dir die GUI-Programmierung so wichtig ist, solltest du definitiv nicht mit C++ beginnen (u.a. weil es keine einheitliche UI-Bibliothek gibt), C++/CLI solltest du als Anfänger definitiv meiden. Ich würde dir zu C# raten, da es syntaktisch recht nah am C++ ist, und speziell für das .Net-Framework entwickelt wurde.

    maugli schrieb:

    Falls es nicht egal sein sollte, klär mich bitte auf, warum sollte ich C# statt C++/CLI lernen? Denn nur mit Deinem bisherigen Hinweis - so wichtig mir Dein Input auch ist - kann ich nunmal nichts anfangen...

    1. C++/CLI ist sehr kompliziert (durch die Verbindung zweier Welten ist es effektiv komplexer als C++, das schon nicht als Anfängerfreundlich zählt).
    2. Zu C++/CLI gibt es kaum Beispiele im Internet.
    3. Die C++/CLI-Unterstützung wurde von MS immer weiter reduziert, eine direkte Unterstützung neuer .Net-Technologien ist unter C++/CLI extrem umständlich.

    Nachtrag: Windows Forms und Visual C++ MACHT KEINEN SINN! ist ein Thread der sich mit einigen Problemen zur UI-Programmierung unter C++/CLI befasst...



  • Danke für die ausführliche Antwort!

    asc schrieb:

    C++/CLI ist jedenfalls jenseits von gut und böse, und hat eigentlich nur Sinn als Brücke zwischen "nativer" und "managed" Welt. Entweder programmierst du C++ oder C#/VB.net, aber bitte nicht C++/CLI, gerade nicht als Anfänger.

    Okay, aber jetzt mal ganz doof gefragt: "Normales" C++ lässt sich ja auch innerhalb C++/CLI programmieren, hab ich jetzt auch schon so gemacht. Dann ist doch der einzige CLI-Berührungspunkt eben das GUI, wenn man von den .NET-Klassen die Finger lässt.

    Meine Sorge ist:
    Nicht lachen, aber ich habe bis vor kurzem nur mit einem ganz alten Basic (ohne GUI) programmiert. 15 Jahre lang, mit sehr, sehr vielen Projekten.

    Ich komme also einfach gar nicht aus einer nicht-objektorientierten Richtung. Jetzt habe ich ein Buch über C++ schon ziemlich weit durchgearbeitet, und bin froh, daß es nicht soo kompliziert ist und vor allen Dingen auch, daß ich da "meine Problemlösungs-Methoden" eigentlich ganz klassisch anwenden kann, wie bisher - abgesehen mal von der GUI.

    Daher wäre jetzt nochmal mit c# neu anfangen doch ein bischen doof, und vielleicht auch unnötiger Aufwand. Kann man es nicht auch so sehen? Eben normales C++ schreiben, die .Net Klassen einfach nicht nutzen - abgesehen eben von Windows Forms, als Schnittstelle zur Aussenwelt?

    asc schrieb:

    Eine Excelansteuerung ist keine triviale Aufgabe, auch wenn .Net das ganze erleichtert.

    Da hast Du mich falsch verstanden: Ich will ja gar keine Excelansteuerung... Ich will ein gemischtes Array, und ich fänds schön, wenn ich Sachen wie Sortierungen und Elemente hinzufügen/wegnehmen und Speicherverwaltung nicht alle zu Fuß programmieren müsste (also wenn es für soetwas Klassen/Klassenfunktionen gäbe). Zur Not mache ich das eben auf die harte Tour 😉



  • Okay, aber jetzt mal ganz doof gefragt: "Normales" C++ lässt sich ja auch innerhalb C++/CLI programmieren, hab ich jetzt auch schon so gemacht. Dann ist doch der einzige CLI-Berührungspunkt eben das GUI, wenn man von den .NET-Klassen die Finger lässt.

    Es mischt sich automatisch, wenns mit /clr Kompiliert wird. Es werden für Funktionen zwei Einsprungspunkte erzeugt (einen managed / einen native), etc.

    Simon



  • Hallo maugli,

    für reines C++ gibt es die STL (Standard Template Library) und dessen Container-Klassen: std::vector<>, std::list<>, std::map<> etc. Dort kannst du dann auch Werte dynamisch hinzufügen, löschen und die ganze Liste sortieren lassen.

    Du solltest dich also wirklich entscheiden, ob du natives C++ willst oder aber generell das .NET-Framework benutzen willst. Und für letzteres ist C# bzw. VB.NET die passende Sprache (da du ja von BASIC kommst, wäre also der Umstieg auf VB.NET vllt. das Richtige).



  • Th69 schrieb:

    Hallo maugli,

    für reines C++ gibt es die STL (Standard Template Library) und dessen Container-Klassen: std::vector<>, std::list<>, std::map<> etc. Dort kannst du dann auch Werte dynamisch hinzufügen, löschen und die ganze Liste sortieren lassen.

    Du solltest dich also wirklich entscheiden, ob du natives C++ willst oder aber generell das .NET-Framework benutzen willst. Und für letzteres ist C# bzw. VB.NET die passende Sprache (da du ja von BASIC kommst, wäre also der Umstieg auf VB.NET vllt. das Richtige).

    Okay, und jetzt die meinerseits entscheidende Frage:

    Spricht denn irgendetwas dagegen, in Microsofts Visual Studio (C++) eben natives C++ mithilfe der STL-KLassen zu programmieren, und .NET eben nur für die Nutzerinteraktion zu verwenden?



  • maugli schrieb:

    Okay, und jetzt die meinerseits entscheidende Frage:

    Spricht denn irgendetwas dagegen, in Microsofts Visual Studio (C++) eben natives C++ mithilfe der STL-KLassen zu programmieren, und .NET eben nur für die Nutzerinteraktion zu verwenden?

    Und hier die entscheidende Antwort:
    http://www.c-plusplus.net/forum/263084



  • theta schrieb:

    Und hier die entscheidende Antwort:
    http://www.c-plusplus.net/forum/263084

    Ich lese die Antwort auf meine Frage aus den dort aufgeführten Argumenten aber nicht unbedingt heraus. z.B. müsste es doch möglich sein, Funktionen und Klassen ausserhalb der form.h zu definieren, und dann kann man von mehreren Form-Elementen darauf zugreifen, ohne sich mit CLI auseinanderzusetzen oder "Code zu mischen", also ohne z.B., wie im zitierten Artikel, ohne "einen STL-Vector in ein CLR Objekt reinzustopfen". Man braucht die CLR-Objekte doch nicht unbedingt, wenn man mit STLs arbeitet. Oder mache ich da einen Denkfehler?



  • Du kannst alles machen. Dazu musst Du aber zuerst C++ verstanden haben.

    Es ist leider eine Untugend, dass die Methoden in der Form*.h Datei implementiert sind... die müssen in der cpp-Datei implementiert werden, dann wird vieles einfacher.



  • Von C++ hab ich schon ein bischen was verstanden. Nur die Organisation des Codes in den verschiedenen Dateien ist mir noch ein bischen schleierhaft.

    Was genau meinst Du mit Methoden? Die .Net-Klassenfunktionen?



  • Ja. Bitte verschiebe die *Implementierung* der Methoden (zu Member-Funktion sagt man Methoden), in die CPP-Datei (die Du auch noch zuerst anlegen musst).

    Damit umgehst Du viele Probleme...



  • Du weisst nichts über die Trennung von Header und Source Files und hast die Absicht native C++ und managed C++ zu mischen.. ist so wie wenn Du ohne Airbag und Gurte mit 180km/h gegen auf eine Wand zufährst.



  • Vielleicht kann mir jemand über die Zusammenhänge ein bischen auf die Sprünge helfen.

    Für euch ist das wahrscheinlich ein Klacks, also ich hoffe auf ein, zwei Sätzchen, die etwas Licht ins Dunkel bringen...

    Ich habe zum Test eine einfache Klasse in einer eigenen .h-Datei deklariert, und eine zugehörige Klassenfunktion in eine cpp gepackt.
    Diese .h-Datei habe ich in die Projekt.cpp inkludiert, in der die main-Funktion steht.

    1. Frage: Um beide Elemente (Deklaration in der h und Funktionsdefinition in der cpp) habe ich eine Namespace-Klammer mit gleichem Bezeichner gesetzt. Diesen nutze ich auch zum Aufruf. Es funktioniert, aber ist das richtig/okay/üblich so?

    Ich habe nun ein Objekt dieser Klasse vor dem Aufruf des Formulars innerhalb der Hauptprojektdatei "Projekt.cpp", genauer, innerhalb der main() Funktion und vor dem Aufruf des "Form"-Objektes erzeugt, und konnte die von mir definierte Klassenfunktion auch erfolgreich ausführen. (getestet hab ich das mittels einer globalen Variablen, die ich innerhalb meines Formulars zur Überprüfung ausgeben ließ)

    Nach der Erzeugung des Objektes wurde ja "form1" erzeugt:

    Application::Run(gcnew Form1())

    2. Frage: Vom Eventhandler in Form1.h aus gesehen ist mein Objekt, welches ich in der *.cpp erzeugt habe, unsichtbar. Wieso? Lässt sich ein Objekt auch so erzeugen, daß es global sichtbar ist?

    3. Frage: Um innerhalb von form1.h ein Objekt erzeugen zu können, musste ich erneut die eigene Klassen-Deklaration .h einbinden, die auch schon in die projekt.cpp eingebunden hatte. Es funktioniert zwar - aber ist das richtig/okay/üblich so?

    Ich weiß, ist alles sehr newbiemässig... Ich danke für Antworten!


Anmelden zum Antworten