将需要默认字符无符号的代码移植到没有此要求的代码库
我已经解决了有关签名/未签名字符的许多问题。我知道 C++ 中有三种不同的 char 类型。目前我有一个使用 Visual Studio 编译的大型代码库 - “默认字符无符号”设置设置为“否”。现在我应该将一个特定的项目添加到我们的代码库中(将其集成为我们当前工具集的一部分)。这个项目附带了一个文档,其中强烈强调它需要默认的字符是无符号的。
现在我开始想:如果作者需要 char 是无符号的,为什么他使用“char”而不是“unsigned char”?如果我更改代码库以将“默认无符号字符”设置设置为“是”,会出现什么问题?如果我将整个项目中的所有“char”更改为无符号字符,我应该添加到我们的代码库中,会出现什么问题?
实际上我应该问的是“我应该如何在不破坏任何内容的情况下将这个项目添加到我们的代码库中”,但这会要求一个解决方案,而我不会学到任何东西;)
i have gone through the numerous questions regarding signed/unsigned char. I understand there are three distinct char types in C++. Currently i have a large code-base which is compiled with Visual Studio - the "default char unsigned" setting is set to "No". Now i'm supposed to add a particular project to our code-base (integrate it to be a part of our current tool-set). This project comes with a documentation where it is strongly emphasized that it needs default char to be unsigned.
Now i began to wonder: why did the author use "char" and not "unsigned char" if he needs char to be unsigned? What could go wrong if i change our code-base to have the "default unsigned char" settings set to "Yes"? And what could go wrong if i change all "char" to unsigned char in the whole project i'm supposed to add to our code-base?
Actually what i should probably ask was "How am I supposed to add this project to our code-base without breaking anything" but that would be asking for a solution and i would not learn anything ;)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
嗯,天哪。您能告诉我们这段代码来自哪里,以便我们避免它吗? :)
我的第一直觉是将代码构建为现有项目链接到的单独库,并且在与它交互时要小心。由于不知道相关代码的确切性质,我不知道这是否可行。
如果您引入的代码确实假设
char
是无符号的,那么您应该只需将其更改为显式unsigned char
,但这提出了一个问题:以后是否必须合并新版本的代码,所以我仍然更喜欢库解决方案。Um, holy crap. Can you tell us where this code came from so we can avoid it? :)
My first instinct would be to build the code as a separate library that your existing project links to, and be careful when you interface with it. Not knowing the exact nature of the code in question, I don't know if that's feasible.
If the code you're bringing in really assumes
char
is unsigned, you should be OK simply changing it to make it an explicitunsigned char
, but that raises the question of whether you're going to have to merge in new versions of the code later, so I'd still prefer the library solution.