C++中泛型使用导致的膨胀问题

简介:

前几天,博主看了一篇文章抨击C++的泛型会导致生成的可执行文件代码臃肿。

博主从事C++软件开发多年,由于之前的开发环境都是资源充足的服务器,不用考虑磁盘空间的问题。最近打算在智能家居主机的嵌入式平台上使用C++进行开发。FLASH存储空间有限,这是必须要考虑的因素,一定要重视。

如下定义两个list,元素类型不同:


list<int> l1;
list<string> l2;

如果是用C语来做应该怎么办?它会对应list<int>写一套代码,再对list<string>写一套。每套都有相同的成员函数,只是变量类型各自不同罢了。

下面是list<int>的C语言实现方式:


//! code-1
struct list_int_item {
    int value;
    struct list_int_item *next;
};
 
struct list_int {
    struct list_int_item *head;
    size_t size;
};
 
void list_int_insert(struct list_int *p, int value);
int  list_int_sort(struct list_int *p);
bool list_int_empty(struct list_int *p);
...


 下面是list<string>的C语言实现方式:

//! code-2
struct list_string_item {
    string value;
    struct list_string_item *next;
};
 
struct list_string {
    struct list_string_item *head;
    size_t size;
};
 
void list_string_insert(struct list_int *p, string value);
int  list_string_sort(struct list_int *p);
bool list_string_empty(struct list_int *p);
...

两者之间就是类型的差别。所以很多时间,在C语言中我们就用宏来替代它的类型,如下:


//! code-3
#define LIST_DECLARE(TYPE) \
    struct list_##TYPE##_item { \
        TYPE## value; \
        struct list_##TYPE##_item *next; \
    }; \
    \
    struct list_##TYPE { \
        struct list_##TYPE##_item *head; \
        size_t size; \
    }; \
    \
    void list_##TYPE##_insert(struct list_##TYPE *p, ##TYPE## value); \
    int  list_##TYPE##_sort(struct list_##TYPE *p); \
    bool list_##TYPE##_empty(struct list_##TYPE *p); \
    ...

然后在头文件中是这样定义list<double>的:


//! code-4
 
LIST_DECLARE(double)

所以,泛型产生冗余代码是无法避免的,至少用C来做这样的泛型也是无法避免的。

既然无法避免的,那就看看怎么尽可能以避免上述的问题。在《Effective C++》中有一章节专门提到:不要在模板中使用不必要的参数。因为每一个不同的参数编译器都会为之生成一套相应的代码。

如果代码中只有一种数据类型,就算用该类型定义了多个变量,编译器是不是只会生成一套相关的代码?(应该是这样的)。

写个例子对比一下:(省略不必要的代码)

test1.cpp,里面只有map<int, string>,但定义了m1, m2, m3。


//! code-5
 
    map<int, string> m1;
    map<int, string> m2;
    map<int, string> m3;
 
    m1.insert(std::make_pair(1, "hello"));
    m2.insert(std::make_pair(1, "hi"));
    m3.insert(std::make_pair(1, "lichunjun"));

test2.cpp,与test1.cpp相比,里面有三个类型:


//! code-6
 
    map<int, string> m1;
    map<int, double> m2;
    map<int, int> m3;
 
    m1.insert(std::make_pair(1, "hello"));
    m2.insert(std::make_pair(1, 1.2));
    m3.insert(std::make_pair(1, 44));

结果,编译出来的可执行文件大小比较:


[hevake_lcj@Hevake tmp]$ ll test1 test2
-rwxrwxr-x. 1 18784 Mar 19 22:01 test1
-rwxrwxr-x. 1 35184 Mar 19 22:03 test2

test2比test1大一倍,原因不用多说。


还有一个问题:指针是不是被认为是一个类型?

上面的list<int>与list<string>不能共用同一套代码,根据的原因是因为int与string这两种类型在空间大小与赋值的方式上都是不同的。所以,必须生成两套代码来实现。

而指针,不管是什么指针,它们都是一样的。我们可以用void*代表所有的指针类型。

于是我们将上面的代码改改,再测试一下:


//! code-7
 
    map<int, string*> m1;
    map<int, string*> m2;
    map<int, string*> m3;
 
    m1.insert(std::make_pair(1, new string("hello")));
    m2.insert(std::make_pair(1, new string("hi")));
    m3.insert(std::make_pair(1, new string("lichunjun")));



//! code-8
 
    map<int, string*> m1;
    map<int, double*> m2;
    map<int, int*> m3;
 
    m1.insert(std::make_pair(1, new string("hello")));
    m2.insert(std::make_pair(1, new double(1.2)));
    m3.insert(std::make_pair(1, new int(44)));

结果是这样的:


-rwxrwxr-x. 1 18736 Mar 19 23:05 test1
-rwxrwxr-x. 1 35136 Mar 19 23:05 test2

预期的结果test1与test2相差不多,但从结果上看并没有什么优化,结果有点令人失望~


思考:C++有没有什么参数可以优化这个?

如果没有,为了节省空间,我们只能将所有的指针统一定义成void*类型了,在使用时再强制转换。


//! code-9
 
    map<int, void*> m1;
    map<int, void*> m2;
    map<int, void*> m3;
 
    m1.insert(std::make_pair(1, new string("hello")));
    m2.insert(std::make_pair(1, new double(1.2)));
    m3.insert(std::make_pair(1, new int(44)));
 
    cout << *static_cast<string*>(m1[1]) << endl;
    cout << *static_cast<double*>(m2[1]) << endl;
    cout << *static_cast<int*>(m3[1]) << endl;

如上代码是将code-8的基础上,将所有的指定都定义成了void*,在使用的时候用static_cast进行强制转换成对应的指针类型。

如此得到的代码大小与code-7的比较,只多了16个字节。

但这种做法是很不可取的,必须用void*指针之后,编译器不再对类型进行检查,很容易把类型搞混淆。


最好还是编译器支持指针泛型的优化吧!

目录
相关文章
|
6天前
|
缓存 人工智能 自然语言处理
我对比了8个Claude API中转站,踩了不少坑,总结给你
本文是个人开发者耗时1周实测的8大Claude中转平台横向评测,聚焦Claude Code真实体验:以加权均价(¥/M token)、内部汇率、缓存支持、模型真实性及稳定性为核心指标。
2385 16
|
18天前
|
人工智能 自然语言处理 安全
Claude Code 全攻略:命令大全 + 实战工作流(建议收藏)
本文介绍了Claude Code终端AI助手的使用指南,主要内容包括:1)常用命令如版本查看、项目启动和更新;2)三种工作模式切换及界面说明;3)核心功能指令速查表,包含初始化、压缩对话、清除历史等操作;4)详细解析了/init、/help、/clear、/compact、/memory等关键命令的使用场景和语法。文章通过丰富的界面截图和场景示例,帮助开发者快速掌握如何通过命令行和交互界面高效使用Claude Code进行项目开发,特别强调了CLAUDE.md文件作为项目知识库的核心作用。
15797 47
Claude Code 全攻略:命令大全 + 实战工作流(建议收藏)
|
23天前
|
人工智能 数据可视化 安全
王炸组合!阿里云 OpenClaw X 飞书 CLI,开启 Agent 基建狂潮!(附带免费使用6个月服务器)
本文详解如何用阿里云Lighthouse一键部署OpenClaw,结合飞书CLI等工具,让AI真正“动手”——自动群发、生成科研日报、整理知识库。核心理念:未来软件应为AI而生,CLI即AI的“手脚”,实现高效、安全、可控的智能自动化。
34943 57
王炸组合!阿里云 OpenClaw X 飞书 CLI,开启 Agent 基建狂潮!(附带免费使用6个月服务器)
|
13天前
|
人工智能 JavaScript Ubuntu
低成本搭建AIP自动化写作系统:Hermes保姆级使用教程,长文和逐步实操贴图
我带着怀疑的态度,深度使用了几天,聚焦微信公众号AIP自动化写作场景,写出来的几篇文章,几乎没有什么修改,至少合乎我本人的意愿,而且排版风格,也越来越完善,同样是起码过得了我自己这一关。 这个其实OpenClaw早可以实现了,但是目前我觉得最大的区别是,Hermes会自主总结提炼,并更新你的写作技能。 相信就冲这一点,就值得一试。 这篇帖子主要就Hermes部署使用,作一个非常详细的介绍,几乎一步一贴图。 关于Hermes,无论你赞成哪种声音,我希望都是你自己动手行动过,发自内心的选择!
3040 29
|
2天前
|
云安全 人工智能 安全
|
2天前
|
人工智能 测试技术 API
阿里Qwen3.6-27B正式开源:网友直呼“太牛了”!
阿里云千问3.6系列重磅开源Qwen3.6-27B稠密大模型!官网:https://t.aliyun.com/U/JbblVp 仅270亿参数,编程能力媲美千亿模型,在SWE-bench等权威基准中表现卓越。支持多模态理解、本地部署及OpenClaw等智能体集成,已开放Hugging Face与ModelScope下载。
|
1天前
|
机器学习/深度学习 缓存 测试技术
DeepSeek-V4开源:百万上下文,Agent能力比肩顶级闭源模型
DeepSeek-V4正式开源!含V4-Pro(1.6T参数)与V4-Flash(284B参数)双版本,均支持百万token上下文。首创混合注意力架构,Agent能力、世界知识与推理性能全面领先开源模型,数学/代码评测比肩顶级闭源模型。
1255 6