当前位置: 首页 > news >正文

Linux C/C++ 编程环境搭建

一、安装必备的编译工具链

1.1 编译器

GCC:默认将.c文件视为C程序,.cpp文件需手动指定为C++(如gcc -xc++);默认链接C标准库(libc),编译C++程序需手动添加-lstdc++参数。‌

G++:自动将.c和.cpp文件均视为C++程序,并启用C++语法解释(如预定义__cplusplus宏);自动链接C++标准库(libstdc++),无需额外参数。‌

两者区别:

  • 底层关系与功能覆盖:
    • 核心一致性‌:两者共享同一编译器核心,G++本质是GCC的C++专用包装。
    • 多语言支持‌:GCC支持C、Fortran、Ada等语言,而G++仅针对C++优化。‌
  • 常见误区澄清:
    • ‌编译阶段‌:两者均可编译C/C++代码,但G++在编译阶段会调用GCC。‌
    • 宏定义‌:__cplusplus宏由文件后缀和编译器共同决定,并非仅G++定义。‌
  • 使用建议:
    • C++项目‌:优先使用G++,避免手动链接库的复杂性。‌
    • C项目‌:使用GCC以获得更简洁的编译流程。‌

扩展‌:G++对C++11/17/20标准支持更完善(如-std=c++17),而GCC需显式指定。

安装完成后验证:

gcc --version
g++ --version
make --version

1.2 链接器

make:适合小型项目,手动维护规则,简单直接。

CMake:适合跨平台和大型项目,自动生成 Makefile 等构建文件,更灵活强大。

详见:make和Cmake区别

1.2.1 Makefile编写

手动敲编译命令容易出错,Makefile 让一切变得自动化:

# 定义编译器,这里选择 GCC
CC = gcc  # 定义编译选项:
# -Wall:打开所有警告
# -g:生成调试信息
CFLAGS = -Wall -g  # 定义目标规则 'all',默认目标是 main
all: main  # 定义如何生成 main 可执行文件
# 使用目标 main.o 和 func.o 链接生成 main
main: main.o func.o  $(CC) $(CFLAGS) -o main main.o func.o  # 定义生成 .o 文件的通用规则
# 这里 $< 表示匹配的 .c 文件
%.o: %.c  $(CC) $(CFLAGS) -c $<  # 定义清理规则,删除所有中间文件和最终生成的目标文件
clean:  rm -rf *.o main

执行命令:

make         # 自动编译,生成目标文件 main
make clean   # 清理编译生成的中间文件和可执行文件

1.2.2 使用 CMake

写 Makefile 太麻烦?那就用 CMake!步骤如下:

  • 安装
sudo pacman -S cmake
  • 项目根目录创建 CMakeLists.txt 文件
# 指定最低版本要求,这里是 3.10
cmake_minimum_required(VERSION 3.10)  # 定义项目名称,这里是 MyProject
project(MyProject)  # 添加可执行文件 main,并指定需要的源文件
# main.cpp 和 func.cpp 是需要编译的 C++ 源文件
add_executable(main main.cpp func.cpp)
  • 执行命令
# 创建一个名为 build 的目录,存放生成的构建文件
mkdir build && cd build  # 使用 CMake 生成 Makefile,.. 表示查找上级目录中的 CMakeLists.txt
cmake ..  # 使用 make 根据生成的 Makefile 编译项目
make

1.3 调试工具

  • 安装
sudo pacman -S gdb
  • 调试
g++ -g hello.cpp -o hello  # 编译的时候必须要加上 -g 参数,不然调试不了。
gdb ./hello
  • gdb使用
    run:运行程序。
    break main:在 main() 函数处打断点。
    next:单步执行。
    print <变量名>:打印变量值。

注:合理使用日志打印也是一种不错的调试方法,有些时候比调试器更管用。

1.4 排查内存问题:Valgrind

  • 安装
sudo pacman -S valgrind
  • 使用
valgrind ./your_program
  • 结果分析
    正常情况: 如果看到 All heap blocks were freed,恭喜,没有内存泄漏!
    有问题: 如果显示 definitely lost 或 indirectly lost,说明有内存没有正确释放,需要检查代码,比如 malloc 和 free 是否匹配。
    一句话总结: 装个 Valgrind,跑一遍程序,就能快速找到内存泄漏问题。简单高效,C/C++ 开发必备!

二、终端

推荐:zsh + oh-my-zsh + vim

三、版本管理

推荐:Git

http://www.sczhlp.com/news/6524/

相关文章:

  • Make、Cmake
  • Substans Painter
  • 关于Mtk修改Android 14 usb连接电脑默认为mtp模式
  • MySQL 8.4 启动报错:io_setup() failed with EAGAIN
  • 基于Python与MobileNetV3的轻量级验证码识别系统设计
  • pyyzDay3
  • dp05
  • Stimulsoft报表及仪表盘解决方案将终止支持 .NET Core 3.1 和 .NET 5.0,聚焦现代平台演进
  • Gitee深度实践报告:国产代码托管平台如何赋能企业技术升级
  • 借助Aspose.OCR ,使用 Python 提取JPG图像文本、将JPG图像转换为Word
  • VS2022中C++导入三方库方法及问题
  • Mysql如何迁移数据库数据
  • 解锁音频创作新可能:AI 人声伴奏分离神器 Replay 深度解析
  • 第一章 应急响应-webshell查杀
  • 第一章日志分析-apache日志分析
  • 2025 7-8 月 ACM 多校记录
  • vs code 中 git 使用
  • ME 807 在表 EINA 中插入时有错误
  • task1 思路
  • Git merge 各种参数以及与 rebase比较
  • 设计模式简介
  • (三)变换
  • Python连接与操作Mongo_Alats
  • 【JPCS出版】第五届计算机、遥感与航空航天国际学术会议(CRSA 2025)
  • 浅谈 RAG 并基于 NodeJS 实现基础向量检索服务
  • 【IEEE出版】第二届计算机与信息安全国际会议(WCCIS 2025)
  • 静态链接和动态链接
  • GCC、CMake 和 vcpkg 的关系与应用
  • rust学习第一课:window环境报错(error: linker `link.exe` not found)
  • Python + Requests 接口自动化框架的实现