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?

[Maxim Yegorushkin]

On Nov 11, 2:40*pm, Hendrik Schober <spamt...@gmx.d ewrote:

Maxim Yegorushkin wrote:

On Nov 11, 1:54 pm, Maxim Yegorushkin <maxim.yegorush [e-mail]>
wrote:

On Nov 11, 11:20 am, Hendrik Schober <spamt...@gmx.d ewrote:

[]

>* Having followed this whole battle of words, I wonder what's
* wrong with putting this operator into the global namespace
* and altogether avoiding the hassle of having to know about
* things you're not supposed to know about?
Nothing wrong and this is indeed the correct way to do so. I confused
this case with another one, sincere apologies.

This what I was confusing it with:

* * #include <map>
* * #include <iostream>
* * #include <iterator>

* * // should be in namespace std::
* * template<class T, class U>
* * std::ostream& operator<<(std: :ostream& s, std::pair<T, Uconst& p)
* * {
* * * * return s << p.first << ' ' << p.second;
* * }

* * int main()
* * {
* * * * typedef std::map<int, intMap;
* * * * Map m;
* * * * std::copy(
* * * * * * * m.begin()
* * * * * * , m.end()
* * * * * * , std::ostream_it erator<Map::val ue_type>(std::c out)
* * * * * * );
* * }

It won't compile unless operator<<(std: :ostream& s, std::pair<T, U>
const& p) is in namespace std.

* I would have asked the same question for this code. :)
* I don't understand why it doesn't compile. It comes down
* to this
* * ostr << val;
* with 'ostr' being an 'std::basic_ost ream<>' and 'val'
* being an 'std::pair<>'. Why doesn't this find the global
* operator?

Because expression "ostr << val" is template argument dependent and
thus is bound at the second phase of the two-phase name lookup. At the
second phase it uses ADL only to search for functions within
namespaces associated with ostr and val. ostr is std::basic_ostr eam
and val is std::pair<int, int>, thus one associated namespace is std.
int has no associated namespaces. So, the only namespace considered
for expression "ostr << val" is std, which lacks a suitable
operator<<().

--
Max

[Hendrik Schober]

Maxim Yegorushkin wrote:

On Nov 11, 2:40 pm, Hendrik Schober <spamt...@gmx.d ewrote:

>Maxim Yegorushkin wrote:

[...]

>> #include <map>
#include <iostream>
#include <iterator>
// should be in namespace std::
template<class T, class U>
std::ostream& operator<<(std: :ostream& s, std::pair<T, Uconst& p)
{
return s << p.first << ' ' << p.second;
}
int main()
{
typedef std::map<int, intMap;
Map m;
std::copy(
m.begin()
, m.end()
, std::ostream_it erator<Map::val ue_type>(std::c out)
);
}
It won't compile unless operator<<(std: :ostream& s, std::pair<T, U>
const& p) is in namespace std.

I would have asked the same question for this code. :)
I don't understand why it doesn't compile. It comes down
to this
ostr << val;
with 'ostr' being an 'std::basic_ost ream<>' and 'val'
being an 'std::pair<>'. Why doesn't this find the global
operator?

Because expression "ostr << val" is template argument dependent and
thus is bound at the second phase of the two-phase name lookup. At the
second phase it uses ADL only to search for functions within
namespaces associated with ostr and val. ostr is std::basic_ostr eam
and val is std::pair<int, int>, thus one associated namespace is std.
int has no associated namespaces. So, the only namespace considered
for expression "ostr << val" is std, which lacks a suitable
operator<<().

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.)

Max

Schobi

[Maxim Yegorushkin]

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

Maxim Yegorushkin wrote:

On Nov 11, 2:40 pm, Hendrik Schober <spamt...@gmx.d ewrote:

Maxim Yegorushkin wrote:

[...]

>* * #include <map>
* * #include <iostream>
* * #include <iterator>
* * // should be in namespace std::
* * template<class T, class U>
* * std::ostream& operator<<(std: :ostream& s, std::pair<T, Uconst& p)
* * {
* * * * return s << p.first << ' ' << p.second;
* * }
* * int main()
* * {
* * * * typedef std::map<int, intMap;
* * * * Map m;
* * * * std::copy(
* * * * * * * m.begin()
* * * * * * , m.end()
* * * * * * , std::ostream_it erator<Map::val ue_type>(std::c out)
* * * * * * );
* * }
It won't compile unless operator<<(std: :ostream& s, std::pair<T, U>
const& p) is in namespace std.
* I would have asked the same question for this code. :)
* I don't understand why it doesn't compile. It comes down
* to this
* * ostr << val;
* with 'ostr' being an 'std::basic_ost ream<>' and 'val'
* being an 'std::pair<>'. Why doesn't this find the global
* operator?

Because expression "ostr << val" is template argument dependent and
thus is bound at the second phase of the two-phase name lookup. At the
second phase it uses ADL only to search for functions within
namespaces associated with ostr and val. ostr is std::basic_ostr eam
and val is std::pair<int, int>, thus one associated namespace is std.
int has no associated namespaces. So, the only namespace considered
for expression "ostr << val" is std, which lacks a suitable
operator<<().

* 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.

* Schobi

--
Max

[Hendrik Schober]

Maxim Yegorushkin wrote:

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

>Maxim Yegorushkin wrote:

>>On Nov 11, 2:40 pm, Hendrik Schober <spamt...@gmx.d ewrote:
Maxim Yegorushkin wrote:
[...]
#include <map>
#include <iostream>
#include <iterator>
// should be in namespace std::
template<class T, class U>
std::ostream& operator<<(std: :ostream& s, std::pair<T, Uconst& p)
{
return s << p.first << ' ' << p.second;
}
int main()
{
typedef std::map<int, intMap;
Map m;
std::copy(
m.begin()
, m.end()
, std::ostream_it erator<Map::val ue_type>(std::c out)
);
}
It won't compile unless operator<<(std: :ostream& s, std::pair<T, U>
const& p) is in namespace std.
I would have asked the same question for this code. :)
I don't understand why it doesn't compile. It comes down
to this
ostr << val;
with 'ostr' being an 'std::basic_ost ream<>' and 'val'
being an 'std::pair<>'. Why doesn't this find the global
operator?
Because expression "ostr << val" is template argument dependent and
thus is bound at the second phase of the two-phase name lookup. At the
second phase it uses ADL only to search for functions within
namespaces associated with ostr and val. ostr is std::basic_ostr eam
and val is std::pair<int, int>, thus one associated namespace is std.
int has no associated namespaces. So, the only namespace considered
for expression "ostr << val" is std, which lacks a suitable
operator<<( ).

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. I have this

#include <iostream>

namespace N {
struct test { };

template< typename T >
void f(T) { std::cout << "f(T)\n"; }

void f(int) { std::cout << "f(int)\n"; }
}

template< typename T >
void g(T o) { f(o); }

int main()
{
N::test t;
g(t);
}

which compiles fine and gives the expected result.
What am I still missing.

Max

Schobi

[Maxim Yegorushkin]

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:

Maxim Yegorushkin wrote:
On Nov 11, 2:40 pm, Hendrik Schober <spamt...@gmx.d ewrote:
Maxim Yegorushkin wrote:
[...]
* * #include <map>
* * #include <iostream>
* * #include <iterator>
* * // should be in namespace std::
* * template<class T, class U>
* * std::ostream& operator<<(std: :ostream& s, std::pair<T, Uconst& p)
* * {
* * * * return s << p.first << ' ' << p.second;
* * }
* * int main()
* * {
* * * * typedef std::map<int, intMap;
* * * * Map m;
* * * * std::copy(
* * * * * * * m.begin()
* * * * * * , m.end()
* * * * * * , std::ostream_it erator<Map::val ue_type>(std::c out)
* * * * * * );
* * }
It won't compile unless operator<<(std: :ostream& s, std::pair<T, U>
const& p) is in namespace std.
* I would have asked the same question for this code. :)
* I don't understand why it doesn't compile. It comes down
* to this
* * ostr << val;
* with 'ostr' being an 'std::basic_ost ream<>' and 'val'
* being an 'std::pair<>'. Why doesn't this find the global
* operator?
Because expression "ostr << val" is template argument dependent and
thus is bound at the second phase of the two-phase name lookup. At the
second phase it uses ADL only to search for functions within
namespaces associated with ostr and val. ostr is std::basic_ostr eam
and val is std::pair<int, int>, thus one associated namespace is std.
int has no associated namespaces. So, the only namespace considered
for expression "ostr << val" is std, which lacks a suitable
operator<<() .
* 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. I have this

* * *#include <iostream>

* * *namespace N {
* * * * *struct test { };

* * * * *template< typename T >
* * * * *void f(T) { *std::cout << "f(T)\n"; }

* * * * *void f(int) { *std::cout << "f(int)\n"; }
* * *}

* * *template< typename T >
* * *void g(T o) { f(o); }

* * *int main()
* * *{
* * * * *N::test t;
* * * * *g(t);
* * *}

* which compiles fine and gives the expected result.
* What am I still missing.

Your example should work just fine.

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);
}

--
Max

[rio]

"Hendrik Schober" <sp******@gmx.d eha scritto nel messaggio
news:gf******** **@hoshi.visyn. net...

rio wrote:

>"Kai-Uwe Bux" <jk********@gmx .netha scritto nel messaggio
news:49******* *************** *@read.cnntp.or g...

>>rio wrote:
i know max(std::size_t ) >= max(vector::siz e_type)
Could you provide a pointer into the standard to backup that claim? or are
you making a statement about a particular platform?

seems to me
should be
in the C standard in the definition of type size_t

I seriously doubt the C standard says anything about the
relation between 'std::size-t' and 'std::vector<T> ::size_type'.

ok
what about relation between "size_t"
and 'std::vector<T> ::size_type'?

>[...]

Schobi

[rio]

"Jeff Schwab" <je**@schwabcen ter.comha scritto nel messaggio
news:2s******** *************** *******@giganew s.com...

rio wrote:
The vector's destructor deallocates the memory. Destruction can be a
wonderful thing. :)

yes i know it, but it is better to know where it is done

[Kai-Uwe Bux]

rio wrote:

"Hendrik Schober" <sp******@gmx.d eha scritto nel messaggio
news:gf******** **@hoshi.visyn. net...

>rio wrote:

>>"Kai-Uwe Bux" <jk********@gmx .netha scritto nel messaggio
news:49****** *************** **@read.cnntp.o rg...
rio wrote:
i know max(std::size_t ) >= max(vector::siz e_type)
Could you provide a pointer into the standard to backup that claim? or
are you making a statement about a particular platform?

seems to me
should be
in the C standard in the definition of type size_t

I seriously doubt the C standard says anything about the
relation between 'std::size-t' and 'std::vector<T> ::size_type'.

ok
what about relation between "size_t"
and 'std::vector<T> ::size_type'?

It's not dealt with anywhere. As far as I know, all we know about
std::size_t is that it is unsigned and the return type of the sizeof()
operator. Whether it can hold any value that std::vector<T>: :size_type can
hold, I have not seen in the standard (neither the C standard, which says
nothing about vector<T>::size _type nor the C++ standard).
Best

Kai-Uwe Bux

[Jeff Schwab]

rio wrote:

"Jeff Schwab" <je**@schwabcen ter.comha scritto nel messaggio
news:2s******** *************** *******@giganew s.com...

>rio wrote:
The vector's destructor deallocates the memory. Destruction can be a
wonderful thing. :)

yes i know it, but it is better to know where it is done

C++ destruction is deterministic, well-defined, and fairly easy to
understand. The fact that something is taken care of by a destructor
doesn't mean you don't know where it's done. If you use automatic
allocation, destruction happens when the object goes out of scope.

[James Kanze]

On Nov 13, 6:58*pm, Kai-Uwe Bux <jkherci...@gmx .netwrote:

rio wrote:

"Hendrik Schober" <spamt...@gmx.d eha scritto nel messaggio
news:gf******** **@hoshi.visyn. net...

rio wrote:
"Kai-Uwe Bux" <jkherci...@gmx .netha scritto nel messaggio
news:49****** *************** **@read.cnntp.o rg...
rio wrote:
i know max(std::size_t ) >= max(vector::siz e_type)
Could you provide a pointer into the standard to backup
that claim? or are you making a statement about a
particular platform?

>seems to me should be in the C standard in the definition
of type size_t

*I seriously doubt the C standard says anything about the
*relation between 'std::size-t' and
'std::vector<T> ::size_type'.

ok
what about relation between "size_t"
and 'std::vector<T> ::size_type'?

It's not dealt with anywhere. As far as I know, all we know
about std::size_t is that it is unsigned and the return type
of the sizeof() operator. Whether it can hold any value that
std::vector<T>: :size_type can hold, I have not seen in the
standard (neither the C standard, which says nothing about
vector<T>::size _type nor the C++ standard).

Well, vector<T>::size _type has to be an unsigned integral type,
capable of representing all of the positive values of
vector<T>::diff erence_type. And vector<T>::diff erence_type must
be the type returned by subtracting two iterators,

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); the default allocator
is required to typedef it to size_t. (The current standard
states that it should be "a type that can represent the size of
the largest object in the allocation model." This is certainly
wrong, since it is incompatible with the requirement that it
must contain all of the positive values which the
difference_type can contain---I've used systems where the
largest single object was 65365, but where pointers were
effectively 20 bits, and the difference between two pointers
could be 1 MB.) All of this has been rewritten in the current
draft to be expressed in terms of concepts, so someone has a lot
of detailed reading to do between here and Jan. 15th (when I
have to submit my comments on the CD to AFNOR).

--
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]