You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is based off of :cpp:class:`ztd::text::any_encoding_with`; the only thing special about it is the constructor logic on top of :cpp:class:`ztd::text::any_encoding_with`.
This is the lowest level base template, ``any_encoding_with``, that sits beneath :doc:`any_encoding and any_byte_encoding </api/encodings/any_encoding>`. It is recommended for power users with specific goals for the input and output types of the encode and decode operations, where normal buffer-based I/O is unsuitable. In general, you should be relying on :doc:`any_encoding and any_byte_encoding </api/encodings/any_encoding>`.
``WideCharToMultiByte`` and ``MultiByteToWideChar`` on Windows platforms has a multitude of encodings with a particular set of quirks. Therefore, on Windows platforms, it may be advantageous to use this over the regular :cpp:class:`execution_encoding_t` type or :cpp:var:`execution_encoding` object. The constructor takes a raw ``int32_t`` whose sole purpose is to be one of the known `Code Page Identifiers`_ that Microsoft supplies on its platforms.
35
+
36
+
.. warning::
37
+
38
+
This type is inefficient due to the poor design of the ``WideCharToMultiByte``/``MultiByteToWideChar`` functions. While this will allow users to achieve parity, if the user knows their encoding ahead of time and can provide either their own encoding object or :doc:`/api//encodings <one of the encoding types provided by this library>`, it is highly preferred over this methodology.
39
+
40
+
.. warning::
41
+
42
+
For certain distributions, specific language packs may need to be installed in order to use certain conversions tied to specific `Code Page Identifiers`_.
0 commit comments