Personal channel of @lancern

Topics: programming, hacking, memes, life, and more. Forward anything as you wish.

Join the discussion group for more fun.

Discord: https://discord.gg/RwUx9et7
Borrow Checking, RC, GC, and the Eleven () Other Memory Safety Approaches https://verdagon.dev/grimoire/grimoire
今日修水管

最近一两周发现家里的水压出奇地低。我住在一栋电梯楼内的三层,照理水压不应该低。刚开始以为是市政供水的问题,但低水压情况持续了好几天没有缓解。遂前往我所在楼层的水表间尝试定位并修复该问题。

在家中水龙头全部关闭的情况下,水表没有走表。这说明家庭管路内没有漏水等情况。

我所在楼层共有四户住户,四根入户水管以并联形式直接连接到单元楼内的一根主供水管道上。在邻居用水时观察邻居的水表走表情况,发现其走表速度明显高于我用水时的走表速度。说明问题出在我家的入户水管上。这一小段入户水管上有且仅有水表以及三个阀门。这四个设备按照从上游到下游排列分别为:阀门 A、阀门 B、阀门 C 和水表。其中阀门 A 和阀门 C 上直接有可供手拧的阀门开关。尝试分别将这两个阀门拧到最大,但问题并没有消失。于是将注意力集中于阀门 B 。

阀门 B 上没有可供手拧的开关,有且仅有一个螺栓和一个压力表。经检查,在不用水时,该压力表显示读数与邻居的压力表读数一致。该读数应该就是单元楼主供水管道内的压力值。在用水时,我家的压力表读数为 0,而在邻居用水时其压力表读数并不为 0 。

上网查阅相关资料可知,阀门 B 是一个减压阀,相关资料指出减压阀上的螺栓可用于调节输出压力。遂翻出扳手等工具相应调节减压阀的螺栓。经过反复调节后,家中的水压恢复了正常。因此问题的原因是我家的减压阀因某种原因被拧了。
2024 年 4 月 Tokyo 会议后一些频道主认为有意思的 C++ 标准提案

P1061R8: Structured Bindings can introduce a Pack
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p1061r8.html

允许结构化绑定引入 pack :

std::tuple<X, Y, Z> f();

auto [...xs] = f();           // OK
auto [x, ...rest] = f();      // OK
auto [x,y,z, ...rest] = f();  // OK
auto [x, ...rest, z] = f();   // OK


P2034R3: Partially Mutable Lambda Captures
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2034r3.pdf

允许分别将每个 lambda 捕获声明为 mutable 了:

auto a = [mutable x, y]() {
  x = 1;  // OK
  y = 2;  // Error
};


P2135R1: P2055R1: A Relaxed Guide to memory_order_relaxed
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2135r1.pdf

一篇科普性质文章,介绍 C++11 relaxed 内存序的原子操作的 out-of-thin-air 现象以及 read-from-untaken-branch 现象,以及如何在已有程序中识别潜在的相关问题

P2141R2: Aggregates are named tuples
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2141r2.html

std::get, std::tuple_element 以及 std::tuple_size 等实现 tuple protocol 的 STL 函数和 type traits 原生支持 aggregate 类型:

struct Foo { int x; double y; std::string z; };

Foo x{1, 2.0, "3"};
std::get<1>(x);  // Evaluate to 2.0
static_assert(std::is_same_v<
  std::string,
  typename std::tuple_element<2, Foo>::type
>);  // OK
static_assert(std::tuple_size<Foo> == 3);  // OK


P2747R2: constexpr placement new
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2747r2.html

让 placement-new 成为 core constant expression

P2748R5: Disallow Binding a Returned Glvalue to a Temporary
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2748r5.html

当函数返回一个引用时,不再允许这个引用绑定到临时对象上,杜绝一类 use-after-free 缺陷:

const int &foo() {
  return 42;  // Ill-formed
}


P2988R4: std::optional<T&>
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2988r4.pdf

std::optional 引入 std::optional<T&> 特化,可以实现用 std::optional 上的 monadic 操作替换一堆空指针判断

逐步氧化起来了

P3166R0: Static Exception Specifications
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3166r0.html

又要搞大新闻,重新引入了之前被废弃的 throw 声明符,可以用于声明一个函数所能够抛出的所有可能的异常类型:

void throws_nothing() throw();  // Effectively `noexcept`
void throws_a_b() throw(A, B);  // throws_a_b can throw A or B
void throws_any() throw(...);   // throws_any may throw any exception


一个亮点是允许使用 throw(auto) 自动推导函数可能抛出的异常类型集合:

void foo() throw(auto) { /* ... */ }


与老式 throw 声明符的本质区别在于编译器会强制检查异常集合的正确性。如果函数带有 throw 声明符但却可能抛出没有通过 throw 声明符声明的异常,那么程序 ill-formed:

void foo() throw(A) {
  throws_a_b(); // Ill-formed: B is not listed above

  try {
    throws_a_b(); // Ill-formed: B is not caught
  }
  catch (A) {}

  try {
    throws_a_b(); // OK since B will be caught
  }
  catch (A) {}
  catch (B) {}
}


按照这样的设计编译器理论上可以把所有带有 throw 声明符的函数的异常路径算得明明白白,可以开始优化 try-catch 路径了(例如把 throw-catch 直接优化为 goto)。

P3176R0: The Oxford variadic comma
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3176r0.html

不再允许不带前导逗号的 ellipsis parameter :

void foo(int ...);  // Ill-formed
今日大脑和手指打架:

大脑:csv! csv! csv! csv!
手:vsc
Dataflow Analyses and Compiler Optimizations That Use Them, for Free https://blog.regehr.org/archives/2578
#交通 #metro
明起上海地铁三站试点“闸机常开门”模式|请乘客正常刷卡(码)有序过闸

为进一步提升车站闸机的客流通行能力,学习借鉴国外同行的经验做法,自2024年4月20日至6月30日,上海地铁将在张华浜、杨树浦路、吴中路3座车站首度试点实测“闸机常开门”模式,即这三站的闸机日常均保持打开状态,乘客正常刷卡或扫码后,无需等待扇门开启即可快速进出闸机。

当闸机接受到无效车票或无票通过时,闸机扇门将自动合拢,阻挡通道,乘客须重新刷卡、扫码或寻求工作人员协助票务处置;同时,排队进出站时,当前面的乘客通过后,后面的乘客无须等待闸门关闭后再刷卡或扫码,而是可以直接刷卡或扫码通行;另外,希望乘客在高峰期排队有序进出闸机,勿拥抢,共同保障高效率通行。

InstantView from Source

woc,太先进了
Back to Top