本文目录
mfc是什么
想象一下,GTK就相当于windows下的win32api,wxwidgets是一个跨平台的东东，而win32api和gtk都是针对特定系统而言的。wxwidgets如果在windows下并且封装了一些win32api那么就叫做wxMSW，这个跟MFC有点像。wxwidgets如果在linux下并且封装了相应的图形库的话，就有其他名字了，一般有三种：包装了x11 的 wxX11, 包装了motif的wxMotif和包装了GTK的wxGTK, 其中可能是wxGTK最流行了。
mfc是什么
WTL都算不上什么Framework，就是利用泛型特性对Win API做了层封装，设计思路也没摆脱MFC的影响，实际上用泛型做UI
Framework也只能算是一次行为艺术，这个思路下继续发展就会变得没法用了，比如 代码过于复杂，编译太慢，出错不好调试等问题难以解决。
而且封装得也不完全，还是随处可见 HWND HDC之类的东西。
用途主要是写一些很小的程序，或者作为其他UI框架的后端实现部分，比如我写过一个小框架用来做安装卸载程序，非常小，其中创建管理窗口部分是用WTL的。
MFC
是更高级点的Win API封装，比WTL封装彻底，很难见到HWND
HDC了，也提供了不少实用工具类，比如高级控件，泛型容器，IO访问，网络协议等。除此之外，还提供了一些基本框架，比如
Document/View，这就是个MVC的简化版本，只有MV，但是对于数据的管理，消息的传递等又没有什么约束，导致Doc/View被用得乱七八
糟。尤其是对事件处理的模型，消息映射是功能简陋，而且容易出错的方式，唯一优点是性能好。 从VC++
1.X就有MFC了，那时整个UI界的设计思想都比较落后（除了Apple），MFC又背负了沉重的兼容性包袱，比如vc++
1.52的MFC程序到了vc2003稍加修改都可以编译，导致MFC后期没有什么发展，就是沿着老的思路完善了些细节，添加了些组件，但是根本性的设计
问题没有改进。
GTK，这个吃了语言的亏，用C写面向对象实在是痛苦，虽然在思想上比MFC要先进了些，但是写出来的代码比MFC要罗嗦很多了。相比MFC，多了Layout的概念，事件处理上有了Signal/slot，虽然用起来很麻烦。
wxWidgets，
这个基本就是个跨平台的MFC，对各个平台的差异做了抽象，实际上后端大多还是用平台原生的API实现，好多控件都是直接用系统原生的。有
wxWidgets for
GTK+的版本，后端就是GTK+，wxWidgets就是一层壳。这也是wxWidgets的优点，它编译出来的程序发行包比较小，性能也不错。
以上这些就是上世纪90年代的UI Framework技术水平了，至今它们也依然没有太多进步。
下面来谈谈21世纪的技术。
Qt，
虽然它也是上世纪90年代出现的，但是它在21世纪有了长足的进步。应该说它的起点就比较高，一开始就定位跨平台，而且不满足于简单封装系统API，而是
要自己创造出一套完整的API和框架，甚至要代替系统API，所以不仅仅是做UI，而是涉及到了APP开发所用到的所有东西，包括网络，数据库，多媒体，
脚本引擎等。signal/slot是Qt发明的，这是事件通知模型里C++语言的最佳实现了，甚至我都觉得这该写进C++标准，估计C++委员会的老顽
固们是从不写GUI的。
早期的QT也是没有DirectUI的概念的，每一个QWidget都对应一个原生窗口，从Qt4.4开始，只有顶层
QWidget才是原生窗口，而Child Widget是Alien
Widget，只是个抽象的图层不对应原生窗口，这就实现了DirectUI的概念，很多图形效果也就变得可能了，比如窗口层叠透明效果。
在4.8后实现了QPA(Qt Platform Abstraction)，这就使移植Qt变得很容易，目前Qt是支持平台最多的框架没有之一。
由于早期授权的问题，Qt对于开源社区不是很友好，导致推广不太顺利，直到它改成了LGPL方式，如果Qt能早点想开了，恐怕就没有wxWidgets的生存空间了。
Qt的缺点也是有的，就是太大，不过可以自己剪裁，我可以把QT库剪裁到发行包压缩后2.5MB。
WPF，
微软在Win
Form的思路上走到死胡同后，终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的，绝对不能是代码写出来的，所以有了XAML这个
强大的定义工具，不但可以定义UI布局，还包括图形动画效果，消息响应方式等。配合C#这种优秀的语言，更是如虎添翼。但是问题也很明显，就是过于庞大，
不仅开发时要用到庞大的IDE和设计工具，发行的安装包也十分巨大，所以目前还是很少有人拿他写通用软件客户端的，大多是做企业项目时写专用客户端。
大概4-5年前吧疼讯曾经用WPF写了个QQ，但是只实现了基本功能就已经比C++客户端大好多了，而且运行缓慢，主要是太吃内存，而且那时WPF的优化还不充分。
最后我想补充下真正的UI库之王，cocoa。
Apple的成功有很多原因，其中之一就是cocoa，cocoa理念十分先进，而且出来得早，我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。
定义式的UI，用xib就可以定义UI的绝大部分细节，而且提供所见即所得的可视化设计工具。
严格的MVC，而且定义非常清晰，分工明确。
signal/slot，虽然不叫这个名字，但思想就是，而且真的是拖动鼠标就能connect。
提供了ARC，闭包和反射，给UI开发带来巨大的便利性，当然这得益于Objective-C这个语言。
再补充下 Borland的OWL和VCL。
我是从Borland C++3.0和Delphi 1.0开始用的，那时的Borland看来很有前途的，可惜后来一系列决策失误导致现在这个公司几乎消失了，同学们不要再往这个坑里跳了。
OWL曾经和MFC是竞争对手，设计思想也差不多，个人感觉OWL的API设计更优雅一点，但是在市场上OWL被MFC彻底击败。
Delphi
是神作，它在RAD（快速应用开发）领域长时间没有对手，直到BS架构取代CS架构。Delphi的特点就是简单、开发快，单纯就写个基本可用的应用来
说，可能至今都没有比他更快的，但是缺点就是丑，基本大多数Delphi应用都是一大堆控件堆积在一起，很不美观，另外由于Pascal语言的限制无法和
现有大量的C/C++代码融合。虽然后来有C++
Builder，但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差，导致后来开源项目都不太愿意兼容这个编译器了。
VCL准确地说不是UI库，而是一套组件接口规范，类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。
UI库是个很大的话题，够写好几本书来探讨的，我这里就是随便写点自己的感受。
单纯讨论每个库的优劣是没有意义的，而是要放到具体的应用场景里来看，每个库都有自己擅长的场景。
如果仅在Windows下，追求程序小巧，用WTL，不足的地方自己实现去吧，但是视觉效果就呵呵了。
如果可以大一点，还要好看点，那就Qt。
如果完全不在乎大小，只要视觉效果华丽，就用WPF，如果把开发工具价格也考虑进来，那么土豪才会选WPF呢。
MFC就是个鸡肋了，除非你现有的工程师不会用别的，或者有历史遗留代码要保持兼容。
如果要求跨平台，那么就用Qt，wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。
如果是iOS Android，那么最好用原生UI库，除非你写游戏。
给排水的各种符号表示什么?
在给排水工程的图纸中，缩写符号含义如下：
给水管道-J，如果分高低区通常用首字母表示即高区-G，低区-D。
排水管道-W，表示污水。也有-F，就是废水。很少见有用-P 表示的。
消火栓管道-XH。
自动喷淋管道-Z或者-ZP。
雨水管道-Y.。
采暖管道-R，一般实线表示供水管，虚线表示回水管。
压力排水-PY。
冷凝水管道-N。
管道立管-L。
另外设备的型号字母： Q-流量或者风量 H-扬程 N-功率 P-压力 QW-潜污泵 其他阀门、器具之类的都是用图形区分。
JL-给水管； WL-污水管； YL-雨水管； RJL-热给水； RHL-热回水 。
(1) 查明给水管道系统的具体走向，干管的布置方式，管径尺寸及其变化情况，阀门的设置，引入管、干管及各支管的标高。
(2) 查明排水管道的具体走向，管路分支情况，管径尺寸与横管坡度，管道各部分标高，存水弯的形式，清通设备的设置情况，弯头及三通的选用等。识读排水管道系统图时，一般按卫生器具或排水设备的存水弯、器具排水管、横支管、立管、排出管的顺序进行。
(3) 系统图上对各楼层标高都有注明，识读时可据此分清管路是属于哪一层的。
扩展资料读管道平面图，应掌握的主要内容和注意事项如下：
查明卫生器具、用水设备和升压设备的类型、数量、安装位置、定位尺寸；
弄清楚给水引入管和污水排出管的平面位置、走向、定位尺寸、与室外给排水官网的连接形式、管径、坡度等；
查明给排水干管、立管、支管的平面位置、走向、管径及立管编号；
消防给水管道要查明消火栓的布置、口径的大小，绩效方向的形式原装位置；
在给水管道上设置水表时，要查明水表的型号，安装位置，以及表前后的阀门设置.
识图预算中WTL剖面图中的C代表什么意思
C-C剖面
C是英文chamfer的缩写，就是斜切的意思,指直倒角,区别于圆倒角R.
以上就是关于wtl什么梗 啥意思,mfc是什么的全部内容，以及wtl什么梗 啥意思的相关内容,希望能够帮到您。
版权声明：本文来自用户投稿，不代表【蒲公英】立场，本平台所发表的文章、图片属于原权利人所有，因客观原因，或会存在不当使用的情况，非恶意侵犯原权利人相关权益，敬请相关权利人谅解并与我们联系（邮箱：350149276@qq.com）我们将及时处理，共同维护良好的网络创作环境。
