初学者怎样看懂c++代码
2018-12-03 19:37:10 qq_40592484 阅读数 263

程序执行过程中最重要的是函数调用
但是C++不像java,简单好学,复杂类型都是指针引用
写程序的都要会C++ 只有理解了C++/C ,才能懂计算机 ,只有理解了计算机,才能程序少出bug
C++的函数调用可以分三步

#include <iostream>
#include <string>
using namespace  std;
class Fa{
public:
    int a;
    int b;
    string c;
    Fa(const Fa& fa){
        cout<<"copy constructor called"<<endl;
        a = fa.a;
        b =fa.b+1;
        c = fa.c;
        cout<<"b:"<<this->b<<endl;
    }
    ~Fa(){
        cout<<"b:"<<this->b<<endl;
        cout<<"deconstractor called"<<endl;
    }
    Fa(){
    cout<<"b:"<<this->b<<endl;
    cout<<"constractor called"<<endl;
    }
};

Fa Process(Fa);

int main(){
    Fa fa;
    Fa fb=Process(fa);
    cout<<fb.b<<endl;
}

Fa Process(Fa fc){
    return fc;
}

这是一段简单的不能在简单的代码 就用它来解释
int main(){
整一个fa对象出来
Fa fa;
这一步执行的是 Fa fc(fa) 这就是函数入栈的过程 ,应为这是值传递 所以要经过拷贝构造函数
第二步 就是return fc 就要把Fa fb(fc) 这一步就是把函数的返回值保存至寄存器,并且 传给fb ,是不是和其他语言不一样
其实其他语言只是帮我们简化了这了流程 但是如果做C++不理解的话 含有指针的类对象 经过浅拷贝 如果一旦delete 回收 掉,那么就会出现野指针 程序就崩溃了

_____________________

Fa Process(Fa fc){
return fc;
}


Fa fb=Process(fa);
cout<<fb.b<<endl;

}
在这里插入图片描述
这个地方通过一个b值就可以看出
process函数 栈被回收,fc立即回收,所以就是中间的打印值就是1

2013-11-04 14:53:10 xxlblue 阅读数 1012
C++代码一直以其运行时的高性能高调面对世人, 但是说起编译速度,却只有低调的份了。本文介绍了加快C++编译速度的方法,一起来看。


C++代码一直以其运行时的高性能高调面对世人, 但是说起编译速度,却只有低调的份了。比如我现在工作的源代码,哪怕使用Incredibuild调动近百台机子,一个完整的build也需要四个小时,恐怖!!!虽然平时开发一般不需要在本地做完整的build,但编译几个相关的工程就够你等上好一段时间的了(老外管这个叫monkey around,相当形象)。想想若干年在一台单核2.8GHZ上工作时的场景 - 面前放本书,一点build按钮,就低头读一会书~~~往事不堪回首。

可以想象,如果不加以重视,编译速度极有可能会成为开发过程中的一个瓶颈。那么,为什么C++它就编译的这么慢呢?

我想最重要的一个原因应该是C++基本的"头文件-源文件"的编译模型:

1.每个源文件作为一个编译单元,可能会包含上百甚至上千个头文件,而在每一个编译单元,这些头文件都会被从硬盘读进来一遍,然后被解析一遍。 

2.每个编译单元都会产生一个obj文件,然后所以这些obj文件会被link到一起,并且这个过程很难并行。
这里,问题在于无数头文件的重复load与解析,以及密集的磁盘操作。

下面从各个角度给出一些加快编译速度的做法,主要还是针对上面提出的这个关键问题。

一、代码角度

1、在头文件中使用前置声明,而不是直接包含头文件。

不要以为你只是多加了一个头文件,由于头文件的"被包含"特性,这种效果可能会被无限放大。所以,要尽一切可能使头文件精简。很多时候前置申明某个namespace中的类会比较痛苦,而直接include会方便很多,千万要抵制住这种诱惑;类的成员,函数参数等也尽量用引用,指针,为前置声明创造条件。

2、使用Pimpl模式

Pimpl全称为Private Implementation。传统的C++的类的接口与实现是混淆在一起的,而Pimpl这种做法使得类的接口与实现得以完全分离。如此,只要类的公共接口保持不变,对类实现的修改始终只需编译该cpp;同时,该类提供给外界的头文件也会精简许多。

3、高度模块化

模块化就是低耦合,就是尽可能的减少相互依赖。这里其实有两个层面的意思。一是文件与文件之间,一个头文件的变化,尽量不要引起其他文件的重新编译;二是工程与工程之间,对一个工程的修改,尽量不要引起太多其他工程的编译。这就要求头文件,或者工程的内容一定要单一,不要什么东西都往里面塞,从而引起不必要的依赖。这也可以说是内聚性吧。

以头文件为例,不要把两个不相关的类,或者没什么联系的宏定义放到一个头文件里。内容要尽量单一,从而不会使包含他们的文件包含了不需要的内容。记得我们曾经做过这么一个事,把代码中最"hot"的那些头文件找出来,然后分成多个独立的小文件,效果相当可观。

其实我们去年做过的refactoring,把众多DLL分离成UI与Core两个部分,也是有着相同的效果的 - 提高开发效率。

4、删除冗余的头文件

一些代码经过上十年的开发与维护,经手的人无数,很有可能出现包含了没用的头文件,或重复包含的现象,去掉这些冗余的include是相当必要的。当然,这主要是针对cpp的,因为对于一个头文件,其中的某个include是否冗余很难界定,得看是否在最终的编译单元中用到了,而这样又可能出现在一个编译单元用到了,而在另外一个编译单元中没用到的情况。

之前曾写过一个Perl脚本用来自动去除这些冗余的头文件,在某个工程中竟然去掉多达了5000多个的include。

5、特别注意inline和template

这是C++中两种比较"先进"的机制,但是它们却又强制我们在头文件中包含实现,这对增加头文件的内容,从而减慢编译速度有着很大的贡献。使用之前,权衡一下。

二、综合技巧

1、预编译头文件(PCH)

把一些常用但不常改动的头文件放在预编译头文件中。这样,至少在单个工程中你不需要在每个编译单元里一遍又一遍的load与解析同一个头文件了。

2、Unity Build

Unity Build做法很简单,把所有的cpp包含到一个cpp中(all.cpp) ,然后只编译all.cpp。这样我们就只有一个编译单元,这意味着不需要重复load与解析同一个头文件了,同时因为只产生一个obj文件,在链接的时候也不需要那么密集的磁盘操作了,估计能有10x的提高,看看这个视频感受一下其做法与速度吧。

3、ccache

compiler cache, 通过cache上一次编译的结果,使rebuild在保持结果相同的情况下,极大的提高速度。我们知道如果是build,系统会对比源代码与目标代码的时间来决定是否要重新编译某个文件,这个方法其实并不完全可靠(比如从svn上拿了上个版本的代码),而ccache判断的原则则是文件的内容,相对来讲要可靠的多。

很可惜的是,Visual Studio现在还不支持这个功能 - 其实完全可以加一个新的命令,比如cache build,介于build与rebuild之间,这样,rebuild就可以基本不用了。

4、不要有太多的Additional Include Directories

编译器定位你include的头文件,是根据你提供的include directories进行搜索的。可以想象,如果你提供了100个包含目录,而某个头文件是在第100个目录下,定位它的过程是非常痛苦的。组织好你的包含目录,并尽量保持简洁。

三、编译资源

要提高速度,要么减少任务,要么加派人手,前面两个方面讲得都是减少任务,而事实上,在提高编译速度这块,加派人手还是有着非常重要的作用的。

1、并行编译

买个4核的,或者8核的cpu,每次一build,就是8个文件并行着编,那速度,看着都爽。 要是你们老板不同意,让他读读这篇文章:Hardware is Cheap, Programmers are Expensive

2、更好的磁盘

我们知道,编译速度慢很大一部分原因是磁盘操作,那么除了尽可能的减少磁盘操作,我们还可以做的就是加快磁盘速度。比如上面8个核一块工作的时候,磁盘极有可能成为最大的瓶颈。买个15000转的磁盘,或者SSD,或者RAID0的,总之,越快越好。

3、分布式编译

一台机子的性能始终是有限的,利用网络中空闲的cpu资源,以及专门用来编译的build server来帮助你编译才能从根本上解决我们编译速度的问题,想想原来要build 1个多小时工程的在2分钟内就能搞定,你就知道你一定不能没有它 - Incredibuild。

4、并行,其实还可以这么做。

这是一个比较极端的情况,如果你用了Incredibuild,对最终的编译速度还是不满意,怎么办?其实只要跳出思维的框架,编译速度还是可以有质的飞跃的 - 前提是你有足够多的机器:

假设你有solution A和solution B,B依赖于A,所以必须在A之后Build B。其中A,B Build各需要1个小时,那么总共要2个小时。可是B一定要在A之后build吗?跳出这个思维框架,你就有了下述方案:

◦同时开始build A和B 。 

◦A的build成功,这里虽然B的build失败了,但都只是失败在最后的link上。

◦重新link B中的project。

这样,通过让A的build与B的编译并行,最后link一下B中的project,整个编译速度应该能够控制在1个小时15分钟之内。

2010-07-14 17:52:00 progliker 阅读数 361

简述(brief description)和详述(detailed description)

 

详述的几种方式

 

1. JavaDoc style

     /**
* ... text ...
*/
2. Qt style
    /*!
* ... text ...
*/
3. C++ comment style
    ///                            
/// ... text ...
///
or
//!
//! ... text ...
//!
4. Block style
    /********************************************//**
* ... text
***********************************************/
(note the 2 slashes to end the normal comment block and start a special comment block).
or
    /////////////////////////////////////////////////
/// ... text ...
////////////////////////////////////////////////
简述的几种方式
1. /brief command
    /*! /brief Brief description.
* Brief description continued.
*
* Detailed description starts here.
*/
2. 设置JAVADOC_AUTOBRIEF , 第一句作为描述
    /** Brief description which ends at this dot. Details follow
* here.
*/
3. C++ style
   /// Brief description.
/** Detailed description. */
or
   //! Brief descripion.

//! Detailed description
//! starts here
示例, 使用Qt style

JavaDoc style, JAVADOC_AUTOBRIEF set to YES:


参考 http://www.stack.nl/~dimitri/doxygen/docblocks.html

2015-05-28 10:41:00 renwotao2009 阅读数 638

1. 介绍

C++程序编译很慢,特别是大型工程,你都可以趁着编译的功夫喝杯咖啡。这里面既有天灾也有人祸。

天灾请看此文,本文探讨怎么避免人祸。

2. 编译过程

后文需要,我们先了解C++源代码的编译过程
这里写图片描述
为叙述方便,图中各文件类型称呼如下:

  • .h 头文件
  • .cc 源文件
  • .o 目标文件

本文不探讨链接过程,只考虑编译和预处理。

预处理

经过预处理后,头文件就消失了。因为 #include 预处理指令将其展开在源文件中,编译阶段是不需要头文件的。常见的预处理指令还有 #if, #elif, #end, #ifndef, #define 等。

#include 其实非常简单,就是把文件在当前位置展开,没有任何多余的功能和限制。所以你不仅能 #include 头文件,还可以 #include .cc文件, 甚至任何文件。

编译

经过预处理后,只剩下源文件了,编译就是把每个源文件转换成目标文件。记住,源文件和目标文件是一一对应的。

编译的实质,是根据源文件生成目标文件的代码段数据段。这一点对于理解前向声明非常重要。

图解说

假设我们有4个源文件和4个头文件,include关系如下

//  A.h                             A.cc
#include "B.h"                     #include "A.h"

----------------------------------------------------
//  B.h                             B.cc
#include "C.h"                     #include "B.h"

----------------------------------------------------
//  C.h                             C.cc
#include nothing                   #include "C.h"

----------------------------------------------------
//  D.h                             D.cc
#include "A.h"                     #include "D.h"
                                   #include "C.h" 

我们可以用一张图来表示这8个文件的预处理和编译两个阶段
这里写图片描述
虚箭头表示编译,是一对一的,没什么好说的。实箭头表示 #incude 关系。如果一个文件有修改,那么所有直接或间接依赖它的源文件都要重新编译。下面我们就根据此图讲解C++工程中的代码依赖问题。

3. 重复include

D.cc两次包含C.h,一次直接包含,一次通过间接包含。这会引起重定义错误,有两种方法解决。

经典的 ifndef

// A.h
#ifndef A_H
#define A_H

// class definition

#endif

或者 pragma once

// A.h
#pragma once

// class defnition

4. 循环依赖

一旦代码中有循环依赖,编译将失败。上文的8个文件没有循环依赖,图中找不到有向循环路径。

万一你的代码出现循环依赖,请将导致循环依赖的代码提出来,放到新文件中。

5. 前向声明

前两个问题关乎对错,跟编译速度关系不大。现在开始,我们探讨怎么加快代码编译速度。

我们向文件中加点东西

//  A.h                             A.cc
#include "B.h"                     #include "A.h"

class A {                          ....
public:
  void f1(B* b);                   void A::f1(B* b) {
                                     b->f3();
  void f2();                       }
};

----------------------------------------------------
//  B.h                             B.cc
#include "C.h"                     #include "B.h"

class B {
public:
  void f3();
};

----------------------------------------------------
//  C.h                             C.cc
#include nothing                   #include "C.h"

----------------------------------------------------
//  D.h                             D.cc
#include "A.h"                     #include "D.h"
                                   #include "C.h"

class D {
public:
private:
  A a;
};

根据前文的依赖图,如果 B.h 修改,那么 A.cc 和 D.cc 都要重新编译。但是, D.cc 不应该重新编译,因为 class D 只受 class A 内存布局的影响,而 class A 的内存布局与 class B 没有关系,只是f1需要一个class B指针的参数而已。

于是C++允许 A.h 不包含 B.h ,只需声明 class B 即可,告诉编译器 B 这丫是个类名哈。A.h用前向声明替代include,但是 A.cc 中利用了 class B 的实现,所以 A.cc 要加一条 include(放心,源文件中的include不会传染,很少有 include 源文件的)

//  A.h                             A.cc
class B;                           #include "A.h"
                                   #include "B.h"

class A {                          ....
public:
  void f1(B* b);                   void A::f1(B* b) {
                                     b->f3();
  void f2();                       }
};

依赖线一增一减,数量虽然没变,但是效果改善不少啊
这里写图片描述

6. Pimpl idiom

是不是有点儿累了,先歇会儿,然后再来看另外一个削减依赖的重磅武器 Piml(pointer to implementation)。

pimpl idiom主要运用在库的接口设计中。如果团队人数达100,有一个维护基础库的小组。原则上除了接口升级,基础库的任何升级都不应该触发应用层模块的重编译。

我们假设 A.h 是基础库的接口,B.cc 是应用层源文件。

// A.h                      A.cc
#include "xx.h"
#include "yy.h"
#include "zz.h"

class A {                       
public: 
  A();                     A() { ... }
  ~A();                    ~A() { ... }
  void f1();               void A::f1() { ... }
  void f2();               void A::f2() { ... }
private:
  XX x;
  YY y;
  ZZ z;
};

-----------------------------------------------------
// B.cc
#include "A.h"

class B {
public:
private:
  A a;
};

依赖图如下
这里写图片描述
从依赖图明显看出这种代码组织方式有缺陷,XX.h, YY.h, ZZ.h 任何一个文件的修改都会触发 B.cc 重编译。那三个文件都是库内部的文件,原则上是与B.cc无关的,并且这三个头文件很可能包含别的头文件,导致程序库最深处的修改都能轻易触发应用层代码重编译。

这时候该Pimpl显身手了,我们把 A.h, A.cc 改造如下

// A.h                         A.cc
class A {                      #include "A.h"   
public:                        #include "XX.h"
  A();                         #include "YY.h"
  ~A();                        #include "ZZ.h"
  void f1();                 
  void f2();                   class A::Impl {
private:                       public:
  class Impl;                    Impl() { ... }
  Impl* impl_;                   ~Impl() { ... }
};                               void f1() { ... }
                                 void f2() { ... }
                               private:
                                 XX x;
                                 YY y;
                                 ZZ z;
                               };

                               A::A() : impl_(new A::Impl()) {}
                               A::~A() { delete impl_; }

                               void A::f1() {
                                 impl_->f1();
                               }

                               void A::f2() {
                                 impl_->f2();
                               }

把A中所有非接口的东西都移到Impl中去,依赖图变成下面的样子。
这里写图片描述
从依赖图看出,只有 A.h 的修改才能触发 B.cc 重编译,而 A.h 中只有库接口,库的接口都变了,应用层当然要重编译咯。

7. 参考资料

1.C++ Compilation Speed
2.Pimpl For Compile-Time Encapsulation (Modern C++)
本文转自:怎样削减C++代码间依赖
作者:wankai

2015-05-24 22:09:27 weixin_33939843 阅读数 8

1. 介绍

C++程序编译很慢,特别是大型工程,你都可以趁着编译的功夫喝杯咖啡。这里面既有天灾也有人祸。

天灾请看此文,本文探讨怎么避免人祸。


2. 编译过程

后文需要,我们先了解C++源代码的编译过程

compile process

为叙述方便,图中各文件类型称呼如下:

  • .h 头文件
  • .cc 源文件
  • .o 目标文件

本文不探讨链接过程,只考虑编译和预处理。

预处理

经过预处理后,头文件就消失了。因为 #include 预处理指令将其展开在源文件中,编译阶段是不需要头文件的。常见的预处理指令还有 #if, #elif, #end, #ifndef, #define 等。

#include 其实非常简单,就是把文件在当前位置展开,没有任何多余的功能和限制。所以你不仅能 #include 头文件,还可以 #include .cc文件, 甚至任何文件。

编译

经过预处理后,只剩下源文件了,编译就是把每个源文件转换成目标文件。记住,源文件和目标文件是一一对应的。

编译的实质,是根据源文件生成目标文件的代码段数据段。这一点对于理解前向声明非常重要。

图解说

假设我们有4个源文件和4个头文件,include关系如下

//  A.h                             A.cc
#include "B.h"                     #include "A.h"

----------------------------------------------------
//  B.h                             B.cc
#include "C.h"                     #include "B.h"

----------------------------------------------------
//  C.h                             C.cc
#include nothing                   #include "C.h"

----------------------------------------------------
//  D.h                             D.cc
#include "A.h"                     #include "D.h"
                                   #include "C.h" 

我们可以用一张图来表示这8个文件的预处理和编译两个阶段

图片描述

虚箭头表示编译,是一对一的,没什么好说的。实箭头表示 #incude 关系。如果一个文件有修改,那么所有直接或间接依赖它的源文件都要重新编译。下面我们就根据此图讲解C++工程中的代码依赖问题。


3. 重复include

D.cc两次包含C.h,一次直接包含,一次通过间接包含。这会引起重定义错误,有两种方法解决。

经典的 ifndef

// A.h
#ifndef A_H
#define A_H

// class definition

#endif

或者 pragma once

// A.h
#pragma once

// class defnition

4. 循环依赖

一旦代码中有循环依赖,编译将失败。上文的8个文件没有循环依赖,图中找不到有向循环路径。

万一你的代码出现循环依赖,请将导致循环依赖的代码提出来,放到新文件中。


5. 前向声明

前两个问题关乎对错,跟编译速度关系不大。现在开始,我们探讨怎么加快代码编译速度。

我们向文件中加点东西

//  A.h                             A.cc
#include "B.h"                     #include "A.h"

class A {                          ....
public:
  void f1(B* b);                   void A::f1(B* b) {
                                     b->f3();
  void f2();                       }
};

----------------------------------------------------
//  B.h                             B.cc
#include "C.h"                     #include "B.h"

class B {
public:
  void f3();
};

----------------------------------------------------
//  C.h                             C.cc
#include nothing                   #include "C.h"

----------------------------------------------------
//  D.h                             D.cc
#include "A.h"                     #include "D.h"
                                   #include "C.h"

class D {
public:
private:
  A a;
};

根据前文的依赖图,如果 B.h 修改,那么 A.cc 和 D.cc 都要重新编译。但是, D.cc 不应该重新编译,因为 class D 只受 class A 内存布局的影响,而 class A 的内存布局与 class B 没有关系,只是f1需要一个class B指针的参数而已。

于是C++允许 A.h 不包含 B.h ,只需声明 class B 即可,告诉编译器 B 这丫是个类名哈。A.h用前向声明替代include,但是 A.cc 中利用了 class B 的实现,所以 A.cc 要加一条 include(放心,源文件中的include不会传染,很少有 include 源文件的)

//  A.h                             A.cc
class B;                           #include "A.h"
                                   #include "B.h"

class A {                          ....
public:
  void f1(B* b);                   void A::f1(B* b) {
                                     b->f3();
  void f2();                       }
};

依赖线一增一减,数量虽然没变,但是效果改善不少啊

图片描述


6. Pimpl idiom

是不是有点儿累了,先歇会儿,然后再来看另外一个削减依赖的重磅武器 Piml(pointer to implementation)。

pimpl idiom主要运用在库的接口设计中。如果团队人数达100,有一个维护基础库的小组。原则上除了接口升级,基础库的任何升级都不应该触发应用层模块的重编译。

我们假设 A.h 是基础库的接口,B.cc 是应用层源文件。

// A.h                      A.cc
#include "xx.h"
#include "yy.h"
#include "zz.h"

class A {                       
public: 
  A();                     A() { ... }
  ~A();                    ~A() { ... }
  void f1();               void A::f1() { ... }
  void f2();               void A::f2() { ... }
private:
  XX x;
  YY y;
  ZZ z;
};

-----------------------------------------------------
// B.cc
#include "A.h"

class B {
public:
private:
  A a;
};

依赖图如下

图片描述

从依赖图明显看出这种代码组织方式有缺陷,XX.h, YY.h, ZZ.h 任何一个文件的修改都会触发 B.cc 重编译。那三个文件都是库内部的文件,原则上是与B.cc无关的,并且这三个头文件很可能包含别的头文件,导致程序库最深处的修改都能轻易触发应用层代码重编译。

这时候该Pimpl显身手了,我们把 A.h, A.cc 改造如下

// A.h                         A.cc
class A {                      #include "A.h"   
public:                        #include "XX.h"
  A();                         #include "YY.h"
  ~A();                        #include "ZZ.h"
  void f1();                 
  void f2();                   class A::Impl {
private:                       public:
  class Impl;                    Impl() { ... }
  Impl* impl_;                   ~Impl() { ... }
};                               void f1() { ... }
                                 void f2() { ... }
                               private:
                                 XX x;
                                 YY y;
                                 ZZ z;
                               };

                               A::A() : impl_(new A::Impl()) {}
                               A::~A() { delete impl_; }

                               void A::f1() {
                                 impl_->f1();
                               }

                               void A::f2() {
                                 impl_->f2();
                               }

把A中所有非接口的东西都移到Impl中去,依赖图变成下面的样子。

图片描述

从依赖图看出,只有 A.h 的修改才能触发 B.cc 重编译,而 A.h 中只有库接口,库的接口都变了,应用层当然要重编译咯。


7. 参考资料

  1. C++ Compilation Speed
  2. Pimpl For Compile-Time Encapsulation (Modern C++)

[转]浅谈怎样加快C++代码的编译速度

阅读数 8

C++代码一直以其运行时的高性能高调面对世人,但是说起编译速度,却只有低调的份了。本文介绍了加快C++编译速度的方法,一起来看。AD:C++代码一直以其运行时的高性能高调面对世人,但是说起编译速度,却只有低调的份了。比如我现在工作的源代码,哪怕使用Incredibuild调动近百台机子,一个完整的build也需要四个小时,恐怖!!!虽然平时开发一般不需要在本地做完整的build,但编译...

博文 来自: hwlzs

怎样在JAVA里嵌入C/C++代码

阅读数 6391

JavaNativeInterface(JNI)是Java语言的本地编程接口,是J2SDK的一部分。在java程序中,我们可以通过JNI实现一些用java语言不便实现的功能。通常有以下几种情况我们需要使用JNI来实现。l  标准的java类库没有提供你的应用程序所需要的功能,通常这些功能是平台相关的l  你希望使用一些已经有的类库或者应用程序,而他们并非用java语言编写的

博文 来自: zealczg

要看懂OpenCV的代码,所需要的C和C++的基础知识

阅读数 1928

图像处理开发资料、图像处理开发需求、图像处理接私活挣零花钱,可以搜索公众号"qxsf321",并关注!图像处理开发资料、图像处理开发需求、图像处理接私活挣零花钱,可以搜索公众号"qxsf321",并关注!图像处理开发资料、图像处理开发需求、图像处理接私活挣零花钱,可以搜索公众号"qxsf321",并关注!1函数重载的含义2符号重载的含义3内联函数的含义 #defineCV_...

博文 来自: wenhao_ir

看懂下面C++代码才说你理解了C++多态虚函数!

阅读数 1842

#includeusingnamespacestd;classFather{private: virtualvoidSay() //只有添加了virtual关键字声明才会产生虚函数表虚函数表在编译的时候确定 virtual是实现多态的关键 {  cout } virtualvoidRun() { cout }};

博文 来自: yue7603835

作为C++小白为看懂算法题C++代码的简单语法整理

阅读数 1111

//一个小的C++程序#includeintmain(){std::cout'Hello,World!'

博文 来自: Klein_Kartoffel
没有更多推荐了,返回首页