在CB上看到新闻：Visual Studio 2008 将对MFC进行重大更新

[八大]

Visual Studio 2008 将对MFC进行重大更新

ugmbbc发布于 2007-11-13 18:45:50| 次阅读 字体： 大 小 打印预览

感谢younker的投递
新闻来源:MSDN Blog
根据微软VC Team 成员的blog,在VS2008发布之后,MFC将很快迎来一个很大的更新.
MS 向BCGSoft 投资,将在MFC的Update中使用BCGControlbar来扩展MFC,另外TR1也将在这次更新中得到支持. 相信这个消息对所有的MFC的开发者都是一个大大的利好消息。。。

哪位用过，说说。

[Du Lei]

没用过MFC，倒是支持TR1的那一堆设施挺不错的

[Googol Lee]

听说了，不过，对mfc还是不抱希望了，除非ms能抛弃对以前mfc的兼容性重新来过......

On Nov 13, 11:11 pm, "八大" <sean4y...@gmail.com> wrote:
> Visual Studio 2008 将对MFC进行重大更新
>
> ugmbbc发布于 2007-11-13 18:45:50| 次阅读

> 字体：大<http://www.google.com/gwt/n?u=javascript%3AfontZoomB%28%29%3B%3F_RW_%...>
> 小<http://www.google.com/gwt/n?u=javascript%3AfontZoomA%28%29%3B%3F_RW_%...>
> 打印预览<http://www.google.com/gwt/n?u=http%3A%2F%2Fwww.cnbeta.com%2Fprint.php...>
>
> *感谢younker的投递*

[怀宇范]

看做的如何了。如果和老的MFC比较像，但好处很多，可以考虑移植原有项目。

 

但如果太新了，并且功能还很好，也是可以考虑在上面做新项目的。

 

毕竟。是基于C++的GUI。。。

 

you.Find("Fan Huaiyu"))return true;
    if(you.MailTo(" dugu...@gmail.com ") || you.MailTo(" fan...@mails.tsinghua.edu.cn "))return true;
    if(you.PhoneTo("13488810330") || you.PhoneTo("01062778689"))return true;
    if(you.QQTo("120628812") || you.MSNTo(" dugu...@hotmail.com"))return true;
    if(you.NetTo(" www.cnblogs.com/duguguiyu "))return true;
    return false;
}

[SpitFire]

bcg就是控件多了，也是基于mfc的，底子在那

bcg以前有个free的，后来都收费了，功能倒是挺多

在07-11-14，怀宇范 <dugu...@gmail.com> 写道：

--
SpitFire

[莫华枫]

看Sutter的blog：http://herbsutter.spaces.live.com/Blog/cns%212D4327CC297151BB%21343.entry

在07-11-14， SpitFire <spit...@gmail.com> 写道：

--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/

[SevenCat]

BCG非常强大，这下是有福了。bcg的7的原代码网上能找得到，比较大。

[寒光]

如果也能做到平台无关，那就有点使人心动了

[王磊]

平台无关不会是MS希望的事情吧。。。。毕竟微软是平台起家的公司。平台的市场份额一直极为关注。2008希望会有进步吧。

在07-11-14，寒光 <gmz...@gmail.com> 写道：

如果也能做到平台无关，那就有点使人心动了

[zhangy...@kedacom.com]

希望一改MFC的丑陋
支持TR1，很好
可惜公司不会换的

[codediscuss.com]

非常同意！MFC老版本的留下了太多兼容这兼容那的东西，还有好多没有使用c++特性而搞出来的东西都还在，强烈要求去除！

另外对于bcg，我印象非常不好，售后服务的bug report,24小时没有任何答复，我写信complaint后，居然直接给我close！！
我强烈反对在mfc中使用俄国老毛子的bcg！！

On Nov 14, 12:05 am, Googol Lee <googol...@gmail.com> wrote:
> 听说了，不过，对mfc还是不抱希望了，除非ms能抛弃对以前mfc的兼容性重新来过......
>

[CAXSOFT]

bcg还不错，我一直在用~

在07-11-14，codediscuss.com <flyi...@gmail.com> 写道：

[Googol Lee]

平台无关的还是qt吧，其实这东西做的很好了，如果能把signal/slot替换成boost的signal/function就更好了......

[王磊]

QT，曾经见过几次的东西：） 自带的小例子游戏不错

在07-11-14，Googol Lee <goog...@gmail.com> 写道：

[pongba]

On Nov 14, 2007 10:41 AM, Googol Lee <goog...@gmail.com> wrote:

平台无关的还是qt吧，其实这东西做的很好了，如果能把signal/slot替换成boost的signal/function就更好了......

这篇文章详细比较了C++里面的各种delegates实现，包括Qt和boost的。
可以看出，boost.signal并非最好的。其最大的缺点就是没有访问控制和元数据。其中又数没有元数据最严重。

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[Googol Lee]

主要觉得qt的signal/slot把本来用库可以解决的东西做到了语法层里面，不爽。其内部实现和signal/function很类似，而元数据
是通过在定义qt类时的一个QObject宏完成的，这个宏会由qmake展开并加入一些元数据信息，比如className啥的。因此如果是使用
signal/function，这个信息也不会丢失。

On Nov 14, 11:37 am, pongba <pon...@gmail.com> wrote:
> On Nov 14, 2007 10:41 AM, Googol Lee <googol...@gmail.com> wrote:
>
> > 平台无关的还是qt吧，其实这东西做的很好了，如果能把signal/slot替换成boost的signal/function就更好了......
>
> 这篇文章<http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html>

[八大]

C++为什么一直固执的不加上反射及元数据支持？

在07-11-14，Googol Lee <goog...@gmail.com> 写道：

主要觉得qt的signal/slot把本来用库可以解决的东西做到了语法层里面，不爽。其内部实现和signal/function很类似，而元数据

[莫华枫]

这方面的提案是有的，但是标准委员会认为还没有精力去处理这类问题。

在07-11-14，八大 <sean...@gmail.com> 写道：

[莫华枫]

突然想到，更新mfc的原因。很可能mfc中的一些代码阻碍了vc的进一步发展，不得不加以更新。
我以前曾经提起过，mfc有一个严重违背c++标准的地方：
class H;
class S
{
public:
    x() {
        H* pThis=this-offsetof(m_s, H);
        ...
    }
};
class H
{
    S m_s;
};
H里包含S的对象，在S里，为了获得宿主类H的指针，用自身的this指针减去m_s在H中的偏移量。这就要求一个类中的子对象必须同宿主对象放在一起（连续分布），并且固定（偏移量永远不变）。为了在对象布局上给予编译器充分的自由，标准规定offsetof只能用于pod。mfc仅考虑在vc上使用，所以为了方便而仅仅面向vc编译器编码。这带来了移植性的问题。不过，编译器间的移植性还是小事。现在我们就可以看到mfc的这种做法是搬起石头砸自己的脚。
sutter和lippman都不止一次地提到将来vc要能够不区分托管和本地的内存管理。也就是说托管的类型可以在native堆上分配，而native的类型可以在托管堆上分配。问题来了，由于托管堆上，子对象和宿主对象的存放不是连续的，子对象可能同宿主对象隔着十万八千里，和成千上万的对象。而且子对象可能会在宿主对象的前面。offset也是不确定的。在这种情况下，使用上面的这种代码无异于自杀。所以，为了实现托管和本地内存管理的统一，必须放弃offsetof这类畸形代码。由此导致了mfc的大幅更新。
另一方面，vc越来越符合标准，而mfc中一些遗留的其他不符合标准的地方，使得编译器不得不同时应付两种情况：标准的和非标的。对编译器着实是个负担，消除这些非标的东西，反而能够使得编译器更加简单高效。
以上这些都是猜测，实际如何，还需具体看2008的mfc库代码。

在07-11-14，莫华枫 <longsh...@gmail.com> 写道：