是可行的。
以 Windows 下 DLL 为例，使用 LoadLibrary 加载 module 之后获得 handle，再使用 GetProcAddress 获得目标函数指针 pFooTarget。
之后神奇的部分就发生了，假定 FooTarget 使用了 x86 cdecl calling convention，可以根据 xml 中描述的变量信息，在调用 pFooTarget 之前自行按照 cdecl 的规则进行参数压栈，最后一句汇编 CALL，即可完成函数的调用。
同样，调用完毕后，需要自行到寄存器或者栈上取回返回值，比如 eax。

失去了 lvalue 像内脏被人狠狠踩了一脚，失去了 rvalue 像割走的盲肠被人踩了一脚。

看编译器报错，缺啥补啥

@q8515620

main() 里面，
```
auto m2 = ::max(s1, s2, s3); //run-time ERROR
```
这句会进入第 3 个 function template
```
// maximum of three values of any type (call-by-reference)
template<typename T>
T const& max (T const& a, T const& b, T const& c)
{
return max (max(a,b), c); // error if max(a,b) uses call-by-value
}
```
这句又进入了第 2 个 function template
```
// maximum of two C-strings (call-by-value)
char const* max (char const* a, char const* b)
{
return std::strcmp(b,a) < 0 ? a : b;
}
```
此时，由于返回类型是 char const*，一个指针 variable，不论 a/b 哪个更大，都会返回一个 variable，类型是 char const*，值是 a/b 中 strcmp 较大的那个指向的地址。这个 variable 就是所谓的 temporary variable。

类似于
```
T a = foo();
```
foo() evaluate 完之后，所有 foo() 中的变量 life cycle 都结束了，那 assignment 要拿谁做等号右边的 variable ？这种情况就会产生一个 temporary variable 用来临时存放返回值，等 assignment 结束后，temporary variable 的 life cycle 也结束了。当然，实际代码中 temporary variable 可能被 RVO 优化掉，更或者被 C++17 的 copy elision 处理掉。这里不展开了。

第 2 个 function template return 后，回到第 3 个 function template，此时，等价于
```
return max(temporary_variable, c);
```
这里会再进一次第 2 个 function template，返回后等价于
```
return temporary_variable_2;
```
然而，第 3 个 function template 返回的类型是 T const&，也就是返回了 temporary variable 的引用，一直传递到了 main 里面，而这个 temporary variable 的 life cycle 也就到第 3 个 function template 结束而已。对 temporary variable 的使用超过的它的 life cycle，是一种 run time error。

此时会不会 crash 就是 UB 了，一般编译器不会做类似 variable life cycle 一结束就清除它的内存之类激进的事情，所以 temporary variable 的内存地址里“可能”暂时还会是它原本的内容（ UB ），将这些字节解释回变量的内容也“可能”得到原来变量的值（ UB again ）。并且
```
auto m2 = ::max(s1, s2, s3);
```
这里，auto 会得到 decay 的类型，去掉了引用，因此只要这个 temporary variable “曾经”所在的内存能撑过这句，就能得到原本的变量值。

而
```
auto m1 = ::max(7, 42, 68); // OK
```
没问题的原因是它从头到尾就不会进第 2 个 function template，始终是引用飞来飞去，引用的就是 7/42/68 这三个 integer literal 产生的 temporary variable，life cycle 是到该语句结束，然后被 auto 得到 decay 的类型后 copy 一份。不属于 UB。

港真，好好写人能读懂的代码，不要乱飞这些乱七八糟的类型更重要。

sizeof 是一个 compile time 的运算符

1. 为什么实际工程中不用 g++ 命令？
其实也用，只不过是隐含在 makefile 里，执行 makefile 时候会自动调用。很多参考书给的用例，因为只有一个 cpp 文件，特意编写 makefile 来组织显得过于繁冗，因而直接一句 g++ 命令生成目标文件方便快捷。而实际工程中动辄几百个 cpp/header/so/a 文件，文件之间还存在依赖关系，这种情况下仍然手工一句一句 g++ 来编译实在过于复杂而且低效。

2. makefile 本质就是描述工程中的依赖关系和编译参数。执行时会自动根据依赖关系确定编译顺序，按序编译。makefile 是 unix-like 系统下的解决方案，Windows 下一般使用 MSVC 的 sln 工程文件。本质都是一样的东西。CMake 是一个跨平台的解决方案，执行时根据选择的目标平台不同将 CMakeList.txt “翻译”成 makefile 或者 vcxproj。

3. 自己搞个几十个 cpp 的小项目，跑一跑，在实践中摸索熟悉吧。相关的书籍有 《程序员的自我修养》、《 GNU Make 项目管理》。还有个文章《跟我一起写 Makefile 》。

多晒太阳，在户外走走，眼前看得见比几米就到头的墙壁更宽阔的地方。
多运动，多健身，冲重量，流流汗。
多看书，感受先哲迷茫时的共情。
祝你好运。

most vexing parse 了解一下

@gnaggnoyil 的回答是最 modern C++ 的进阶方法。

楼主所举例的命名一是属于一些早期 C++命名习惯的沿袭、二是属于一些惯用法。

如 sz，代表 string end with zero，类似的，还有 lpsz, psz, lpcsz 等，分别为 long pointer to string end with zero, pointer to string end with zero, long pointer to const string end with zero 等含义。其中 long pointer 的概念自 Win32 之后便已经淡化，现在 long pointer 与 pointer 在 Win32 API 中基本已无差别。早期 Win16 时代才有所区别。

如 lhs, rhs，属于惯用法 left hand side 与 right hand side 的缩写，一般代表 operator 左手侧与右手侧的变量。比如 operator+ (T lhs, T rhs)，调用时形式可为 a + b，此处 a 即左手侧，b 于右手侧。

一般应用这种形式的命名法正如 2 楼 @tmqhliu 所指出，叫做匈牙利命名法。指使用几个字符做简短前缀表明变量类型，后跟随其它命名含义的方式。比如常见的 nSize, lpcszFileName, rValue 等。但是现在很多新式 coder 已经不推荐这种命名法。若重构时更改变量类型，需要额外重新命名以保证一致，给维护带来负担。

建议变量名的命名应跟随当前项目的标准，与其他 coder 保持一致。不要给后来的阅读者带来困扰，命名含义表达清晰即可。

近年尽管网络上对东北偏见颇多，不可否认几所老牌工科学校在东北还是树大根深。除去 985 的因素不谈，东北大学的计算机本身实力是很强劲的。本科教育而言，更多依赖的还是个人的自觉奋进。而本科学历作为敲门砖的第一学历，学校本身的地位更会大于地域带来的优势。

@suixn 运气不太好，被标记不合适了 T_T

@suixn 音乐云技术部,PTBG-C++ :)

@suixn 拉勾投了，希望不会不合适

@pwcong
*s2 并不能完全认为是'x'，1 楼就举出了一个反例。可以看 19 楼的回答。

空调直接单独空气开关更安全些

包括任何可能参与此行的家庭成员

:reg 看看剪贴板里都是些啥内容