这是一个创建于 4847 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前重要基于VC++的MFC写一些工控和试验类型的桌面应用程序，不知C#是否更有优势？
请大家发表一下看法
请大家发表一下看法
 |
1
ayang23 2012 年 10 月 10 日  1
刚买了本c#的大厚书，准备转。不过想先研究下common lisp。个人不喜欢mfc，一直用wtl。
|
 |
3
cranej 2012 年 10 月 10 日
工作三年以上还不能独立思考决定这个问题就别转了，浪费时间，啥熟悉做啥混口饭吃吧。csharp在偏底层的开发没有优势，擅长的是商业应用程序。
|
|
4
cranej 2012 年 10 月 10 日
入门书籍推荐c#本质论，然后clr via c#, 然后就不需要看书了，msdn就可以了
|
 |
5
gcweb 2012 年 10 月 10 日
用WPF写界面，轻松又愉快
|
 |
6
bombless 2012 年 10 月 10 日
看场景。现在 C/S 或者 RESTful 的程序用C#做很常见，主要是因为 .net FCL 的网络相关的API实在太方便了。
|
 |
8
sharpblade 2012 年 10 月 11 日
推荐《C#本质论》，很好的一本书，深入浅出，条理明晰，体系严谨
至于你的应用领域，不是很清楚C#合适不合适，不过应该没有问题，必要时可以使用互操作 |
 |
9
azure 2012 年 10 月 11 日 1
C#的问题在于.Net框架版本的不统一。 XP WIN7 WIN8预装版本都不一样。WPF确实轻松又愉快。但是有时候发行版本附带一个20多M的运行环境安装程序实在没有太舒心。。
当初的dbradioPlus就吃尽了这个亏。 http://www.douban.com/note/79600836/ 基于.net4 受尽了各种关于.Net的吐槽 |
 |
10
xupefei 2012 年 10 月 11 日 2
@azure 解决这个问题不算麻烦，用 3.5 版本就行了。
XP 不预装 NET，但是现在那些盗版一般也都附带了 2.0 版本（或更高），于是在分发软件的时候，把那些版本号为 3.5 的 DLL 放在程序目录下一起打包就行了（ NET 3.5 的 mscoredll 还是 2.0版，只是在周边附加了一些库）。即使是 WPF，也就是把核心 DLL 打包就行了。 WIN7 自带 NET 3.5。 WIN8 自带 4.0，但是在使用基于 3.5 的程序时有十分友好的提示提醒用户安装 3.5，不会出现 Error Msg，体验还算不错。 |
 |
11
haohaolee 2012 年 10 月 11 日
所谓试验类型的程序是指什么？C++写程序无非就是对于CPU bound的应用更高效，对细节控制更精确。要是整天都是和控件打交道，winform足以应付了，开发效率也高
|
|
12
azure 2012 年 10 月 11 日 1
@xupefei BUT，WPF真正成熟好用是在4.0时代。你总不能针对客户开发两套基于不同版本WPF的软件吧。或者妥协让步，让你的软件止步于3.5时代？ 以及用户在拥有4.0 Framework的时候还需要再装一个3.5.这实在让很多用户不解吧
|
 |
15
c4pt0r 2012 年 10 月 11 日 1
作为曾经的桌面应用开发者可以负责的说, 对于大规模分发的用户桌面软件，比如一些流行的免费互联网软件（浏览器, qq, 360, xunlei, 词典, 输入法什么的），c++是几乎是唯一的选择: mfc, qt和裸写native win32程序, 从来不会考虑c#之类的，原因是兼容性太差，用户太小白，对安装包的大小太敏感等.
当然，如果只是做实验或者小范围应用的软件, 当然怎么快怎么来了, c#开发起来能轻松非常非常多 |
 |
17
huangliushen 2012 年 10 月 12 日
C#的开发还是属于不吃力还讨好的那种，当然还要分具体情况的·
|
 |
18
Ricepig 2012 年 10 月 12 日
C＃帖居然喷的人这么少？！时代的进步啊！
|
 |
20
Alpha PRO 现在比较流行go
|
 |
21
avatasia 2012 年 10 月 12 日
你说的是WPF,c++程序的优势是体积小，对系统的控制能力高。
|
 |
23
gislord 2012 年 10 月 12 日
@hyq 正解。。csdn喷这个厉害些。。cnbeta喷公司比较多。。另外补充，一些行业相关的桌面应用程序，也不会考虑C#，效率不够，前期做demo还差不多。
|
|
26
haohaolee 2012 年 10 月 13 日
@gislord 那些大型软件的特点是什么都用，该用C/C++的地方C/C++，该用.Net的地方就.Net，还会内嵌各种脚本语言。一切视需求和实现而定
|
 |
29
siemonday 2012 年 10 月 13 日
去年买的本质论，一大本砖头。。还是多写写代码好
|
|
31
gislord 2012 年 10 月 13 日
@haohaolee 嗯对的。大型商业软件一般都不会只考虑一种语言。但是研究性的项目，可能更多的注重是算法或者学科相关的研究探索，可能C++就是最好的选择了，效率好，也不需要考虑c++在实际项目中带来的诸多问题。。
|
 |
33
wuxqing 2012 年 10 月 14 日
可以混合编程
算法部分用c++ ui部分用c# |
 |
34
halfbloodrock 2012 年 10 月 14 日
evernote在早期的版本是.NET的，最后还是换成C++开发了
|
 |
35
fwee 2012 年 10 月 14 日
如果每台电脑都装了.net4.0那什么问题都没了
|
 |
36
lyping OP evernote的C++版本不是MFC的吧。不知C++除MFC以外还有什么可以选择的。qt呢？
|
 |
37
funcman 2012 年 10 月 14 日
行业软件用.Net有神马问题，装上.Net Framework就是了，开发起来要多方便就多方便。
面向大众的桌面软件至少要用MFC/WTL，最好是自己封装Win32来做。Qt都显得不够用。 游戏开发领域，编辑器一般用.Net或Qt。用.Net的麻烦在于游戏引擎要包装给.Net，还是比较麻烦的。Qt作为一个C++的超集，就没有这方面的麻烦。 尽量用容易开发的技术来做。 |
|
41
haohaolee 2012 年 10 月 15 日
@Ricepig 这取决于是动态链接还是静态链接的，刚才写了个boost thread的hello world，全部static linking的话，大约是800k，但是如果动态连接到c++标准库和其它系统lib的话，就只有50+k了
|
|
43
gislord 2012 年 10 月 16 日
@Ricepig C++本身坑多大多在于软件开发后期。研究性项目，譬如点云数据，建个MFC，加入openGL显示，剩下的就是尝试各种滤波算法和点云处理方法。效率也得到了保障。没有你所谓精力无法集中于研究的问题。因为往往不是大型工程，也没有严格的安全性扩展性要求。
|
 |
47
phnessu4 2012 年 10 月 17 日
不看好c#, 好多年前就不看好, 现在依旧不看好, C#东家MS都把注意力全部集中到xbox上了, 建议转objective-c或者还是做c++, 换个方向, 做移动, 游戏 或是 体感方向.
|
|
48
phnessu4 2012 年 10 月 17 日
同样鄙视java
|
Select Language