我自逍遙笑

摘要： # 配置 ~/.bashrc 來啟用高級歷史功能 #打開 ~/.bashrc 文件： vi ~/.bashrc #在文件末尾添加以下內(nèi)容： # Enable incremental history search bind '"\C-r": reverse-search-history' #保存文件并 閱讀全文

摘要： 使用 std::all_of 判斷字符串是否全為字母、數(shù)字或字母數(shù)字 #include <iostream> #include <string> #include <algorithm> #include <cctype> // 用于 isdigit, isalpha 等函數(shù) // std::isl 閱讀全文

摘要： Liunx應(yīng)用編譯，需要降低GLIBC版本編譯運(yùn)行，但libc.so.6出現(xiàn)異常，shell 命令均不支持； /bin/ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No su 閱讀全文

摘要： #獲取branch名 GIT_BRANCH=$(shell git branch | sed -n '/\* /s///p')$(info GIT_REVISION = $(GIT_BRANCH)) #獲取commit GIT_REVISION = $(shell git show -s --pre 閱讀全文

摘要： 普通的C++成員函數(shù)都隱含了一個(gè)傳遞函數(shù)作為參數(shù)，亦即“this”指針； 與類相關(guān)的回調(diào)函數(shù)要注意，類成員函數(shù)，如果是非靜態(tài)，是帶有this指針的，會(huì)與函數(shù)指針的類型不一致（無this），所以需要使用static函數(shù)，或者使用bind(&class::handler,this,_1) 1.普通函數(shù)方 閱讀全文

摘要： 使用memset會(huì)造成兩個(gè)問題： 內(nèi)存泄漏； =賦值時(shí)出現(xiàn)crash string類內(nèi)部是使用char* data維護(hù)，使用new分配空間，直接memset會(huì)導(dǎo)致string內(nèi)部data=NULL, 造成內(nèi)存泄露； 如果這時(shí)使用string s1 = s2; 會(huì)出現(xiàn)NULL= new char(si 閱讀全文

摘要： string StringTest::core_get_param_by_key(string data, string key){ int pos = 0; int count = 0; string str_sub = ""; string str_result = ""; string str 閱讀全文

摘要： 一.為什么要內(nèi)存對齊 經(jīng)過內(nèi)存對齊之后，CPU的內(nèi)存訪問速度大大提升; 內(nèi)存空間按照byte劃分，從理論上講似乎對任何類型的變量的訪問可以從任何地址開始，但實(shí)際情況是在訪問特定變量的時(shí)候經(jīng)常在特定的內(nèi)存地址訪問，這就需要各類型數(shù)據(jù)按照一定的規(guī)則在空間上排列，而不是順序的一個(gè)接一個(gè)的排放，這就是對齊。 閱讀全文

摘要： 在c語言中，碰到一個(gè).c文件，無.h頭文件,在另一.c文件調(diào)用函數(shù)時(shí)，并沒有進(jìn)行聲明extern， 此時(shí)編譯器不會(huì)報(bào)錯(cuò)，會(huì)默認(rèn)去查找同名的函數(shù)，這樣會(huì)存在一些問題，查了些資料，稍微總結(jié)了下： 總結(jié)： 1.聲明函數(shù)可以不加extern，函數(shù)默認(rèn)extern。2.聲明變量必須要加extern.3.如果不 閱讀全文

摘要： 因項(xiàng)目需要，需要在DLL中共享數(shù)據(jù)，即DLL中某一變量只執(zhí)行一次，在運(yùn)行DLL中其他函數(shù)時(shí)該變量值不改變；剛開始想法理解錯(cuò)誤，搜到了DLL進(jìn)程間共享數(shù)據(jù)段，后面發(fā)現(xiàn)直接在DLL中定義全局變量就行，當(dāng)時(shí)腦袋有點(diǎn)犯2了。但既然接觸到DLL進(jìn)程間共享數(shù)據(jù)段，覺得還是挺重要的，干脆一不做二不休，就詳細(xì)了解了 閱讀全文