-
Notifications
You must be signed in to change notification settings - Fork 201
C STL
Mikhail Yakshin edited this page Sep 4, 2016
·
4 revisions
Mapping KS types to C++ is pretty straight-forward:
type |
C++ type |
---|---|
no type | std::string |
u1 |
uint8_t |
u2 |
uint16_t |
u4 |
uint32_t |
u8 |
uint64_t |
s1 |
int8_t |
s2 |
int16_t |
s4 |
int32_t |
s8 |
int64_t |
str , strz
|
std::string |
Note that both byte arrays and strings are mapped to std::string
— that's because when we store byte array, we need something that would be able to both hold the byte buffer and store it's length (or at least able to derive it).
There's no universal agreement on dealing with encodings in C++, so KS allows you to choose one of the few popular approaches. You can choose how to deal with string encoding using a compile-time define.
- Ignore encodings at all. In this mode, all string parsing operations just ignore any encoding specifications and pass raw bytes as a string to application. Note that in some cases it might break some .ksy files that actually depend on string being properly decoded / converted.
- Convert all incoming byte streams into strings in a single, one-size-fits-all encoding (for example, UTF8, as suggested by UTF8 Everywhere Manifesto). By default, the Since there's no universal way to do it, KS would use one of platform-dependent ways (which can be also enforced by specifying specific defines):
- Use POSIX
iconv
library — usually preinstalled (or included in libc) on all POSIX systems, can be linked as external library on most other systems (i.e. Windows) - Use Windows API functions MultiByteToWideChar and WideCharToMultiByte — obviously, available only on Windows platform
- Use ICU library
- Use POSIX