因此，在这里，我试图理解协程的新的复杂概念。为此，用Clang进行编译clang++ -std=c++17 -fcoroutines-ts -stdlib=libc++就可以了。
task<>协程类型是最有用的概念之一，在这里提到了它，甚至有一些有趣的实现，它们由Gor Nishanov和cppcoro库提供。
好吧，在最简单的情况下尝试自己看起来不错。因此，目标是实施应如下所示的工作方式：
{
auto producer = []() -> task<int> {
co_return 1;
};
auto t = producer();
assert(!t.await_ready());
assert(t.result() == 1);
assert(t.await_ready());
}
模板类task<>本身变得非常简单：
#pragma once
#include <experimental/coroutine>
#include <optional>
namespace stdx = std::experimental;
template <typename T=void>
struct task
{
template<typename U>
struct task_promise;
using promise_type = task_promise<T>;
using handle_type = stdx::coroutine_handle<promise_type>;
mutable handle_type m_handle;
task(handle_type handle)
: m_handle(handle)
{}
task(task&& other) …我正在尝试改进YML文件中描述的项目构建脚本，这种改进本身似乎微不足道，但是不小心破坏自动构建的想法使我有些害怕。
现在，项目中有几个分支，版本标签和其他内容。
可以使用不是由跑步者构建的开发分支，因为以某种方式在虚拟机之间复制大型项目以在不同平台上测试构建并不方便。因此，我想从构建中排除一些“ prj-dev”分支。
我们有：
stages:
- build
- linuxbuild
job:
tags:
- win2008build
stage: build
script:
# something complex
job1:
tags:
- linux
stage: linuxbuild
script:
# something else complex
我用Google搜索，发现了一个解决方案，例如：
stages:
- build
- linuxbuild
job:
tags:
- win2008build
branches:
except:
- *dev-only
但是似乎我们的管道是完全不同的，标签不是git标签，它们是管道标签。因此，我正在考虑使用如下配置：
stages:
- build
- linuxbuild
job:
tags:
- win2008build
except:
branches:
- *dev-only
...这意味着“像往常一样构建，而不是我的分支”。尝试这两种方法都有一定的复杂性，我很确定有人肯定会知道该食谱。
因此，如果您愿意，-如何在不更改管道的情况下排除我的dev分支，仅配置？有可能吗？
我对 Qt 和 pimpl 的问题实际上不是问题，而是对最佳实践建议的请求。
所以：我们有一个相当大的项目，有很多 GUI 和其他 Qt 类。良好的协作需要标头的可读性，减少编译时间也是经常考虑的问题。
因此，我有很多课程，例如：
class SomeAwesomeClass: public QWidget
{
Q_OBJECT
public:
/**/
//interface goes here
void doSomething();
...
private:
struct SomeAwesomeClassImpl;
QScopedPointer<SomeAwesomeClassImpl> impl;
}
当然，Pimpl 类在 .cpp 文件中，工作正常，例如：
struct MonitorForm::MonitorFormImpl
{
//lots of stuff
}
这个软件应该是跨平台的（这并不奇怪）并且无需大量工作即可交叉编译。我知道 Q_DECLARE_PRIVATE、Q_D 和其他宏，它们让我更多地考虑 Qt MOC，Qt 版本中可能存在的差异（由于遗留代码），但是这样或那样的方式有很多行代码 contatinig 之类的
impl->ui->component->doStuff();
//and
impl->mSomePrivateThing->doOtherStuff()
//and even
impl->ui->component->SetSomething(impl->mSomePrivateThing->getValue());
上面的伪代码是真实代码的简化版本，但我们大多数人都可以接受。但一些同事坚持认为，编写和阅读所有这些长行相当麻烦，尤其是在impl->ui->mSomething->重复过于频繁的情况下。意见指出，Qt marcos 最终也为这种情况添加了视觉垃圾。Seversl#define可以提供帮助，但这些通常被认为是不好的做法。
简而言之，根据您的经验，有没有办法让 pimpl 使用更简洁？例如，在非图书馆课程中，也许并不像看起来那样经常需要它？也许它的使用目标不一样，取决于情况？
无论如何，正确的烹饪方法是什么？
嗯，我的目标很简单——尝试使用打包/交错的 BGR 数据（也可以是 RGB）从缓冲区创建 JPEG 编码图像。
NVidia 文档包含一个示例，此处基本上描述了正确的图像输入。
所以我尝试了以下方法：
#include <nvjpeg.h>
// very simple
typedef struct {
int width;
int height;
unsigned char *buffer;
unsigned long data_size;
} my_bitmap_type;
std::vector<unsigned char> BitmapToJpegCUDA(const my_bitmap_type *image)
{
nvjpegHandle_t nv_handle;
nvjpegEncoderState_t nv_enc_state;
nvjpegEncoderParams_t nv_enc_params;
cudaStream_t stream = NULL;
nvjpegStatus_t er;
nvjpegCreateSimple(&nv_handle);
nvjpegEncoderStateCreate(nv_handle, &nv_enc_state, stream);
nvjpegEncoderParamsCreate(nv_handle, &nv_enc_params, stream);
nvjpegImage_t nv_image;
nv_image.channel[0] = image->buffer;
nv_image.pitch[0] = 3 * image->width;
// Nope, that's for planar images!
// nv_image.channel[0] = image->buffer;
// nv_image.channel[1] = …我的同事给我做了一个“小测验”，他让他的学生解决了一次。似乎我虚弱的头脑无法理解现代C ++功能的所有美妙之处。
主题：
实现一个join函数，接受任意函子并返回与它们中的任何一个一样的函子。例如：
{
auto result = std::visit(custom::join(
[](std::string const& s) { return "it's a string"; },
[](std::pair<int, int> const& p) { return "it's a pair"; }
), var);
assert(result == "it's a string");
var = std::make_pair(10, 20);
auto lvalue_lambda = [](std::string const& s) { return "it's a string"; };
result = std::visit(custom::join(
lvalue_lambda,
[](std::pair<int, int> const& p) { return "it's a pair"; }
), var);
assert(result == "it's a pair");
}
好吧，经过一番思考，我明白了这个想法，std::variant就“类型安全的联合”而言，这意味着“列出的一个”，因此我需要一个元组。尝试过这样的事情：
namespace custom …