来一发Visual C++ 2015 引入更新的 C++ 特征到 Windows API
你一开始永远也看不到所有． 但总的大纲，你是清楚的．不是吗？ Visual C++ 2015 是 C++ 团队支付伟大勉力将古代C++引入windows平台的功效。在最新的几个刊行版本里，VC++已慢慢添加了古代C++言语和库的特征，这些联合在一同会发明一个用于构建通用windows App和组件的相对冷艳的开辟情况。Visual C++2015创立在初期版本引入的惊人前进，供应了成熟的、撑持大多半C++11特征和C++ 2015子集的编译器。你也许会嫌疑编译器撑持的完全水平，公平地说，我以为他能撑持大局部主要的言语特征，撑持古代C++将会迎来windows 法式库开辟一片新的六合。这才是关头。只需编译器撑持一个高效优雅的库的开辟情况，开辟者就可以构建巨大的app和组件。这里我不会让你看一个单调的新特征列表，或蜻蜓点水地看下它的功效，而是会带你阅读下一些传统情形下的庞杂代码如今若何让人相当兴奋书写。固然，这得益于成熟的Visual C++编译器。我将会向你展现windows的一些实质，在如今或未来API中实践上都是很主要的实质。
颇具取笑意味的是,关于COM来讲,C++已足够古代了.是的,我在议论组件对象模子(COM),多年以来,它一向是大多半Windows API的基石.同时,它也持续作为Windows运转时的基石.COM无可辩论的依靠于C++的原始设计,自创了很多来自C++的二进制和语义商定,然而它历来都不敷优雅.C++的局部内容被以为可移植性不敷,如dynamic_cast,必需防止利用它,以采取可移植的处理计划,这使得C++的开辟完成更具应战性.近年已为C++开辟者供应了很多处理计划,让COM变得加倍可移植.C++/CX 言语拓展,多是Visual C++团队到今朝为止最具野心的.具有取笑意味的是,这些提拔尺度C++撑持的勉力,已将C++/CX弃之掉臂了,也让言语拓展变得冗余.
为了证实这点,我会展现给你若何完全的用古代C++完成IUnknown和IInspectable接口.关于这两个接口没有甚么古代的或吸引力的器材.IUnknown持续成为出色API,如DirectX,的集中笼统.这些接口--IInspectable承继自IUnknown--位于Windows运转时的中间.我将展现给你若何不必任何言语拓展来完成它们,接口表或其它宏--只需求包括大批类型信息的高效和优雅的C++,就能够让编译器和开辟者具有,关于若何创立所需的,优良的人机对话.
次要的成绩是, 若何列出COM 或 Windows Runtime 类需求完成的接口, 并且要便利开辟者利用, 和编译器会见. 好比, 列出一切可用类型, 以便编译器查询, 乃至列举出响应的接口. 如果能完成如许的功效, 或许就可以让编译器生成 IUnknown QueryInterface 乃至 IInspectable GetIids 办法的代码. 这两个办法才是成绩的关头. 依照传统的不雅念, 独一的处理举措触及到言语扩大(language extensions), 万恶的宏界说, 和一堆难以保护的代码.
两种办法的完成, 都用到类需求完成的接口. 可变参数模板( variadic template)是首选:
template <typename ... Interfaces> class __declspec(novtable) Implements : public Interfaces ... { }; __declspec(novtable)拓展属性可以避免机关函数和析构函数初始化笼统类的vfptr,这凡是意味着削减大批的代码.完成类模板包含一个模板参数包,这使它成为一个可变模板.一个参数包即一个模板参数承受恣意数量的模板参数变量.然而在这类情形下,我描写的模板参数将只会在编译时停止查询.接口将不会呈现在函数的参数列表当中.
这些参数的一个利用已不言而喻.参数包拓展后成为公共基本类的参数列表.固然,我依然有义务到最初完成这些虚函数,然而此刻我会描写一个完成恣意数量接口的一个详细类:
class Hen : public Implements<IHen, IHen2> { }; 由于参数包拓展为指定基本类的列表,一切它同等于上面我能够会写出的代码:
class Hen : public IHen, public IHen2 { }; 用这类体例布局化完成类模板的美好的地方在于,我如今可以,在完成类模板中,写入各类样版完成代码,而Hen类的开辟者则可使用这类不冒昧的笼统,同时大批疏忽隐含的细节.
到今朝为止,一切都很好.如今,我将思索IUnknown的完成.我应当可以在完成类模板中完全的完成它,并供应编译器如今所具有的类型信息.IUnknown供应了关于COM类十分主要的两种东西,就像氧气和水关于人类一样.第一个能够复杂些的是援用计数,这也是COM对象跟踪它们性命周期的体例.COM划定一种侵入式的援用计数,它借助于每一个对象,统计几何个内部援用存在,来担任办理本人的性命周期.这与智能指针,如C++ 11的shared_ptr类,的援用计数恰好相反,智能指针对象其实不晓得它的同享关系.你能够会争辩这两种体例的优弱点.然而,实践上COM的办法凡是更高效,这也是COM的任务体例,你必需处置它.假如没有其它的,你极可能会赞同这点,在shared_ptr外面包装一个COM接口会是一件极不友爱的工作!
我将以只要运转时的开支作为入手下手,它是经由过程完成类模板引见的:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {} 默许机关函数并非真实的开支地点,它只是复杂切实其实保终究的机关函数--它将初始化援用计数--为protected而不是public的.援用计数和虚拟造函数都是protected的.让派生类会见援用计数,是为了答应更庞杂的类组合.大多半类可以复杂的疏忽它,然而需求注重的是,我正初始化援用计数为1.这和凡是建议初始化援用计数为0,构成光鲜的对照,由于此时并没有处置援用.这个体例在ATL中十分盛行,分明遭到Don Box的COM实质论的影响,然而这长短常有成绩的,ATL的源代码的研讨可以作为左证.入手下手于这个假定,即援用的一切权将会当即由挪用者取得,或依靠于一个供应更少毛病机关处置的智能指针.
虚析构函数供应了很大的便当性,它答应完成类模板完成援用计数,而不是强迫完成类自己来供应完成.另外一个选项,是利用奇异的递归模板形式(Curiously Recurring Template Pattern)来防止利用虚函数.凡是我会选择这个办法,然而它会略微增添笼统的庞杂性,同时,由于COM类自己有一个vtable,所以这里也没有甚么来由去防止利用虚函数.有了这些根基类型以后,在完成类模板中完成AddRef和Release将会变得十分复杂.起首,AddRef办法可以复杂的利用InterlockedIncrement来增添援用计数:
virtual unsigned long __stdcall AddRef() noexcept override { return InterlockedIncrement(&m_references); } 这不言自明.不要想出某些庞杂的办法,经由过程利用C++的加减操作符来有前提的交换InterlockedIncrement和InterlockedDecrement函数.ATL经由过程极大的增添庞杂性去做这个测验考试.假如你思索效力,宁可为防止挪用AddRef和Release发生错误而多花心思.一样的,古代C++增添了对move语义的撑持,和增添转移援用一切权的才能.如今,Release办法只是略显庞杂:
virtual unsigned long __stdcall Release() noexcept override { unsigned long const remaining = InterlockedDecrement(&m_references); if (0 == remaining) { delete this; } return remaining; } 援用计数削减后,了局被赋值给一时变量.这很主要,由于了局需求前往.然而假如对象烧毁了,援用此对象的成员变量就长短法的了.假定没有其它未处置的援用,这个对象就经由过程后面说到的虚析构函数删除.这就是援用计数的结论,完成类Hen依然和之前的一样复杂:
class Hen : public Implements<IHen, IHen2> { }; 如今，到了想象一下QueryInterface的奇奥世界的工夫了。完成IUnknown办法是一个很主要的理论。在我的Pluralsight课程中，我普遍的完成了它。你可以在Don Box编写的<<COM实质论>>(Addison-Wesley Professional，1998)一书中，浏览关于完成你本人的IUnknown的奇奥的和难以想象的办法。需求注重的是，固然这是一本关于COM的优异书本，然而它是基于C++98的，并没有出现出任何古代C++的特点。为了节俭工夫，我假定你已熟习了QueryInterface的完成进程，并集中于若何用古代C++完成它。上面是虚函数自己:
virtual HRESULT __stdcall QueryInterface( GUID const & id, void ** object) noexcept override { } 给定一个GUID用来标识一个出格的接口以后，QueryInterface应当来决意一个对象是不是完成了需求的接口。假如完成了，它必需削减这个对象的援用计数，同时经由过程内部参数来前往所需的接口指针。假如没有完成，它必需前往一个空指针。因而，我将以一个粗略的轮廓来作为入手下手:
*object = // Find interface somehow if (nullptr == *object) { return E_NOINTERFACE; } static_cast<::IUnknown *>(*object)->AddRef(); return S_OK; QueryInterface起首会测验考试想法查找所需的接口。假如接口受不撑持，则前往E_NOINTERFACE毛病码。请注重，我是若何依照请求处置接口指针不撑持的情形。你应当把QueryInterface接口看做是二元的操作。它要末胜利找到所需的接口，要末查找掉败。不要测验考试发扬发明性，只需求根据前提呼应便可。虽然COM标准有一些限制项，然而大多半花费者城市复杂的假定接口不受撑持，而不论你会前往何种毛病码。在你的完成中的任何毛病，都毫无疑问的会招致你堕入调试的深渊。QueryInterface长短常基本的，不克不及胡乱看待。最初，AddRef由接口指针再次挪用，用来撑持某种少少的而又答应的类组合场景。这些不受完成类模板的显式撑持，然而我宁愿在这里做一个榜样。主要的是，记住援用计数操作是面向接口的，而不是面向对象的。你不克不及 复杂的，在属于一个对象的恣意接口下面，挪用AddRef或Release。你必需依附COM划定规矩来办理对象，不然你会冒险引入以难以想象的体例溃散的不法代码。
然而我若何得知，恳求的GUID是不是就代表着类想要完成的接口呢？我需求回到完成类模板搜集的类型信息的中央，个中类型信息经由过程它的模板参数包来搜集。请记住，我的方针是准予编译器为我完成它。我但愿终究代码，和我手写的一样高效，乃至更好。我会经由过程可变函数模板纠合来停止查询，函数模板本身包含模板参数包。我将以BaseQueryInterface函数模板作为入手下手:
virtual HRESULT __stdcall QueryInterface( GUID const & id, void ** object) noexcept override { *object = BaseQueryInterface<Interfaces ...>(id); BaseQueryInterface实质上是IUnknown QueryInterface的古代C++版本。它直接前往接口指针而不是HRESULT类型。空指针则标明掉败的情形。它承受单一函数参数，GUID标识着要查找的接口。更主要的是，我拓展了类模板参数包为完全形式，如许，BaseQueryInterface函数就能够入手下手列举接口的处置进程。 后来你能够会以为，因为BaseQueryInterface是完成类模板的成员函数，所以它可以复杂直接的会见接口的链表，然而我需求准予这个函数剥离链表中的第一个接口，就像上面如许:
class Hen : public Implements<IHen, IHen2> { };0 依照这类体例，BaseQueryInterface函数能辨认第一个接口，而且给接上去的搜刮留不足地。看吧，COM有必定数目的特别划定规矩来撑持QueryInterface 完成或最少承受对象辨认。特别是恳求IUnknown，必需老是前往切实不异的指针，客户端才干肯定两个接口的指针是不是来自统一个对象。因而，BaseQueryInterface函数最棒的中央就是完成了这些假定。所以，可以从首个代表类想要完成的第一个接口的模板参数的GUID恳求的对照入手下手。假如不婚配，我会反省IUnknown是不是入手下手恳求了：
class Hen : public Implements<IHen, IHen2> { };1 假定有一个婚配的，我直接正确无误的前往了第一个接口的指针。static_cast 能确保编译器基于IUnknown的多种接口不会引发歧义。cast只是校准了指针，让类的vtable能找到准确的指针地位，由于一切vtable接口是以IUnknown的三个办法入手下手的，这十分合适逻辑。
而我无妨一样添加IInspectable查询的可选撑持。IInspectable相当反常，在某种意义上，它是Windows运转时接口，由于每一个Windows运转时估计编程言语（如 C# 和 JavaScript）必需直接来自IInspectable，而不单单只是IUnknown接口。相对C++的任务体例和COM传统的界说体例，以顺应公共言语运转库的体例完成对象和接口是不幸的现实。更不幸的是当对象组合的时分对功能的影响，我会鄙人文中会商。至于QueryInterface，我只需确保IInspectable能被查询，它应当是一个Windows运转时类的完成，而不是一个复杂的典范COM类。固然关于IUnknown的明白的COM划定规矩不合用于IInspectable，我可以复杂的用不异的体例看待后者。但这两个应战。起首，需求懂得是不是有任何IInspectable派生出来的接话柄现。第二，需求懂得接口的类型，如许就能够准确的前往一个没有歧义的调剂过的接口指针。假定列表中的第一个接口都是基于IInspectable，那可以只更新BaseQueryInterface 以下：
class Hen : public Implements<IHen, IHen2> { };2 注重，我用的是C++ 11中的is_base_of 的特征，来肯定第一个模板参数是一个IInspectable的衍生接口。万一完成典范的COM类不撑持Windows运转时，就可以确保随后的对比是由编译器扫除的。如许我可以无缝地撑持Windows运转时和经典的COM类，即没有增添组件开辟人员的语句庞杂性，也没有任何不用要的运转时开支。然而，假如刚好遇罗列出来得首位不是IInspectable接口，就会有不轻易发觉的Bug的隐患。所需求做的就是，用某种办法替换is_base_of来扫描全部接口的列表：
class Hen : public Implements<IHen, IHen2> { };3 IsInspectable 也是基于is_base_of特征的，然而以后合用于婚配接口。假如没找到基于IInspectable 的接口则终止：
class Hen : public Implements<IHen, IHen2> { };4 我会禁用失落八怪七喇的默许参数。假定 IsInspectable 前往的是 true，我需求找到第一个IInspectable-based 接口：
class Hen : public Implements<IHen, IHen2> { };5 再次利用 is_base_of 特征，但此次要前往一个真实婚配的接口指针：
class Hen : public Implements<IHen, IHen2> { };6 BaseQueryInterface 这时候可以使用IsInspectable 和 FindInspectable 一同来撑持查询 IInspectable:
class Hen : public Implements<IHen, IHen2> { };7 然后指定详细的 Hen 类:
class Hen : public Implements<IHen, IHen2> { }; 完成类的模板，可以确保编译器能生成更高效的代码，不论 IHen、Hen2 来自 IInspectable 仍是 IIUnknown （或其他接口）。如今，我可以最初完成 QueryInterface 的递归局部，和任何追加的接口，例如下面例子中的 IHen2。BaseQueryInterface 是靠挪用 FindInterface 函数模板停止的：
class Hen : public Implements<IHen, IHen2> { };9 注重，我挪用这个FindInterface函数模板，大致同等于我本来挪用的BaseQueryInterface，在这个例子中，我向它传递接口的其他局部。我特地再次扩展参数包,如许它可以在列表的其他局部辨认第一接口。但会提醒一个毛病。因为模板参数包不是以函数实参来扩大的，这能够会变得辣手，编程言语写不出来我想要的。更多的时分，这类“递归的”FindInterface可变模板恰是你想要的：
class Hen : public IHen, public IHen2 { };0 它会从模板参数的其他局部平分离，假如有婚配就前往调剂过的接口指针。别的，它也会挪用本人，直到list取完。当我笼统地说起编译期递归时，主要的是要注重这个函数模板，和其他相似的完成类模板的例子，在手艺上递归，而不是在编译期。每一个函数模板的实例挪用分歧的函数模板的实例。例如，FindInterface<IHen, IHen2> 挪用 FindInterface<IHen2>， FindInterface<IHen2>挪用 FindInterface<>。为了让它递归， FindInterface<IHen, IHen2>不需求挪用FindInterface<IHen, IHen2>。
虽然如斯，仍是要记住，如许的“递归”产生在编译时，它就像你本人手写的一条条if语句。然而，如今，我碰到费事了。这个序列若何终止呢？固然是当模板参数列表为空的时分。这个成绩在于C++已界说了空模板参数列表的寄义:
class Hen : public IHen, public IHen2 { };1 这几近是准确的，然而编译器会提醒你，函数模板在这个特化中没法利用。同时，假如我不供应终止函数，当参数包为空的时分，编译器将没法编译终究的挪用。这不是函数重载的情形，由于参数列表照旧是不异的。侥幸的是，处理计划十分复杂。我可以经由过程供应一个无名的默许参数，来防止终止函数看起来像一个特化:
class Hen : public IHen, public IHen2 { };2 编译器乐于此，同时，假如恳求一个不撑持的接口，终止函数会复杂的前往一个空指针，同时虚函数QueryInterface将前往E_NOINTERFACE毛病码。对IUnknown而言，这思索得很周密。假如你所关怀的是经典的COM，你可以平安的停在那边，由于那就是你所需求的一切内容。关于这点，可以重复的操作，编译器将优化QueryInterface的完成，其间利用各类各样的“递归的”函数挪用和常量表达式，代码最少和你手工写的一样好。关于IInspectable而言，一样的体例也能够完成。
关于Windows 运转时类，完成IInspectable会增添额定的庞杂度。这个接口并不是是和IUnknown一样的基本性接口，它供应了一些不肯定的东西的纠合，而IUnknown则供应了相对基本的函数。关于此，我会为今后的文章留下一个会商，并聚焦于撑持恣意Windows运转时类的高效和古代的C++完成。起首，我会避开GetRuntimeClassName和GetTrustLevel虚函数。完成这两个办法绝对而言微乎其微，同时因为少少利用，所以它们的完成可以复杂敷衍一下。GetRunTimeClassName办法，需求前往这个对象所代表的运转时类的完全名字的字符串。我将把这留给类本身去完成，决意是不是去如许做。完成类模板可以复杂地前往E_NOTIMPL，用来标明此办法并未完成:
class Hen : public IHen, public IHen2 { };3 一样的，GetTrustLevel 办法也会复杂前往列举类型的常量:
class Hen : public IHen, public IHen2 { };4 需求注重的是，我并没有显示的标志这些IInspectable办法为虚函数。防止声明为虚函数，是为了让编译器剔除这些函数，COM类无需真实的完成任何 IInspectable 接口。如今，我将注重力转移到IInspectable GetIids 办法。这比 QueryInterface 更轻易发生毛病。虽然它的完成不是那末严厉，然而一个高效的编译器生成的完成也是可取的。GetIids 前往一个静态分派的 GUID 数组。每一个 GUID 代表一个对象要完成的接口。后来你能够会以为，这只是对象经由过程 QueryInterface 所撑持的一个复杂的声明，然而那只在外表上看是准确的。GetIids 办法能够会保存一些接口而不公然。不论如何，我会以根基界说作为入手下手：
class Hen : public IHen, public IHen2 { };5 第一个参数指向挪用者供应的变量，个中 GetIids 办法必需设置它为了局数组中的接口数量。第二个参数指向一个 GUID 数组，同时也暗示着这里的完成是若何将静态分派的数组前往给挪用者的。此处，我排除了这二者参数，只是为了平安起见。如今我需求决意这个类完成几何个接口。我想说的是，利用 sizeof 操作符，它可以肯定这个参数包的巨细，以下:
class Hen : public IHen, public IHen2 { };6 这相当便利，同时，编译器也会呈报参数包拓展后要展示的模板参数的数量。这也是一个无效的常量表达式，它会在编译时发生一个值。我之前略为说起的，这没法完成的缘由是，GetIids的完成会保存一些他们不肯和其别人同享的接口，这相当广泛。这些接口被称为隐含接口。任何人都可以经由过程QueryInterface来查询它们，然而GetIids不会告诉这些接口是可用的。如许，我需求为扫除了隐含接口的可变sizeof操作符，供应一个编译时的替换品。同时，我需求供应某种体例来声明和标识这些隐含接口。我今后者作为入手下手。关于组件开辟人员，我但愿让完成类变得尽量复杂，如许就需求一个不太惹人注重的技能。我复杂的供应一个Cloaked类模板，用来“润色”恣意的隐含接口:
class Hen : public IHen, public IHen2 { };7 然后，我决意在类Hen上完成一个出格的"IHenNative"接口，并不是一切的利用者都晓得它的存在:
class Hen : public IHen, public IHen2 { };8 因为Cloaked类模板承继自它的模板参数，所以已存的QueryInterface完成可以持续无缝任务。我已增添了一点额定的编译时的类型信息，如今我可以查询它们。由此，我会界说一个IsCloaked类型，如许，我就能够很轻易的查询恣意接口以判别它是不是被埋没:
class Hen : public IHen, public IHen2 { };9 如今，我可使用一个递归的可变函数模板，来盘算未埋没的接口数量:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}0 固然，我需求一个终止函数，可以复杂的前往0:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}1 利用古代C++在编译时停止算术盘算的壮大才能使人呆头呆脑，同时也复杂的使人赞叹。如今我经由过程恳求数目来持续完美GetIids的完成:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}2 一个不太美满的中央是，编译器对常量表达式的撑持还不是很成熟。虽然，这毫无疑问是一个常量表达式，然而编译器却不会如斯对待constexpr成员函数。幻想情形下，我可以标识CountInterfaces函数模板为constexpr，同时了局表达式也将是一个常量表达式，然而，编译器不会这以为。另外一方面，无庸置疑，编译器会优化这段代码。如今，不论是甚么缘由，假如CountInterfaces没有找到隐含接口，GetIids会复杂的前往胜利，由于了局数组会为空:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}3 一样的，这也是一个无效的常量表达式，编译器会无需任何前提的生成代码。换句话说，假如没有未埋没的接口，剩下的代码会复杂的从完成中删除。不然，代码的完成，会强迫请求利用传统的COM分派器，分派一个公道巨细的GUID数组:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}4 固然，这能够掉败，在这类情形下，我复杂的前往适合的HRESULT值:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}5 在这点上，GetIids筹办好一个数组用来寄存GUID。就像你所等候的那样，我需求最初一次列举接口，然后拷贝每一个未埋没的接口的GUID到这个数组当中。我将利用一组函数模板，就像我之前利用的那样:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}6 这个可变模板（第二个函数）可以复杂的利用IsCloaked类型来决意，在增添指针之前，是不是拷贝由First模板参数标识的接口的GUID。利用这类体例，可以遍历数组，而无需纪录它包括几何个元素，或它将写入数组的哪一个地位。我也制止了关于常量表达式的正告:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}7 如你所见，在最初“递归”挪用CopyInterfaces利用了能够增添的指针的值。我几近完成了(全部完成进程)。在前往给挪用者之前，GetIids的完成可以经由过程挪用CopyInterfaces来填凑数组:
protected: unsigned long m_references = 1; Implements() noexcept = default; virtual ~Implements() noexcept {}8 关于Hen类来讲，编译器在它下面的一切操作都是通明的（它完整不晓得这些操作）:
class Hen : public IHen, public IHen2 { };8 这就是一个好的库所应当有的模样。Visual C++ 2015编译器供应了Windows平台上面关于尺度C++的完善撑持。它答应C++开辟者创立优雅而高效的库。这一样撑持利用尺度C++开辟Windows运转时组件，和完整利用尺度C++编写的通用的Windows使用法式。完成类模板仅仅只是古代C++针对Windows运转时的一个例子。(检查 moderncpp.com).
Kenny Kerr 是一名加拿大的开辟者，一样也是Pluralsight的作者，和微软的MVP。 它的博客是 kennykerr.ca。你可以存眷他的Twitter账号twitter.com/kennykerr。
多谢微软的手艺专家James McNellis核阅这篇文章。
原文地址：http://msdn.microsoft.com/en-us/magazine/dn879357.aspx
你一开始永远也看不到所有． 但总的大纲，你是清楚的．不是吗？ 只有想不到的”，“团结就是力量”，“实践是检验真理的标准”，“不耻下问”……的寓意。 大学C++老师开始上课就告诉我们了这个秘诀，而听取得人不多，所以最后很大一批转Java了。对于一个初学者来说，熟悉语法、锻炼手感和培养思维最好得办法就是code. 慢慢得，你会发现你得问题强人基本解决不了，不是你超过他，而是你们关注领域不同，这个时候，你自己也成为强人了，嘿嘿！！ 否极泰来。在你专注一个技术极度郁闷得时候不要放弃，可以暂时放弃，但是请马上回来，因为灵感在等你。黎明前确实是黑暗，但是到了黎明，下面就是很长一段得光明。 在实训中，我也学会了与别人合作。由于这次实训，单双学号的同学的实验不一样，然而我的四个舍友都是双号，唯独我一人是单号，不过同班的还有三位单号的女同学在我隔壁宿舍，于是我常过去她们宿舍那跟她们一起讨论，一起思考，互相交流。 简单控件??是VC++吧？那就写按钮 文本框 。。。。简单的就行了选修交上点东西就及格了 ！！如： 通过这门课程，增加了我学习软件技术的兴趣。 不过根据你提供的信息.你应该是在校学生. 当然可能关于面向对象,设计模式.重构.敏捷开发.等比较少. 关于C++与C语言的规范化问题。众所周知，C++是从C语言发展而来的，所以在C++中就不可避免的夹杂些C留下来的糟粕（使用C语言的请见谅）。 关于C++中string和vector的使用，在C++的规范标准之后，正式提出了标准库类型string和vector。 照着书上（好书，大家认可得）敲，编译，并思考，你会发现很多问题，解决问题的同时你正在提高。 我觉得你一开始..应该学好\\\\\\\\\\\\\\\"数学\\\\\\\\\\\\\\\", \\\\\\\\\\\\\\\"数据结构\\\\\\\\\\\\\\\" \\\\\\\\\\\\\\\"算法\\\\\\\\\\\\\\\", \\\\\\\\\\\\\\\"英语\\\\\\\\\\\\\\\"记住.学语言.不仅仅是学语言. 语言仅是一种表达方式而已.. 下午把最后一部分附录的标准库看完时，还有是点小激动~ 第5版已经买好，准备用半个月的时间，把第5版看看，然后把重点的知识做一个归纳。 关于用类来控制C++的内存分配，应该算是C++的一个高级技法。写的好的C++程序，基本看不到delete与new。因为这些内存的分配，销毁都让一特殊的类去管理。 在编程序时，我也学会了敢于尝试，“不试不知道，试试就能行”这是我在实训中领悟的道理之一。 在C++里边就成读者负担了！ 虽然还不明确软件技术包含的具体内容，但从C++语言这门课程开始，已发现程序设计的乐趣，在学习C++语言的过程中也学到了许多计算机应用基础知识，对计算机的机体也有了一个大体的了解。 北邮历来都是学C++的，干嘛大家都搞得象是学C出身，然后狂鄙视学C++的，只能说明一点，他们两者都顺手拈来，已经完全融会贯通。 整本书看来，第一部分基本语言是最简单的一部分，内容基本上是C的内容，与此同时，语法细节也较多，第一遍看时，不必在意。 程序.最主要的是实践.就我所学过的语言来说(差不多十门), C++应该是其中最难的.
页:
[1]