一、
1, GCC 4.4.5 默认的 C++ 方言不是 C++11。
2,
源码里 64 位类型定义是老式 typedef:
-ordinary.hpp:42:typedefunsignedlonglonguint64;-ordinary.hpp:43:typedeflonglongint64;-std_tp.h:21:typedeflonglongint8;没有使用 C++11 的 <cstdint>、std::int64_t 等写法。3, 不能因为在.h文件就判断是c语言而不是c++
typedeflonglongint8;这是一个类型定义声明,不是“语句”。它本身既可以被 C 编译器解析,也可以被 C++ 编译器解析;关键看哪个源文件 #include 了它。
在当前项目里,std_tp.h:21 虽然后缀是 .h,但主要被 C++ 代码路径使用,例如 当前 模块的源文件都是 .cpp,Makefile 用的是 g++ 编译:
.cpp.o:; $(CXX) -c $(CFLAGS) $< -o $@
所以这行在当前项目构建中应理解为:被 g++ 按 C++ 方言编译,历史意图大概率是 gnu++98 下的 GNU C++ 扩展。
如果它被 .c 文件包含,并用 GCC 的 gnu89 模式编译,那么它也能成立,但那时才叫 GNU C 扩展。
总结:
typedef long long mint8;
在当前项目里:主要是 GNU++98/C++ 侧用法。
不是因为它在 .h 文件里,就自动属于 GNU C。
二、
CFLAGS中没有-std=选项。这意味着编译器使用其默认标准:
- C++ 文件(
.cpp/.cxx)用g++编译,默认为 GNU C++98(即-std=gnu++98)——这是 GCC 4.x 系列的默认值,等价于 C++98 + GNU 扩展。 - C 文件(
.c)用gcc编译,默认为 GNU C89(即-std=gnu89)。
long long的使用依据是GNU 扩展(gnu89/gnu++98),而非 C++11 标准。
具体来说:
long long在 C99 / C++11 才被正式纳入标准。- 但 GCC 作为扩展,在
gnu89和gnu++98模式下也支持long long,只是在严格标准模式(-std=c89/-std=c++98,无gnu前缀)下会报警告。 - 项目用的
g++ -m64(无-std=),默认就是gnu++98,所以long long能编译通过,是靠 GNU 扩展,而不是 C++11。
验证点:makefile里有-D__GCC_4_4_5__宏,说明本项目明确针对 GCC 4.4.5,该版本默认标准正是gnu++98,早于 C++11(2011 年发布)。
❯long long是 C 语言的 还是 C++ 的语句吗?
只有 3 处,全部是typedef类型别名定义,这是 C 和 C++ 共用的语法,两者都支持。
具体看:
| 文件 | 语句 | 所在文件类型 |
|---|---|---|
| std_tp.h` | typedef long long int8; | .h头文件,C 风格 |
| ordinary.hpp` | typedef unsigned long long uint64; | .hpp头文件,C++ |
ordinary.hpp | typedef long long int64; | .hpp头文件,C++ |
结论:typedef long long是纯 C 风格写法,C 和 C++ 都完全相同,看不出 C++ 特有语法。项目里没有用 C++11 的int64_t(来自<cstdint>)或std::int64_t,而是手动typedef了自己的别名(mint8/my_int64_t),这是典型的老式 C/C++ 跨平台移植写法,与 GNU C89 扩展的风格一致。