这年头还在这里折腾个啥呢……
CRT再有什么新版本也无所谓了，反正C标准库接口就那么些常用的，mingw-w64自己打包部署得了，默虽然默认依赖的msvcrt是古董（而且换新的会被spec里libgcc的依赖坑）但是其它一些辅助运行时（比如mingwex）擦屁股还算干净。
反正cl最近几年都是残货，cl的ABI历来奇葩。VC++就算不放置play理所当然也退居二线了。
PS.isprint自己撸一个不费事，但是iswprint这种就算去掉locale-specific也太那啥了……测试用例都没法找全。。。
Wine里的GetStringTypeW什么的完全不明觉厉啊。
http://git.musl-libc.org/cgit/musl/tree/src/ctype/iswprint.c
https://www.sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/ctype/iswprint.c?cvsroot=src
疯了……

正折腾艹蛋的isprintf……
https://connect.microsoft.com/VisualStudio/feedback/details/799287/isprint-incorrectly-classifies-t-as-printable-in-c-locale

predicate本身就可以作动词……

@em70
“其一是不懂资本市场运作，不会借助资本市场的力量快速发展自己。其二，团队速度太慢，创始人是海外背景，一直不紧不慢的打造产品。”
结果就是用户发现快车不够迅雷好用，所以用脚投票把快车踹一边去了。
顺便……
“迅雷创始人在谈及自己的创业史时提到，感谢魔兽世界，当年迅雷被网际快车(FlashGet)压制的时候，网际快车创始人侯延堂迷恋魔兽世界，停止更新软件长达一年，市场份额被迅雷迅速占领。”
2333
本来都是基于互联网的服务实际上要说是不是互联网精神也过于含混了。这样吧，你说说迅雷怎么表现得和Web相关？是不是网页版迅雷就比客户端的好用？

@em70 别拿“思想”粉饰对用户需求的注意不足来分散注意力了。本体论意义上就不通。
迅雷当年的成功跟你所谓的“互联网思维”有多少关系？P2SP就比直接下载更“互联网”了？是不是迅雷服务器挂掉了就都不能下载了然后用户会更高兴？

@em70
“大型软件公司都在往这个方向发展”说明他们发现这里方便他们捞钱，而不必然说明用户需求如何或者整个软件业就应该往这个方向发展。
顺便：
http://www.gnu.org/philosophy/who-does-that-server-really-serve.html

“团队没有明确规定应该怎么命名”还赖个人，团队素养拙计……
只要没有禁止，开发者名字命名是很正常的事。但是因为已经有保存历史记录，上面加日期就画蛇添足了。svn这样开branch是奇葩……

@elvba 这个虽然是权威的但只有顶级域名后缀。
顶级以下的要到各个注册机构里找么。

真正零基础还是算了。本来的设计就不合适。
ISO/IEC JTC1/SC22/WG14 N1570 + Cor 1:2012 + Defect reports and record of responses on ISO/IEC 9899:2011

啥叫好用。具体需求呢。做应用还是框架二次开发？平台？资源限制？
看起来只是说桌面开发？
撸Windows上的WPF和WinForms基本够用，不想多碰M$货或者要跨平台就Qt/PyQt，想要架构严谨能抄的就Swing，想量产Ecplise风的就SWT。Gtk也是跨平台的，不限于Linux，只是Windows上比较弱。（嘛，C代码撸到死一般不推荐……虽然不见得比MFC和wx麻烦。）js做桌面开发的也有像XULRunner什么的，不过dt，不成气候……
剩下的FLTK啊Tcl/tk啊之类杂七杂八的一般还是算了。各有各用。
GacLib？设计器打算什么时候撸出来？

pic || JSR337

只要投稿贴吧A岛之类找人代投就行了嘛……
猴子应该不管你账号哪来的。

标题问的只是语法问题，怎么连局部变量都来了。（不过后来好像还想要语义？那就随便吧。）
如果只是想治疗规范强迫症，具体结果看起来怎么样其实倒相对不重要了。
所有存在形式语法的语言通用的可保证结果唯一无歧义的方法：预测行数并指定上限，约定标点是否能出现在行首和行尾的策略，然后按节点高度优先顺序拆AST。（嘛，没有考虑对齐还真简单很多；能习惯有些情况下return后立刻换行就好……）

@clino 代码可读性好还是不好，根本上取决于两类因素：代码自身的构造；读者的理解能力。光从一个角度考虑得到的不全面的结论难以说明多少问题。是不是习惯了就会“好很多”，也得看代码写的怎么样和读者的理解水平怎么样两方面，没法一言蔽之。
要使特定领域的语言来作为一个问题的解决方案具有可操作性，一个重要的前提是读者必须具有对这个领域足够熟悉。不管是不是针对工匠，没有这个前提的“臆测”都是下下之选——这可能会让一个解决方案看起来可行，却埋下更高的因为理解错误带来整体失败的风险。如果你说的“可读性”好包括能让外行臆测比较容易撞大运蒙对的话，那我情愿可读性更差一点，排除掉不合格的读者，免得逼所有人都一起低效。大部分工匠更喜欢怎么样我没法下定论，但我相信，干大部分活的工匠不会乐于为蒙出来的问题买单。
从绝对意义上来说，只要用户有超过一种语用习惯，语言的分化是不可避免的。消极避免语言分化基本上算不上是可行的选择。实际上用户需要的结果是尽量达成合理的共识，这跟分化并不全然矛盾。在工程上，形成共识的一种主要手段是参照规范。无论在此之前如何减少了分化，也不会取代这个步骤，这个意义上刻意从语言设计上避免分化，在这里就成了过早的优化。
进一步地，在特定的环境下，因为语用习惯的多样性导致的“可读性差”是不是真能成问题，也未为可知。如果使用的代码总是由具有足够领域经验的用户编写的，一组项目中在参照规范之前取得领域含义的共识来解决“由于一个给定的符号可能是一个变量，函数或操作”这样的问题都不怎么困难。
而如果说要让所有用户都形成统一的风格，上面所说的“事后”方法自然的确不怎么可行，非得要做到就基本只能残害语言设计的灵活了；但这同样没有多少现实意义：取得共识的成本大于收益，还仅仅因为习惯问题就提前把一部分可能发挥价值的潜在用户排除掉了。
顺便，利用语言的分化恰恰能够更快捷地设计DSL并观察有效性。至于文化之类另当别论。

@clino 一直没搞清楚关于这里的“可读性”的判据是什么。
如果说命名烂，让读者搞不清楚意图，所以可读性差，那么应该都没什么意见。
如果嫌()多，试试把一般语言的[] {} <> begin end全部替换成()，统计下token多多少，（不管人肉还是机器）parse起来能省多少劲？
如果嫌))))))))))多觉得麻烦……看起来像那么回事，但不管是读还是写的时候都没人逼着用户靠数数来人肉匹配吧。(前的缩进也不是当摆设的。
还是说，只是单纯看不惯使用()分隔AST节点，所以可读性就差了？
如果只有这样的理由，只能是当作跟理性无关的习惯了。工匠需要这种品质么。

就算是同一个语言，如果用到了不同风格的依赖，不得不分裂。
趁早约定好convention。