兩種情況：
1，同步函數(shù)

這個(gè)簡(jiǎn)單，順序執(zhí)行就可以了

2,異步函數(shù)（我猜你是這種情況）async await可以解決

async function a() {
    return Promise.resolve("a");
}
async function b() {
    return Promise.resolve("b");
}
async function c() {
    await a();
    await b();
    console.log('執(zhí)行c')
}
c();

VMT is implementation dependent, so topics should be limited to compilers implementations rather than c++ itself.

那么虛表是在什么時(shí)候生成的呢. 是在構(gòu)造函數(shù)執(zhí)行之前還是在構(gòu)造函數(shù)之后之后呢？

For Most compilers, virtual table pointer initializes __vptr at constructor's initializer list.

而且虛表存放在哪里呢？

What confuses you is where __vptr is(not VMT, because VMT just consists of the addresses of trivial non-virtual functions which can be invoked by __vptr), then:

Compilers have multiple choices(all as a hidden member), you can refer to here

Summary: Where is the __vptr stored in an object (first or last are the usual answers).

Of course, you can implement VMT with c, then you will not ask such questions.

BTW, this is not good (even is a bad) question, because you even haven't searched it on google before asking, so -1.

Update:

Wikipedia is also your friend.

應(yīng)該是路由器的問題。

借花獻(xiàn)佛
https://blog.csdn.net/u010003...
另外MongoDB 4.0已經(jīng)開始支持事務(wù)了

推薦@pezy 大佬寫的設(shè)計(jì)模式專欄。

設(shè)計(jì)模式

因?yàn)?code>&&的優(yōu)先級(jí)比||高，所以你給的例子去掉括號(hào)也不影響結(jié)果。加上括號(hào)只是使代碼更易讀。

但是有時(shí)候括號(hào)是必須的，比如a && (b || c)，如果去掉括號(hào)結(jié)果就變成了(a && b) || c。

inspect只是為了查看容器里面的值的時(shí)候用的，你這里沒有調(diào)用，當(dāng)然也不會(huì)執(zhí)行

class SparseMat {
public:
    SparseMat(int MAXROW, int MAXCOL, int NonZeroterms);
    SparseMat MAT_transpose(SparseMat b);
private:
    int Rows, Cols, NonZeroterms;
    Trituple* SMArray;
};

SparseMat::SparseMat(int MAXROW, int MAXCOL, int NonZeroterms)
    :Rows(MAXROW), Cols(MAXCOL), NonZeroterms(NonZeroterms)
{
     SMArray = new Trituple[NonZeroterms];
}

The statement:

    if(location > listSize++ || location < 1 )
        cout<<"Please enter correct value."<<endl;

can be considered like

    if(location > listSize || location < 1 )
    {
        ++listSize;
        cout<<"Please enter correct value."<<endl;
    }
    

From the C++ Standard (5.2.6 Increment and decrement)

1 The value of a postfix ++ expression is the value of its operand. [ Note: the value obtained is a copy of the original value —end note ]...

So, it will change listSize's value(because of ++listSize;), which is not you hope to see.

title 沒加索引吧

拋磚引玉

• 一臺(tái)服務(wù)器上已經(jīng)安裝了Nginx并啟動(dòng)監(jiān)聽80端口，但此時(shí)你又下載一個(gè)Apache想啟動(dòng)也去監(jiān)聽80端口，這時(shí)服務(wù)器就不讓了，會(huì)提示端口被占用，這就是一個(gè)端口對(duì)應(yīng)一個(gè)應(yīng)用程序。
• 當(dāng)你訪問一個(gè)網(wǎng)址時(shí)，默認(rèn)會(huì)訪問80端口，假設(shè)服務(wù)器使用Nginx，當(dāng)Nginx監(jiān)聽到有客戶請(qǐng)求自己監(jiān)聽的80端口時(shí)，會(huì)根據(jù)請(qǐng)求做出相應(yīng)的相應(yīng)，至于為什么可以同時(shí)鏈接多個(gè)用戶，那得看服務(wù)器的本身配置了，可以同時(shí)允許多少個(gè)用戶同時(shí)訪問，若是僅允許一個(gè)，那么第一個(gè)進(jìn)來了，接下來的就順次排隊(duì)，服務(wù)器處理一個(gè)之后會(huì)接下往下處理

樓主的意思是將二叉樹的空節(jié)點(diǎn)也表示出來嗎？比如說：

               1
              / \
                 3
                / \
               4   5

表示成

               1
             /   \
           nil    3
           / \   / \
          nilnil4  5
          

這樣嗎。
個(gè)人想法滿二叉樹可以用數(shù)組保存，那么樓主可以將數(shù)組將二叉樹擴(kuò)充為滿二叉樹

關(guān)鍵字 qqwry 應(yīng)該個(gè)個(gè)語言都有實(shí)現(xiàn). 這種速度最快, 成本最低, 準(zhǔn)確率較好

你的token在哪里？？

• 如果是放在cookie中，就不用管了，ajax自己會(huì)帶上的。
• 如果不是，header上手動(dòng)放入token，一下舉例

$.ajax({
????type:"POST",
????url:url,
????data:formData,
????//在請(qǐng)求前設(shè)置請(qǐng)求頭 在請(qǐng)求頭里面設(shè)置設(shè)置請(qǐng)求頭的信息
????beforeSend: function(request) {
????????????request.setRequestHeader("Authorization", token1);
????},
????success:function(res){
????    console.log(res);
????}
});

既然你了解了引用折疊, 我相信你也應(yīng)該知道了forward就是一簡(jiǎn)單的static_cast<T&&>t.

此函數(shù)void process(T&& t)是有問題的, 它依舊是一個(gè)universal reference/forwarding reference , 只有void process(int&& t)這樣明確是右值引用你才能稱作rv, 對(duì)吧. 所以先改下函數(shù)并簡(jiǎn)化代碼:

template <typename T> void process(const T& t) { cout << "const T&" << endl; }
template <typename T> void process(T&& t)      { cout << "T&&" << endl; }
void test(...) { process(...) ;}

因?yàn)閒orward只是一個(gè)轉(zhuǎn)發(fā)(從上面的實(shí)現(xiàn)配合引用折疊也是很好理解的), 并且能保留原有的ref-qualifier和const-qualifier, 所以被稱作完美轉(zhuǎn)發(fā), 因此你可以把test里面的process繼續(xù)簡(jiǎn)化掉:

int non_const_a = 1;
int const const_a = 1; 
template <typename T> void process(const T& t) { cout << "const T&" << endl; }
template <typename T> void process(T&& t)      { cout << "T&&" << endl; }
test(1); // T&&
test(non_const_a); // T&&
test(const_a); // const T&

有沒有發(fā)現(xiàn)什么? 整個(gè)過程其實(shí)就是簡(jiǎn)化成左值, 右值, 加上const-qualifier對(duì)process的函數(shù)重載決議了.

無論T&&還是const T&都和標(biāo)題中的forward, 右值引用沒什么關(guān)系了

這下應(yīng)該明白了吧? 只有const的左值才會(huì)匹配const T&, 其他都會(huì)匹配T&&. 很明了的一個(gè)重載決議.

繼續(xù), 可能OP會(huì)想, 如果我這么重載呢?

template <typename T> void process(const T& t) { cout << "const T&" << endl; }
template <typename T> void process(const T&& t)      { cout << "T&&" << endl; }

都有const呀, 此時(shí)該怎么辦呢? 編譯器是不是就gg了?

簡(jiǎn)單的說, 此時(shí)const T&&不再是人見人愛花見花開的, forwarding reference, 因?yàn)橛辛薱onst-qualifier, 所以退化成了rvalue-reference了. g(i)妄想傳個(gè)左值進(jìn)去不是作么. 比如這樣的例子:

void f(int&& a) {} 
int main()
{
    int a = 1;
    f(a);
}

prog.cc:5:12: error: cannot bind rvalue reference of type 'int&&' to lvalue of type 'int'

 f(a);

有了以上鋪墊, OP是不是能想出之前提的問題:

#include <utility>
#include <iostream>

using std::cout;
using std::endl;

template
<typename T>
void process(const T& t)
{
    cout << "const T&" << endl;
}

template
<typename T>
void process(const T&& t)
{
    cout << "const T&&" << endl;
}

template
<typename T>
void test(T&& t)
{
    process(std::forward<T>(t));
}

int main()
{
    int a = 1;
    const int const_a = 1;
    test(1);
    test(a);
    test(const_a);
}

const T&&
const T&
const T&

可見只有右值1匹配了const T&&, 畢竟人家只能匹配右值嘛, 也是應(yīng)該的.

主要原因就是unique_ptr比shared_ptr更輕，沒有運(yùn)行時(shí)負(fù)擔(dān)，所以unique_ptr的刪除器是編譯期確定的。

兩個(gè)unique_ptr即使指向類型相同，若刪除器不同，也屬于不同類型。unique_ptr的刪除器已經(jīng)內(nèi)植于類型，所以不需要存儲(chǔ)一個(gè)刪除器對(duì)象就知道刪除器在哪。“類型內(nèi)植”過程是編譯期確定的，刪除過程的代碼的運(yùn)行當(dāng)然是運(yùn)行期運(yùn)行的。

shared_ptr就不同，構(gòu)造函數(shù)傳進(jìn)來一個(gè)實(shí)實(shí)在在的對(duì)象，它存儲(chǔ)起來用?！皩?duì)象存儲(chǔ)”過程是運(yùn)行期確定的，刪除過程的代碼的運(yùn)行當(dāng)然也是運(yùn)行期運(yùn)行的。shared_ptr的靈活性更高。

由于你沒有給出錯(cuò)誤提示，無法判斷錯(cuò)誤的具體原因。

考慮到Account只授予了std::vector<Account>訪問權(quán)。一個(gè)可能得原因是在std::vector<Account>內(nèi)對(duì)Account的構(gòu)造是由另一個(gè)類/函數(shù)完成的，比方說std::allocator<Account>。

class Account
{
    friend std::vector<Account>::allocator_type;
public:
    Account(const char *, double = 0.0);
private:
    Account() {}
};

編譯時(shí)加上 -DCMAKE_PREFIX_PATH=path/to/qt5widgets 試一試

沒有報(bào)錯(cuò)是因?yàn)橹苯訉?code>array[3]當(dāng)做*(array+3)處理嗎？

可以這么理解。以C++的尿性來看，這樣最簡(jiǎn)單，最快，也方便各種魔幻用法。檢測(cè)越界這種事應(yīng)該交給庫，或者更高級(jí)的語言。

那為什么array[3]，array[4]輸出結(jié)果相同？

Visual C++ 編譯器會(huì)在調(diào)試模式下把未初始化的內(nèi)存用0xCC填充。如果輸出字符串，就是喜聞樂見的燙燙燙。如果輸出int32，就是-858993460。

[...new Uint8Array(Int32Array.of(-858993460).buffer)].map(e => e.toString(16))
// <- ["cc", "cc", "cc", "cc"]

也可以搜索“補(bǔ)碼在線計(jì)算器”自己驗(yàn)證。

樹形結(jié)構(gòu)，網(wǎng)上有很多參考案例
參考鏈接