Veraltet-header <codecvt> Ersatz

Etwas Vordergrund: meine Aufgabe erforderlich, die Umwandlung von UTF-8-XML-Datei in UTF-16 (mit richtigen header natürlich). Und so suchte ich über die üblichen Wege der Umwandlung von UTF-8, UTF-16, und fand heraus, dass man Vorlagen verwenden, aus <codecvt>.

Aber jetzt, wenn es veraltet, ich Frage mich, was ist das neue, gemeinsame Art und Weise zu tun, die gleiche Aufgabe?

(Egal mit Boost auf alle, aber andere, als dass ich es vorziehen zu bleiben, wie nah an der standard-Bibliothek wie möglich.)

InformationsquelleAutor login_not_failed | 2017-03-22

  1. 16

    std::codecvt Vorlage von <locale> selbst ist nicht veraltet. Für UTF-8, UTF-16, es ist noch std::codecvt<char16_t, char, std::mbstate_t> Spezialisierung.

    Jedoch, da std::wstring_convert und std::wbuffer_convert sind veraltet zusammen mit der standard-Konvertierung Facetten, es gibt keine einfache Möglichkeit zur Konvertierung von Zeichenfolgen mithilfe von Facetten.

    So, als Bolas bereits beantwortet: Sie selbst einzubauen (oder Sie können eine Drittanbieter-Bibliothek, wie immer) oder halten mit der deprecated API.

    Aber laut P0618, alle der <codecvt> header ist veraltet. Nicht nur die typedefs; std::codecvt ist veraltet in seiner Gesamtheit.
    Der Vorschlag erscheint nicht, änderungen vorzuschlagen, um [locale.codecvt] wo codecvt_base und codecvt der <locale> header definiert sind. Jedoch, das Dokument liest, kann ich sehen, dass w{string buffer}_convert veraltet sind, als auch, was, soweit ich weiß, sind das nur standard-Funktion, die tatsächlich verwendet die codecvt-Facette. Also, auch wenn codecvt ist nicht veraltet, es gibt nicht wirklich eine einfache Möglichkeit, Sie zu benutzen. Glauben Sie, dass die Unterlassung der std::codecvt form das Dokument ist ein Zufall?
    verwendet es.
    P0618 ist nur ein Vorschlag von einem Mitglied der standardkommission, wenn auch einflussreicher. Es sagt nichts darüber aus, ob der Vorschlag akzeptiert wurde; wenn es wurde, es wird nicht veraltet sein, bis der nächste standard (wahrscheinlich in der Mitte der 2020er-Jahren) und wird wahrscheinlich nicht entfernt werden, bis etwa 2030. Ich kann mir vorstellen Compiler wird weiterhin unterstützt es eine Weile.
    nach P0636R0, P0618R0 wurde für C++17, was bedeutet, dass die Abschreibungen sind in der Tat da, die standard-revision.

    InformationsquelleAutor eerorika

  2. 22

    Keine sorgen machen.

    Laut die gleichen Informationen Quelle:

    diese Bibliothek-Komponente sollte sich in Anhang D, Seite an Seite ,
    , bis ein geeigneter Ersatz ist standardisiert.

    So, können Sie immer noch verwenden, bis eine neue standardisierte, sichere version ist fertig.

    Das war leider Wunschdenken. Die Missbilligung angewendet wurde, auf C++ - 17. Die Empfehlung offensichtlich: "Benutzer sollten verwenden Sie dedizierte text-processing-Bibliotheken statt." Visual Studio 2017 wird die Frage deprecation-Warnungen, wenn verwendet.

    InformationsquelleAutor xmllmx

  3. 4

    Der neue Weg ist... du schreibst es selbst. Oder einfach nur verlassen sich auf veraltete Funktionen. Hoffentlich, die Normen-Ausschuss nicht wirklich entfernen codecvt, bis es einen funktionierenden Ersatz.

    Aber zur Zeit, gibt es nicht.

    Es ist das problem: ich brauche die meisten portablen Weg, dies zu tun. Natürlich gibt es immer Dinge wie Intensivstation, iconv und diverse andere libs, aber es war ein ziemlich straight-forward Weg vor, die mit drei Zeilen code, und jetzt ist es ein reines Chaos.
    nicht "war", es immer noch ist, da es nicht entfernt werden (und nicht gelöscht, für eine Weile)

    InformationsquelleAutor Nicol Bolas

Schreibe einen Kommentar