"Less is exponentially more"的读后感
Yili Zhao
先从Rob演讲的主题开始：“为什么 Go，一个被设计为用于摧毁 C++ 的语言，却并未获得 C++ 程序员的芳心？"
"我认为那是因为 Go 和 C++ 有着完全不同的哲学。C++ 是让你的指尖解决所有的问题。”
我曾经做过过一个实验项目，是关于图像处理方面的。
这个实验项目很小，只是一个桌面程序，没有涉及到网络编程和服务器编程。
我们小组成员对C++的理解也很肤浅。
一开始我们看到Boost有一个图像处理范型库-GIL，后来经过一段时间的使用，
发现GIL的设计有些“超范型”，而且学习曲线比较陡峭，对于普通的C++使用者
来说比较难。
因此我们希望设计一个微型库，能够提供一个公共的接口来表示内存中的图像数据。
由于像素有8位的，16位，和32位的等等，因为自然想到使用C++的模板：
template <typename Type, size_t N> class Image {...}
常见的类模板实例包括：Image<Byte, 1>，Image<Byte, 3>, Image<Float, 1>, Image<Float, 3>等。
由于受到STL的影响，我们将类模板Image设计成为像素的容器，并且在其中添加了诸如迭代器之类的STL容器元素。
并且，为了能够方便表示图像数据之间的运算，我们还对运算符进行了重载，能够完成诸如C = A + B这样的运算。
从这个角度来说，C++的范型和运算符重载特性确实给我们带来了便利。
本质上图像处理算法和图像文件的格式没有直接关系，更多的是对内存中的图像像素数据进行处理。
但是，总要把处理后的数据写到相应的图像文件中保持，便于观察实验结果。
我们也想提供一个公共的接口，支持常用的图像文件格式读写，主要包括PNG, JPEG, TIFF。
由于这三种图像格式本身都有相应的C语言库：LibPNG，LibJPEG和LibTIFF，可以在上面进行封装。
这时我们需要使用C++的函数模板：
// 读接口
template <typename I>
bool read(I& image, const std::string& filename) {...}
// 写接口
template <typename I>
bool write(const I& image, const std::string& filename) {...}
其中还需要函数模板重载和模板嵌套模板语法的支持。
我想说自己用了很多时间来学习C++的模板和范型编程，就向Rob提到的：
"C++ 程序员无法转到 Go 是因为他们经过艰辛的战斗才获得对其语言的精确控制能力，
他们不想放弃已经获得的任何东西。对于他们，软件不仅仅是关于让工作完成，而是关于用一个确定的方式完成。"
对于那些能够熟练使用C++的人来说，要转到Go语言应该会很难。
更何况C/C++经过几十年的发展，还积累了很多的库。
Rob提到的“我们并未尝试去设计一个更好的 C++，甚至更好的 C。仅仅是一个对于我们在意的那种类型的软件来说更好的语言。"
Rob所谓“他们在意”的那种类型的程序应该是指服务器端和分布式的程序。如果Go被设计成只是一个更好的C++，
那么很可能和已经存在的D语言一样。
目前在内核编写和驱动领域，C/C++应该更加适合；在图形／图像领域，C/C++和Matlab更加适合。
--
Yili Zhao
shiwei xu
--
Yili Zhao
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
许式伟
Gao Ya'nan
更多的地方是完成某些功能，而不需要精确控制，这个地方 C++ 又并非优选。
我觉得没有完美的语言，以增加特性让语言达到完美是适得其反的。
2012/6/29 shiwei xu <xushi...@gmail.com>:
Xing Xing
"Gao Ya'nan" <abutt...@gmail.com> 写道:
> 有些地方需要精确控制，对时序和时间有苛刻的要求，如驱动程序，这方面
> C、C++和汇编会有优势，不过个人以为 C 和汇编更容易掌握一些。
>
> 更多的地方是完成某些功能，而不需要精确控制，这个地方 C++ 又并非优选。
>
> 我觉得没有完美的语言，以增加特性让语言达到完美是适得其反的。
>
发现真需要精确控制，其实 go 联合 c 能做得很好。
平民四月份
Face the sea, for the spring flowers blossoming
