我一直在阅读关于C99和C++ 11以及所有这些非常甜蜜的东西,它们被添加到语言标准中,有一天可能会很好用.但是,我们目前正处于在Visual Studio中编写C++的过程中.
标准中的任何新东西是否会被添加到visual studio中,或者微软是否更有兴趣添加新的C#变体来做到这一点？
编辑:除了接受的答案,我找到了Visual C++团队博客:
http://blogs.msdn.com/vcblog/
具体来说,这篇文章在其中:
http://blogs.msdn.com/vcblog/archive/2008/02/22/tr1-slide-decks.aspx
很有用.谢谢!
MS对此有一系列的公开回复,其中大多数都指责他们的用户.像这个:
http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx
现在,Visual C++编译器团队偶尔会收到关于我们为什么没有实现C99的问题.它真的基于我们用户的兴趣.在我们收到许多关于某些C99功能的请求的地方,我们已经尝试实现它们(或类似物).一对夫妇的例子是复杂的宏,
long long,__pragma,__FUNCTION__,和__restrict.如果您在工作中发现其他C99功能,请告诉我们!我们没有从C用户那里听到太多,所以大声说出来并让自己听到
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=345360
嗨:不幸的是,我们从大多数用户那里得到的压倒性的反馈是他们更希望我们专注于C++ - 而不是C-99.我们已经"挑选"了某些流行的C-99特性(可变参数宏
long long),但除此之外,我们不太可能在C-99空间中做更多的事情(至少在短期内).乔纳森洞穴
Visual C++编译器团队.
这是一个非常悲伤的事态,但如果你怀疑MS想要锁定用户,这也是有道理的:它很难将现代的基于gcc的代码移植到MSVC中,至少我觉得非常痛苦.
但是存在一种解决方法:请注意,英特尔对此更为开明.英特尔C编译器可以处理C99代码甚至与gcc具有相同的标志,使得在平台之间移植代码变得更加容易.此外,英特尔编译器适用于visual studio.因此,通过废弃MS COMPILER,您仍然可以使用您认为具有某种价值的MS IDE,并使用C99来表达您的内心.
一个更明智的方法是诚实地转移到Intel CC或gcc,并将Eclipse用于您的编程环境.跨Windows-Linux-Solaris-AIX-etc的代码的可移植性在我的经验中通常很重要,遗憾的是MS工具完全不支持.
Herb Sutter是C++标准化委员会的主席和非常活跃的成员,以及Visual Studio for Microsoft的软件架构师.
他是为C++ 0x标准化的新C++内存模型的作者之一.例如,以下论文:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2669.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007 /n2197.pdf
他的名字就在上面.所以我想只要H. Sutter留在微软,就可以确保在Windows上包含C++ 0x.
至于部分包含在Visual Studio中的C99,我想这是一个优先级问题.
最有趣的C99功能已经存在于C++中(内联,变量声明,//注释等),并且可能已经在Visual Studio中的C中使用(如果只在C++编译器中执行C代码).见我的答案在这里有关C++ C99的功能更完整的讨论.
C99通过添加已经存在于C++中的功能来增加C和C++之间的差异,但是以不兼容的方式(抱歉,但C99中的布尔复杂实现是可笑的,充其量......请参阅http://david.tribble.com/ text/cdiffs.htm了解更多信息)
Windows上的C社区似乎不存在或不够重要,无法被承认
Windows上的C++社区似乎太重要了,不容忽视
.NET是微软希望人们在Windows上编程的方式.这意味着C#,VB.NET,也许是C++/CLI.
那么,我是否会成为微软,为什么我会在很多人已经使用的更多社区活跃语言中提供相同的功能时,实现很少有人会使用的功能？
C++ 0x将包含在VS 2008的扩展中,或者包含在Visual Studio的下一代(几代？)中.
未经实施的C99功能将不会在未来几年内出现,除非发生一些戏剧性的事情(一个充满C99开发者的国家突然出现？)
显然,"充满C99开发者的国家"已经存在:http ://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6415401
^ _ ^
不过,我猜最后的评论是:http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6828778.
Herb Sutter明确表示:
我们的主要目标是支持"大多数C99/C11,它是ISO C++ 98/C++ 11的一个子集."
我们还出于历史原因发布了一个C90编译器,它接受(仅)C90而不是C++
我们不打算支持不属于C90或ISO C++的ISO C功能.
博客文章为这些决定添加链接和进一步解释.
资料来源:http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/
从VC2013预览版1,C99开始,支持更多样化的C++ 11和一些新引入的C++ 14标准.查看官方博客了解更多详情:http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview. ASPX
更新:
来自https://news.ycombinator.com/item?id=9434483(Stephan T Lavavej又名:STL是STL @VC团队的维护者):
具体来说,2015年我们的C99标准库实现已完成,但tgmath.h(在C++中无关)和CX_LIMITED_RANGE/FP_CONTRACT pragma宏除外.
查看这篇文章了解详情:http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx.
我参与了ISO C++工作(2000-2005),微软为这种语言做出了重要贡献.毫无疑问,他们将使用C++ 0x,但他们需要比英特尔更多的时间.Micosoft必须处理通常使用其专有扩展的更大代码库.这简单地使得更长的测试时间.然而,他们最终将支持大部分C++ 0x(导出仍然不被喜欢,或者我理解).
在ISO C方面,从事标准工作的人员并不代表微软市场.微软客户可以使用C++ 98,如果他们只是在寻找更好的C.那么为什么微软会花钱购买C99呢？当然,微软挑选了部分产品,但这是理智的业务.他们无论如何都需要那些C++ 0x,为什么要等？
遗憾的是,MSVC对C的支持非常缺乏.它只支持C99中作为C++子集的部分...这意味着,例如,在MSVC中编译ffmpeg或其libav*库在物理上是不可能的,因为它们使用许多C99功能,例如命名的struct元素.由于libavcodec还需要一个维护堆栈对齐的编译器,MSVC不需要这样做,因此情况更糟.
我在x264上工作,与ffmpeg不同,它确实努力支持MSVC,尽管这样做本身往往是一场噩梦.即使您通过显式的基于汇编的堆栈对齐函数显式传递最高函数调用,它也不会保持堆栈对齐,因此必须禁用所有需要对齐堆栈的函数.它也非常烦人,我也不能使用vararrays; 也许这是最好的,因为显然海湾合作委员会大规模地使他们在表现方面感到悲观.
有关MSVC 2010年和2011年MSVC C++ 11功能兼容性的最新帖子现已上线.
京公网安备 11010802040832号 | 京ICP备19059560号-6 