如何做便携式64位算术,没有编译器警告 [英] How to do portable 64 bit arithmetic, without compiler warnings

查看:116
本文介绍了如何做便携式64位算术,没有编译器警告的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我偶尔在我的开源C ++库中使用64位算术。我发现 long long 很好地满足了我的目的。甚至一些10岁的solaris框可以编译它。它的工作原理不会在Windows上乱搞#defines。

I occasionally use 64 bit arithmetic in an open source C++ library of mine. I discovered that long long serves my purpose quite nicely. Even some 10 year old solaris box could compile it. And it works without messing around with #defines on Windows too.

现在的问题是我收到来自我的用户的投诉,因为他们编译与GCC的外部设置,GCC坚持发出 long long 不是C ++标准的一部分的警告。这可能是对的,但我对C ++标准本身并不感兴趣,我只是希望我的代码在尽可能多的编译器上工作。

Now the issue is I get complaints from my users because they compile with GCC -pedantic settings, and GCC insists on issuing warnings that long long is not part of the C++ standard. This is probably right, but I am not too interested in the C++ standard per se, I just want my code to work on as many compilers as reasonably possible.

所以我的问题是双重的:

So my question is twofold:


  • 任何人都可以命名实际的C ++编译器不支持64位长整数?

  • 是否有一种方法使GCC编译64位算术(在32位平台上),而不需要编译器警告? (stdint.h不起作用,因为它也取决于 long long

  • can anyone name actual C++ compilers that don't support 64 bit long long's?
  • is there a way to make GCC compile 64 bit arithmetic (on 32 bit platform) without compiler warnings? (stdint.h does not help, as it also depends on long long)

PS

如果有平台,长longs变成128位或更大,这很有趣,但对我来说不是一个问题。

If there are platforms where long longs become 128 bit or bigger, that is interesting, but not a problem for me.

推荐答案

当您的库作为源提供时,一个选项是提供移植标头, '负责提供一个64位的类型(你可以指定名字)。它们自然也有责任处理任何编译器警告,他们选择的类型引发,避免它们,抑制它们或忽略它们。

When your library is provided as source, one option is to provide a "porting" header, in which it is your users' responsibility to provide a 64 bit type (you'd specify the name). It's then also naturally their responsibility to deal with any compiler warnings that their choice of type provokes, either avoid them, suppress them, or ignore them.

我想这是什么你叫用#defines搞定,但我不认为有太多错误。您可以提供一个直接使用 long long 的默认版本,并且可以在您的10年的Solaris软件包和Windows上使用,因此大多数用户永远不需要去

I guess this is what you call "messing around with #defines", but I don't think there's too much wrong with it. You can provide a default version which just uses long long directly and will work on your 10-year-old Solaris box and also on Windows, so most users would never need to go near the user-configurable part of your library.

然后对于用户来说,您可以为GCC提供一个版本,其中包含< sys / types.h> 并使用 int64_t 而不是 long long 。这不会给我带来 g ++ -pedantic 的任何警告。你甚至可以通过识别GCC,在默认版本中这样做,这当然是搞乱#defines,但是再也不是一个多平台产品不寻常的方式。

Then for the pedantic users, you can provide a version for GCC which includes <sys/types.h> and uses int64_t instead of long long. This doesn't provoke any warning for me with g++ -pedantic. You could even do this in the default version by recognising GCC, which certainly is messing around with #defines, but again not in a way that's at all unusual for a multi-platform product.

如果你的库也是作为某些平台的二进制文件提供的,那么你必须决定64位的类型。如果它也出现在库接口(因此头文件),那么你只需要选择一个不会引发任何警告与合理的编译器选项。我认为 -pedantic 是一个合理的编译器选项,显然你的用户,所以再次是 int64_t 在GCC。

If your library is also provided as binaries for certain platforms, then of course you have to decide what the 64 bit type is going to be. If it also appears in the library interface (and hence the header file), then you'll just have to choose one which will not provoke any warnings with reasonable compiler options. I think -pedantic is a reasonable compiler option, and apparently so do your users, so again that's int64_t on GCC.

这篇关于如何做便携式64位算术,没有编译器警告的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆