Klotzkopp

Das ist Unsinn. Stichwort Zweierkomplement. -61 = 1100 0011 (0xC3) -74 = 1011 0110 (0xB6) Das ergibt den Code 1111 0110 = 0xF6, das ist ein kleines ö.

Das ist keine gültige UTF-8-Sequenz. Selbst wenn man die Bytes vertauscht (dann wäre es gültig), kommt da kein Ö raus. Ö wäre C3 96. Wo liest du diese Daten denn ab?

Ich wollte dich nur darauf aufmerksam machen, dass deine Quicksort-Implementierung (entgegen deiner Beschreibung) nicht Median-of-3 verwendet, um das Pivotelement auszuwählen, sondern einfach das Element in der Mitte des Arrays benutzt. Nicht drumherum. In der Quicksort-Implementierung wird unter bestimmten Bedingungen (Rekursionstiefe, Arraygröße) auf einen anderen Algorithmus umgeschaltet. Statt also sich selbst aufzurufen, ruft die Quicksort-Funktion einen anderen Sortieralgorithmus auf.

Da wäre jetzt eine etwas genauere Problembeschreibung hilfreich. Oder vielleicht eine Frage. Was mir aufgefallen ist: Das ist eine umständliche Schreibweise für iMedian = (iRight + iLeft) / 2;und das ist kein Median, sondern ein einfaches arithmetisches Mittel.

Nein. Grundsätzlich gilt beim Casten, dass man genau wissen muss, was man tut, weil man damit Fehlerprüfungen durch den Compiler abschaltet.

Die Funktion heißt iconv. Ich weiß nicht, wie du darauf kommst, dass iconv nicht von UTF-32 in eine andere Codierung konvertieren kann. Noch weniger verstehe ich allerdings, warum du jetzt wieder von UTF-32 wegwillst. Der ganze bisherige Aufwand hatte doch das Ziel, die Strings in genau diese Codierung zu überführen. Was ist denn das endgültige Ziel dieser Umcodierungsorgie?

Sieht doch gut aus. Nein. Wie willst du denn "ab" von "慢" (Unicode-Zeichen 0x6162) unterscheiden? UTF-32 ist keine Multibyte-Codierung mit "Zusatznullen". Die Tatsache, dass jedes Zeichen durch genau 32 Bits codiert wird, ist eine für die Decodierung wichtige Zusatzinformation. Wenn du die Nullbytes entfernst, kann man nicht mehr rekonstruieren, wo im Datenstrom ein neues Zeichen anfängt. Multibyte-Codierungen benutzen zusätzliche Bits für genau diese Information. Ist es ja auch. Aber so einfach ist es dann doch nicht.

Warum tust du das? fputwc nimmt in Abhängigkeit der aktuellen Locale wieder eine Umcodierung in Multibyte vor. WCHAR ist auch keine Codierung. Aber du kannst Textdateien natürlich in eine Wide-Character-Codierung wie UTF-32 konvertieren.

Den Satz verstehe ich überhaupt nicht. UTF-8 ist keine Wide-Character-Codierung. Wenn du Wide Character hast, hast du nicht UTF-8. Das schließt sich gegenseitig aus. Ich vermute, dass irgendwo in deiner iconvert-Funktion irgendwie Speicher reserviert wird. Den musst du natürlich wieder freigeben.

Das ist ein BOM, das ist da durchaus angebracht. Wenn du es nicht willst, lass es weg. Moment, was ist jetzt dein Ziel? Wide Character oder UTF-8? Beides gleichzeitig ist Quatsch.

Nimm doch einfach nicht "wchar_t", sondern eine vom aktuellen Locale unabhängige Codierung, wie beispielsweise UTF-32.

Deine Konsole kann also auch nicht so einfach Wide-Character-Strings ausgeben. Die Konsole ist damit nicht geeignet für die Erfolgsprüfung. Wie gesagt, wenn ich den von iconv umgewandelten Text in eine Datei schreibe, ist der in Ordnung. Was soll denn hinterher in deinem Programm mit den Wide-Character-Strings passieren? Logisch, du liest in UTF-8 ein und gibst in UTF-8 wieder aus. Na sicher. Dein Quellcodeeditor benutzt mit sehr hoher Wahrscheinlichkeit auch UTF-8. Du kannst dir ja mal sizeof("ä") ausgeben lassen, sollte 3 sein (eine UTF-8-Sequenz aus zwei Bytes und ein Nullterminator).

Funktioniert denn std::wcout << L"abcä"; bei dir? Meine Konsole hat anscheinend Schwierigkeiten mit wcout. Wenn ich die Daten in eine Textdatei schreibe und mir den Hexdump ansehe, ist alles OK, es ist sogar ein BOM drin.

Der Rückgabewert ist size_t. Ich nehme an, du meinst den outbuf-Parameter. Das ist nur ein Puffer, der Typ sagt da nicht viel aus. Du kannst ein wchar_t-Array benutzen und das beim Aufruf auf char* casten.

iconv kann auch direkt in Wide-Character-Unicode konvertieren (UTF-32 bzw. UCS-4)

Warum der Umweg über UTF-8? Warum nicht gleich von iso-8859-1 in Wide Character?

C++ Sets [C++ Reference] Ein set ist ein Container der Standardbibliothek, wie vector. Ein set zeichnet sich dadurch aus, dass eingefügte Elemente automatisch sortiert werden. Dadurch werden Duplikate verhindert, und man kann sehr schnell darin suchen (Stichwort Binäre Suche). // Ein set von ints anlegen set<int> s; // Etwas einfügen s.insert(5) // Etwas suchen if( s.find(6) == s.end() ) { // 6 ist nicht drin }[/code] Das wäre eine Lösungsmöglichkeit.

Und wieder aus demselben Grund. Es reicht nicht, die zu prüfende Zahl mit nur einem einzigen Element des Vectors zu vergleichen. Stell dir vor, du hast eine Liste von Namen, und willst prüfen, ob diese Leute in deiner Stadt wohnen. Wenn du so vorgehen würdest, wie dein Programm, dann würdest du den ersten Namen auf der Liste mit dem ersten (und nur dem ersten) Telefonbucheintrag vergleichen. Und wenn die nicht gleich sind, würdest du daraus schlussfolgern, dass diese Person nicht in deiner Stadt wohnt. Dann vergleichst du den zweiten Namen auf der Liste mit dem zweiten Telefonbucheintrag usw. Ich hoffe, so wird klar, warum das nicht funktionieren kann. Du musst in jedem Schleifendurchlauf j mit jedem Element des Vectors vergleichen. Ein set wäre übrigens hier besser als ein vector. Erstens werden Duplikate ausgeschlossen, und zweitens sind Suchvorgänge effizienter durchführbar.

Der Vergleich i != test1 vergleicht nicht i mit jedem Wert, den test1 irgendwann mal hatte oder haben wird. Er vergleicht den aktuellen Wert von i mit dem aktuellen Wert von test1. Und wenn i 4 ist, ist test1 8. Mit genau diesen Werten findet der Vergleich statt, nicht mit irgendwelchen Werten von früher. Dass test1 irgendwann vorher mal 4 war, ist an dieser Stelle komplett egal.

i und test1 sind aber nie gleichzeitig 4. Bei dem Schleifendurchlauf, bei dem i 4 ist, setzt du test1 auf 8. 4 != 8 ist true. Du hast offenbar eine ganze Menge von Werten, die nicht ausgegeben werden sollen, dafür reicht aber nicht eine einzelne Variable, die diese Werte nacheinander annimmt.

Noch eine Anmerkung: Statt while (tort) { getline(tort, spei); buffer.push_back(spei); }[/code] besser[code]while (getline(tort, spei)) { buffer.push_back(spei); } Der Fehlerstatus des Streams wird erst dann gesetzt, wenn das Auslesen einmal fehlgeschlagen ist. Mit dem oberen Code schreibst du also am Ende einmal Müll in den Puffer. Das Gleiche gilt für die andere Einleseschleife. Und noch etwas: count = count + 1; So etwas erweckt immer den Eindruck eines BASIC-Umsteigers. Schreib besser count += 1; oder gleich ++count;

Es ist keine gute Idee, in einem Vector die Adressen der Elemente eines anderen Vectors zu speichern, wenn letzterer noch befüllt wird. Wenn sich tempOrt nämlich dynamisch vergrößert, holt er neuen Speicher und kopiert seinen kompletten Inhalt in den neuen Speicherbereich um. Die alten Zeiger werden damit ungültig.

Hast du denn mindestens Visual Studio 2008 Professional? Die Express-Edition wird vom WM6-SDK nicht unterstützt.

vector<Person> go; go.push_back(Person( wert, wert, wert ));[/code] So geht's.

Du musst deinen Code in eine Funktion schreiben, nicht einfach mitten in eine Klassendefinition. Woher soll das Programm sonst erkennen, wann das ausgeführt werden soll? Ach ja, und verschoben -> .NET.