這個效率太低了

同上，這么寫會死人的

這樣的寫法太差了

那你們寫個好一點的啊

這個是尾遞歸啊，直接改成循環(huán)不更好
萬一有一行巨長的，直接棧溢出了……
當(dāng)然你要說沒那么長的，也無所謂

老大，你看看boost::algorithm里面關(guān)于string的吧。你的效率太低了。

str.erase(remove_if(str.begin(), str.end(), isspace), str.end());

喏，還是很容易，一句就搞定了。

博主太恐怖了，居然敢返回string&.

一般用遞歸去除Left和Right沒有關(guān)系，但是整體的話是不行的

請問 沐楓 老兄，這個例子里返回string&會有什么嚴(yán)重后果呢？

效率的卻有問題啊

@沐楓
您這個最棒. 謝謝!

多謝各位熱心人的指點,俺是不勝感激.

PS 如果是考慮效率的話,我是認(rèn)為用C來實現(xiàn)可能效率比string更高一些吧.

效率高不高不是你認(rèn)為不認(rèn)為的問題。
而是實際使用環(huán)境造成的。

現(xiàn)在的編譯器已經(jīng)不是當(dāng)年的編譯器了。你要是沒有把編譯器的各種優(yōu)化功能用好，就很難說哪種方法在哪個使用環(huán)境下，誰的效率更高。

就拿VC來說吧。VC除了各種編譯時和鏈接時的優(yōu)化外，還有一個按配置優(yōu)化的功能。也就是讓你的程序在運(yùn)行中收集信息，經(jīng)過一段長時間的使用以后，將收集的信息，讓編譯器根據(jù)這個信息對代碼重新進(jìn)行優(yōu)化。這種優(yōu)化才是真正的根據(jù)實際需要優(yōu)化的。

@owlcn
就好象返回局部變量的指針一樣。這樣，有可能你可以運(yùn)行，也有可能在某些時候就不能運(yùn)行。。。

@沐楓
程序里返回的并不是局部變量的指針，它返回的是傳入到函數(shù)里參數(shù)的地址。
所以，調(diào)用者拿到該返回值跟實參是一個東西。
在函數(shù)返回給調(diào)用者之前，實參的內(nèi)容還沒有被銷毀。

@沐楓
關(guān)于效率問題，俺的想法是 看這段代碼放到哪里去運(yùn)行，如果是在游戲，嵌入式系統(tǒng)等，或者成為系統(tǒng)性能瓶頸的時候，必須要考慮這段代碼的性能的問題。
如果就是在其他的商業(yè)軟件里，就不必要為這段代碼考慮效率的問題，而是要著重與開發(fā)工時一起權(quán)衡考慮。我們不會為了僅僅提高了系統(tǒng)0.0001%的性能而浪費0.1%的工時。當(dāng)然，也不是完全不考慮效率的問題，而是在一定工時里寫出盡可能漂亮，盡可能高效的代碼。 這僅僅是我的一點拙見，有不對之處請斧正。

另外，我對把“優(yōu)化工作完全交給編譯器來做”這個觀點不敢茍同。
寫的非常糟糕的代碼，編譯器的優(yōu)化遠(yuǎn)遠(yuǎn)比不上用人把這段代碼重寫而優(yōu)化的好。 完全靠編譯器來優(yōu)化我認(rèn)為有點不妥。

優(yōu)化工作完全交給編譯器來做
－－呵呵，這不是我說的，是你說的。我也不完全認(rèn)同。
優(yōu)化的問題太復(fù)雜了，不可能討論的出來結(jié)果的，因為它與實際情況關(guān)系太密切了。

至于返回引用，的確是我看錯了。不好意思。

這種方法也要用得著發(fā)到博客里嗎？怎么不發(fā)一篇題為：《C++如何定義整型》的文章呢？

void blank_out(char *buf)
{
char *p;
for (p = buf; *buf; buf++) {
if (*buf != ' ') {
*p = *buf;
if (buf != p++)
*buf = ' ';
}
}
*p = '\0';
}
這個算法可以解決，意思是后移空格

str.erase(remove_if(str.begin(), str.end(), isspace), str.end());