Skip to content

Commit d159aa0

Browse files
authored
Merge pull request #42 from muyuuuu/main
Update no_more_new.md with some bad demo
2 parents e02029e + 03889fc commit d159aa0

File tree

1 file changed

+96
-1
lines changed

1 file changed

+96
-1
lines changed

docs/no_more_new.md

+96-1
Original file line numberDiff line numberDiff line change
@@ -203,7 +203,7 @@ some_c_function(foo.get());
203203
204204
> {{ icon.detail }} 在[错误处理专题](error_code.md)中有进一步的详解。
205205
206-
然而这有时我们会忘记在提前返回的分支中 delete 之前分配过的所有智能指针
206+
然而这有时我们会忘记在提前返回的分支中 delete 之前分配过的所有指向动态内存的指针
207207
208208
```cpp
209209
int func() {
@@ -219,6 +219,101 @@ int func() {
219219
}
220220
```
221221

222+
过去,人们使用 `goto` 大法拙劣地在提前返回时 `delete` 动态内存:
223+
224+
```cpp
225+
int main() {
226+
Foo *foo1, *foo2;
227+
int ret = 0;
228+
foo1 = new Foo();
229+
...
230+
if (出错) {
231+
ret = -1;
232+
goto out_foo1;
233+
}
234+
...
235+
Foo *foo2 = new Foo();
236+
...
237+
if (出错) {
238+
ret = -2;
239+
goto out_foo2;
240+
}
241+
...
242+
out_foo2: delete foo2;
243+
out_foo1: delete foo1;
244+
return ret;
245+
}
246+
```
247+
248+
这对于“写”程序的人,其实还不算什么,无非就是注意匹配,反正都是一次性写完就得了。
249+
250+
真正遭罪的是“改”程序的人,如果他要删掉foo1,那么他需要在两个地方来回跳转,如果foo1变成 `new[]` 了,那么他需要跳到下面把 `delete foo1` 也改成 `delete[] foo1`。如果foo1要改名,那么还需要跳到下面 `out_foo1:` 标签也改了。如果要新增一个foo3指针,那还需要跳到上面加个 `Foo *foo3;`,下面加个标签和 delete。
251+
252+
> {{ icon.fun }} BUG漫漫其修远兮,吾将上下而求索。
253+
254+
你是否遇到过写程序梭哈,事后“上下求索”的情况?同一个变量 foo 的生命周期被极限撕扯,分居两地,极大的妨碍了我们改程序的效率。
255+
256+
而统计表明,程序员10%的时间用于写代码,90%的时间花在改代码上。节约改代码的时间,就是节约程序员90%的生命。改代码不容易出错,可以省去软件中90%的BUG。
257+
258+
所以,除非你是一次性交差项目不打算更新了,或者确认了改代码的人不会是你,否则必然要用包括智能指针、设计模式在内的各种手段竭力避免代码分散化。
259+
260+
在一个庞大的代码系统中看到原始指针是最头疼的:
261+
262+
```cpp
263+
Student *getstu(const char *name);
264+
```
265+
266+
没有任何信息告诉我:
267+
268+
1. 这个指针指向对象生命周期如何?
269+
2. 要我负责释放内存吗?
270+
3. 如何释放,`delete`、`delete[]`、`free`、还是 `fclose`?
271+
4. 可以是空指针吗?
272+
5. 数组还是单个对象?
273+
6. 如果是数组,那么长度多少?是C风格0结尾字符串吗?
274+
7. 是否移交所有权?
275+
8. 共享或独占?
276+
9. 该资源可以拷贝吗?
277+
10. 如果可以,如何拷贝?
278+
279+
而你只能通过查阅文档,才能确认这些信息,拖慢了开发效率。
280+
281+
而使用 RAII 容器(不仅是只能指针)作为类型,就能让人一眼就看出以上10个信息。
282+
283+
```cpp
284+
gsl::not_null<std::unique_ptr<Student>> getstu1(std::string_view name);
285+
Student &getstu2(std::string_view name);
286+
```
287+
288+
以上代码中,一看就明白,getstu1会移交所有权,且不可能为空;getstu2不转移所有权,仅仅只是提供给调用者访问,且不可能为空。
289+
290+
传统指针因为语义不明确,功能多样化,有用错的可能,例如用户可能偷懒不看文档,就擅自瞎写:
291+
292+
```cpp
293+
char name;
294+
Student *stu = getstu(&name);
295+
if (stu == NULL) exit(1);
296+
free(stu);
297+
```
298+
299+
实际上 `getstu` 的参数 `name` 需要是一个 C 风格 0 结尾字符串,用户却不小心当作单个 `char` 的指针写了,编译器没有报错。
300+
301+
而 `stu` 实际上是 `getstu` 返回给调用者的临时引用,并不移交所有权,而用户却想当然的释放了。
302+
303+
并且实际上 `getstu` 从不返回空指针,用户根本不用提心吊胆地检查。
304+
305+
一个优质的函数接口,就不应该给用户这种犯错的机会。
306+
307+
我知道,你会说,`std::string` 不也能从 `&name` 构造,放任编译通过,不也会犯错吗?
308+
309+
是这样的,你甚至可以从 `0` 构造 `std::string`,编译一样通过,程序会直接崩溃:
310+
311+
```cpp
312+
std::string s = 0; // 0 被当作 NULL,从而调用构造函数 std::string(const char *)
313+
```
314+
315+
标准库里不符合小彭老师设计模式的多了去了,标准库的垃圾是历史遗留问题,不是小彭老师的问题。
316+
222317
而智能指针,不论是提前返回还是最终的返回,只要是函数结束了,都能自动释放。智能指针使得程序员写出“提前返回式”毫无精神压力,再也不用惦记着哪些需要释放。
223318

224319
```cpp

0 commit comments

Comments
 (0)