std::unique_ptr 是 C++11 标准的 STL 中, 用来取代 std::auto_ptr 的指针容器 (如果在代码中使用了 std::auto_ptr, 使用 gcc 4.5 之后的版本加上 -std=c++0x -Wall 参数编译时, gcc 会报出警告 std::auto_ptr 已经过时).

同 std::auto_ptr 一样, std::unique_ptr 的基本功效也能当作简单的自动对象管理指针来使用, 如

#include <memory> /* for std::unique_ptr */
#include <iostream>

struct echo {
    echo()
    {
        std::cout << "ctor" << std::endl;
    }

    ~echo()
    {
        std::cout << "dtor" << std::endl;
    }

    echo(echo const&) = delete;
};

void test()
{
    std::unique_ptr<echo> echo_ptr(new echo);
}

int main()
{
    test();
    std::cout << "." << std::endl;
    return 0;
}

输出应该如

ctor
dtor
.

类型 echo 在构造和析构时的输出信息可以帮助掌握对象的生命周期. 如上述程序中, echo 对象在 test 函数结束时析构.

std::unique_ptr 的复制构造函数被 delete 处理了, 所以类似下面的代码会出错

std::unique_ptr<int> a(new int(0));
std::unique_ptr<int> b(a); // ERROR
            // deleted function
            // ‘std::unique_ptr<...>::unique_ptr(std::unique_ptr<...> const&)'

如果确实需要复制一份整数的值, 需要可以做如下操作

std::unique_ptr<int> b(new int(*a));

而如果是想要将 a 所持有的指针转移到 b 中, 需要显式调用 std::move 将来移交指针控制权

std::unique_ptr<int> a(new int(0));
std::unique_ptr<int> b(std::move(a));

此时 a 中的指针会变为 NULL. 明确的转移语义由 std::move 函数表达, 与 std::auto_ptr 暧昧的构造函数不同, std::move 明确指出 std::unique_ptr 对象是通过转移构造进行参数传递的.

当函数需要使用 std::unique_ptr 作为参数或返回值时, 可以是如下几种形式

Posted at Mar 13 2011 - 08:34:22

Permanent Link: /p/181 Load full text

Post tags:

C++
C++11
unique_ptr
Move Semantic
Tutorial

C++ 到底怎么使用流来输出对象

书上写的做法当然是类似

struct my_type {
    void set_x(int xx);
    void set_y(double yy);

    my_type(int xx, double yy)
        : x(xx)
        , y(yy)
    {}

    friend std::ostream& operator<<(std::ostream& os, my_type const&);
private:
    int x;
    double y;
};

std::ostream& operator<<(std::ostream& os, my_type const& m)
{
    return os << m.x << ' ' << m.y;
}

一般使用这样没问题, 不过在想要写得很省略的用况下, 这样就很纠结

my_type m(10, 20.0);
std::stringstream ss;
std::string image = (ss << m).str(); // WRONG!

因为 operator<< 返回的类型已经变成没有 str() 取得字符串函数的基类 std::ostream& 了. 看起来要什么流类型进来什么流类型出才行, 比如

struct my_type {
    void set_x(int xx);
    void set_y(double yy);

    my_type(int xx, double yy)
        : x(xx)
        , y(yy)
    {}

    friend template<typename _OS>
    _OS& operator<<(_OS& os, my_type const&); // WRONG
private:
    int x;
    double y;
};

template <typename _OS>
_OS& operator<<(_OS& os, my_type const& m)
{
    os << m.x << ' ' << m.y;
    return os;
}

不过很遗憾, 泛型函数无法做朋友
那要不先把 my_type 对象弄成字符串了, 再把字符串输出好了

struct my_type {
    void set_x(int xx);
    void set_y(double yy);

    my_type(int xx, double yy)
        : x(xx)
        , y(yy)
    {}

    std::string str() const
    {
        std::stringstream ss;
        ss << m.x << ' ' << m.y;
        return ss.str();
    }
private:
    int x;
    double y;
};

template <typename _OS>
_OS& operator<<(_OS& os, my_type const& m) // ACTUALLY NOT NEEDED ANY MORE
{
    os << m.str();
    return os;
}

这看起来多疼啊.

一个可能的方案是, 为每个自定义类型实现 str() 成员函数 (有必要的还可以虚一下), 然后全局声明一个

template <typename _OS, typename _T>
_OS& operator<<(_OS& os, _T const& t)
{
    os << t.str();
    return os;
}

也许这样会好很多.

Posted at Mar 05 2011 - 15:14:50

Permanent Link: /p/177 Load full text

Post tags:

C++
Operator Overload
Output Stream

C++ 中捕获整数除零错误

继承自 C 的优良传统, C++ 也是一门非常靠近底层的语言, 可是实在是太靠近了, 很多问题语言本身没有提供解决方案, 可执行代码贴近机器, 运行时没有虚拟机来反馈错误, 跑着跑着就毫无征兆地崩溃了, 简直比过山车还刺激.
虽然 C++ 加入了异常机制来处理很多运行时错误, 但是异常机制的功效非常受限, 很多错误还没办法用原生异常手段捕捉, 比如整数除 0 错误. 下面这段代码

#include <iostream>

int main()
{
    try {
        int x, y;
        std::cin >> x >> y;
        std::cout << x / y << std::endl;
    } catch (...) {
        std::cerr << "attempt to divide integer by 0." << std::endl;
    }
    return 0;
}

输入 "1 0" 则会导致程序挂掉, 而那对 try-catch 还呆在那里好像什么事情都没发生一样. 像 Python 一类有虚拟机环境支持的语言, 都会毫无悬念地捕获除 0 错误.

使用信号

    不过, 底层自然有底层的办法. 这得益于硬件体系中的中断机制. 简而言之, 当发生整数除 0 之类的错误时, 硬件会触发中断, 这时操作系统会根据上下文查出是哪个进程不给力了, 然后给这个进程发出一个信号. 某些时候也可以手动给进程发信号, 比如恼怒的用户发现某个程序卡死的时候果断 kill 掉这个进程, 这也是信号的一种.
    这次就不是 C 标准了, 而是 POSIX 标准. 它规定了哪些信号进程不处理也不会有太大问题, 有些信号进程想处理也是不行的, 还有一些信号是错误中断, 如果程序处理了它们, 那么程序能继续执行, 否则直接杀掉.
    不过, 这些错误处理默认过程都是不存在的, 需要通过调用 signal 函数配置. 方法类似下面这个例子

#include <csignal>
#include <cstdlib>
#include <iostream>

void handle_div_0(int)
{
    std::cerr << "attempt to divide integer by 0." << std::endl;
    exit(1);
}

int main()
{
    if (SIG_ERR == signal(SIGFPE, handle_div_0)) {
        std::cerr << "fail to setup handler." << std::endl;
        return 1;
    }
    int x, y;
    std::cin >> x >> y;
    std::cout << x / y << std::endl;
    return 0;
}

可以看出, signal 接受两个参数, 分别是信号编号和信号处理函数. 成功设置了针对 SIGFPE (吐槽: 为什么是浮点异常 FPE 呢?) 的处理函数 handle_div_0, 如果再发生整数除 0 的惨剧, handle_div_0 就会被调用.
handle_div_0 的参数是信号码, 也就是 SIGFPE, 忽略它也行.

底层机制

Posted at Jul 24 2010 - 13:17:37

Permanent Link: /p/100 Load full text

Post tags:

POSIX
C
Exception Handling
Signal
C++

C++ 转移构造

    这篇文章中的例子均可在 GCC 4.5.1 版本和 Clang 2.8 版本编译, 在某些较老或优化不尽相同的编译器上, 下面的例程可能并不能获得与文中所述一致的结果.
    不过, 这篇文章的重点并非讲述 C++ 中关于复制构造函数的优化, 而是为了说明 C++0x 标准中出现的 Move Semantic 所试图解决的问题之一, 所以对关于复制构造函数的例子有大致理解即可.
    重点是, 如果希望完整地编译文中最后一部分中出现的任何 0x 标准相关的代码, 强烈推荐 GCC 4.5.x 版本编译器.

    废话少说, 先来一段代码:

#include <iostream>

struct cp_ctor_doubling {
    cp_ctor_doubling(int ii)
        : i(ii)
    {}

    cp_ctor_doubling(cp_ctor_doubling const& rhs)
        : i(rhs.i * 2)
    {}

    int const i;
};

cp_ctor_doubling create(int i)
{
    return cp_ctor_doubling(i);
}

int main()
{
    cp_ctor_doubling c(create(10));
    std::cout << c.i << std::endl;
    return 0;
}

问: 输出多少? A. 10 B. 20 C. 40 D. 以上答案都不正确.
    嗯, 也许有得到 B 和 C 的, 得到 D 的同学也许该试着为自己的编译器报个 bug 了, 如果得到 A, 那么恭喜, 您的编译器已经具备对于复制构造函数最基本的优化能力了.
    C 语言忠实信徒揶揄 C++ 编译器会背着程序员做的 "额外的事情" 时, 历来会想到 C++ 的类复制构造函数. 然而, 现实不仅仅是这样, 编译器还会做出更多额外的事情, 比如把不必要的复制构造函数调用优化掉, 或者更准确地说, 把一些临时对象给优化掉, 于是复制构造函数根本不会被调用到.
    如果对上述例子中的编译优化有任何疑虑, 可以尝试下面这段代码

#include <iostream>

struct cp_ctor_not_impl {
    cp_ctor_not_impl(int ii)
        : i(ii)
    {}

    cp_ctor_not_impl(cp_ctor_not_impl const&);

    int const i;
};

cp_ctor_not_impl create(int i)
{
    return cp_ctor_not_impl(i);
}

int main()
{
    cp_ctor_not_impl c(create(10));
    std::cout << c.i << std::endl;
    return 0;
}

Posted at Jul 17 2010 - 16:27:35

Permanent Link: /p/94 Load full text

Post tags:

C++
C++11
Move Semantic
Copy Constructor

C++ 中的左值

请使用 x86 32位 ArchLinux GCC 4.5.0 环境编译文中 C++ 示例代码, 不过只要是 GCC 或 clang++ 编译结果应该都相仿.

作为一个特别的语言, C++ 中的左值是*语义*概念而非*语法*概念, 这一点甚至也可以认为是沿袭自 C 语言. 在任何其他语言中讨论 “什么是左值” 这个概念时, 会简短使用 “变量可以是左值”, “表达式不能是左值”, “常数不能作为左值” 等等, 诸如 “变量”, “表达式”, “常数” 这些都是语法概念, 所以刚才这些说法都是左值的语法约定. 确实一些语言使用语法约束来规定左值, 比如 Python, 下面的 Python 代码

class A:
    pass

a = A()
a + 1 = 0

编译时会报 “SyntaxError: can’t assign to operator”, 是 *Syntax* 哦. -甚至连- JS -这样乱的语言-也有类似的例子, 比如

var f = function() {};
f() = 0;

在执行的时候会报 "ReferenceError: Invalid left-hand side in assignment" --- Chromium.

在 C 里面表达式, 或者函数的返回值, 或者两者的混合, 只要语法恰当, 返回值类型又是一个可写指针, 那么通过对该指针引用的方式来赋值, 如

int* f() { return NULL; }

*(f() + 1) = 0;

这一特性在 C++ 那放荡不羁的类型系统里得到了极大的加强, 完全不再受制于语法的约束, 编译器只需要先根据运算符优先级搭起语法树, 至于左值判定什么的都留在以后的语义分析再来.

而这一切的开端仅仅是因为 C++ 支持一个指针的替代, 也就是引用, 这样连前缀星号都省略了.

另一方面, C++ 中的运算符重载机制又极大地扩展其左值概念的超凡脱俗, 并且 C++ 程序员似乎从来也未有过 “哦, 这只是个示例程序, 尽量别引入复杂特性” 这样的想法, 即使是经典的 Hello World 程序中, 也毫不吝惜地显摆着运算符重载这种高级特性.

#include <iostream>

int main()
{
    std::cout << "Hello, world\n";
}

从这个例子扩展出一个赋值语句几乎毫不费力, 只需要在函数体第一行加个 = 之后随手发挥就好.

#include <iostream>

int main()
{
    std::cout << "Hello World\n" = std::cerr;
    return 0;
}

当然这份代码会报错但不是因为左值不合理, 而是 --- 赋值操作符被设为私有函数或赋值操作符重载被删除了 (C++11 中).

如果希望的话, 可以进一步参考下面这个操作符重载错乱的例子 (它可能由一位危险的 C++ 实习生在主键盘区 += 坏掉的机器上编写的)

struct type {
    int x;

    type& operator+(type& rhs)
    {
        this.x = rhs.x;
        return *this;
    }

    type& operator=(type& rhs)
    {
        this.x += rhs.x;
        return *this;
    }
};

int main()
{
    type a, b, c;
    a + b = c;
    return 0;
}

所以在 C++ 的世界里, 左值跟赋值运算操作符已经没有半点关系了, 倒是只要类型能够匹配上, 运算符重载就能通过编译, 看起来再离奇的算式都没问题.

不过, 如果非要扯赋值运算符, 它跟其它二元运算符有什么不同?

这差异还确实有, 那就是, 赋值运算符必须是成员非静态的, 也就是说下面的编译无法通过

Posted at Jun 19 2010 - 13:05:49

Permanent Link: /p/85 Load full text

Post tags:

C++
Left Value
Operator Overload

char** 不能赋值给 char const**

C 和 C++ 允许把指向 "某物" 的指针赋值给指向 "不可改变" 的 "某物" 的指针, 如

char* call = "fsck";
char const* call_const = call;

而且, 如果确定不会更改所知向的对象, 那么推荐加上 const, 这是 C++ 的代码编写建议之一. 但是, 要把指向 “某物” 的二级指针赋值给... 见鬼, 简单的说, 下面这种赋值, 任何一个负责任的 C++ 编译器会报出指针不兼容错误:

char* call = "fsck";
char** ptr_to_call = &call;
char const** ptr_const_to_call = ptr_to_call; // error

C/C++ 这样做, 目的其实是在于防范将 char const* 赋值给 char* 的意外行为. 这样说也许很难理解, 那么请看下面这段示例代码

Code Snippet 0-0

char const* CALL = "fsck";

void bind(char const** m)
{
    *m = CALL;
}

int main(void)
{
    char* s;
    bind((char const**)&s); // explicit convert
    s[1] = 'u'; // crash on write
    return 0;
}

在调用 bind 时, 采取强制转换来规避编译错误. 而此时调用 bind 就出现了问题, 它把 char const* 类型的 CALL 变量赋值给了实际上是 char* 的 s, 结果就是在紧接下来的那个赋值中, 程序由于尝试去写只读内存区而崩溃. 有崩溃有真相, 这就是对标题的解答.

另一个类似的例子是, 子类对象的二级指针不能赋值给父类对象的二级指针, 如

Code Snippet 0-1

struct base {};
struct inherit : base {};

void f(void)
{
    inherit** i = NULL;
    base** b = i; // error
}

Posted at Apr 25 2010 - 05:12:33

Permanent Link: /p/83 Load full text

Post tags:

C
C++
const

STL 悲剧之 for_each

这篇文章谈一个我使用 STL 中 for_each 的负面心得. 我对这个东西在当前 C++ 语法下约束是否能广泛使用持有怀疑态度, 至于能否替代所有的 for 循环, 我持完全否定观点! 如果您发现文中提及的这档子事情本质上是我不了解 STL 而自寻死路, 请不吝赐教, 在下方回复, 在下感激不尽.

在 Google 中输入 "for_each" 然后猛击 "I’m feeling lucky", 这时我幸运地跳转到大名鼎鼎的 sgi 的网站里, 页面中有个例子

template<class T> struct print : public unary_function<T, void>
{
    print(ostream& out) : os(out), count(0) {}
    void operator() (T x) { os << x << ' '; ++count; }
    ostream& os;
    int count;
};

int main()
{
    int A[] = {1, 4, 2, 8, 5, 7};
    const int N = sizeof(A) / sizeof(int);

    print<int> P = for_each(A, A + N, print<int>(cout));
    cout << endl << P.count << " objects printed." << endl;
}

从泛型党的视角看来, 这例子非常不错, 完备而规范地演示了 for_each 的用法. 从此泛型党成了大赢家, 除了 for_each 内部, 外面的代码再也不需要 for 这个关键字了.
而那些说写 C++ 代码像谈话一样简短, 基本上泛型编程完全不及格的程序员, 在写上面功能的时候一般会这样做

int main()
{
    int A[] = {1, 4, 2, 8, 5, 7};
    const int N = sizeof(A) / sizeof(int);

    int i;
    for (i = 0; i < N; ++i)
        cout << A[i] << ' ';
    cout << endl << i << " objects printed." << endl;
}

    在喷这个改编版的丑陋之前, 不妨先淡定下来, 想想这个例子到底想做什么, 无非是给个数组 (或者其它什么容器) 把每个成员输出 (或者做个什么其它简单的操作), 并记录被操作的元素个数. 然而, 完成这个操作的代码量与它的功能相比, 臃肿得令人发指. 所以, 在用了几次 for_each 之后, 我完全丧失了当初的激情, 变得极其懒惰, 不愿意把简单的操作抽取到函数外部构造成一个对象然后传递给 for_each; 在维护自己以前写的代码时, 也会偷偷把 for_each 改回 for 循环, 因为有的时候我实在不知道伙伴们把我弄出来的那个函数对象类型给维护到哪里去了.
    当然, 我并不认为这是 for_each, 或者 STL, 或者泛型的错. 在我心目中, 泛型思想是风骚的, for_each 的设计是超前的, 问题出在 C++ 语法这个悲剧帝身上, 或者说, 硬要用 C++ 这个传统的面向过程加面向对象语言的语法来包装对象, 来实现类似高阶函数这种函数式编程中的特性, 是悲剧的根源所在. 不仅是 for_each, 连 find_if 等类似的 STL 函数都差不多一样的下场, 与其构造一个精妙绝伦的函数对象类型, 程序员还不如老老实实写个破循环来得实在.
    一个振奋人心的消息是, C++ 新标准即将发布了, 它会支持闭包对象, 那样的话, for_each 以及其它函数就不会像现在这么处境尴尬了.

Posted at Apr 17 2010 - 13:17:47

Permanent Link: /p/81 Load full text

Post tags:

C++
STL
for_each

STL set 悲剧指导

这篇文章谈一个我使用 STL 中 set 容器的负面心得. 是的, 我已经被这丫的杀得超神了, 快来人阻止它吧! 如果您发现文中提及的这档子事情本质上是我不了解 STL 而自寻死路, 请不吝赐教, 在下方回复, 在下感激不尽.

最坏对数时间插入, 删除, 查询, 迭代遍历, 这些听起来都无比诱人, 它们由 STL 中的 set 容器鼎力支持. 然而, set 的只读制度是非常龌龊的, 简而言之, 只要你敢往这个坑里面放, 你就得接受它们以后再也无法修改的命运. 比如下面这段例子

#include <set>
#include <string>

using std::set;
using std::string;

struct student {
    string name;
    int grade;

    student(string const& name_, int grade_)
        : name(name_)
        , grade(grade_)
    {}

    bool operator<(student const& rhs) const
    {
        return name < rhs.name;
    }

    bool operator==(student const& rhs) const
    {
        return name == rhs.name;
    }
};

int main(void)
{
    set<student> students;
    students.insert(student("Li Lei", 5));
    students.insert(student("Han Meimei", 5));
    students.insert(student("Jim Green", 5));

    for (set<student>::iterator i = students.begin();
         students.end() != i;
         ++i)
    {
        ++(i->grade);
    }
    return 0;
}

    student 类的 key 是 name, 跟 grade 没有关系, 原则上来说, 修改后者并不会破坏 set 的存储结构. 然而, 编译器一棒子打死, 不许改, 除非剩下的成员全部 mutable 修饰.
    只读制度悲剧的根源在于, set 所谓的 key 撑死只是个假象, value_type 这玩意儿就是 key_type 本身.
    伪 key 导致的不仅仅是不能改, 重要的是还不能查! 看看 set::find 函数的参数, 要的又是阴魂不散的 key_type. 这意味着什么? 意味着 Han MM 同学报出她名字的时候, 还查不出她几年级, 而必须要利用她的名字, 伪造一个充气娃娃放进去才能找到! 看到这里我就败了, 这明摆着就是不让我用 set, 让我转投 map 么? 一个也许可行的方案是

#include <map>
#include <string>

using std::map;
using std::string;

struct student_periphery {
    int grade;
};

map<string, student_periphery> students;

这样建模的话也是够狗血的, 如果哪个函数拿着一份 student_periphery 问怎么查出学生姓名, 那就更悲剧了.

Posted at Mar 12 2010 - 08:34:52

Permanent Link: /p/79 Load full text

Post tags:

set
C++
STL

0 1 2 Page 3 4

`std::unique_ptr<`cookbook`>` `std::unique_ptr` 是 C++11 标准的 STL 中, 用来取代 `std::auto_ptr` 的指针容器 (如果在代码中使用了 `std::auto_ptr`, 使用 gcc 4.5 之后的版本加上 `-std=c++0x -Wall` 参数编译时, gcc 会报出警告 `std::auto_ptr` 已经过时). 同 `std::auto_ptr` 一样, `std::unique_ptr` 的基本功效也能当作简单的自动对象管理指针来使用, 如 `#include <memory> /* for std::unique_ptr / #include <iostream> struct echo { echo() { std::cout << "ctor" << std::endl; } ~echo() { std::cout << "dtor" << std::endl; } echo(echo const&) = delete; }; void test() { std::unique_ptr<echo> echo_ptr(new echo); } int main() { test(); std::cout << "." << std::endl; return 0; }` 输出应该如 `ctor dtor .` 类型 `echo` 在构造和析构时的输出信息可以帮助掌握对象的生命周期. 如上述程序中, `echo` 对象在 `test` 函数结束时析构. `std::unique_ptr` 的复制构造函数被 `delete` 处理了, 所以类似下面的代码会出错 `std::unique_ptr<int> a(new int(0)); std::unique_ptr<int> b(a); // ERROR // deleted function // ‘std::unique_ptr<...>::unique_ptr(std::unique_ptr<...> const&)'` 如果确实需要复制一份整数的值, 需要可以做如下操作 `std::unique_ptr<int> b(new int(a));` 而如果是想要将 `a` 所持有的指针转移到 `b` 中, 需要显式调用 `std::move` 将来移交指针控制权 `std::unique_ptr<int> a(new int(0)); std::unique_ptr<int> b(std::move(a));` 此时 `a` 中的指针会变为 `NULL`. 明确的转移语义由 `std::move` 函数表达, 与 `std::auto_ptr` 暧昧的构造函数不同, `std::move` 明确指出 `std::unique_ptr` 对象是通过转移构造进行参数传递的. 当函数需要使用 `std::unique_ptr` 作为参数或返回值时, 可以是如下几种形式 Posted at Mar 13 2011 - 08:34:22 Permanent Link: /p/181 Load full text	Post tags: C++ C++11 unique_ptr Move Semantic Tutorial
C++ 到底怎么使用流来输出对象书上写的做法当然是类似 `struct my_type { void set_x(int xx); void set_y(double yy); my_type(int xx, double yy) : x(xx) , y(yy) {} friend std::ostream& operator<<(std::ostream& os, my_type const&); private: int x; double y; }; std::ostream& operator<<(std::ostream& os, my_type const& m) { return os << m.x << ' ' << m.y; }` 一般使用这样没问题, 不过在想要写得很省略的用况下, 这样就很纠结 `my_type m(10, 20.0); std::stringstream ss; std::string image = (ss << m).str(); // WRONG!` 因为 `operator<<` 返回的类型已经变成没有 `str()` 取得字符串函数的基类 `std::ostream&` 了. 看起来要什么流类型进来什么流类型出才行, 比如 `struct my_type { void set_x(int xx); void set_y(double yy); my_type(int xx, double yy) : x(xx) , y(yy) {} friend template<typename _OS> _OS& operator<<(_OS& os, my_type const&); // WRONG private: int x; double y; }; template <typename _OS> _OS& operator<<(_OS& os, my_type const& m) { os << m.x << ' ' << m.y; return os; }` 不过很遗憾, 泛型函数无法做朋友那要不先把 `my_type` 对象弄成字符串了, 再把字符串输出好了 struct my_type { void set_x(int xx); void set_y(double yy); my_type(int xx, double yy) : x(xx) , y(yy) {} std::string str() const { std::stringstream ss; ss << m.x << ' ' << m.y; return ss.str(); } private: int x; double y; }; template <typename _OS> _OS& operator<<(_OS& os, my_type const& m) // ACTUALLY NOT NEEDED ANY MORE { os << m.str(); return os; } 这看起来多疼啊. 一个可能的方案是, 为每个自定义类型实现 `str()` 成员函数 (有必要的还可以虚一下), 然后全局声明一个 `template <typename _OS, typename _T> _OS& operator<<(_OS& os, _T const& t) { os << t.str(); return os; }` 也许这样会好很多. Posted at Mar 05 2011 - 15:14:50 Permanent Link: /p/177 Load full text	Post tags: C++ Operator Overload Output Stream
C++ 中捕获整数除零错误继承自 C 的优良传统, C++ 也是一门非常靠近底层的语言, 可是实在是太靠近了, 很多问题语言本身没有提供解决方案, 可执行代码贴近机器, 运行时没有虚拟机来反馈错误, 跑着跑着就毫无征兆地崩溃了, 简直比过山车还刺激. 虽然 C++ 加入了异常机制来处理很多运行时错误, 但是异常机制的功效非常受限, 很多错误还没办法用原生异常手段捕捉, 比如整数除 0 错误. 下面这段代码 `#include <iostream> int main() { try { int x, y; std::cin >> x >> y; std::cout << x / y << std::endl; } catch (...) { std::cerr << "attempt to divide integer by 0." << std::endl; } return 0; }` 输入 "1 0" 则会导致程序挂掉, 而那对 try-catch 还呆在那里好像什么事情都没发生一样. 像 Python 一类有虚拟机环境支持的语言, 都会毫无悬念地捕获除 0 错误. 使用信号不过, 底层自然有底层的办法. 这得益于硬件体系中的中断机制. 简而言之, 当发生整数除 0 之类的错误时, 硬件会触发中断, 这时操作系统会根据上下文查出是哪个进程不给力了, 然后给这个进程发出一个信号. 某些时候也可以手动给进程发信号, 比如恼怒的用户发现某个程序卡死的时候果断 kill 掉这个进程, 这也是信号的一种. 这次就不是 C 标准了, 而是 POSIX 标准. 它规定了哪些信号进程不处理也不会有太大问题, 有些信号进程想处理也是不行的, 还有一些信号是错误中断, 如果程序处理了它们, 那么程序能继续执行, 否则直接杀掉. 不过, 这些错误处理默认过程都是不存在的, 需要通过调用 `signal` 函数配置. 方法类似下面这个例子 `#include <csignal> #include <cstdlib> #include <iostream> void handle_div_0(int) { std::cerr << "attempt to divide integer by 0." << std::endl; exit(1); } int main() { if (SIG_ERR == signal(SIGFPE, handle_div_0)) { std::cerr << "fail to setup handler." << std::endl; return 1; } int x, y; std::cin >> x >> y; std::cout << x / y << std::endl; return 0; }` 可以看出, `signal` 接受两个参数, 分别是信号编号和信号处理函数. 成功设置了针对 `SIGFPE` (吐槽: 为什么是浮点异常 `FPE` 呢?) 的处理函数 `handle_div_0`, 如果再发生整数除 0 的惨剧, `handle_div_0` 就会被调用. `handle_div_0` 的参数是信号码, 也就是 `SIGFPE`, 忽略它也行. 底层机制 Posted at Jul 24 2010 - 13:17:37 Permanent Link: /p/100 Load full text	Post tags: POSIX C Exception Handling Signal C++
C++ 转移构造这篇文章中的例子均可在 GCC 4.5.1 版本和 Clang 2.8 版本编译, 在某些较老或优化不尽相同的编译器上, 下面的例程可能并不能获得与文中所述一致的结果. 不过, 这篇文章的重点并非讲述 C++ 中关于复制构造函数的优化, 而是为了说明 C++0x 标准中出现的 Move Semantic 所试图解决的问题之一, 所以对关于复制构造函数的例子有大致理解即可. 重点是, 如果希望完整地编译文中最后一部分中出现的任何 0x 标准相关的代码, 强烈推荐 GCC 4.5.x 版本编译器. 废话少说, 先来一段代码: `#include <iostream> struct cp_ctor_doubling { cp_ctor_doubling(int ii) : i(ii) {} cp_ctor_doubling(cp_ctor_doubling const& rhs) : i(rhs.i * 2) {} int const i; }; cp_ctor_doubling create(int i) { return cp_ctor_doubling(i); } int main() { cp_ctor_doubling c(create(10)); std::cout << c.i << std::endl; return 0; }` 问: 输出多少? A. 10 B. 20 C. 40 D. 以上答案都不正确. 嗯, 也许有得到 B 和 C 的, 得到 D 的同学也许该试着为自己的编译器报个 bug 了, 如果得到 A, 那么恭喜, 您的编译器已经具备对于复制构造函数最基本的优化能力了. C 语言忠实信徒揶揄 C++ 编译器会背着程序员做的 "额外的事情" 时, 历来会想到 C++ 的类复制构造函数. 然而, 现实不仅仅是这样, 编译器还会做出更多额外的事情, 比如把不必要的复制构造函数调用优化掉, 或者更准确地说, 把一些临时对象给优化掉, 于是复制构造函数根本不会被调用到. 如果对上述例子中的编译优化有任何疑虑, 可以尝试下面这段代码 `#include <iostream> struct cp_ctor_not_impl { cp_ctor_not_impl(int ii) : i(ii) {} cp_ctor_not_impl(cp_ctor_not_impl const&); int const i; }; cp_ctor_not_impl create(int i) { return cp_ctor_not_impl(i); } int main() { cp_ctor_not_impl c(create(10)); std::cout << c.i << std::endl; return 0; }` Posted at Jul 17 2010 - 16:27:35 Permanent Link: /p/94 Load full text	Post tags: C++ C++11 Move Semantic Copy Constructor
C++ 中的左值请使用 x86 32位 ArchLinux GCC 4.5.0 环境编译文中 C++ 示例代码, 不过只要是 GCC 或 clang++ 编译结果应该都相仿. 作为一个特别的语言, C++ 中的左值是语义概念而非语法概念, 这一点甚至也可以认为是沿袭自 C 语言. 在任何其他语言中讨论 “什么是左值” 这个概念时, 会简短使用 “变量可以是左值”, “表达式不能是左值”, “常数不能作为左值” 等等, 诸如 “变量”, “表达式”, “常数” 这些都是语法概念, 所以刚才这些说法都是左值的语法约定. 确实一些语言使用语法约束来规定左值, 比如 Python, 下面的 Python 代码 `class A: pass a = A() a + 1 = 0` 编译时会报 “SyntaxError: can’t assign to operator”, 是 Syntax 哦. -甚至连- JS -这样乱的语言-也有类似的例子, 比如 `var f = function() {}; f() = 0;` 在执行的时候会报 "ReferenceError: Invalid left-hand side in assignment" --- Chromium. 在 C 里面表达式, 或者函数的返回值, 或者两者的混合, 只要语法恰当, 返回值类型又是一个可写指针, 那么通过对该指针引用的方式来赋值, 如 `int* f() { return NULL; } (f() + 1) = 0;` 这一特性在 C++ 那放荡不羁的类型系统里得到了极大的加强, 完全不再受制于语法的约束, 编译器只需要先根据运算符优先级搭起语法树, 至于左值判定什么的都留在以后的语义分析再来. 而这一切的开端仅仅是因为 C++ 支持一个指针的替代, 也就是引用, 这样连前缀星号都省略了. 另一方面, C++ 中的运算符重载机制又极大地扩展其左值概念的超凡脱俗, 并且 C++ 程序员似乎从来也未有过 “哦, 这只是个示例程序, 尽量别引入复杂特性” 这样的想法, 即使是经典的 Hello World 程序中, 也毫不吝惜地显摆着运算符重载这种高级特性. `#include <iostream> int main() { std::cout << "Hello, world\n"; }` 从这个例子扩展出一个赋值语句几乎毫不费力, 只需要在函数体第一行加个 `=` 之后随手发挥就好. `#include <iostream> int main() { std::cout << "Hello World\n" = std::cerr; return 0; }` 当然这份代码会报错但不是因为左值不合理, 而是 --- 赋值操作符被设为私有函数或赋值操作符重载被删除了 (C++11 中). 如果希望的话, 可以进一步参考下面这个操作符重载错乱的例子 (它可能由一位危险的 C++ 实习生在主键盘区 `+=` 坏掉的机器上编写的) `struct type { int x; type& operator+(type& rhs) { this.x = rhs.x; return this; } type& operator=(type& rhs) { this.x += rhs.x; return *this; } }; int main() { type a, b, c; a + b = c; return 0; }` 所以在 C++ 的世界里, 左值跟赋值运算操作符已经没有半点关系了, 倒是只要类型能够匹配上, 运算符重载就能通过编译, 看起来再离奇的算式都没问题. 不过, 如果非要扯赋值运算符, 它跟其它二元运算符有什么不同? 这差异还确实有, 那就是, 赋值运算符必须是成员非静态的, 也就是说下面的编译无法通过 Posted at Jun 19 2010 - 13:05:49 Permanent Link: /p/85 Load full text	Post tags: C++ Left Value Operator Overload
`char` 不能赋值给 `char const` C 和 C++ 允许把指向 "某物" 的指针赋值给指向 "不可改变" 的 "某物" 的指针, 如 `char* call = "fsck"; char const* call_const = call;` 而且, 如果确定不会更改所知向的对象, 那么推荐加上 `const`, 这是 C++ 的代码编写建议之一. 但是, 要把指向 “某物” 的二级指针赋值给... 见鬼, 简单的说, 下面这种赋值, 任何一个负责任的 C++ 编译器会报出指针不兼容错误: `char* call = "fsck"; char ptr_to_call = &call; char const ptr_const_to_call = ptr_to_call; // error` C/C++ 这样做, 目的其实是在于防范将 `char const` 赋值给 `char` 的意外行为. 这样说也许很难理解, 那么请看下面这段示例代码 Code Snippet 0-0 `char const* CALL = "fsck"; void bind(char const** m) { m = CALL; } int main(void) { char s; bind((char const*)&s); // explicit convert s[1] = 'u'; // crash on write return 0; }` 在调用 `bind` 时, 采取强制转换来规避编译错误. 而此时调用 `bind` 就出现了问题, 它把 `char const` 类型的 `CALL` 变量赋值给了实际上是 `char` 的 `s`, 结果就是在紧接下来的那个赋值中, 程序由于尝试去写只读内存区而崩溃. 有崩溃有真相, 这就是对标题的解答. 另一个类似的例子是, 子类对象的二级指针不能赋值给父类对象的二级指针, 如 Code Snippet 0-1 `struct base {}; struct inherit : base {}; void f(void) { inherit* i = NULL; base** b = i; // error }` Posted at Apr 25 2010 - 05:12:33 Permanent Link: /p/83 Load full text	Post tags: C C++ const
STL 悲剧之 `for_each` 这篇文章谈一个我使用 STL 中 `for_each` 的负面心得. 我对这个东西在当前 C++ 语法下约束是否能广泛使用持有怀疑态度, 至于能否替代所有的 `for` 循环, 我持完全否定观点! 如果您发现文中提及的这档子事情本质上是我不了解 `STL` 而自寻死路, 请不吝赐教, 在下方回复, 在下感激不尽. 在 Google 中输入 `"for_each"` 然后猛击 "I’m feeling lucky", 这时我幸运地跳转到大名鼎鼎的 sgi 的网站里, 页面中有个例子 template<class T> struct print : public unary_function<T, void> { print(ostream& out) : os(out), count(0) {} void operator() (T x) { os << x << ' '; ++count; } ostream& os; int count; }; int main() { int A[] = {1, 4, 2, 8, 5, 7}; const int N = sizeof(A) / sizeof(int); print<int> P = for_each(A, A + N, print<int>(cout)); cout << endl << P.count << " objects printed." << endl; } 从泛型党的视角看来, 这例子非常不错, 完备而规范地演示了 `for_each` 的用法. 从此泛型党成了大赢家, 除了 `for_each` 内部, 外面的代码再也不需要 `for` 这个关键字了. 而那些说写 C++ 代码像谈话一样简短, 基本上泛型编程完全不及格的程序员, 在写上面功能的时候一般会这样做 `int main() { int A[] = {1, 4, 2, 8, 5, 7}; const int N = sizeof(A) / sizeof(int); int i; for (i = 0; i < N; ++i) cout << A[i] << ' '; cout << endl << i << " objects printed." << endl; }` 在喷这个改编版的丑陋之前, 不妨先淡定下来, 想想这个例子到底想做什么, 无非是给个数组 (或者其它什么容器) 把每个成员输出 (或者做个什么其它简单的操作), 并记录被操作的元素个数. 然而, 完成这个操作的代码量与它的功能相比, 臃肿得令人发指. 所以, 在用了几次 `for_each` 之后, 我完全丧失了当初的激情, 变得极其懒惰, 不愿意把简单的操作抽取到函数外部构造成一个对象然后传递给 `for_each`; 在维护自己以前写的代码时, 也会偷偷把 `for_each` 改回 `for` 循环, 因为有的时候我实在不知道伙伴们把我弄出来的那个函数对象类型给维护到哪里去了. 当然, 我并不认为这是 `for_each`, 或者 STL, 或者泛型的错. 在我心目中, 泛型思想是风骚的, `for_each` 的设计是超前的, 问题出在 C++ 语法这个悲剧帝身上, 或者说, 硬要用 C++ 这个传统的面向过程加面向对象语言的语法来包装对象, 来实现类似高阶函数这种函数式编程中的特性, 是悲剧的根源所在. 不仅是 `for_each`, 连 `find_if` 等类似的 STL 函数都差不多一样的下场, 与其构造一个精妙绝伦的函数对象类型, 程序员还不如老老实实写个破循环来得实在. 一个振奋人心的消息是, C++ 新标准即将发布了, 它会支持闭包对象, 那样的话, `for_each` 以及其它函数就不会像现在这么处境尴尬了. Posted at Apr 17 2010 - 13:17:47 Permanent Link: /p/81 Load full text	Post tags: C++ STL for_each
STL `set` 悲剧指导这篇文章谈一个我使用 STL 中 `set` 容器的负面心得. 是的, 我已经被这丫的杀得超神了, 快来人阻止它吧! 如果您发现文中提及的这档子事情本质上是我不了解 STL 而自寻死路, 请不吝赐教, 在下方回复, 在下感激不尽. 最坏对数时间插入, 删除, 查询, 迭代遍历, 这些听起来都无比诱人, 它们由 STL 中的 `set` 容器鼎力支持. 然而, `set` 的只读制度是非常龌龊的, 简而言之, 只要你敢往这个坑里面放, 你就得接受它们以后再也无法修改的命运. 比如下面这段例子 #include <set> #include <string> using std::set; using std::string; struct student { string name; int grade; student(string const& name_, int grade_) : name(name_) , grade(grade_) {} bool operator<(student const& rhs) const { return name < rhs.name; } bool operator==(student const& rhs) const { return name == rhs.name; } }; int main(void) { set<student> students; students.insert(student("Li Lei", 5)); students.insert(student("Han Meimei", 5)); students.insert(student("Jim Green", 5)); for (set<student>::iterator i = students.begin(); students.end() != i; ++i) { ++(i->grade); } return 0; } `student` 类的 key 是 `name`, 跟 `grade` 没有关系, 原则上来说, 修改后者并不会破坏 `set` 的存储结构. 然而, 编译器一棒子打死, 不许改, 除非剩下的成员全部 `mutable` 修饰. 只读制度悲剧的根源在于, `set` 所谓的 key 撑死只是个假象, `value_type` 这玩意儿就是 `key_type` 本身. 伪 `key` 导致的不仅仅是不能改, 重要的是还不能查! 看看 `set::find` 函数的参数, 要的又是阴魂不散的 `key_type`. 这意味着什么? 意味着 Han MM 同学报出她名字的时候, 还查不出她几年级, 而必须要利用她的名字, 伪造一个充气娃娃放进去才能找到! 看到这里我就败了, 这明摆着就是不让我用 `set`, 让我转投 `map` 么? 一个也许可行的方案是 `#include <map> #include <string> using std::map; using std::string; struct student_periphery { int grade; }; map<string, student_periphery> students;` 这样建模的话也是够狗血的, 如果哪个函数拿着一份 `student_periphery` 问怎么查出学生姓名, 那就更悲剧了. Posted at Mar 12 2010 - 08:34:52 Permanent Link: /p/79 Load full text	Post tags: set C++ STL
0 1 2 Page 3 4

	Back to Bit Focus
	NijiPress - Copyright (C) Neuron Teckid @ Bit Focus
	About this site

Bit Focus

使用信号

底层机制