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?

[Hendrik Schober]

rio wrote:

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

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

[...]

Schobi

[Jeff Schwab]

rio wrote:

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

>Pete Becker wrote:

>>On 2008-11-07 06:03:15 -0500, Maxim Yegorushkin
<ma********** *****@gmail.com said:

#include <algorithm>
#include <iostream>
#include <iterator>
#include <vector>

template<typen ame T>
std::ostream & operator<<(std: :ostream& out, std::vector<Tco nst& v) {
if (!v.empty()) {
typedef std::ostream_it erator<Tout_ite r;
copy(v.begin(), v.end() - 1, out_iter( out, " " ));
out << v.back();

why not write above only?
copy(v.begin(), v.end(), out_iter( out, " " ));

The "easy" solution outputs a trailing space.

is it not better the "operator<< " defined below?

....

No, it is not better.

the above seems ok what not seems ok to me that this
"
std::vector<int vettor1;

for(i=0; i<90; ++i)
vettor1[i]=i;
"
here goes in segmentation fault
is not vector1 self sizabile?

The vector is resizable, but does not resize itself on indexing. See
the push_back and resize methods.

than how you are sure that *all* the allocations have its deallocation?
for example it seems "std::vector<in t>(ints,ints+4) "
copy in new memory the array ints[0..3]
and than it has to deallocate it but when and where

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

[Jeff Schwab]

James Kanze wrote:

On Nov 7, 7:21 pm, Jeff Schwab <j...@schwabcen ter.comwrote:

>James Kanze wrote:

>>On Nov 7, 1:32 pm, Jeff Schwab <j...@schwabcen ter.comwrote:
Pete Becker wrote:
On 2008-11-07 06:03:15 -0500, Maxim Yegorushkin

>>>><maxim.yego rush...@gmail.c omsaid:

>>>>> namespace std {
> template<class A1, class A2>
> ostream& operator<<(ostr eam& s, vector<A1, A2const& vec)

>>>>Which has undefined behavior.

>>>The correct alternative, AIUI:

>>>template<typ ename T>
std::ostream & operator<<(std: :ostream& out, std::vector<Tco nst& v) {

>>Correct in what sense?

>Correct in the sense that it implements the OP's intent, and
is allowed by the standard.

-- It doesn't work. Try it with std::vector<
std::vector< int , for example.

you don't output raw vectors, but vectors with a semantic
signification, which determines how you format them.

You're right. In real life, I don't write that sort of operator as a
template; I use a formatted_whate ver type. Good call.

My original intent was to provide a Standard-compliant alternative to
specializing a template in std for non-UDT types. Pete pointed out the
previous poster's UB, but did not suggest any alternative. There is a
delicate art to keeping such abstract discussions both generic and
focused, especially on Usenet.

[James Kanze]

On Nov 10, 6:29*am, "rio" <[e-mail] e:

"rio" <[e-mail] scritto nel
messaggionews:4 9************** *********@reade r5.news.tin.it. ..

"Kai-Uwe Bux" <jkherci...@gmx .netha scritto nel messaggio
news:49******** *************** @read.cnntp.org ...

Juha Nieminen wrote:

>Jeff Schwab wrote:
template<type name T>
std::ostrea m& operator<<(std: :ostream& out, std::vector<Tco nst& v){
* * if (!v.empty()) {
* * * * typedef std::ostream_it erator<Tout_ite r;
* * * * copy(v.begin(), v.end() - 1, out_iter( out, " " ));
* * * * out << v.back();
* * }
* * return out;
}

>* Is there some advantage of that code over a shorter and simpler:

>template<typen ame T>
std::ostream & operator<<(std: :ostream& out, std::vector<Tco nst& v) {
* * for(std::size_t i = 0; i < v.size()-1; ++i)

Nit: std::size_t is not guaranteed to be vector::size_ty pe.

i know max(std::size_t ) >= max(vector::siz e_type)

If this is true, then g++, VC++ and both of the library
implementations used with Sun CC are buggy, since they all allow
me to instantiate std::vector with an allocator which typedef's
size_type to unsigned long long.

i know *v.size()-1<=max(vector:: size_type) <= max(std::size_t )

Given that v.size() returns a vector::size_ty pe, it's safe to
say that v.size() <= max( vector::size_ty pe ). But if
vector::size_ty pe is an unsigned long long, and size_t is only
an unsigned long or an unsigned int, the second part is false.

Depending on what you're doing, it may be acceptable to suppose
that the default allocator is being used---I use size_t for this
a lot, when I know the actual instantiation of vector. But it's
not acceptable in a generic library.

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

[James Kanze]

On Nov 10, 12:47*pm, Maxim Yegorushkin <maxim.yegorush [e-mail]>
wrote:

On Nov 10, 10:22*am, James Kanze <james.ka...@gm ail.comwrote:

On Nov 10, 10:19 am, Maxim Yegorushkin <maxim.yegorush [e-mail]>
wrote:

On Nov 7, 12:17 pm, Pete Becker <p...@versatile coding.comwrote :
On 2008-11-07 06:03:15 -0500, Maxim Yegorushkin
<maxim.yegorush [e-mail] id:
The example probably assumes there is an overloaded
operator<<() for std::ostream and std::vector<>, something
like this:
* * #include <ostream>
* * #include <iterator>
* * #include <algorithm>
* * namespace std {
* * * * template<class A1, class A2>
* * * * ostream& operator<<(ostr eam& s, vector<A1, A2const& vec)
* * * * {
* * * * * * copy(vec.begin( ), vec.end(), ostream_iterato r<A1>(s, "
"));
* * * * * * return s;
* * * * }
* * }
Which has undefined behavior. You can only add template
specializations to namespace std when they depend on
user-defined types.
Formally true.
On practice it works just fine as long as One Definition Rule
is not violated.

Taking into account all of the code, including that which
you can't see or know about, such as in the implementation
of the library.

Precisely.

In other words, it works just fine as long as you're lucky.

Not quite. Rather as long as one understands what he is doing.

And has access to, and has read and understood all of the source
code of the standard library he's using, and can guarantee that
his code will never be compiled using a compiler where this is
not the case.

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

[Maxim Yegorushkin]

On Nov 11, 9:24*am, James Kanze <james.ka...@gm ail.comwrote:

On Nov 10, 12:47*pm, Maxim Yegorushkin <maxim.yegorush [e-mail]>
wrote:

On Nov 10, 10:22*am, James Kanze <james.ka...@gm ail.comwrote:

On Nov 10, 10:19 am, Maxim Yegorushkin <maxim.yegorush [e-mail]>
wrote:
On Nov 7, 12:17 pm, Pete Becker <p...@versatile coding.comwrote :
On 2008-11-07 06:03:15 -0500, Maxim Yegorushkin
<maxim.yegorush [e-mail] id:
The example probably assumes there is an overloaded
operator<<() for std::ostream and std::vector<>, something
like this:
* * #include <ostream>
* * #include <iterator>
* * #include <algorithm>
* * namespace std {
* * * * template<class A1, class A2>
* * * * ostream& operator<<(ostr eam& s, vector<A1, A2const& vec)
* * * * {
* * * * * * copy(vec.begin( ), vec.end(), ostream_iterato r<A1>(s, "
"));
* * * * * * return s;
* * * * }
* * }
Which has undefined behavior. You can only add template
specializations to namespace std when they depend on
user-defined types.
Formally true.
On practice it works just fine as long as One Definition Rule
is not violated.
Taking into account all of the code, including that which
you can't see or know about, such as in the implementation
of the library.

Precisely.

In other words, it works just fine as long as you're lucky.

Not quite. Rather as long as one understands what he is doing.

And has access to, and has read and understood all of the source
code of the standard library he's using, and can guarantee that
his code will never be compiled using a compiler where this is
not the case.

You just confirmed that no luck involved here, this is just a question
of understanding. ;)

--
Max

[Hendrik Schober]

Maxim Yegorushkin wrote:

On Nov 11, 9:24 am, James Kanze <james.ka...@gm ail.comwrote:

>On Nov 10, 12:47 pm, Maxim Yegorushkin <maxim.yegorush [e-mail] ote:

>>On Nov 10, 10:22 am, James Kanze <james.ka...@gm ail.comwrote:
On Nov 10, 10:19 am, Maxim Yegorushkin <maxim.yegorush [e-mail] ote:
On Nov 7, 12:17 pm, Pete Becker <p...@versatile coding.comwrote :
>On 2008-11-07 06:03:15 -0500, Maxim Yegorushkin <maxim.yegorush [e-mail] id:
>>The example probably assumes there is an overloaded
>>operator< <() for std::ostream and std::vector<>, something
>>like this:
>> #include <ostream>
>> #include <iterator>
>> #include <algorithm>
>> namespace std {
>> template<class A1, class A2>
>> ostream& operator<<(ostr eam& s, vector<A1, A2const& vec)
>> {
>> copy(vec.begin( ), vec.end(), ostream_iterato r<A1>(s, "
>>"));
>> return s;
>> }
>> }
>Which has undefined behavior. [...]
In other words, it works just fine as long as you're lucky.
Not quite. Rather as long as one understands what he is doing.

And has access to, and has read and understood all of the source
code of the standard library he's using, and can guarantee that
his code will never be compiled using a compiler where this is
not the case.

You just confirmed that no luck involved here, this is just a question
of understanding. ;)

During the last decade, I had to write and maintain code
that was compiled using half a dozen different compilers
(and compiler versions), multiplied by several std lib
implementations (and versions thereof) multiplied by half
a dozen platforms multiplied by several different apps
the code was used for (standalone app/plugin, GUI/command
line...). There were enough different things we had to
have a thorough understanding of to make the idea of
having to have a thorough understanding of each of those
implementations and code versions rather unattractive.

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?

Max

Schobi

[Maxim Yegorushkin]

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.

--
Max

[Maxim Yegorushkin]

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.

--
Max

[Hendrik Schober]

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?

Max

Schobi