Frage zu strtok() - Threadsicher?
-
Also bei mir (Visual Studio 2010) kompiliert das sowohl als C++ als auch als reines C ohne Probleme...
-
strtok_s gehört nicht zum C Standard, es ist eine Erweiterung von neueren MS-VC.
Du verwendest eine Entwicklungsumgebung, die diese Funktion nicht unter diesem Namen anbietet, der Linker kann also den passenden Code nicht finden und genau das sagt er dir.
-
Der Fehlermeldung nach verwendet er eindeutig Visual C++. Es kann sich also eigentlich nur um eine uralte Version oder um ein Konfigurationsproblem handeln...
-
Ok war doch wohl eine etwas ältere Version von Visual C++ daran hats gelegen.
Lade mir gerade jetzt gerade das Visual Studio C++ 2010 Pro. herunter.
Muss irgendwas groß am Code geändert werden wenn ich von der alten Version auf die neuste Umsteige?
-
nein
-
Doch.
Neuere VC haben standardmäßig Unicode eingeschaltet, ebenso das nichtstatische Linken. Mehr dazu gibt es beim MFC Forum.
Außerdem ist die "frei" runterladbare Pro Version zeitlich in ihrer Verwendung begrenzt, ich glaube 90 Tage.
-
Wutz schrieb:
Neuere VC haben standardmäßig Unicode eingeschaltet.
Also bei einem neuen leeren Projekt ist bei mir kein Unicode eingeschaltet..
-
Doch.
Sobald du in dein leeres Projekt eine .c Datei einfügst, steht unter Konfigurationseigenschaften/Allgemein/Zeichensatz "Unicode-Zeichensatz verwenden".
Glaub mir, diese "Portierungseigenart" zw. älteren und neueren VC gehört zu den Tops.
-
Deswegen muss aber doch nichts
0x02 schrieb:
groß am Code geändert werden
-
Ach nein?
Und Stringliterale? Ich habe mal gehört, dass diese in C Programmen häufiger vorkommen sollen.
-
Und? Wo ist das Problem, das Projekt mit einem Häkchen auf Multibyte umzukonfigurieren? Es war ja offensichtlich bis zu diesem Zeitpunkt auch kein Unicode-Projekt ...
-
Abgesehen davon wird, wenn er das Projekt konvertiert, dieses Häkchen richtig übernommen werden
-
Ferner erwartet strtok_s keinen LPTSTR oder sonstige auf TCHAR aufbauende Typen und ist von der ganzen Problematik nicht betroffen.
-
Naja, das Projekt wird vielleicht aus mehr als strtok_s bestehen ...
-
Der vom Threadersteller gepostete Code enthielt nichts, was in diesem Zusammenhang kritisch wäre.
Wenn es darum geht, ob es möglich ist, Code zu schreiben, der abhängig von bestimmten Projekteinstellungen kompilieren oder nicht kompilieren kann: Das ist der Fall. Ich halte das allerdings für keine sonderlich profunde Erkenntnis.
-
Es soll Windowsprogramme geben, die Windows-API Funktionen verwenden, und ein simples
CopyFile("bla","fasel",0)wird unterschiedlich ablaufen, je nachdem, ob Unicode oder nicht.
Deshalb ist die L/_TEXT/_T/wasweissich Anpassung für so verwendete Literale unumgänglich.
Und da die meisten Quelltextautoren von der Auswertung von Rückgabewerten oder gar einer Fehlerbehandlung nicht viel halten und andere Quelltextautoren widerum vom Lesen von Compilerwarnungen ebensowenig, ist Nacharbeit und Anpassung im größeren Umfang nötig.
-
Und was hat das jetzt mit strtok_s() zu tun!?
-
Wutz schrieb:
Es soll Windowsprogramme geben, die Windows-API Funktionen verwenden, und ein simples
CopyFile("bla","fasel",0)wird unterschiedlich ablaufen, je nachdem, ob Unicode oder nicht.
Ja, und deshalb sollte man eine nicht generisch, sondern als reines MultiByte - Projekt entwickelte Anwendung auch nach Wechsel der Entwicklungsumgebung weiterhin als MultiByte - Anwendung kompilieren.
Ich meine, Ausgangspunkt dieser Diskussion war doch die Frage, ob man was am Code ändern müsse, wenn man auf eine jüngere Visual Studio - Version als IDE umsteigt. Die Tatsache, dass neu angelegte Projekte in diesen Versionen zunächst mal als Unicode - Projekte erstellt werden, ist da kein Argument für, weil diese Einstellung im Handumdrehen geändert werden kann, so daß auch weiterhin die entsprechenden Versionen der WinApi - Funktionen übersetzt werden.
Es gibt doch nur drei plausible Möglichkeiten:
Der alte Code ist entweder nur MB-tauglich, möglicherweise ist er auch nur Unicode-tauglich, oder er ist, was den Zeichensatz angeht, generisch.In allen drei Fällen kann die IDE so eingestellt werden, dass der Code übersetzt werden kann, ohne am Code ändern zu müssen.
-
Abgesehen davon betrifft das alles strtok_s() in keiner Weise...
-
Wer lesen kann ist klar im Vorteil.
