stream to file a matrix

[bob]

Hi,

given a vector of vectors of strings thus;

typedef std::vector<std ::string> product;
typedef std::vector<pro duct> product_matrix;
whats the fastest, most efficient means of streaming the
"product_matrix " to a file? I.E. without using two "for" or "while"
loops. Is there a means of using copy ? I'd like to use stl's copy
along with my 2 dimensional vector of strings. Is that possible? Or
should I just iterate over the contents myself ?

thanks much

G

[Dietmar Kuehl]

Fei Liu wrote:

Dietmar Kuehl wrote:

Ben Pope wrote:

> I would create a stream operator for product and product_matrix:

Note, that this code is not supposed to compile! The problem is
that output operator used by 'std::ostream_i terator<int>' is sought
only in namespace 'std'. However, since the involved types are all

what do you mean 'sought only in name space std'?

Which part you didn't understand? I'm not qualified to give you a
lecture in English and thus I assume you understood the statement
per se (otherwise use a dictionary).

On a technical level, 'std::ostream_i terator<T>' is a template and
look-up of names in separated into two phases which is thus called
two-phase-look-up. For the dependent names, i.e. those depending on
the template arguments, only the second phase, i.e. argument dependent
look-up, applies. The rules for this are that only namespace are
considered in which one of the arguments is defined (the specification
of this are tricky but just collecting all namespace qualifiers of the
fully qualified names of the arguments will to the trick). The only
namespace involved in you class is 'std', i.e. this is the only
namespace in which names are sought.

built-in types, you are - strictly speaking - not allowed to define
the output operator there! Technically, it is likely to work if you

I don't see the connection between built-in type and reason why output
operator is not allowed to be fined in 'std', can you elaborate on this
please?

It is a restriction imposed to protect the library implementation
from being hosed up by people defining more or less arbitrary
functions in namespace 'std': as a user of the standard C++ library
you are only allowed to define certain functions in namespace 'std'
and when you are allowed to define a function the signature has to at
least contain one user defined type.

just plug the output operators into namespace 'std' but the
behavior of the program is not defined.

Not sure about the meaning of 'plug the output operators into name
std'...And why is the program behavior not defined? The code seem to
compile/run perfectly.

I suggested to disobey the rules and define a function in namespace
'std' which are, strictly speaking, not allowed to define in
namespace 'std'. This is likely to work but the standard does not
give you any guarantee that it indeed will work because this violates
a specific restriction. These restrictions are there to protect the
library implementations : it is pretty easy to put functions into
namespace 'std' which will almost certainly cause the library to fail
in funny way. Also, compilation might easily fail if the library
implementor choose to put similar or even the same function into his
implementation.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

[Fei Liu]

Dietmar Kuehl wrote:

Fei Liu wrote:

Dietmar Kuehl wrote:

Ben Pope wrote:
> I would create a stream operator for product and product_matrix:

Note, that this code is not supposed to compile! The problem is
that output operator used by 'std::ostream_i terator<int>' is sought
only in namespace 'std'. However, since the involved types are all

what do you mean 'sought only in name space std'?

Which part you didn't understand? I'm not qualified to give you a
lecture in English and thus I assume you understood the statement
per se (otherwise use a dictionary).

On a technical level, 'std::ostream_i terator<T>' is a template and
look-up of names in separated into two phases which is thus called
two-phase-look-up. For the dependent names, i.e. those depending on
the template arguments, only the second phase, i.e. argument dependent
look-up, applies. The rules for this are that only namespace are
considered in which one of the arguments is defined (the specification
of this are tricky but just collecting all namespace qualifiers of the
fully qualified names of the arguments will to the trick). The only
namespace involved in you class is 'std', i.e. this is the only
namespace in which names are sought.

built-in types, you are - strictly speaking - not allowed to define
the output operator there! Technically, it is likely to work if you

I don't see the connection between built-in type and reason why output
operator is not allowed to be fined in 'std', can you elaborate on this
please?

It is a restriction imposed to protect the library implementation
from being hosed up by people defining more or less arbitrary
functions in namespace 'std': as a user of the standard C++ library
you are only allowed to define certain functions in namespace 'std'
and when you are allowed to define a function the signature has to at
least contain one user defined type.

just plug the output operators into namespace 'std' but the
behavior of the program is not defined.

Not sure about the meaning of 'plug the output operators into name
std'...And why is the program behavior not defined? The code seem to
compile/run perfectly.

I suggested to disobey the rules and define a function in namespace
'std' which are, strictly speaking, not allowed to define in
namespace 'std'. This is likely to work but the standard does not
give you any guarantee that it indeed will work because this violates
a specific restriction. These restrictions are there to protect the
library implementations : it is pretty easy to put functions into
namespace 'std' which will almost certainly cause the library to fail
in funny way. Also, compilation might easily fail if the library
implementor choose to put similar or even the same function into his
implementation.

Thank you, I didn't know there exists such kind of limitation on
implementing function in namespace 'std'. Too many rules...