OWenT's blog
  • Introduction
  • About Me
  • 2020
    • 近期对libatapp的一些优化调整(增加服务发现和连接管理,支持yaml等)
    • xresloader转表工具链增加了一些新功能(map,oneof支持,输出矩阵,基于模板引擎的加载代码生成等)
    • 在游戏服务器中使用分布式事务
    • libcopp接入C++20 Coroutine和一些过渡期的设计
    • libatbus 的大幅优化
    • nftables初体验
    • 容器配置开发环境小计
  • 2019
    • PALM Tree - 适合多核并发架构的B+树 - 论文阅读小记
    • 跨平台协程库 - libcopp 简介
    • C++20 Coroutine 性能测试 (附带和libcopp/libco/libgo/goroutine/linux ucontext对比)
    • 尝鲜Github Action
    • 一些xresloader(转表工具)的改进
    • protobuf、flatbuffer、msgpack 针对小数据包的简单对比
    • 协程框架(libcopp) 小幅优化
    • Excel转表工具(xresloader) 增加protobuf插件功能和集成 UnrealEngine 支持
    • Anna(支持任意扩展和超高性能的KV数据库系统)阅读笔记
    • C++20 Coroutine
    • libcopp merge boost.context 1.69.0
    • Google去中心化分布式系统论文三件套(Percolator、Spanner、F1)读后感
    • Rust玩具-企业微信机器人通用服务
  • 2018
    • 使用ELK辅助监控开发测试环境服务质量和问题定位
    • Webpack+vue+boostrap+ejs构建Web版GM工具
    • 2018年的新通用伪随机数算法(xoshiro / xoroshiro)的C++(head only)实现
    • Rust的第二次接触-写个小服务器程序
    • 理解和适配AEAD加密套件
    • atsf4g-co的进化:协程框架v2、对象路由系统和一些其他细节优化
    • 协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比
    • 可执行文件压缩
    • 初识Rust
    • 使用restructedtext编写xresloader文档
    • atframework的etcd模块化重构
    • C++的backtrace
  • 2017
    • ECDH椭圆双曲线(比DH快10倍的密钥交换)算法简介和封装
    • protobuf-net的动态Message实现
    • pbc的proto3接入
    • atgateway内置协议流程优化-加密、算法协商和ECDH
    • 整理一波软件源镜像同步工具+DevOps工具
    • Blog切换到Hugo
    • libcopp v2的第一波优化完成
    • libcopp(v2) vs goroutine性能测试
    • libcopp的线程安全、栈池和merge boost.context 1.64.0
    • GCC 7和LLVM+Clang+libc++abi 4.0的构建脚本
    • libatbus的几个藏得很深的bug
    • 用cmake交叉编译到iOS和Android
    • 开源项目得一些小维护
    • atapp的c binding和c#适配
    • 对象路由系统设计
    • 2016年总结
    • 近期的一个协程流程BUG
  • 2016
    • 重写了llvm+clang+libc++和libc++abi的构建脚本
    • atsf4g完整游戏工程示例
    • atframework基本框架已经完成
    • 游戏服务器的不停服更新
    • 对atbus的小数据包的优化
    • Android和IOS的TLS问题
    • pbc的一个陈年老BUG
    • boost.context-1.61版本的设计模型变化
    • 接入letsencrypt+全面启用HTTP/2
    • 理解Raft算法
    • libatbus基本功能及单元测试终于写完啦
    • 博客文章和文档迁移到gitbook
  • 2015
    • 博客文章和文档迁移到gitbook
    • 给客户端写得LRU缓存
    • 近期活动比较零散
    • 关于BUS通信系统的一些思考(三)
    • 针对Java JIT的优化(转表工具:xresloader)
    • libcopp更新 (merge boost 1.59 context)
    • 小记最近踩得两个C++坑
    • Redis全异步(HA)Driver设计稿
    • Vim常用命令
    • 关于firewalld和systemd的一些命令速记
    • Jenkins(hudson)插件记录
    • 我们的Lua类绑定机制
    • LLVM+Clang+Libcxx+Libcxxabi(3.6)工具链编译(完成自举编译)
    • 回顾2014
    • Android NDK undefined reference to ___tls_get_addr 错误
    • gitlab腾讯企业邮箱配置
  • 2014
    • 回顾2013
    • C++11动态模板参数和type_traits
    • C++又一坑:动态链接库中的全局变量
    • tolua++内存释放坑
    • [转]类似github的框架
    • Lua性能分析
    • 集成Qt Webkit 到cocos2d-x
    • Gitlab环境搭建小计
    • 近期研究VPN的一些记录(OpenVPN,pptp,l2tp)
    • LLVM + Clang + Libcxx + Libcxxabi 工具链编译
    • 关于BUS通信系统的一些思考(二)
    • 关于BUS通信系统的一些思考(一)
    • [libiniloader] Project
    • 记录一些在线编辑器
    • [WP Code Highlight.js] Project
    • 再议 C++ 11 Lambda表达式
    • 基于Chrome插件的开发工具链
    • [ACM] HDU 1006 解题报告
    • Linux 编译安装 GCC 4.9
    • 又碰到了这个解谜游戏,顺带记下地址
    • 简单C++单元测试框架(支持一键切到GTest或Boost.Test)
    • 捣鼓一个协程库
  • 2013
    • std和boost的function与bind实现剖析
    • 不知道是哪一年的腾讯马拉松题目 照片评级 解题报告
    • Lua 挺好用的样子
    • VC和GCC成员函数指针实现的研究(三)
    • VC和GCC成员函数指针实现的研究(二)
    • VC和GCC内成员函数指针实现的研究(一)
    • 一个C++关于成员变量偏移地址的小Trick
    • ptmalloc,tcmalloc和jemalloc内存分配策略研究
    • POJ 2192 Zipper HDU 2059 龟兔赛跑
    • 从Javascript到Typescript到Node.js
    • 网络编程小结
    • 试试Boost.Asio
    • Lnmp yum 安装脚本 (for CentOS)
    • ARM 交叉编译环境搭建
    • Linux 编译安装 GCC 4.8
    • [记录]虚拟硬盘的压缩|磁盘写零
  • 2012
    • Boost.Spirit 初体验
    • “C++的90个坑”-阅读笔记
    • AC自动机
    • C++ 标准过渡期
    • 程序员修炼之道 -- 阅读笔记
    • [转载]狼与哈士奇
    • C++ 新特性学习(八) — 原子操作和多线程库[多工内存模型]
    • C++ 新特性学习(七) — 右值引用
    • 理解Protobuf的数据编码规则
    • 忆往昔ECUST的ACM时代
    • Linux编译安装GCC 4.7
    • JSON显示库 -- showJson (Javascript)
    • C++ 新特性学习(六) — 新的字符串编码和伪随机数
    • C++ 新特性学习(五) — 引用包装、元编程的类型属性和计算函数对象返回类型
    • C++ 新特性学习(四) — Bind和Function
  • 2011
    • C++ 新特性学习(三) — Regex库
    • C++ 新特性学习(二) -- Array、Tuple和Hash库
    • C++ 新特性学习(一) -- 概述+智能指针(smart_ptr)
    • Linux 和 Windows PowerShell 常用工具/命令 记录
    • 非常帅气的Linq to sql
    • 2011 Google Code Jam 小记
    • C++总是很神奇
    • 大学生创新项目[国家级]经费使用记录
    • 常用官方文档整理
    • 我们学校的IPV6很不错嘛
  • 2010
    • 线段树相关问题 (引用 PKU POJ题目) 整理
    • 2010 ACM 赛前笔记
    • POJ PKU 2596 Dice Stacking 解题报告
    • POJ PKU 3631 Cuckoo Hashing 解题报告
    • POJ PKU 1065 Wooden Sticks 3636 Nested Dolls 解题报告
    • HDU 3336 Count the string 解题报告
    • Hash模板 个人模板
    • ZOJ 3309 Search New Posts 解题报告
    • POJ PKU Let's Go to the Movies 解题报告
    • 注册表常用键值意义
    • PKU POJ 1724 ROADS 解题报告
    • 《神奇古今秘方集锦》&《民间秘术大全》
    • PKU POJ 1720 SQUARES 解题报告
    • POJ PKU 2155 Matrix 解题报告
    • PKU POJ 1141 Brackets Sequence 解题报告
    • PKU POJ 2728 Desert King 解题报告
    • PKU POJ 2976 Dropping tests 解题报告
    • PKU POJ 3757 Simple Distributed storage system 解题报告
    • GCD Determinant 解题报告
    • Southeastern European 2008 Sky Code 解题报告
    • HDU HDOJ 3400 Line belt 解题报告
    • 线性筛法求质数(素数)表 及其原理
    • HDU HDOJ 3398 String 解题报告
    • 树状数组模块(个人模板)
    • 浙江理工 省赛总结 team62 By OWenT of Coeus
    • POJ PKU 3659 Cell Phone Network 解题报告
    • USACO 2008 March Gold Cow Jogging 解题报告
    • C#格式化输出(记录)
    • 参加有道难题笔记
    • POJ PKU 2446 Chessboard 解题报告
    • POJ PKU 1986 Distance Queries 解题报告
    • 计算几何算法概览[转载]
    • 关于差分约束(转载)
    • POJ PKU 2826 An Easy Problem?! 解题报告
    • 数论模板(个人模板)
    • 简易四则运算(ACM个人模板)
    • Catalan 数
    • The 35th ACM/ICPC Asia Regional Tianjin Site —— Online Contest 1009 Convex 解题报告
    • JQuery扩展插件--提示信息
    • ACM 计算几何 个人模板
    • 解析网站字符串型参数 Javascript QueryString 操作 TQueryString类
    • POJ PKU 1474 Video Surveillance 解题报告
  • 2009
    • 模式匹配(kmp)个人模板
    • 并查集 模板
    • POJ 3267 The Cow Lexicon 解题报告
    • C/C++语言常用排序算法
    • POJ 2606 Rabbit hunt 2780 Linearity 1118 Lining Up 解题报告
    • 打造最快的Hash表(转) [以暴雪的游戏的Hash为例]
    • ECUST 09年 校赛个人赛第六,七场总结
    • ECUST 09年 校赛个人赛第三场部分解题报告(A,D,F,I)
    • 牛顿迭代解方程 ax^3+bX^2+cx+d=0
    • 09年8月9日 ECUST ACM 练习赛总结
    • 连接最多点直线 (OWenT 个人模板)
    • 点到直线距离 和 线段间最短距离 (OWenT 模板)
    • ECUST 09年 校赛个人训练赛第五场总结
    • ECUST 09年 校赛个人赛第八场(最后一场)总结
    • 09年8月14日 ECUST ACM 练习赛总结
    • 矩阵相关 (增强中)
    • Prime最小生成树(个人模板)
    • 最长单调子序列 复杂度nlog(n)
    • POJ PKU 2549 Sumsets 解题报告
    • POJ PKU 3277 City Horizon 解题报告
    • 我的ACM生涯
    • POJ PKU 2528 Mayor's posters 解题报告
    • POJ PKU 2378 Tree Cutting 解题报告
    • POJ PKU 1990 MooFest 解题报告
Powered by GitBook
On this page
  • 目录
  • C++ 的Lambda表达式
  • 语法规则
  • 类型
  • 为什么要关心lambda表达式的类型
  • 类型推断和Lambda表达式
  • 利用C++11 decltype关键字适配Lambda表达式
  • 不使用C++11 decltype关键字的适配方案?
  • 写在最后

Was this helpful?

  1. 2014

再议 C++ 11 Lambda表达式

Previous[WP Code Highlight.js] ProjectNext基于Chrome插件的开发工具链

Last updated 6 years ago

Was this helpful?

目录

C++ 的Lambda表达式

C++ 11 标准发布,各大编译器都开始支持里面的各种新特性,其中一项比较有意思的就是lambda表达式。

语法规则

C++ 11 Lambda表达式的四种声明方式

  1. [ capture ] ( params ) mutable(optional) exception attribute -> ret { body }

  2. [ capture ] ( params ) -> ret { body }

  3. [ capture ] ( params ) { body }

  4. [ capture ] { body }

  5. capture是外部引用的参数

  6. params是函数参数

  7. 后面可以跟一些函数修饰符

  8. ret是返回值类型,如果不指定,会推断一个类型

  9. body部分是函数内容

    具体用法可以参照,这里就不复述了

这四个声明式都会返回一个匿名的仿函数实例)。 这里有一个比较重要的一点,就是他是一个仿函数实例,而不是直接一个函数。

类型

我们可以通过一个简单的示例来看它的类型。

#include <cstdio>
#include <typeinfo>

int main(){
    auto f1 = [](int, char*){
        return 0;
    };

    typedef int (*f_t)(int, char*);

    auto f2 = [](int, char*) {
        return 1;
    };

    f_t f3 = f2;

    puts(typeid(f1).name());
    puts(typeid(f2).name());
    puts(typeid(f3).name());
    return 0;
}

上面的结果在GCC里输出

Z4mainEUliPcE_

Z4mainEUliPcE0_

PFiiPcE

在clang(with -stdlib=libc++)中输出

Z4mainE3$_1

Z4mainE3$_0

PFiiPcE

在VC12中输出

class <lambda_215c4a8550380ee3200a8b722b5d538b>

class <lambda_cb3f26d0aaec1026a36e541fdceeb301>

int (cdecl)(int,char ptr64)

可见,在不同的编译器中是可以有不同的命名方式的,并且对每一个不同的函数体(body部分)都会有一个特定的类型。 而它实现了转换成普通函数的接口,故而 f_t f3 = f2; 这一行得以执行成功。 而如果我们把代码稍微修改一下:

#include <cstdio>
#include <typeinfo>

int main(){
    int m = 0;
    auto f1 = [](int, char*){
        return 0;
    };

    typedef int (*f_t)(int, char*);

    auto f2 = [&](int x, char*) {
        m += x;
        return 1;
    };

    f_t f3 = f2;

    puts(typeid(f1).name());
    puts(typeid(f2).name());
    puts(typeid(f3).name());

    f3(2, 0);
    return 0;
}

这时候编译的时候会报错。 t.cpp: In function ‘int main()’: t.cpp:17:14: error: cannot convert ‘main()::lambda1’ to ‘f_t {aka int ()(int, char)}’ in initialization f_t f3 = f2; ^ 类型转换失败,这段示例和上面不同的是这次指定了要传入m的引用类型到f2中,然而普通函数f3是不接受外部引用的。 这其实很好理解。在构建f2的时候m的引用包装可以作为仿函数的成员记录下来,也就是说。这里的main()::lambda1可以是这样:

class __lambda1 {
private:
    int &m;

public:
    __lambda1(int &m_):m_(m){}
    int operator()(int x, char*) {
        m += x;
        return 1;
    }
};

简单地说,可以理解为编译器自动生成了这个class,然后赋值给f2,然而普通函数f3无法由这个functor转换而来,因为没有地方放置这个m的引用。 如果有兴趣的话可以把f2和f1的size打印出来,f2一定比f1大。一般情况下f2比f1大一个指针的大小。加上考虑到c++的地址规则(保证空对象的地址不会和其他的变量混用,所以空对象的size会被补齐到1Byte),f2也可能比f1大一个指针的大小再减一个字节(32位架构下相差3字节,64位架构下相差7字节)

为什么要关心lambda表达式的类型

这个麻烦起源于对任务系统的一个接口设计。 我们先来看看微软PPL库的线程任务系统的一个有意思的接口。

task<StorageFile^> t1(createOp);

t1.then([_this](StorageFile^ resultOp){
    _this->m_VideoStorage = resultOp;
    return _this->m_MediaCaptureMgr->StartRecordToStorageFileAsync(_this->m_EncodingProfile, _this->m_VideoStorage);
}).then ([_this](){
   _this->m_recordState = true;
   _this->btnRecording->Content = "Stop Recording";

});

这段代码摘自MSDN的一个示例,主要注意有一个then函数,它是创建一个任务并在执行完这个任务后继续执行。 但是它这里有一点比较重要的是,它的task必须指定返回值且必须返回类型一致。

// create a task using lambda expression
my_task_t::ptr_t first_task = my_task_t::create([&](){
    puts("|first task running...");
    printf("test code already reset => %d\n", ++ test_code);
    return 0;
});

// add many next task using lambda expression
first_task->next([=](){
    puts("|second task running...");
    printf("test code should be inited 128 => %d\n", test_code);
    return 0;
})->next([&](){
    puts("|haha ... this is the third task.");
    printf("test code is the same => %d\n", ++ test_code);
    return 0;
})->next([&](){
    puts("|it's boring");
    printf("test code is %d\n", ++ test_code);
    return 0;
});
// 这里不再列举出next传入task、action、函数、仿函数和成员函数的情况。

于是有了如下接口:

/** next接口:类似ppl的then接口 **/

// 接受task指针
ptr_t next(ptr_t next_task);
// 接受task action对象
ptr_t next(action_ptr_t action, size_t stack_size);
// 接受仿函数及lambda表达式
template<typename Ty>
ptr_t next(Ty functor, size_t stack_size);
// 接受普通函数
template<typename Ty>
ptr_t next(Ty (*func)(), size_t stack_size);
// 接受成员函数且必须使用类实例绑定
template<typename Ty, typename TInst>
ptr_t next(Ty (TInst::*func), TInst* instance, size_t stack_sizei);

/** 对于action的类型分支时 **/
// functor
template<typename Ty>
class task_action_functor: public impl::task_action_impl;

// function
template<typename Ty>
class task_action_function: public impl::task_action_impl;

template<>
class task_action_function<int>: public impl::task_action_impl;

// mem function
template<typename Ty, typename Tc>
class task_action_mem_function: public impl::task_action_impl;

template<typename Tc>
class task_action_mem_function<int, Tc>: public impl::task_action_impl;

利用模板特化或偏特化实现在next函数传入不同类型对象时,构建不同的task action,以实现不同函数返回值的不同处理。 但是对于仿函数,暂时我还没有找到一个跨平台并且兼容所有主流编译器并能在不使用C++ 11的decltype关键字并在编译期对其operator()()的返回值不同而产生差异化的完美的方案。(这里如果哪位大神如果有比较简单的解决方案可以指导一下,感激不尽)

这也是上面使用lambda表达式作为next函数的参数时,必须有一行return 0;的原因。需要让lambda表达式自动推断返回类型位int型。

也许这也是ppl库必须指定task返回值的原因。

类型推断和Lambda表达式

lambda难以处理返回值,究其原因主要是无返回值和有返回值时的行为差异。 比如上面的例子中,可以加一个代理返回值的函数来处理返回值差异。比如:

template<typename Tr>
int func(Tr ret) {
    return 0;
}
template<>
int func(int ret) {
    return ret;
}

// === 调用 ===
auto f = [](){
    // ... any code
    return ...;
}

int ret = func(f());

这个函数在ret传入int型时返回lambda函数返回的int,否则返回0。然而如果lambda表达式没有返回值,就比较难处理了。 因为不能出现类似

template<>
int func(void) {
    return 0;
}

这样的语法。但是前文说过,在不使用decltype时这个问题很难解决,那么如果使用decltype如何实现呢?

利用C++11 decltype关键字适配Lambda表达式

直接上代码吧

#include <cstdio>
#include <typeinfo>

template<typename Tr>
struct func {
    template<typename Tf>
    int operator()(Tf& f) {
        f();
        return -1;
    }
};

template<>
struct func<int>{

    template<typename Tf>
    int operator()(Tf& f) {
        return f();
    }
};

template<>
struct func<void> {
    template<typename Tf>
    int operator()(Tf& f) {
        f();
        return 1;
    }
};


int main() {

    auto f1 = [](){
        puts("Hello");
    };

    auto f2 = [](){
        puts("Hello");
        return 100;
    };

    auto f3 = [](){
        puts("Hello");
        return "hahaha";
    };

    int ret = 0;

    ret = func<decltype(f1())>()(f1);
    printf("fn %s, ret %d\n", typeid(f1).name(), ret);

    ret = func<decltype(f2())>()(f2);
    printf("fn %s, ret %d\n", typeid(f2).name(), ret);

    ret = func<decltype(f3())>()(f3);
    printf("fn %s, ret %d\n", typeid(f3).name(), ret);

    return 0;
}

这段代码分别适配了lambda表达式无返回值的,返回值类型是int的和反回值类型是const char*的。基本覆盖了前面提到的各种情况。 究其原因,就是decltype可以在不执行表达式的情况下判定表达式的返回值。 那么不使用decltype要实现这个功能思路就很清晰了,利用type_traits技术或者编译器功能来获取表达式类型。

不使用C++11 decltype关键字的适配方案?

对于GCC和Clang编译器,所幸有个typeof关键字。 对于VC编译器就比较悲剧了,还好VS2010以上版本已经支持decltype。

当然还有一些比较绕的方法,可以通过手工注册一些信息来标识类型,但是这些方法个人感觉并不是很完美,这里就不列举了。

写在最后

写这篇文章主要是对近期碰到的这个lambda表达式行为的一些总结和记录。当可以全线使用C++11特性的时候这些问题都不复存在。但是在现在这个过渡时期,大多生产环境用得都是很低版本的编译器,还不支持C++11的这些特性。而这个时候需要开发出兼容老编译器又支持一些高级特性的组件和库就尤其麻烦。 希望C+11普及的那一天早日到来吧。

为什么要关心lambda表达式的类型呢?这关系到一些兼容型api的实现。 首先,如果用std::function绑定lambda表达式,它会走仿函数的执行流程,而不是函数的。(关于std::function实现原理可以参照: ) 其次,是因为我在设计之前的的API的时候,碰上了一些麻烦。

而在我这里的任务接口里,我希望的是统一有一个int型的返回值(仿照进程执行结果只返回一个int型)。并且如果task的action函数是一个int型返回值的,接受它成为task返回码,否则使用默认的0作为返回值。 目标是使其支持类似如下形式的调用:(参见: )

C++文档
std和boost的function与bind实现剖析
协程任务框架
https://github.com/owt5008137/libcopp/blob/master/sample/sample_task_with_lambda.cpp