這個效率太低了

同上，這么寫會死人的

這樣的寫法太差了

那你們寫個好一點的啊

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

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

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

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

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

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

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

效率的卻有問題啊

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

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

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

效率高不高不是你認為不認為的問題。
而是實際使用環境造成的。

現在的編譯器已經不是當年的編譯器了。你要是沒有把編譯器的各種優化功能用好，就很難說哪種方法在哪個使用環境下，誰的效率更高。

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

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

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

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

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

優化工作完全交給編譯器來做
－－呵呵，這不是我說的，是你說的。我也不完全認同。
優化的問題太復雜了，不可能討論的出來結果的，因為它與實際情況關系太密切了。

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

這種方法也要用得著發到博客里嗎？怎么不發一篇題為：《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());