Klotzkopp

Extern als Klassenmember ergibt keinen Sinn. Ein nichtstatischer Member ist niemals global, sondern immer an die Existenz einer Instanz der Klasse gebunden.

Soweit ich weiß, braucht man das nur, wenn man innerhalb eines extern "C"-Blocks eine Funktion dann doch wieder mit C++-Linkerkonventionen haben will.

In einer bestimmten Programmiersprache, oder als Pseudocode? Im ersteren Fall wärst du hier im falschen Forum.

Header: extern std::vector<std::string> xyz; Source (irgendeine, egal welche, aber nur eine): std::vector<std::string> xyz;

Ich nehme einfach mal an, dass du dich auf das gets-Problem beziehst. Da hier ja offensichtlich C++ zum Einsatz kommt, würde ich die Streamklassen und std::getline benutzen. In C++ muss man eher selten mit rohem Speicher hantieren.

Keine Ahnung, ich habe nicht jedes Buch gelesen. Ehrlich gesagt, erinnere ich mich an keines, in dem dazu geraten wurde, unbedingt Konstruktoren zu erstellen. Kannst du ein Beispiel bringen? Das ist Ansichtssache, und hängt vermutlich eher davon ab, was man gewöhnt ist. Wenn man von C kommt, wo es (zumindest nach dem Standard von 1989) gar nicht anders geht, kommt einem das Deklarieren von Variablen mitten im Code sicher unübersichtlich vor. Zudem ist es effizienter, Variablen erst dort anzulegen, wo sie gebraucht werden. Im Gegensatz zu C können einfache Variablendeklarationen eine Menge Code erzeugen (Konstruktoren). Wenn man das so spät wie möglich macht (z.B. erst nachdem Prüfungen der Vorbedingungen abgeschlossen sind), kann man viel Zeit sparen.

Einfache Antwort: Nein. C++ ist statisch typisiert. Man kann so etwas natürlich nachbilden. Du könntest dir beispielsweise mal boost::any ansehen. Ich weiß allerdings nicht, ob man boost auf deiner Plattform ans Laufen bringen kann. Außerdem vermute ich, dass das deinem Ziel der Minimierung des Speicherverbrauchs eher entgegenläuft. Solche "Komfort"-Features muss man sich immer durch Performance erkaufen, sei es durch Laufzeit- oder durch Speicheroverhead.

Die Schleife geht vermutlich noch weiter, diese beiden Zeilen allein ergeben keinen sinnvollen Schleifenrumpf, weil sich der Wahrheitswert der Abbruchbedingung möglicherweise niemals ändert. Zum Inhalt: Es wird ein istringstream-Objekt namens converter erstellt. istringstream ist eine Klasse, mit deren Hilfe man Strings in andere Typen konvertieren kann. Man "füttert" den istringstream mit einem String, und kann dann daraus, wie aus cin oder einem ifstream, mit dem operator>> auslesen. Hier wird converter mit dem String zeichnungsnummern_xar[2].substr(11,2) initialisiert. zeichnungsnummern_xar ist vermutlich ein Array oder Vector von Strings. Danach wird aus dem Stream die int-Variable hoechstes_blatt befüllt. Wenn also im Stream beispielsweise der String "42" steht, steht hinterher in der int-Variablen der Wert 42. Das Ganze hätte man auch mit sscanf oder atoi machen können, allerdings ist der Funktionsumfang dieser Funktionen von vornherein beschränkt. Zudem kann sscanf keine Typprüfung bieten. Stringstreams sind flexibler. Man kann aus ihnen (wie aus jedem anderen istream) jeden Typ herauslesen, der einen operator>> anbietet, und die kann man für eigene Typen selbst schreiben. Stringstreams bieten sich also insbesondere für die generische Programmierung (also Templates) an.

Naja, einen nach dem anderen. Vermutlich soll das auf eine verschachtelte Schleife hinauslaufen. Weißt du, was ein Algorithmus ist?

Das ist eine 5x5-Matrix. Und ein Algorithmus ist es nicht.

Dann sag doch mal, was du meinst. Der Standard kennt keinen Begriff "Vererbungsart". Die Beziehung einer Klasse zu ihrer Basisklasse in C++ kann virtuell sein oder nicht, und hat einen Access Specifier (public, protected, private). Das ergibt 6 mögliche Kombinationen. Ob das allerdings das ist, was du mit "Vererbungsart" meinst, weiß ich nicht.

Der Rumpf einer while-Schleife umfasst nur die nächste Anweisung. Da du keine geschweiften Klammern gesetzt hast, ist es also nur die Deklaration von converter. Die nächste Zeile converter >> hoechstes_blatt; gehört nicht mehr zur Schleife. Der Stringstream wird im Schleifenrumpf deklariert, ist also danach nicht mehr gültig. Wenn man seinen Code konsequent richtig einrückt, findet man solche Fehler sehr viel schneller.

Das lässt sich aus diesem winzigen Codefragment nicht ablesen. Der Compiler ist aber anderer Meinung, und meistens hat er Recht. Ist das die erste Fehlermeldung? Hast du <sstream> eingebunden?

Nein, da der Compiler zuerst im Namensraum std sucht, und dort natürlich jede Menge operator<< findet, werden andere Namensräume gar nicht durchsucht. Dann beginnt die Suche nach einer passenden Überladung, und da es in std keinen Operator für std::pair in irgendeiner Form gibt, schlägt das fehl. Andere Namensräume werden aber trotzdem nicht durchsucht. Praktisch könntest du deinen Operator in den Namensraum std stecken. Das wird häufig benutzt, um std::swap für eigene Typen zu überladen. Theoretisch gesehen erzeugt das allerdings undefiniertes Verhalten. Ich glaube aber, dass das nur daher rührt, dass es dann zu unerwarteten Namenskonflikten kommen, nicht dass das irgendein Problem für den Compiler darstellt.

An dieser Stelle hättest du dich mal fragen können, warum du keine Antwort bekommst. Du zeigst den Code aus zwei Dateien, so dass man nicht mehr erkennen kann, was woher kommt. Die Includedirektive hast du anscheinend entfernt. Du hast sämtliche Kommentare im Code kaputtgemacht, so dass man das erst aufwändig reparieren muss, wenn man das im Compiler nachprüfen will. Du benutzt C++/CLI, nicht C++, deshalb ist das hier das falsche Forum. So wie ich das erkennen kann, fehlt in Form1.h schlicht und einfach das abschließende Semikolon bei der Klassendefinition und die schließende Klammer für den Namespace. Außerdem hast du noch ein Mehrdeutigkeitproblem mit DialogResult. Es gibt sowohl ein Property von Form mit diesem Namen, als auch den Enum im namespace Forms. Schreib's einfach aus.

Du drehst den String mitsamt der Terminierung um. Damit steht die Terminierung in test2 ganz vorn. Und damit hört der String dort auf. Ganz nebenbei, gets ist "böse", weil du keine Möglichkeit hast, zu verhindern, dass jemand mehr eingibt als in deinen Puffer passt. Ein klassisches Szenario für einen Pufferüberlauf.

Da hast du IMHO eine dunkle Ecke von C++ gefunden. Doch. Aber in diesem Fall liegt der Aufruf des Operators im Namensraum std. Darum wird auch dort zuerst nach einem Operator gesucht. In std liegen natürlich jede Menge operator<<, also beschränkt sich die Überladungsauflösung auf den Namensraum std. Dein Operator ist aber im globalen Namensraum, und wird daher nicht gefunden.

isdigit [C++ Reference]

Diese Zeile deklariert einen char-Zeiger namens b, der auf das Literal "hallo" verweist. Nein, du hast kein Array. b ist ein Zeiger. Doch, genau das heißt es Richtig. In diesem Fall zeigt der Zeiger auf die Adresse des Literals. Zeichenkettenliterale sind übrigens die einzigen Literale, deren Adresse man bestimmen kann. Das ist etwas völlig anderes. In diesem Fall wäre b ein Array von 6 char, mit dem Inhalt hallo\0. Der entscheidende Unterschied ist der, dass du den Inhalt hier verändern darfst. Bei einem Zeiger auf ein Literal darfst du das nicht. Das ist einfach ein Array von 2 char-Zeigern. Der erste zeigt auf das Literal "hallo", der zweite auf das Literal "welt". Du hast da char-Zeiger, keine char. Mit int geht das wie gesagt nicht, weil du von int-Literalen keine Adresse ermitteln kannst.

Ein paar Anmerkungen: Die Klasse braucht weder Defaultkonstruktor noch Destruktor. Die automatisch generierten tun das Richtige. In C++ deklariert man die Variablen üblicherweise erst dann, wenn man sie braucht, nicht am Anfang des Blocks. Erhöhe den Iterator besser mit Preincrement. Postincrement ist potentiell langsamer, weil es eine Kopie des Iterators anlegen muss. Überhaupt sollte man sich angewöhnen, immer Preincrement zu benutzen, es sei denn, man braucht den besonderen Effekt von Postincrement. Du brauchst kein Objekt der Klasse für die Ausgabe, das geht auch direkt über den Iterator: cout << index->name <<endl;

Die Suche nach Überladungen geht in C++ nicht über Vererbungsbeziehungen hinweg. Wenn in A eine Methode mit passendem Namen vorhanden ist, werden Basisklassen nicht weiter nach Überladungen durchsucht. Das kannst du durch eine using-Deklaration umgehen: class A : public Interface { using Interface::load; // ...[/code]

Vermutlich ist hier nicht gemeint, das ganz ohne zusätzlichen Speicher zu lösen, sondern mit konstantem Speicherbedarf, und nicht mit linearem, wie ihn Mergesort normalerweise hat. Die C++-Standardbibliothek hat dafür eine Funktion: std::inplace_merge. Da das eine Templatefunktion ist, kann man sich die Implementierung bei jedem Compiler einfach ansehen. Vielleicht findet man da ein paar Anregungen.

In C++ müssen wir uns aber nicht mehr mit void-Zeigern herumschlagen: sort [C++ Reference]

Dafür haben wir einen Thread im Coffeehouse

s_unterordner = s.substr(1,3); Der erste Parameter ist der Anfangsindex, der zweite ist optional und gibt Anzahl der Zeichen an.