Though I suspect the original form (without explicitly mentioning of string when creating the tmp string object) should work as well, I’ve modified my example code snip, just to be sure.

Would you post the entire error message regarding the ambiguous call? I would like to see which functions VC10 selected as viable candidates.

Fortunately, this code works fine:
strings.push_back(string("hi"));

Sounds like we have a chance to support rvalue-references in NTL’s containers, even before Dinkumware’s implementation.

Cool~

Happy hacking!

yuxio,

那篇文章與其相關的討論串挺有意思吧~

但我與你的看法不同. 我認為工作上的專案或許更容易被中斷. 以我個人的經驗來說, 或許是由於不夠遠視, 迫於 (來自股東的) 短期獲利壓力等因素, 台灣的軟體公司更不容易堅持高技術難度 (也因此對 engineer 來說, 通常為有趣) 的 project.

反而很少聽說掛掉的 FOSS project 案例. FOSS project 的狀態差異通常是在於受不受歡迎, user 多寡, 是否 actively developed/maintained 等等. 一個由於 contributor 沒空維護的 FOSS project 比較像是在冬眠, 隨時可因為 contributor 又有時間了就 (至少在 contributor 眼裏) 又活過來了. Contributor 沒興趣了可能會是最慘的狀況了吧.

BTW, 我去看了 slashdot 的那篇文章，真的是非常兩難的問題。接受了，也許就衣食無虞，又可以做自己喜歡的案子（開戰鬥機 )，但是接受對方公司的條件後，就代表自己就算下班之後研究、設計戰鬥機的貢獻，也不能對外對社群發佈。

靠著興趣而開發的專案，也許哪天會因為現實問題而中斷；現在有公司付錢讓你做自己有興趣想做的東西，雖然專案不會中斷，但成果卻屬公司所有，即使在下班之後也不能做相關領域的貢獻….也難怪這篇會引起那麼多的迴響。

It seems to me, in the context of your comments regarding this post, the word “allocator” is not related to STL allocator. You just meant a software module which enables dynamic memory allocation in a more generic sense.

If so, I think I’ve managed to understand your comment better this time.

In this reply, I am going to use the word “allocator” the same way as you do, unless otherwise specified.

In my works , allocator is used for make sure memory can be safely free and don’t need to call destructor on objects and help performance for huge number of objects…

IMO, this is a customized garbage collection scheme/protocol for this special purpose non-global (process wise) allocator, performance gain is one of its side effects.

Therefore, I will carefully design all classes won’t mess up when
we we destory allocator. So, if we use objects along with particular
allocator, these objects will just like living in isolated world.

I gotcha. Your schema works similar to allocating memory blocks in a process, without deallocation. However, they would be deallocated when the process exists anyway.

Your schema is basically the same as boost::pool (non-typed) and boost::object_pool (typed).

Correct?

If you can’t isolate them, you shouldn’t use allocator.
I don’t believe there is any kind allocator will allow you swap managed memory block.

I disagree. This is just a schema one (in this case, you) chooses to use in his/her application. Though it may be one of the better schema for that particular application.

However, one may adopt a different schema (say) so that an allocator is never destroyed earlier than any reference to its managed memory blocks, for example, boost::singleton_pool. This would’ve surrendered the isolation you deemed mandatory pointless, in a different application where a different choice was made.

Always keep this in mind, there is no one schema that works best for all applications.

STDCXX is good enough to protect you do stupid things, in my opinion.

Okay, back to STL allocators. Yes, functionality wise, STDCXX works. (Was it your intention to not mention DINKUMWARE/MSVC? The behaviors of the two implementations are effectively the same in this regard.) In fact, according to the Standard, all implementations I examined worked (functionality wise) and are compliant to the Standard. (that is if we don’t take the non-inheritable allocator thing into account) But this post is not about functionality nor Standard compliance. Rather, it’s about stateful STL allocator semantics and assumptions programmers make about STL containers (in respect of swapping, mostly). For example, one may write a function template that needs to swap the content of two containers in the middle of things it does:

template <class StlContainer>
void foo(StlContainer& container)
{
  // do something meaningful...

  // This container, `another_container`, uses default
  // constructed instance of type StlContainer::allocator_type.
  StlContainer another_container;

  // However, since the parameter `container` is passed in, it
  // could very well use an user specified instance of type
  // StlContainer::allocator_type.
  swap(another_container, container);

  // do other meaningful things...
}

One would (I certainly would before I wrote the allocator library mentioned earlier in this post) most likely to assume the swapping is always trivial (say swapping a few pointers) and no-throw. When such assumption is more than programming convenience, but an assertion he/she relies on for a particular application, he/she may be in very deep trouble.

Because there is nothing stopping users of this function passing a STL container which uses a stateful allocator. BTW, IMO, such usages are very valid and reasonable, unless it is documented otherwise. To make things worse, this is not an issue caused by the STL implementation he/she uses, the problem roots in the Standard. He/she can’t just file a bug report and expect someone would fix the implementation.

BTW, I don’t belive my C++ is better than you.

This I wouldn’t know and is a non-matter in this discussion.

Anyhow, I know no shame so I took it as a compliment. Thanks.

I just feel strange you try to figure out what will happen
when STL objects works with mixed allocator.
I my experience, even not STL. this is not allowed.

Yes, it is allowed, at least in the context of STL containers. It is a real problem. Please visit the first two links in the reference section of this post:

• Issue 431, C++ Standard Library Active Issues List
• n1599, C++ Standards Committee Papers

As you can see, this issue has been noted and documented more than once, by the C++ Standard Committee. I am not the first person to talk about this issue, I just happen to re-discovered it on my own.

Cheers~

PS. this has gotta be one of the longest replies I’ve ever written.

Therefore, I will carefully design all classes won’t mess up when
we we destory allocator. So, if we use objects along with particular
allocator, these objects will just like living in isolated world.

If you can’t isolate them, you shouldn’t use allocator.
I don’t believe there is any kind allocator will allow you swap managed memory
block.

STDCXX is good enough to protect you do stupid things, in my opinion.

For many C++ programmers, this post is just flat boring, most of them probably couldn’t care less about the issues it attempted to highlight. I am thrilled by the fact that there are real people who read this post.

However, I failed to understand some of your comment in a sensible way. My guess is that, it would be easier if we could communicate in Chinese, regarding this post. (But I could be wrong :P)

Allocator per instance is used for performance generally.

Yes and No.

我想你的原意與 STL-style allocator 無關, 指的是特別的 custom allocator.

我舉個例, 除了 general purpose memory allocator (e.g. C 的 malloc, C++ 的 ::operator new), 最常見的 memory allocator 大概就是 memory pool (e.g. boost::singleton_pool). Memory pool 會被使用的原因很多, 當然 runtime performance 可以是原因, 也有其他與 runtime performance 無關的重要因素會讓 programmer 選擇 memory pool. 例如為了確保 memory allocation 不會失敗 (e.g. pre-allocation), 或是限制某 module 使用 memory 的上限 and/or 簡化 garbage colloction (e.g. resource pool).

The issues you raise is not real problem you gonna happened, unless you don’t know how the whole idea works.

這句話前半句的意思是說 “這不是個有意義的問題, 因為你不會遇到這個狀況” 嗎???

事實上我就是遇到了這個狀況. 雖然鑽研 STL source code 常是有趣的事情, 但這次我是在對 container 做 swap 時觀察到預期之外的行為才發現這個問題的.

後半句好像是說 “除非你不完全清楚這玩意到底是怎麼運作的”.

小弟應該算是稍微清楚的…

If you concern too much , nothing will be done before everything is perfect.

我猜這句話的意思是 “想太多會幹不了事, 沒有東西是完美的”.

的確, 我是個想很太多的人 不過老闆還沒把我 fire 掉, 還是有在幹事啦~~

C++ 絕對不是最好或是 perfect. 我也不敢期盼任何事物是完美的. (除了老婆之外 :P) 但請你考慮一下我的角度, 我 (自認) 是個熱愛 C++ 的重度使用者, 如果你也看了我其他的文字的話可能會注意到, 雖然在評論時我會試著客觀, 但在模糊地帶我只會偏心說 C++ 的好話, 幹樵都是樵別人. 在我跳出來談 C++ 語言/library/standard 的缺點時, 雖不見得是天大的事情, 卻 (IMO) 很可能是值得探討/注意的 issue.

It’s not reasonable to exchange data between two same class object by different allocator. It won’t and should’nt be happened in real work. Unless the coder is idiot.

很遺憾, 我對這段的理解比較肯定. 這個笨蛋就是我 XD. 不論我同不同意這個結論, 希望 Ziyu 可以對前題 - 為什麼這在真實世界不會發生 - 做進一步的說明.

BTW, I didn’t feel offended by your comment. 但我確實希望能夠了解你的回應中我沒能夠清楚理解的部份.

Cheers~

Happy holidays~

http://channel9.msdn.com/posts/Charles/The-Concurrency-Runtime-Fine-Grained-Parallelism-for-C/

If you concern too much , nothing will be done before everything is perfect.

It’s not reasonable to exchange data between two same class object by different
allocator. It won’t and should’nt be happened in real work. Unless the coder is idiot.

我也對 concurrency 很有興趣, 希望有機會能交流彼此己的心得.

看了你的幾篇文章介紹後，我也開始閱讀 Sutter 的部落格了。
目前特別感興趣的是關於 Concurrency 主題的文章。

我也想問，where are you?