Re: ostream outputting garbage
On Jan 3, 10:29 pm, LR <lr...@superlink.net> wrote:
James Kanze wrote:
On Jan 3, 3:44 pm, LR <lr...@superlink.net> wrote:
I didn't look all that carefully at your code, but please consider:
std::ostream &operator<<(std::ostream &o,
const std::vector<std::string> &v);=
That function doesn't exist.
Oops. I should have made that clear.
And if you actually define it, it won't be found in a template.
Sorry, but I'm not sure that I understand what you meant by
that. Could you please expand on that?
That the operator won't be found, and won't be considered during
operator overload resolution, when << is invoked in a template,
e.g. in an ostream_iterator, for example. At least when
dependent lookup is involved (which will almost always be the
case) and the operator is only declared after the template has
been defined (which will depend on the order of includes, if the
operator is declared in an include).
For such operators to work correctly, they must be defined in a
namespace used in ADL. In the above case, std. And as a user,
you're not allowed to define such functions in the std
namespace. Formally, it's undefined behavior.
For a quick experiment, course, just to test something, I'll go
ahead and define the operator in std. In production code, of
course, you don't want to define it, even if you could.
The correct way of handling this is to wrap std::vector in a
user defined class.
Do you mean to wrap it if you're going to output it? Or
create an operator<< function? Why is wrapping the correct
way?
std::vector doesn't really have any established high level
semantics, which would define how you would output it. It's
sort of like the girders in a building: a structural detail of
the implementation, but having nothing directly to do with the
actual use of the building or the semantics of the program.
Within a program, you would normally wrap vector anyway, in an
application dependent class with application dependent
semantics. std::vector is not an abstraction of your
application. (I'm not sure that "wrap" is the correct word
here, since the class you define definitely adds to the
semantics.) There are doubtlessly some exceptions, when the
abstraction really is just an array; but since there is no
"standard" text representation of an array, you still have to
wrap it for output: you'll want different formats for output
depending on what the vector is being used for (e.g. a set of
values, a list of elements, a mathematical vector, etc.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34