What is prefered way of passing pointer/reference to existing object in a constructor?
<p>I'll start from example. There is a nice "tokenizer" class in boost. It take a string to be tokenized as a parameter in a constructor:</p>

<pre><code>std::string string_to_tokenize("a bb ccc ddd 0");
boost::tokenizer&lt;boost::char_separator&lt;char&gt; &gt; my_tok(string_to_tokenize);
/* do something with my_tok */
</code></pre>

<p>The string isn't modifed in the tokenizer, so it is passed by const object reference. Therefore I can pass a temporary object there:</p>

<pre><code>boost::tokenizer&lt;boost::char_separator&lt;char&gt; &gt; my_tok(std::string("a bb ccc ddd 0"));
/* do something with my_tok */
</code></pre>

<p>Everything looks fine, but if I try to use the tokenizer, a disaster occurs. After short investigation I realized, that the tokenizer class store the reference that I gave to it, and use in further use. Of course it cannot work well for reference to temporary object.</p>

<p>The documentation doesn't say explicitly that the object passed in the constructor will be used later, but ok, it is also not stated, that it won't be :) So I cannot assume this, my mistake.</p>

<p>It is a bit confusing however. In general case, when one object take another one by const reference, it suggest that temporary object can be given there. What do you think? Is this a bad convention? Maybe pointer to object (rather than reference) should be used in such cases? Or even further - won't it be useful to have some special keyword to argument that allow/disallow giving temporary object as parameter?</p>

<p>EDIT: The documentation (version 1.49) is rather minimalistic and the only part that may suggest such a problem is:</p>

<blockquote>
  <p>Note: No parsing is actually done upon construction. Parsing is done on demand as the tokens are accessed via the iterator provided by begin.</p>
</blockquote>

<p>But it doesn't state explicitely, that the same object that was given will be used.</p>

<p>However, the point of this question is rather discussion about coding style in such a case, this is only an example that inspired me.</p>
