Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the problems encountered in C++ cross-platform development?

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly explains "what are the problems encountered in the cross-platform development of C++". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. let's study and learn what are the problems encountered in the cross-platform development of C++.

1. Character coding

In my development environment, clang coding defaults to utf8, VS is GB2312 (code page is 936), and they are all compatible with ASCII.

If only English appears in the code file, both ends can be compiled. If Chinese appears in the code, the file is encoded as utf8, and there is no problem with iOS compilation, VS will have a compilation error error C2001. If the encoding is set to utf16, there will be no problem with VS compilation, and iOS will have a compilation error encoding is not supported. So if the code is in Chinese, you need to change the source file encoding to Unicode (UTF8 with signature)-code page 65001.

See vs compilation error C2001: constants with newline characters cannot be compiled in Chinese

In addition, if it contains Chinese strings, read and use directly, the program is easy to run garbled. Code like this:

Const char* str = "Hello, World"

It is uncontrollable to want to display str text correctly on different platforms. Cross-platform code should not use Chinese, absolutely can not define strings in Chinese to read again, even more stringent can not write comments in Chinese. If you want to display Chinese strings, you should separate them from the program, write them in a utf8-encoded configuration file, and then read them dynamically.

We hit a hole, we originally intended to export a lua Api, automatically generate the corresponding document. There is code like this:

ADD_METHOD_WITH_DOC (Context,nv12ToRGBPass, "shader program for getting color space nv12 to rgb", "3.2"," [Program] (# program) "," program ", 0)

Later found that it was compiled on Windows, but not compiled by iOS. After changing the code, iOS is compiled, but not on Windows. When both ends are compiled, but the code is garbled again. Finally, we have to write them all in English and generate English documents automatically.

2. Int8_t and char

On VS, int8_t is actually the typedef of char, which means that int8_t and char are of the same type. But on iOS, int8_t and char are different types. The following code

Printf ("% d\ n", (int) std::is_same::value)

Output 1 on VS and 0 on iOS. This refreshes my perception that char and int8_t are the same all the time. Because of this difference, I stepped on it again.

To make it easier to write lua exports, we use the LuaCpp library, which contains this code

Typedef LOKI_TYPELIST_15 (bool, char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, float, double,std::string, luaObject, luatable, int64_t) SupportType

Here you define a typelist for Loki that contains types that support automatic conversion. Typelist see Books C++ New ideas for Design.

LuaCpp is basically template code, if the type T belongs to SupportType, you can perform automatic conversion code, otherwise you need handwriting conversion, if there is no handwriting conversion, for this type T, it will collapse directly.

The code here is very old and works well all the time. Until int8_t appears on one of the interfaces, so the VS runs normally and the iOS crashes.

By the same token, int8_t, uint8_t, int16_t, and uint16_t also need to pay attention.

For similar template code, it is best to obediently use the std::is_integral in the standard library. Don't be so smart to write your own typelist.

3. _ _ VA_ARGS__

_ _ VA_ARGS__ can be used for macros with variable parameters. But its behavior is different between VS and clang. Such as the following code

# include # define MY_PRINT (format,...) Printf (format, _ _ VA_ARGS__) int main (int argc, const char* argv []) {MY_PRINT ("Hello, World"); return 0;}

It can be compiled and passed on VS. However, it does fail to compile on clang, and the _ _ VA_ARGS__ of the clang compiler cannot expand 0 variable length parameters. Write as

MY_PRINT ("Hello, World, d", 1)

To unfold correctly. In order to expand 0 parameters, it needs to be written as # _ _ VA_ARGS__, and defined as

# define MY_PRINT (format,...) Printf (format, # # _ VA_ARGS__)

Reference Variadic macros with zero arguments

4. Static variables across dll modules

A project often has multiple dynamic modules. On VS, the dynamic module is a dll file; on iOS, it is framework or dylib. When VS crosses modules, the default symbols are not exported. Clang default symbols are exported.

On VS, when you want to define a class or a function in module A for module B to use, you need to use _ _ declspec (dllexport) and _ _ declspec (dllimport) to indicate. Macros are usually defined, such as.

# if defined (OF_WIN32) | | defined (_ WIN32) | | defined (WIN32) # ifdef MODULE_A_API_LIB# define MODULE_A_API_ _ declspec (dllexport) # else# define MODULE_A_API_ _ declspec (dllimport) # endif#else# define MODULE_A_API#endif

Then the functions or classes that need to be used across modules are written as

Class MODULE_A_API TestClass {}; MODULE_A_API void myfunction (int a, int b)

Usually there is no problem, if you forget to write export, there will be a link error. But when it comes to templates and static variables, this platform difference can be a pit.

Template code is usually written directly in the header file, such as the following code.

/ / myheader.htemplate class TemplateClass {public:static std::string str;}; template std::string TemplateClass::str

In the module, you can use TemplateClass by including the header file myheader.h. If module A uses a statement to set the value of str at this time

TemplateClass::str = "Hello, World"

Module B then reads the value of str.

Std::string str = TemplateClass::str

In VS, both module An and module B use TemplateClass, but because there is no export, they are actually two separate classes, and their static variables are not shared. So module A sets TemplateClass::str, and module B reads the default null value.

In the clang compiler, it is exported by default. So module An and module B see the same TemplateClass, and the static variables are shared. So module A sets TemplateClass::str, and module B reads "Hello, World" after setting.

This kind of Bug is hidden and can be compiled or run normally, but the actual result is wrong. We stepped on a similar pit.

As mentioned earlier, we used the LuaCpp library to export lua. This library is a template library that contains static variables for automatic registration. We have registered a number of lua classes in module A. After that, the class objects registered with the lua virtual machine in module B run normally on iOS, but are abnormal on Windows. Because from the point of view of module B, these classes are not registered at all in LuaCpp's record.

Thank you for your reading. The above is the content of "what are the problems encountered in C++ cross-platform development". After the study of this article, I believe you have a deeper understanding of the problems encountered in C++ cross-platform development. Specific use also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report