@chocotan JavaFX 既做桌面又做 RIA ，看上去类似于 WPF 和 Silverlight 的混合，除去前途和用户数量问题，定位也感觉比较糊，所以就没提。
“效果还是性能或者是实现质量普遍惨不忍睹”这方面严格来说不是全部都一样。例如 Swing 的默认 look & feel 一直跟 Windows 上常见的其它 app 很不搭，我也几乎没有见到过有在 Swing 基础上定制的产品； AWT 和 SWT 因为和原生 UI 有一腿所以实现比较脏。相比之下， SWT 还是比较能用的，但是写起来遇到一些不那么 eclipse 的需求嘛……
要用 Java 开发出性能外观都过得去的东西也不算太难，但想要底层实现干净点（看得清楚而且容易改），那种东西还不存在。虽然后者一定程度上和语言无关（至少涉及 Win32 native GUI 的部分都不会好到哪去），但 Java 和 native code 的互操作加剧了这种混乱；相比之下.NET 做这个就容易多了。
JetBrains 家的东西……不想说脏话，事实是我在 Windows 机器上体验过跟他们家有一腿的产品（ Android Studio 、 IntelliJ IDEA ……）无一不是卡到几乎没法日用，如果不算打不开的话（ CLion ）。也就 ReSharper 能动得起来，但还是卡。虽然这也许是我只试用早期测试版本的原因（顺便，这些机器上都没 SSD ），但同样的机器 eclipse 也没那么夸张……更大的问题（和 Chrome 类似）是狂吃内存，开发机内存多少不是我说了算那就只能嗝屁了。不过这些性能问题应该不是 UI 的锅，卡顿是整体性的，和 UI 看上去关系不大。

@21grams Java 桌面的话， AWT/Swing/SWT ？（先不说部署问题估计不会合 LZ 胃口了。）
大致上 Swing 和 WPF 是一类、 SWT 和 Qt 这样的是一类、剩下的 AWT 和 MFC 和 wx 是一类奇葩。老调重弹没有新意。
也就 Swing 架构还算规整造轮子能（找 Sun 的白皮书）抄，然而不管是效果还是性能或者是实现质量普遍惨不忍睹。剩下的不是 Java 厨估计无法忍受……

@hunk 不管是要练手还是开发实用 app ，耗不起资源的话，我的忠告：远离 C++、远离 Win32 、远离桌面 GUI 。
掐指一算，我撸 C 艹 GUI 好像有 7 年啦……虽然就 GUI 而论是三天打渔两天晒网的，前 3 年和 Win32 其实也没什么关系，最近几年可是有一大半浪费在 Win32 这坨辣鸡上了。（虽然讲道理， Android 和 X11 更辣鸡……）
https://github.com/FrankHB/YSLib
就这么个轮子敲捣你给出的需求还得费些劲。

从 0 开始？ Win32 那坨不用倒腾了，基本上只配被封装的料。自己造轮子撸个十年八年的顺眼了再说。
虽然 Qt 一坨私货金玉其外败絮其中，然而矮子里挑将军倒是没什么疑义……眼前勉强算是个“能用”的。不过要是在乎部署，一不小心和.NET 半斤八两。 PyQt 的话，搞不好从 0 开始的工作量翻两倍。
MFC ？ wx ？不是拿来给现有项目擦屁股还不如直接 Win32 呢……

@BSD ——“不是你买的闭嘴。”
不过说实话，其实和程序员也没太大关系……
就是作为最终用户买的也该自裁，很多市场就是被这坨逗比代婊了主流配置而搞烂的。合着真正搞对需求的用户计算成本的时候反而还得迁就这种惯坏逗比用户的行情花冤枉钱才叫正义了？

@dphdjy Worse Is Better 不是一群图样应付 YY 出来的需求的么。
都 it is slightly better to be simple than correct 了嘛。
这看来不能算是学院式，但要笼统说成面向需求，脸皮也太厚了点。
所以是啥。

……最好？要说贴近需求，当然是自己实现。
现在就 ConEmu+MSYS2 凑数。主要是 pacman 简单暴力而且 MinGW 原生包够多日常打 Cygwin 不成问题……虽然迟早都得重新倒腾（反正对 conhost/pty 互操作没兴趣，不是难点）。
Win10 的那个山寨笨兔现在相比之下就是玩具阶段所以一般人就不用浪费时间了。

看人。
然后得看问题领域。比如说倒腾 C ，一时不会也通常不是什么大问题，反正九成九都挺渣的……很多基础科目教育质量包括教师和参考资料的水平就满是槽点，这样下来还真不见得就打得过培训班。
想象不清楚的话出来几年就习惯了。

什么 base type ……现在的“入门”书已经没节操在这里生造概念了吗……难怪某糖看不起“底火”……
有点正确的基础的话真的就是一句话的事情……
WG21/N4594
7.1.6.4 auto specifier [dcl.spec.auto]
1 The auto and decltype(auto) type-specifiers are used to designate a placeholder type that will be replaced
later by deduction from an initializer. ...
（当然怎么 deduce 就要倒腾 Clause 14 了，没问题就可喜可贺。）

因为基本上_t 都是文件作用域外部名称，所以你临时性地在块内 typedef 一下_t 的用法是不受限制的。不过排除了最有用的用法，似乎也没多大卵用就是了……
@halibut735 _t 约定俗成也就是 type 的意思。
不过最近似乎有越用越集中的趋势，像 ISO C++ 14 已经到处后缀_t 表示 typename *::type 了……甚至还有直接当 alias template 的： https://github.com/ericniebler/range-v3/blob/4ae2b5bd7b36ce2281f34abb40dab0e88f81e519/include/meta/meta.hpp#L147

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
包含任意 POSIX 头（文件）的翻译单元的文件作用域内保留_t 后缀作为外部链接的标识符（给 POSIX 标准或实现），所以你要 strict conforming to POSIX 自然不能随便用，否则一旦实现提供了扩展或者更新了使用的 POSIX 版本就可能冲突，慢慢重构去吧……
但如果你的项目本身就是在实现 POSIX 或者 ISO C ，自行添加扩展当然是允许的（兼容性问题自负），如：
https://www.cygwin.com/ml/cygwin/2009-08/msg00376.html
ISO C 没有保留后缀只是提供了一些_t 的名称，所以不管 POSIX 就无所谓。
题外话， C++的成员因为类和非全局命名空间都有单独的作用域而不是 C 那种名称空间(name space) 来区分，所以不受类似的限制，只是全局命名空间以及 ISO C 的保留标识符限制仍然类似；除此以外不踩到宏的坑就能无视。

“好好读书”？如果是口癖也罢，否则一句 you can you up 八成能打回原形了。说这种话的出发点一般也就是“不理解”和“看不惯”罢了，未必就有个听者有心的预期，往往更像是牢骚；另一方面，功利点地说，没有进一步具体意见，就是拿没有卵用的空话浪费时间。因此真会“读书”的先辈，若目的是善意的，通常不会幼稚到这般点到为止。
至于被念的……分类讨论。
玩到对什么是玩什么不是玩都没发言权的，活该被玩。
也有不懂瞎 bb 成瘾的，还有脸自居父母或者长辈倚老卖老的。平日里谁惯坏的？上梁不正下梁歪，多少也是活该。
反过来，要是连要解决的问题是什么都不知道，连什么是工具都分不清楚，被抽脸又能怪谁？