不太清楚你想要的"本地编码"指的是什么.每个 ios_base 对象都会被指定一个 locale 的.你想要的是不是 std::cout.getloc() ?

基于 JVM 的开发者跑去了解主流 JVM 的 GC 实现和适应方式本身就是一件十分讽刺的事情:JVM 上的 GC 原本目的就是为了让基于其上的开发者可以无视内存的管理而设计出来的抽象,结果到头来大量开发者不得不去 overfitting 对应 JVM 的 GC 实现,从这一点上看来 JVM 的全局托管式 GC 作为一种抽象层级真的是完全失败,相比而言 C++/Rust 的 RAII 在内存和资源管理上的设计水平远高于 JVM 的 GC ——而且还不需要 hack 特定实现的实现原理.

emmmmmm 你指望 ffmpeg 这种一个 char 能同时当成 byte buffer 和 code point 的典型 C 程序碰到非 ASCII 编码能吐出什么象牙来.更何况 windows 下经过 mingw 的 glibc 那更是屎上加屎.LZ 最好还是通过 pipe 的方式喂输入吧.

@NoAnyLove 问题就是对于 cpp 而言补全函数名之类的事情很麻烦啊……比如我敲下了'std::char_traits<wchar_t>::'接下来希望 intellisense 能自动补全,这种需求可不是简单的下推自动机跑一遍就能解决的啊是吧……

@PythonAnswer 比较两个东西流畅不流畅首先至少要保证两个东西要跑的东西一样吧……比如宇宙牌 IDE 能对 C++做出非常友好的 intellisense,vim 要想做到这点只能上 Clang+YCM.但这俩玩意一上,vim 的速度可就比宇宙牌 IDE 快不了多少咯……

@zhoudaiyu 你跑一下 python interpreter 会看到这个 CPython 构建时所使用的 MSC 版本,对着 MSC 版本找对应的 Visual Studio 即可

LZ 的头像完美的展示了 C 语言标准面对 LZ 这个需求的时候的反应.

s/USC/UCS/g

在与 ASCII 兼容的编码中"0"-"9"的编码都是一样的,因为一个编码是 ASCII 兼容就意味着该编码中一段仅含有 ASCII 字符集的字符串其编码和该字符串的 ASCII 编码完全相同.而非 ASCII 兼容的编码就不好说了,自己一个个去查码表吧……

据我所知目前主流字符编码的大部分都是 ASCII 兼容的,比如 UTF-8,GB18030 等等.Shift-JIS 和 EUC-KR 如果不考虑 0x5C 的反斜线问题的话也可以算作 ASCII 兼容.非 ASCII 兼容的编码的例子一个是 USC-2 和 USC-4,另一个就是在 18M 的机子上常用的,和 ASCII 差不多古董并且和 ASCII 处处不兼容的 EBCDIC 了.

既然.Net Core 没有 GUI 组件的话那最不烂的选择只有 Qt 了……

顺便你们这些推荐 electron 的是认真的吗?至少为客户的机子着想吧……

SICP,不开玩笑.服务端的维护大概率会需要使用异步逻辑,而如果有基本的程序语言的理论的理解的话上手异步逻辑是很轻松的.别的东西可以之后慢慢学,但是如果一开始学习的时候思维定势被错误地固定下来的话后面要吃的苦就多了——特别是在学习其它东西之前就被 C 的残废抽象给拐到坑里去的话后面就只有弯路可走了——到最后还要被收割一波智商税.

emmmmm ……所以 LZ 不说在蓝鲸的哪个地方么……

@lieh222 $str="<a name='</a>' href='./page.html'>foo_bar</a>"
请开始你的表演.

这种需求 LZ 如果不想找现成的轮子用的话就做好手撸一个完整的 HTML parser 的准备吧……

@scinart 因为试图对偏特化模板进行匹配的实例不是 has_value_type2<A, int>,而是 has_value_type2<A, void>……你注意到主模板第二个参数的默认参数是什么了吗……

@scinart 因为你 has_value_type2 的写法就弄出来了一个不偏特化也是 well-formed 的上下文啊……具体原因我 2L 已经说了,has_value_type2<A>因为是 has_value_type2<A, void>,而 void != typename A::value_type,所以是用的主模板版本进行的实例化.

has_value_type2 的偏特化错了.has_value_type<A, void>并不能选取 has_value_type<A, int>作为自己的特化实例.