C++14 一致性改进: constexpr 和 aggregate初始化

原文发表地址] C++14 conformance improvements: constexpr and aggregate initialization [原文作者] Andrew Pardoe [原文发表时间] 2017/3/7 C++11 中有2个重要的特性在C++14中进行了小的升级,这具有深远的影响。 1. C++11 中,constexpr 函数体只允许一条return 语句,而在C++14 中,constexpr 函数体允许几乎所有的语句,允许更多的C++ 使用习惯。在core constant expressions on CppReference 与 learn about constexpr on the same site 中,你可以了解到更多的使用规则。 2. C++11 中,如果一个聚合类型所包含的任何一个成员具有默认的成员初始值时,则不能将其初始化为聚合类型。而在C++14 中,C++标准委员会移除了对含有默认初始值的非静态数据成员的这种限制。你可以在aggregate initialization on CppReference 与non-static data member initialization (被称为NSDMI) 中找到更多的信息。 你可以从CppReference site 看到,虽然这些更改都是对标准的小改动(在这些页面上搜索”C++14” 的注释),但是它们对编译器的实现以及开发人员编写代码方面有很大的影响。 · 以前,constexpr…

0

使用Visual Studio下的linux子系统来学习C++ Concepts

[原文发表地址] Learn C++ Concepts with Visual Studio and the WSL [原文作者] Andrew Pardoe [原文发表时间] 2017/2/22 Concepts是可以从概念上改变C++模板代码的使用. 与Coroutines,Modules,ranges特性一样,Concepts位于技术指标(TS)中, 在它们将要列入C++标准前去学习并使用这些重要的特性,是很有帮助的. 你已经可以使用VS 2017中已增加的Coroutines,Modules以及Range-V3分支中的Ranges特性. 现在我们又在VS2017针对Windows中的linux子系统模块(WSL)中支持使用Concept. 我们来看看他们是如何工作的. 关于Concepts 模板参数可以通过Concept来确定它所必须的条件, 这也是创建不同接口的本质条件. C++社区期盼很多年希望Concepts加入C++标准。 如果你对于这些事感兴趣, 可以阅读Bjarne Stroustrup写的一些关于concept背景需求的一些文章。 a recent paper about designing good concepts.如果你对于如果使用concept感兴趣, 请参考 Constraints and concepts on cppreference.com. 如果想知道关于concepts的所有细节, 你可以阅读 Concepts Technical Specification (TS). Concepts当前仅在Gcc 6版本以上可用。 它还没有被MSVC和Clang编译器所支持。 我们计划先完成当前已经被投票通过的C++17特性, 并完成一些还没有实现的准则,然后我们就会在MSVC的TS里实现Concept. 我们可以通过VS2017包含的linux for…

0

总是设置不可能的目标

[原文地址]:https://blogs.msdn.microsoft.com/vcblog/2017/03/03/always-set-impossible-goals/ [发表时间]: 3/3/2017 Bogdan Mihalcea – MSFT   不可能的目标就像是梦想,我们总是带着梦想成真的希望在追逐。在我最近的一个体验中,我管理着一个功能组,C++快速加载项目(FPL),一个特殊的团队。就我个人而言,我对性能很感兴趣,因为我相信它使我们与心爱的机器之间的互动更让人满意。 随着时间的推移,大型代码库的增长,我们往往在使用Visual Studio时遇到低性能加载和构建。大部分的根源是来自于我们的项目系统体系结构。多年来,我们做了合理的改进,仅仅是想解决这些问题,由代码库稳定的增长率可以看出。硬件的改进,例如更好的CPU或者SSD帮助,但是它们没有产生很大的改变。 这个问题需要一个“不可能的目标”,所以我们决定把目标定很高,志在将解决方案的加载时间提高10倍! 疯了吗?不。尤其是因为多年来,我们几乎没有做出小的改进,现在目标设立好了?检查了,就开始行动,行动,行动!   几年前,当我在Visual Studio Graphics Debugger工作时,我遇到了类似的问题,加载巨大的捕获文件,需要做渲染(有时在REF驱动程序上,非常非常缓慢),这些花费了很长时间,特别是对于复杂的图形应用程序。当时,我采用了缓存机制,这使我们能够扩展和重复使用以前的计算,显著减少了重新加载的时间和内存消耗。 对于FPL,大概半年前,我们采取相似的策略。幸运的是,我们有一个好的起步从三年前我们创建的一个模型,那时我们没有时间完成的一个模型。 这一次,所有的东西都已齐备,我们能够贡献宝贵的资源实现这一点。这是一次非凡的旅程,因为我们必须以很快的速度交付,这一个功能可能会突破很多功能,而它的优点只是性能的提高。 我们开始玩非常大的解决方案,建立一个良好的基准。我们可以访问伟大的现实世界解决方案(不容易找到的,受IP约束) 以及我们内部和生成的解决方案。我们喜欢强调超出原始设计项目大小(500个项目)。这一次我们为了更好的体验推出一个“不可能的目标”(10倍的加载速度)。 主要的目标是提高解决方案的加载速度并大幅度的减少内存的消耗。在最初的设计中,我们总是在加载项目时都像第一次见到它们一样,计算它们的值并在内存中保存它们,准备编辑。从遥测数据来看,后者是完全没有必要的,因为大多数用户方案都是”只读的“ 。这是第一个大的需求,设计一个“只读的”项目系统能够向Visual Studio组件提供所需的信息,能不断地对它进行查询(Design Time工具,智能感知,项目扩展),第二个要求是确保我们尽可能的重复使用以前的负载。 我们把所有项目的“真实”加载和“评估”转变为一个out-of-proc服务,它使用SQLite存储数据并按需提供服务。这为我们提供了一个并行化项目加载的好机会,它本身也提供了巨大的性能改进。转变到out-of-proc还有一个很大的好处,减少了Visual Studio进程的内存占用,我可以轻易的加载数百MB的解决方案,甚至在GB范围的巨大解决方案 (2-3k个项目的解决方案)。这并不意味着我们只是移动内存使用到别的地方,我们实际上依赖于SQLite存储,我们不必加载MSBuild后面的重对象模型。   我们采取增量型的改进,我们根据客户对预发布产品的反馈调整和改进我们的解决方案。我们启用的第一个项目类型是Desktop,因为它是主要类型,紧接着是CLI项目类型。当所有的项目类型都不支持,将像早期版本一样”完全”加载,所以它们的功能很好,但是没有FPL的作用。 令人着迷的是,如何意外引入在原始设计不占用大量可能的负载的地方找到N ^ 2算法。他们是小的,相对于原来的大时代,但一旦我们添加缓存层,他们往往被放大。我们修复了其中的几个,并提高了性能。我们还花了大量时间尝试减少内存中大量计数对象的大小,主要是在解决方案项目内部表示。 从可用性的角度来看,我们仍然允许用户编辑他们的项目,只要他们尝试去“编辑”,我们无缝加载真正的基于MSBuild的项目,并委托给它,允许用户更改并保存它们。 我们还没有完成,我们还有很多事情要做。从用户的反馈,我们认识到我们需要强化我们的功能来保持缓存,及时在磁盘上更改时间戳(只要内容是相同的,一般情况:git分支切换,CMake重新生成)。   不可能的目标就像是魔法指南,给你长期的方向允许你打破陈规,让我们公平的把我们的思想束缚在预先存在的解决方案中!设立远大的梦想,然后努力追求!这被证明是一个伟大的策咯,因为他允许我们探索箱子之外的路径并最终产生奇妙的结果。不要期望一瞬间的满足,要实现大的成就,就要花费大量的时间,虽然目标很高,但那是值得的,但当你回头看时,你会看到你是多么接近一个不可能的梦想。  

0

二进制兼容性和无忧升级:为什么转换到Visual Studio 2017如此 “容易”

[原文发表地址]:Binary Compatibility and Pain-free Upgrade: Why Moving to Visual Studio 2017 is almost “too easy” [原文发表时间]:3/7/2017 与VS 2015相比,Visual Studio 2017在C ++功能方面有重大的飞跃。我们希望升级到新版本后能让您的日常工作变得更轻松。 这篇博客主要介绍从Visual Studio 2015升级到2017的步骤。正如我们在BUILD 2016会话中谈论的“将C ++代码转移到Visual Studio 2015的6个原因”(点击跳转到1h:04)。在这个版本中,我们团队使代码库移动到Visual Studio 2017非常容易。这里有四个原因。 通过Visual Studio 2017安装程序获取MSVC 2015.3工具集 在Visual Studio 2017中加载使用较老C++工具集的C++工程,并不会改变C++工程。 这允许你在以前的IDE中加载这个工程,以备你需要使用之前的IDE加载工程,或者你仍然有队友把VS没有完全升级到2017。为了使工程在Visual Studio 2017加载中不受到任何影响,就像在以前的版本中,IDE支持工程往返。 在以前的版本中,为了能够构建项目,必须同时安装最新版本和旧版本的Visual Studio。 现在Visual Studio 2017允许您直接安装MSVC 2015(v140)工具集,使其便于引导新机器,通过仅安装所需的工具集而不是整个VS 2015 IDE来减少安装所需的磁盘空间。 MSVC 2017 中的VC运行时与2015二进制兼容 这个版本的Visual Studio中C++编译器和库有很多改进,这将引导您转换到Visual Studio 2017的最新工具集(v141)-…

0

在Visual Studio中使用任何C++编译器

msvc-all-options
msvc-all-options

原文发表时间: 3/07/2017 原文发表地址: Use any C++ Compiler with Visual Studio 微软Visual Studio 2017支持几种C++编译器以适应各种各样的代码库。除了很多人熟悉的微软Visual C++编译器外, Visual Studio2017还支持Clang, GCC以及其他针对某些平台的编辑器。 这篇文章旨在令您熟悉各种与Visual Studio IDE兼容的C++编译器,并且使您清楚什么情况下能适用于您的项目。一些编译器能更好的适应您的需要,这些具体取决于您的项目或者所针对的情况。或者,您可能更有兴趣去了解新的语言功能,比如在不需要离开IDE的情况下,在所有编译器上都不可用的C++概念。 您可以在对C++ 项目的常规配置属性里,选择编译器和使用相应的”平台工具集“属性的工具集来生成项目。在”平台工具集”的下拉列表中会列出所有已安装的适用于您的项目类型的编译器。 微软C++编译器(MSVC) 如果您针对的是Windows系统, 微软C++编译器(MSVC)或许是一个好的选择。这是大多数Visual Studio C++项目的默认编译器。所以如果针对的是Windows,推荐使用这个。 Clang 针对安卓,iOS, 和windows系统, 您可以使用Visual Studio的Clang编译器。 如果您针对的是安卓系统,您可以使用带有Andriod NDK和工具链的Clang/LLVM编译器来生成您的项目。同样的,针对iOS系统, Visual Studio可以在Mac上使用Clang来运行生成项目。”C++的移动开发“工作负载中包含对Andriod 和iOS的支持。您可以在标有关键字”安卓“和”iOS“的文章里查阅更多有关于安卓和iOS的详细信息。 如果您针对的是Windows系统,您有如下几个选项: 1. 使用Clang/LLVM; “Windows的Clang”包含了在Visual Studio中安装Clang/LLVM平台工具集的说明。 2. 针对Windows使用Clang的Clang/C2(Clang前端的微软代码生成)。 如果你想利用Clang在Windows平台的语言功能引入一个代码库,使用Clang/C2可能是有意义的。由于代码生成和优化处理是由MSVC后端处理的,由Clang/C2生成的二进制文件是完全符合由MSVC生成的二进制文件。您可以从微软代码生成的Clang —或者查阅我们最近更新的带有关键字”clang“的文章来了解更多关于Clang/C2的信息 GCC 如果您针对的是Linux或者安卓系统,您可以考虑使用GCC。如同Clang一样, Visual Studio的C++安卓开发也支持使用带有安卓NDK的GCC来生成项目。对于Linux — 无论是远程或本地的Linux Windows子系统, 都可以使用GCC. 如果您想了解更多的如何使用Visual…

0

VS 2017 中的C++游戏开发工作负荷

原文发表时间: 3/07/2017 原文发表址: C++ game development workload in Visual Studio 2017 在Visual Studio 2017版本中我们将介绍一个全新的“使用C++的游戏开发”工作负荷,如果你想用C++创建高质量的游戏软件,这个工作负荷将会帮助你更容易地获取需要的工具。无论你是使用DirectX或是例如 Unreal或Cocos2d这样功能强大的游戏引擎,Visual Studio都可以同时安装这些你所需要的所有工作负荷。 在这篇博客中,我们会讨论如何来安装带有下面四个不同的C++游戏开发方案的Visual Studio: DirectX games for desktop,DirectX games for Universal Windows Platform (UWP), games with the Unreal Engine和 games with the Cocos2d engine。 安装带有DirectX 桌面开发的Visual Studio 首先,下载Visual Studio 2017。打开Visual Studio安装器界面,在“移动与游戏” 分类下选择“使用C++的游戏开发”工作负荷。这个工作负荷将会提供给你一些核心的工具来创建桌面DirectX游戏,包括Visual Studio核心编辑器,Visual C++编译器,Windows Universal C Runtime和Visual Studio调试器。 在安装界面右边的可选组件列表里你可以选择一些对创建DirectX游戏有用的附加组件。强烈推荐下面的组件: C++分析工具:包括DirectX的图形调试和一套内存,CPU以及GPU的分析工具。这个组件是默认被选的。 Windows…

0

VS 2017 RTM 关于STL 的修复

  [原文发表地址]VS 2017 RTM 关于STL 的修复 [原文发表时间] 2017/2/6 9:20AM VS 2017 RTM 版本很快就要发布了。 目前VS 2017 RC 已经投入使用,并且包含了我们在这里描述的所有改变 – 请尝试在IDE 的help >Send Feedback >Report A Problem (或者 Provide A Suggestion) 提交您的反馈信息。 关于STL 在VS2015 update 3 和 VS 2017 RTM之间的改变, 这是第三篇也是最后一篇博客。 在第一篇博客中(关于2017 Preview 4),我们详细地阐述了2015 和2017 版本是如何实现二进制兼容问题的。 在第二篇博客中(关于VS 2017 Preview 5),我们列举了那些添加到编译器和STL 的模块。(从此之后,我们已经实现了P0504R0中新引入的 in_place_t/in_place_type_t<T>/in_place_index_t<I> 和P0510R0 中抛弃的数组, 引用以及不完整类型变量。) Vector 修改:…

0

通过libuv使用可重入函数

[原文发表地址]通过libuv使用可重入函数 [原文发表时间] 2017/2/7 9:20AM 在这篇文章之前我们曾经就已经讨论过可重入函数了,甚至最近关于Visual Studio 2017 版本在我们的实现中已经就“yield”关键字在VS2017中被“co_yield”替换进行了更深入的讨论。这种有意义的C++ 标准模块让我非常兴奋, 因此在这篇博客中我很高兴和您分享一些在具体实践中是如何通过libuv 库来使用它。你可以用微软编译器或者其他支持可重入函数的编译器来使用这些代码,在进入这些代码之前,让我们首先认识下问题空间以及为什么你应该考虑它。 问题空间 等待磁盘的响应或者从网络上下载数据这本身就比较漫长,而且我们通常被告知写入块崩溃了, 对吗? 对于客户端编程而言,进行I/O 操作或者阻塞UI线程都将会引起诸如像app瘫痪或者挂起的这样糟糕的用户体验。对于服务器端编程而言,新的请求在其他线程都被阻塞的情况下,通常仅仅只需要创建一个新的线程, 然而这样会引起一个线程的资源利用率较低的问题,这些资源却往往并不便宜。   然而, 写一个高效的真正意义上的异步代码的确仍然存在一个普遍的困难。不同的平台提供了不同的机制以及实现异步的API。 许多的API也将不再支持异步的功能。通常,解决方案是通知辅助线程,这将会调用阻塞API, 并且返回结果到主线程。 这同样也是有一定难度的而且需要使用异步机制去避免并发问题。有一些库提供了基于这些不同机制的抽象, 然而,许多例子都包含了Boost ASIO,以及C++ Rest SDK 以及libuv。 Boost ASIO 和 Rest SDK 是C++ 库, 而libuv 是一个C 库。 在他们之间有一些重叠的地方, 但是他们都有他们各自的优势。   Libuv 是一个C库,它在Node.js 中提供了支持异步的I/O, 尽管Node.js 显式地为用户设计的这一功能, 但是它也可以独立使用并且提供了一个公共的跨平台API, 不需要顾及到多种特定平台异步的API。 另外,API 即使在Windows 上仍然是UTF8-only 格式, 这也是非常方便的。每一个会阻塞的API 可以接受一个指向回调函数的指针,当所有的请求操作完成后,这些回调函数将被调用。 一个事件循环启动等待多种请求完成以及调用特定的回调函数。对于我而言,…

0

yield”关键字在VS2017中被“co_yield”替换

原文发表地址] `yield` keyword to become `co_yield` in VS 2017 [原文作者] EricMittelette [原文发表时间] 2017/1/27 协程(Coroutines)—也就是之前我们说的”C++ resumable方法重入函数”—它作为技术规范TS的一部分已经在Visual C++编译器上实现.自2013年11月VC++ CTP release版本发布支持协程功能,已经有三年的时间. 如果你正在使用协程,你应该发现关键字’yield’在VS2017中被移除.如果你的代码里面含有’yield’关键字, 你需要将它们替换为’co_yield’.如果生成器使用了’yield 表达式’,这些也需要替换为’co_yield 表达式’. 如果想将’await’替换为’co_await’, 协程中的‘return’替换为’co_return’.新的Visual C++编译器也会接受这样的改变. 请参考协程技术规范: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4628.pdf 如果有什么问题,你也可以给我们发邮件或者在评论下面留言. 为什么这样改变 作为技术规格,协程还没有被C++标准采纳.Visual C++团队最初实现协程功能时,它还只是个有前景的C++特性.2015年10月,C++标准委员会投票引入前缀”co_”去替换关键字.委员会不想改变可能会引起冲突的正在使用的关键字.”yield”关键字已经被广泛使用在农业和财务相关的应用软件中.同时,thread support library线程支持库中的Ranges TS 关键字替换如下图   Instead of `await` Use `co_await` Instead of `return` Use `co_return` Instead of `yield` Use `co_yield` 我们在VS2017中移除了”yield”关键字是因为Range-V3特性的实现, 我们希望许多开发人员声明了ranges(using namespace ::ranges)后去调用”yield”….

0

Visual Studio Code C/C++ 扩展12月份的更新

[原文发表地址] December Update for the Visual Studio Code C/C++ extension [原文发表时间] 2016/12/12 在今年的//Build大会上我们推出了Visual Studio Code的C/C++扩展, 我们将保持每月发行的节奏和目标并不断对您的反馈做出回应。下面将介绍十二月份更新的一些功能: GDB用户的调试器可视界面的默认美观输出 在调试过程中能够映射到源文件 如果您还没来得及给我们提供反馈,为了这个扩展能够更好的满足您的需要,请您填一下这份快速调查问卷。最初的博客中已经更新了这些新功能,现在让我们一起仔细地逐一学习一下它们。 GDB用户的调试器可视界面的默认美观输出 使用美观输出器使GDB的输出更具有可用性,因此使调试更加地容易。美观输出现在可以被预先设置在‘launch.json’文件中的‘setupCommands’部分里,‘-enable-pretty-printing’的标志说明现在美观输出是可用的。这个标志可以传递到GDB MI来开启美观输出。 为了说明美观输出的优点,让我们来看看下面这个例子。 #include <iostream> #include <string> #include <vector> using namespace std; int main() { vector<float> testvector(5,1.0); string str = “Hello World”; cout << str; return 0; } 在一个实时调试会话中,让我们看一下如果没有开启美观输出时‘str’ 和‘testvector’的样子: 现在我们可以看到‘str’ 和‘testvector’的值看起来很隐晦很难懂…… 让我们再看一下开启了美观输出时‘str’ 和‘testvector’的值: 现在我们可以感受到这两个值是如此的简单明了!…

0