《C++ 基础进阶:内存开辟规则、类型转换原理与 IO 流高效使用》

《C++ 基础进阶:内存开辟规则、类型转换原理与 IO 流高效使用》
前引:在 C++ 编程中,内存管理是程序稳定性与性能的基石,而类型转换与 IO 流则是数据处理和交互的核心工具。栈与堆作为内存分配的两大核心区域,其开辟方式直接决定了变量的生命周期、访问效率及内存安全 —— 错误的分配策略可能导致内存泄漏、野指针或栈溢出等致命问题。与此同时,类型转换的合理性关乎类型系统的严谨性,不当转换易引发数据截断、逻辑错误;IO 流作为数据输入输出的桥梁,其正确使用则直接影响程序与外部设备(如控制台、文件)交互的可靠性!

目录

【一】内存完美开辟

(1)栈和堆的本质区别

(2)如何只在栈上开辟空间

(3)如何只在堆上开辟空间

【二】C++的四种类型转换

(1)static_cast

(2)reinterpret_cast

(3)const_cast

(4)dynamic_cast

【三】operator类型转换

(1)奇怪的现象

(2)类型转化的本质


【一】内存完美开辟

(1)栈和堆的本质区别
栈上开辟:比如一个函数、变量、数组等不需要明确的去malloc、new等申请动态空间

堆上开辟:需要手动去开辟指定大小的空间以及释放
特性栈(Stack)堆(Heap)
分配方式编译器自动分配 / 释放程序员手动分配(new)/ 释放(delete
生命周期随作用域(如函数、代码块)结束而销毁delete调用而销毁(否则内存泄漏)
大小限制通常较小(如几 MB,由系统限制)较大(几乎等于系统可用内存)
速度极快(类似 “拿取 / 放回固定货架”)较慢(类似 “找空地放东西,还要记录位置”)
使用场景局部变量、函数参数等短期存在的变量动态大小的数据(如数组长度运行时确定)
(2)如何只在栈上开辟空间

栈上开辟不需要手动的去malloc、new动态内存,周期一般在该函数调用结束时自动销毁

我们知道动态开辟,比如C++的new形式开辟是调用operator new开辟堆空间的,因此解决如下:

禁用(私有)operator new这样用户就没法调用,那就只能在栈上开辟空间,实现如下:

template<class T> class StackOnly { public: StackOnly() { } private: // 将operator new设为私有,禁止堆分配 void* operator new(size_t size); void operator delete(void* ptr); };
(3)如何只在堆上开辟空间

堆上调用是明确的调用new开辟空间,而栈每次是调用构造函数,因此我们禁用(私有)构造函数,只放new出来就可以完成只在堆上开辟空间,实现如下:

class HeapOnly { private: // 构造函数私有,禁止栈上创建(栈上创建需要调用构造函数) HeapOnly() {} public: // 静态函数:在堆上创建对象并返回指针 static HeapOnly* create() { return new HeapOnly(); } ~HeapOnly() { delete this; // 释放当前对象 } }; 
这里为什么要用static静态修饰这个create函数?
简洁解释:若不用static修饰,这个函数就属于对象,就要调用构造函数。而用static修饰之后,这个函数就属于类本身,不需要创建对象就可以调用,就可以避免先有对象再调用函数

详细解释如下:

栈上创建对象时,需要直接调用构造函数(比如 HeapOnly obj; 会触发构造函数)。但我们为了禁止栈上创建,把构造函数设为了 private(外部无法直接调用)此时,如果 create 不是静态函数:非静态函数属于对象(需要先有一个 HeapOnly 对象才能调用)。但构造函数私有,根本无法在外部创建第一个 HeapOnly 对象,自然也无法调用非静态的 create。而 静态成员函数属于 “类本身”,不需要先创建对象就能调用(可以直接通过 类名::函数名 调用,比如 HeapOnly::create())。这样就能绕开 “必须先有对象才能调用函数” 的限制,在 create 内部用 new (调用私有构造函数)创建堆上的对象

【二】C++的四种类型转换

介绍:在 C++ 中,类型转换是程序中常见的操作,为了使转换行为更清晰、更安全,C++ 提供了四种显式类型转换运算符(也称为 “转换的类模板”),分别是static_castdynamic_castconst_castreinterpret_cast。它们各自有明确的适用场景和特性!

(1)static_cast
static_cast一般用于相近类型的转化

比如 int 和 double,:

int a = 10; double b = static_cast<double>(a);

比如 char 和 long:

char c = 'c'; long d = static_cast<long>(c);
(2)reinterpret_cast
reinterpret_cast一般用于不相关类型转化

比如:int *  和 double *

int* c = &a; double* d = reinterpret_cast<double*> (c);

比如:char* 和 double*

char* c = &c; double* d = reinterpret_cast<double*> (c);
(3)const_cast
const_cast一般用于去掉const

例如:

int x = 10; // 本质是非const对象 const int* pc = &x; // const指针指向非const对象(仅限制通过该指针修改) // 需求:需要通过指针修改x的值 int* non_const_ptr = const_cast<int*>(pc); // 移除const
(4)dynamic_cast
dynamic_cast一般用于继承上的父->子的转化

(父类的指针是可以指向子类的对象的->切片)

(子类的指针是不可以指向父类的对象的)

例如:

class A { public: virtual void f() {} int _x = 0; }; class B : public A { public: int _y = 0; }; void fun(A* pa) { // pa是指向子类对象B的,转换可以成功,正常返回地址 // pa是指向父类对象A的,转换失败,返回空指针 B* pb = dynamic_cast<B*>(pa); if (pb) { cout << "转换成功" << endl; pb->_x++; pb->_y++; } else { cout << "转换失败" << endl; } }

【三】operator类型转换

(1)奇怪的现象

例如现在有一个类:

class Func { public: int a = 10; operator bool() { return a; } }; 

现在我们创建一个Func类类型的对象A,并进行赋值:

int main() { Func A; bool pc = A; cout << pc << endl; return 0; }
问:一个对象怎么赋值给一个变量呢?

但是结果是可以的,我们看下面的运行结果:

(2)类型转化的本质
运算符重载的本质是重新定义运算符的行为,让自定义类型(类)能像内置类型(如 intdouble)一样使用运算符运算符选择:大部分 C++ 运算符都可重载(如 +-=<< 等),但少数不可重载(如 .::sizeof?: 三目运算符)类型转换运算符(特殊的运算符重载):用于将类对象转换为其他类型(如 boolintdouble 等)语法上没有显式的返回值类型(返回值类型由 “operator 目标类型” 决定),也没有参数(因为是 “将当前对象转换为目标类型”)。示例:operator int() 表示 “将对象转换为 int 类型”,operator double() 表示 “将对象转换为 double 类型”

Read more

全网最全!Python、PyTorch、CUDA 与显卡版本对应关系速查表

全网最全!Python、PyTorch、CUDA 与显卡版本对应关系速查表

摘要:搞深度学习,最痛苦的不是写代码,而是配环境! “为什么我的 PyTorch 认不出显卡?” “新买的显卡装了旧版 CUDA 为什么报错?” 本文提供一份保姆级的版本对应关系速查表,涵盖从 RTX 50 系列 (Blackwell) 到经典老卡的软硬件兼容信息。建议收藏保存,每次配环境前查一下,能省下大量的排坑时间! 🗺️ 核心逻辑图解 在看表格前,先理清显卡架构的代际关系与 CUDA 版本的强绑定逻辑。 📊 一、PyTorch 版本对照表 (推荐) PyTorch 是目前兼容性最好的框架,只要 CUDA 驱动版本 足高,通常都能向下兼容。对于使用最新硬件(如 RTX 50 系)的用户,请务必使用 2.4 或更高版本。 PyTorch 版本Python 版本推荐 CUDA适用显卡建议2.

By Ne0inhk
具身智能中 Wrapper 架构的深度解构与 Python 实战

具身智能中 Wrapper 架构的深度解构与 Python 实战

具身智能中 Wrapper 架构的深度解构与 Python 实战 零、前言 在具身智能(Embodied AI)的开发中,我们常常需要让智能体(Agent)在仿真环境(如 Isaac Sim, Mujoco, PyBullet)中进行千万次的试错训练,然后再部署到真实的物理机器人上。 很多新手在做强化学习(Reinforcement Learning)与机器人的结合时,喜欢直接修改底层仿真环境的源码:改一下奖励函数、加一点传感器噪声、裁剪一下动作输出。随着项目迭代,环境代码变得像“意大利面”一样纠缠不清,不仅难以维护,更无法复用。 今天,我们就来聊聊具身智能架构设计中的一门必修课——Wrapper(包装器)模式。本文将从核心理论到企业级代码落地,带你彻底掌握如何优雅地重构你的机器人训练环境。 一、核心概念:具身智能的“翻译官”——Wrapper 架构 1.1

By Ne0inhk

从零到一:YOLOv8OBB旋转目标检测在RK3588上的C++部署心路历程

从零到一:YOLOv8OBB旋转目标检测在RK3588上的C++部署心路历程 作为一名长期从事边缘计算部署的工程师,我深知将先进的AI模型落地到嵌入式设备上的挑战与乐趣。当第一次接触到YOLOv8OBB旋转目标检测模型时,我就被其在复杂场景中的精准检测能力所吸引。然而,将这样一个前沿模型部署到RK3588平台,并用C++实现高效推理,却是一段充满技术探索和实战考验的旅程。 RK3588作为一款高性能的AIoT芯片,其强大的NPU算力为复杂模型部署提供了硬件基础。但在实际部署过程中,从模型转换、环境配置到代码优化,每个环节都可能遇到意想不到的问题。本文将分享我从零开始,一步步将YOLOv8OBB模型部署到RK3588的完整过程,包括技术选型的思考、环境搭建的细节、模型转换的陷阱,以及最终C++代码的优化实践。 1. 技术选型与环境准备 在开始部署之前,明确技术栈和硬件环境是确保项目顺利推进的基础。我选择的是YOLOv8OBB模型,这是Ultralytics团队针对旋转目标检测推出的专用版本,相比传统的水平框检测,它能更精准地定位旋转物体,特别适合遥感图像、文档检测等场景。 R

By Ne0inhk