Klotzkopp

Wenn du deine Verständnisprobleme etwas konkretisieren könntest, könnte man dir besser helfen. Der Grund, warum eine RTF-Suche nichts mit einer Stringsuche zu tun hat, ist der: Wenn eine RTF-Datei zum Beispiel das Wort "Hundkatzemaus" enthält, aber beispielsweise der "katze"-Teil eine andere Schriftart, -farbe oder -größe hat, wirst du in der Datei diesen Text nicht an einem Stück finden, weil dazwischen die Formatinformationen stehen. Deswegen bringt dir eine Stringsuche nichts. Es gibt aber im .NET-Framework die Klasse RichTextBox, die du hier benutzen kannst. Die Klasse hat sowohl eine LoadFile-Methode als auch eine Find-Methode.

Das hat nichts mit deinem Problem zu tun, weil du keine Strings durchsuchen willst, sondern RTF-Daten. In RTF-Daten sind Formatierungsanweisungen drin, die du beim Suchen natürlich ignorieren musst. Deswegen hat eine RTF-Suche nicht viel mit einer Suche in einem reinen String zu tun.

Daran, dass die Methode Find heißt? Groß-/Kleinschreibung ist relevant.

Gar nicht. Du ermittelst zuerst alle zu durchsuchenden Dateien, und dann durchsuchst du jede gefundene Datei einzeln nach deinem Suchparameter.

Hilfestellung bedeutet, dass du selbst auch einen Teil der Arbeit tust. Davon ist aber bisher nichts zu sehen. Zeig, was du bisher geschrieben hast. Ein Grundgerüst für das Programm wirst du ja haben. Eine Zeichenkette vom Benutzer einzulesen, sollte auch kein Problem sein.

Wenn bei dir gar nichts geht, wenn du nicht irgendwo abschreibst, ist das ziemlich traurig. Du kannst nicht erwarten, dass hier jemand deine Hausaufgaben macht, wenn deine Eigeninitiative gerade mal dazu ausreicht, irgendwelchen Code abzuschreiben.

Ja, das kommt vor, wenn man Code, den man nicht versteht, von irgendwoher kopiert. Das ist übrigens kein C++, was du da abgeschrieben hast. Um das mal abzukürzen: Hast du vor, das Programm selbst zu schreiben?

Ich auch nicht. Effizienter im Vergleich wozu? Darstellen in welcher Form? Im Rahmen welcher Vorlesung passiert das, und was ist da gerade behandelt worden?

Und was möchtest du jetzt von uns? Es ist sicher nicht Sinn dieser Aufgabe, dass du dir im Internet jemanden suchst, der das für dich macht. Wir helfen bei erkennbarer Eigeninitiative gern bei konkreten Problemen, aber wir machen hier nicht deine Arbeit.

Könntest du ein wenig mehr Kontext liefern? Zum Beispiel, was du eigentlich modellieren willst?

Berechnet aus welchen Eingabedaten? Was die Prüfung angeht: International Bank Account Number ? Wikipedia Das heißt, jemand anders soll die Arbeit machen, die eigentlich für dich vorgesehen ist? Wie sieht denn deine Gegenleistung aus?

So lautet die Fehlermeldung des Compilers? Wirklich? Gehst du auch zum Arzt und sagst nur "Mir tut was weh"? Mal im Ernst: Glaubst du, wenn du so wichtige Informationen weglässt, kann man dir besser helfen?

Aber was hast du von dieser Information? Du weißt dann immer noch nicht, ob SSE2 verfügbar ist, außer du hast einen anderen Mechanismus, um das zu erkennen. Aber dann könntest du diesen auch gleich anwenden. Das heißt (beispielsweise), die Software ist für den Win95-Kompatibilitätsmodus von XP geprüft, aber nicht für Windows 95 selbst? Da würde ich doch eher die Versionsnummern relevanter System-DLLs ins Log schreiben. Die Betriebssystem-Version ist eine ziemlich schwammige Größe. Wenn es denn unbedingt sein muss, würde ich so vorgehen, wie es hier vorgeschlagen wurde, also der Reihe nach die Verfügbarkeit von APIs prüfen, die erst in späteren OS-Versionen hinzugekommen sind.

Sag doch mal, wieso. Vielleicht gibt es ja einen anderen Weg, das zu tun, was du mit der genauen Versionsbestimmung erreichen willst.

Es geht übrigens in aller Regel nicht mehr, wenn du virtuelle Methoden aufrufst. Denn die sind üblicherweise über einen vtable-Zeiger implementiert, der an der Instanz hängt, also auch relativ zum Instanzzeiger adressiert wird. Es handelt sich weniger um Sprachinterna als um Implementierungsdetails der Compiler. Du bist hier längst über den Bereich hinaus, der durch die Sprache geregelt wird.

Das Grundkonzept der Sprache ist, dass du für nichts mit Performance bezahlen musst, was du nicht brauchst. Man kann eine Programmiersprache so schreiben, dass bei Zugriffen über Nullzeiger grundsätzlich Laufzeitfehler ausgelöst werden (siehe Java), aber das erfordert eine Prüfung bei jedem einzelnen Zeigerzugriff, das kostet Performance und passt daher nicht ins Sprachkonzept. Wenn du so ein Feature brauchst, kannst du es dir selbst bauen. Wie gesagt, es ist vom Standpunkt des Standards sinnlos, sich darüber Gedanken zu machen, warum sich dieser Code so oder so verhält. Konkret ist es hier so, dass der this-Zeiger des Objekts als versteckter Parameter übergeben wird, und in diesem Fall eben Null ist. Das geht bei den meisten Compilern so lange gut, wie du nicht auf Membervariablen der Klasse zugreifst, denn nur deren Adressen beziehen sich auf diesen Zeiger. Es muss ja nicht gleich boost sein, einfache Smartpointer kann man sich auch selbst stricken. Und std::auto_ptr gibt's auch noch, auch wenn der ein ziemlich eingeschränktes Anwendungsfeld hat. So sehe ich das auch. Ein doppeltes delete ist ein Fehler, den du mit dem Nullsetzen nur vertuschst. Quasi eine Symptombehandlung. Letzteres. Richtig. Aber mal ehrlich, wie oft implementiert man solche Container selbst?

Es ist undefiniertes Verhalten. Du kannst hier schlicht und einfach nicht erwarten, dass etwas bestimmtes passiert. Sich zu fragen, warum Code mit "undefined Behavior" in diesem oder jenem Fall dieses oder jenes Verhalten zeigt, ist sinnlos. Sorg dafür, dass so etwas gar nicht erst passieren kann. Wenn du denn unbedingt mit Zeigern arbeiten musst, dann nimm Smartpointer. Das darfst du mir aber bitte auch mal erklären. Mir fällt dafür nämlich kein vernünftiger Grund ein.

Gut, es ist auf dem Video schlecht zu erkennen, aber ein wenig Grundlagenwissen über die verwendete Programmiersprache und ihre Syntax sollte man dann doch haben. Dann erkennt man, dass hier ein Funktionsaufruf vorliegt. Und den macht man mit (), nicht |). Und was den logischen Fehler angeht, der ist im Screenshot schon drin. Aber diesen Fehler kann man ohne Kenntnis der Programmiersprache nur mit ein wenig Nachdenken erkennen. Das überlasse ich dir, ein wenig mentale Eigenleistung sollte ja drin sein.

Die Übersetzung ist eigentlich ziemlich einfach. Wenn auf statische Methoden zugegriffen wird, musst du den Punkt durch zwei Doppelpunkte ersetzen. Aus double.Parse wird double::Parse. Wenn auf nichtstatische Methoden oder Eigenschaften von CLR-Klassen zugegriffen wird, musst du den Punkt durch einen Pfeil (->) ersetzen. Aus rdbtnplus.Checked wird rdbtnplus->Checked. Der Punkt bei Ergebnis.ToString bleibt. Vorher solltest du aber noch die Fehler in diesem Code beheben. Da sind zwei Syntaxfehler und ein logischer Fehler drin. Eventuell falsch abgeschrieben? Und natürlich musst du entweder die Steuerelemente auf deiner Form genauso nennen wie in dem Code, oder den Code entsprechend ändern.

Das kommt darauf an, wie dein Programmablauf strukturiert ist. Beispiel: Ein Programm liest vom Benutzer eine Liste von Zahlen ein und gibt sie wieder aus. Der Benutzer soll das Einlesen durch Eingabe von -1 beenden können. Die Einleseschleife muss also mindestens einmal durchlaufen werden, um überhaupt erst einmal eine Zahl einzulesen, auch wenn der Benutzer die Eingabe sofort durch -1 beendet. Wenn das Programm hinterher die Zahlen wieder ausgeben soll, soll es natürlich nichts tun, wenn keine Zahlen zum Ausgeben vorhanden sind. Die Eingabeschleife wäre also fußgesteuert, die Ausgabeschleife kopfgesteuert.

"Solange wahr" und "solange bis falsch" ist dasselbe Das ist der entscheidende Unterschied. Im Gegensatz dazu wird die kopfgesteuerte Schleife, wenn die Schleifenbedingung gleich zu Beginn falsch ist, komplett übersprungen.

Du kannst deinen Code zwischen [CODE] und [/CODE] einschließen, dann wird er immerhin in einer Festbreitenschriftart angezeigt und die Einrückung bleibt erhalten. Es gibt dafür auch einen Knopf in der Editor-Symbolleiste, der mit der Raute (#). Mehr kann die Forensoftware zur Zeit nicht, aber es ist besser als nichts.

Ich habe dir in meinem vorigen Beitrag erklärt, wie du alle Probleme dieser Art lösen kannst. Das ist schon wieder dasselbe Problem, das wir schon dreimal behandelt haben. Die Lösung ist immer noch dieselbe. Das Prinzip sollte doch allmählich klar geworden sein. Übrigens: "es geht irgendwie nicht so ganz" ist keine ausreichende Problembeschreibung.

So eine Menge Code abzuladen, ohne die Stellen zu kennzeichnen, an denen der Compiler sich beklagt, ist wenig hilfreich. Hinter dem = ein (problem*) hinzufügen. Zwischen dem return und dem dahinterstehenden Ausdruck ein (problem*) hinzufügen. Gegebenenfalls muss der dahinterstehende Ausdruck geklammert werden. Das Problem ist eigentlich immer dasselbe, und auch dasselbe wie bei deinem vorherigen Thread: In C kann ein void* implizit in jeden anderen Zeigertyp konvertiert werden. Wenn du C-Code als C++ kompilierst, treten Fehler auf, weil das in C++ eben nicht geht. Das kannst du beheben, indem du an diesen Stellen eine explizite Typkonvertierung einbaust. Jedes weitere Problem der Art "void* kann nicht in irgendwas* konvertiert werden" kannst du genauso lösen: An passender Stelle ein (irgendwas*) einfügen.

Das ist so nicht ganz richtig. Der Standard legt nicht genau fest, wann i erhöht wird, nur, dass es vor dem nächsten Sequence Point passiert. Weder ist garantiert, dass beim Ausführen von ++i i schon den neuen Wert hat, noch dass beim Ausführen von i++ i noch den alten Wert hat. Gesichert ist nur der Wert des gesamten Ausdrucks. Der Ausdruck ++i hat als Wert den neuen, bereits erhöhten Wert von i. Der Ausdruck i++ hat den alten Wert. Dieser Unterschied ist also egal, wenn der Wert des Gesamtausdrucks gar nicht verwendet wird, wie es beispielsweise der Fall ist, wenn man so einen Ausdruck als dritten Teil einer for-Schleife benutzt. Die Tatsache, dass nicht genau definiert ist, wann die Erhöhung stattfindet, ist auch der Grund dafür, dass man mit den Inkrementausdrücken so schnell im Bereich des undefinierten Verhaltens landet. Man sollte also tunlichst vermeiden, den Operanden eines Inkrementoperators im selben Ausdruck nochmal zu verwenden. Quizaufgaben der Art wie "Was ergibt ++i + i++" sind witzlos, weil das laut Standard gar nicht definiert ist, da darf jeder Compilerhersteller machen, was er will. http://forum.fachinformatiker.de/c-c/133586-bubble-sort.html#post1189800