cout << vector<string>

[barcaroller]

In the boost::program_ options tutorial, the author included the following
code:
cout << "Input files are: "
<< vm["input-file"].as< vector<string()
<< "\n";
Basically, he is trying to print a vector of string, in one line. I could
not get this compile (let alone run). To get it to compile and run, I had
to re-write it as:
vector<stringv = vm["input-file"].as< vector<string() ;

vector<string>: :const_iterator i;

for ( i = v.begin();
i != v.end();
++i )
{
cout << *citer << " ";
}
Does anyone know if the original line of code is correct? If so, what was I
missing?

[Jeff Schwab]

James Kanze wrote:

I'm almost sure that the intent was that vector<T>::size _type
should be then same as the size_type of it's allocator; this is,
at least, what all of the implementations I know do. Which
means that it can be pretty much anything the user wants (as
long as it is an unsigned integral type);

I don't think that's true.

the default allocator is required to typedef it to size_t.

It's not just that the default allocator has to use size_t. The standard
containers are always permitted to assume that
SomeAllocator<T >::size_type is size_t, even if SomeAllocator is
user-supplied. See 20.1.5, bullet 4.

[James Kanze]

On Nov 13, 11:15 pm, Jeff Schwab <j...@schwabcen ter.comwrote:

James Kanze wrote:

I'm almost sure that the intent was that
vector<T>::size _type should be then same as the size_type of
it's allocator; this is, at least, what all of the
implementations I know do. Which means that it can be
pretty much anything the user wants (as long as it is an
unsigned integral type);

I don't think that's true.

What isn't true, that the intent was that it should be the same
as size_type of the allocator, or that that's what most
implementations do. With regards to the implementations , there
does seem to be some differences: g++ and the STLPort use
size_t, but Dinkumware and Roguewave use allocator::size _type.
With regards to the "intent", it's very difficult to know what
the intent was behind anything to do with allocators, but if
there was no intent that the user could customize it, why the
typedef to begin with.

the default allocator is required to typedef it to size_t.

It's not just that the default allocator has to use size_t.
The standard containers are always permitted to assume that
SomeAllocator<T >::size_type is size_t, even if SomeAllocator
is user-supplied. See 20.1.5, bullet 4.

You mean paragraph 4. Then see paragraph 5. The whole thing is
a farce, of course---the standard says that it doesn't require
user supplied allocators to be useful for anything, then goes on
to say that the implementation is "encouraged " to make them
useful. At the time of standardization , there was considerable
discussion about allocators---a lot of people seemed to want
them, but for a lot a of different reasons. I can remember
hearing at least two justifications for this additional
complexity: to support different pointer sizes (i.e. far
pointers on an Intel at the time), and to support things like
putting containers in shared memory. A mimimum implementation
of the standard, i.e. one which takes full advantage of the
freedoms in 20.1.5/4, doesn't support either. Quality
implementations , such as Dinkumware, do take the statement of
intent in paragraph 5 seriously, however. (Whether this means
that you actually can use allocators to put a container in
shared memory, I really don't know. If not, however, then
allocators are just excess baggage.)

Anyway, with regards to my original statement: it should be
ammended to say that it's implementation defined whether
vector<T>::size _type can be anything the user wants, but the
standard explicitely "encourages " an implementation to support
this possibility.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Hendrik Schober]

Maxim Yegorushkin wrote:

On Nov 11, 4:39 pm, Hendrik Schober <spamt...@gmx.d ewrote:

>Maxim Yegorushkin wrote:

>>On Nov 11, 3:36 pm, Hendrik Schober <spamt...@gmx.d ewrote:

[...]

>>> But lookup isn't ADL only. The enclosing namespaces are considered,
too, aren't they? And the global namespaces is always enclosing.
(I'm not saying you're wrong. I just don't understand this.)
At the second stage of the two-phase name lookup (at the point of
template instantiation) it is ADL only.

I'm trying to come up with some trivial example that
illustrates this, but I fail. [...]

Here is a simplified version of the problem with
std::ostream_it erator<std::pai r< and a global
operator<<(std: :ostream&, std::pair<>):

namespace N {

struct X {};

void bar(struct overload_for_co mpilers_with_no _two_phase_look up&);

template<class Tvoid foo(T t) { bar(t); }

}

template<class Tvoid bar(T);

int main()
{
N::X x;
foo(x);
}

Thanks, I didn't know this.
I suppose the rationale is to limit the number of possibly
surprising overloads considered?

Max

Schobi