加餐丨部分課后思考題答案合集

多個不同線程在同一個智能指針上執(zhí)行原子操作（atomic_load等）是安全的多個不同線程根據(jù)同一個智能指針創(chuàng)建新的智能指針（增加計數(shù)）是安全的其他操作潛在是不安全的，特別是在不同的線程對同一個智能指針執(zhí)行reset等修改操3為什么smart_ptr::operator對左值和右值都有效，而且不需要對等號兩邊是否答：我們使用值類型而非類型作為形參，這樣實參會被移動（右值的情況）（左值的情況），不可能和*this同一個對象4為什么stack（或queue）的pop函數(shù)返回類void，而不是直接返回容器的top（或front）成員？答：這是C++98里、還沒有移動語義時的設(shè)計。如果pop返回元素，而元素拷貝時發(fā)生異常的話，那這個元素就丟失了。因而容器設(shè)計成有分離的top（或front）和pop成員有一種可能的設(shè)計是把接口改成voidpop(T&)，這增T必須支持默認構(gòu)造和賦值的要求，在單線程為主的年代沒有明顯的好處，反而帶來了對T的額外要求。5為什么大部分容器都提供了begin、end等方答：容器提供了beginend方法，就意味著是可以迭代（遍歷）的。大部分容器都可以為什么容器沒有繼承一個公用的基答：C++是面向?qū)ο蟮恼Z言，尤其在標準容器的設(shè)計上主要使用值語義，使用公共基類7目前這個輸入行迭代器的行為，在什么情況下可能導(dǎo)致意料之外的答it!=reader.end();++it)cout<<*it<<16}以上代碼，因為begin多調(diào)用了一次，輸出就少了一答：很。比如，文件如果為空的話，從迭代器的行為角度，begin()應(yīng)該等于10這講里我們沒有深入討論賦值；請你思考一下，如果例子里改成賦值，會有什么樣的變vector尾部追加數(shù)據(jù)，盡量對變量進行賦值、不后續(xù)修改。這樣的代碼更容易推11為什么說UTF-32處理會比較簡單答：UTF-32，一個字符就是一個基本的處理單位，一般不會出現(xiàn)一個字符跨多個處理單位的情況（UTF-8和UTF-16下會發(fā)生）。你知道什么情況下UTF-32也并不那么簡單Unicode下有所謂的修飾字符，用來修飾前一個字符。按UnicodeUTF-2下也不可以在任意單位處粗暴斷開處理。哪種UTF編碼方式空間效率比較高答：視的內(nèi)容而定比如，如果內(nèi)容以ASCII為主（如源代碼），那UTF-8效率最高。如果內(nèi)容以一般的中文文本為主，那UTF-16效率最高。12為什么并非所有的語言都支持這些不同的多Python例，它是動態(tài)類型的語言。所以它不會有真正的靜態(tài)多態(tài)。但和靜態(tài)類型的面向?qū)ο笳Z言（如Java）不同，它的運行期多態(tài)不需要繼承。沒有參數(shù)化多態(tài)初看是個缺陷，但Python動態(tài)參數(shù)系統(tǒng)允許默認參數(shù)和可變參數(shù)，并沒有什么參數(shù)化多態(tài)能做得到而Python做不到的事。17想，你如何可以實現(xiàn)一個惰性的過濾器答代1#include 23usingnamespace4 te<typenameI,typenameclassfilter_viewclass tortypedeftypename I>::value_typetypename I>::pointertypename I>::referencetypedef tor(Icurrent,Iend,F:,, if(current_!=end_!cond_(*current_)) tor&{while(current_!=end_)if{}}return} tor{autotemp=return}referenceoperator*(){return}pointeroperator->(){return}booloperator==(const {returncurrent_==}booloperator!=(const tor&{return}IIFfilter_view(Ibegin,IF:,, torbegin(){return tor(begin_,end_,} torend() return tor(end_,end_, Ibegin_;IIbegin_;Iend_;Fcond_;我展示了compose帶一個或參數(shù)的情況。你覺得compose不帶任何參數(shù)該如何定答代代inlineauto{return[](auto&&x)->{return 7這個函數(shù)把參數(shù)原封不動地傳回。它的意義相當于加法里的0，乘法里的1在普通的加法里，你可能不太需要0；但在一個做加法的地方，如果別人想告訴你不要做任何操作，傳給你一個0是最簡單的做法。有沒有可能不用index_sequence來初始化bit_count？如果行，應(yīng)該如何實現(xiàn)答：似乎沒有通用的辦法，因為目前constexpr要求在構(gòu)造時直接初始化對象的內(nèi)但是C++20，允許constexpr象里存在平凡默認構(gòu)造的成員之后，就可以使用下代代12te<size_tstructbit_count_tconstexprconstexpr{for(autoi=0U;i<N;{count[i]=}}unsignedchar3456789constexprconstexpr{for(autoi=0U;i<N;{count[i]=}}unsignedchar3456789作為一個，你能自行實現(xiàn)出make_integer_sequence嗎答代代123456789te<classT,T...structinteger_sequencete<classstruct{te<TN,T...structinteger_sequence_helper{usingtype=typenameinteger_sequence_helper<N-1,N-1,te<T...structinteger_sequence_helper<0,Ints...>{usingtype=integer_sequence<T,Ints...>;te<classT,Tusingmake_integer_sequencetypenamete如果一開始寫成tem te<classT,TN,T...Ints>structinteger_sequence_helper的話，就會遇到錯誤“non-typetemteargumentspecializesatemteparameterwithdependenttype‘T’”（非類型的模板實參特化了一個使用依賴類型的‘T’的模板形參）。這是目前的C++標準所不允許的寫法，改答9T,}elsereturnT,N-1,N-1,14}這又是一個constexpr能簡化表達的例子19并發(fā)編程中哪些情況下會發(fā)生死答：多個線程里，如果沒有或不能事先約定順序，同時進行可阻塞的資源，順可阻塞的資源可能包括（但不限于互斥量上的lock調(diào)用條件變量上的wait調(diào)用對線程的join調(diào)用future的get調(diào)27你覺得C++RESTSDK接口好用嗎？如果好用，原因是什么？如果不好用，你有什么樣答：舉幾個可能的改進點C++RESTSDK的uri::decode接口設(shè)計有不少問題最嚴重的，不能對querystring的等號左邊的部分進行decode；只能先split_querydecode，此時等號左邊已經(jīng)在map里，不能修改——要修改需要建一個新的map。目前的實現(xiàn)對“+”不能重新還原成空格換個說法，目前的接口能正確處理“/serq=query%string”ser%=qutring”這樣的請求。應(yīng)當有一個split_query_and_decode接口，同時執(zhí)行分割和另外，json的接口也還是不夠好用，最主要是沒有使用初始化列表的構(gòu)造。構(gòu)造復(fù)雜JSON結(jié)構(gòu)有點啰嗦了fstream::open_ostream缺省行為跟std::ofstream不一樣應(yīng)該是個bug。應(yīng)當要么修正接口（接口缺省參數(shù)里帶上trunc），要么修正實現(xiàn)（跟std::ofstream一樣把out當成out|trunc）。28“概念”可以為開發(fā)具體帶來哪些好處？反過來，的影響又可能會是什么SFINAE使用，還能以較為精確和形式化的形式在代碼里寫出對類型的要求，使得代碼變可、、前置+與sentl類型對象的=（單一形式）。而為了滿足迭代器概念，則要額外確保滿足以下各點：可默認初始在i tor類型和sentin