#### Archived

This topic is now archived and is closed to further replies.

# Vector<short> in to std::ostream

This topic is 5572 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Is there a better way of dumping a vector of shorts in to an ostream than just looping over them one element at a time? Chris Brodie http:\\fourth.flipcode.com

##### Share on other sites
you could use the member_fun_ptr functor with the insertion operator on cout... but essentially any way you do it would do the same thing. What do you see as the drawbacks of looping over one element at a time?

Don''t listen to me. I''ve had too much coffee.

##### Share on other sites
quote:
Originally posted by Sneftel:
you could use the member_fun_ptr functor with the insertion operator on cout

Why the mem_fun_ptr? I don't get how you would use it :\

Anyway, try this:

    #include <iostream>#include <algorithm>#include <vector>int main(int argc,char** argv){	std::vector<short> vs;	for(short i = 0; i < 10; ++i)		vs.push_back(i);	std::copy(vs.begin(),vs.end(),ostream_iterator(std::cout)); // dump all the shorts to std::cout	return 0;}

[edited by - daerid on September 9, 2002 1:44:09 AM]

##### Share on other sites
IIRC, insertion operators for primitive types are implemented as member functions for ostream; so you could use mem_fun_ptr to call the operator directly for each value.

Both of these approaches, however, don''t allow for field separators. And certain field separators (commas between values, but not before the first or after the last value) would be extremely difficult to handle gracefully within STL algorithms.

Don''t listen to me. I''ve had too much coffee.

##### Share on other sites
"What do you see as the drawbacks of looping over one element at a time? "

Clean code I guess. In every case where I thought I needed to loop on elements of a container the STL Guru''s here seem to have a way of using the algorithm. This has made me a better STL coder as a whole. This question however releated to ostream and by the looks of the doco it didn''t look like a container enough for me to use any tricks i know of.... but I was proven wrong again.

My first reason to ask however was that I ''know'' that a vector is a contiguous block of memory and i just want to dump that to disk, I thought there might be some .reserve() like trick that I should be using to ensure I''m not doig it poorly.

I just tend towards better techniques even when I always know that a for loop will suffice. I guess I just like hurting myself . A for_each or copy just looks so much cleaner in code...

cb

Chris Brodie
http:\\fourth.flipcode.com

##### Share on other sites
quote:
Original post by gimp
My first reason to ask however was that I ''know'' that a vector is a contiguous block of memory...

It''s not guaranteed by the standard, IIRC, so you shouldn''t write code that depends on it (because implementations may vary to allow for faster growth/resize times).

##### Share on other sites
It wasn''t in the original standard, but it is now. Just reading in Sutter''s book about it. He said he''s never come across a compiler that doesn''t implement vector as contiguous memory anyhow, so you''re pretty darn safe to code that way. Sutter quotes chapter & verse, but the book''s downstairs & I''m too lazy to move. Heheheh.

BTW, what was with the game tonight? Were the refs going for a record or something? Not totally their fault, though--NE''s defense had Pittsburg completely rattled.

##### Share on other sites
also realize that there are 2 types of output into ostreams, formatter and raw. with continous memory you can always do raw binary writes and get absolute maximum efficiency - but there will be no format conversion .. so things like \n don''t get translated into platform specific versions ... etc ... the iterator / algorithm method is (efficiency wise) basically the same as looping over all the elements yourself .. but it is syntactically cleaner and less error prone.

##### Share on other sites
quote:
It wasn''t in the original standard, but it is now.

quote:
Just reading in Sutter''s book about it. He said he''s never come across a compiler that doesn''t implement vector as contiguous memory anyhow, so you''re pretty darn safe to code that way. Sutter quotes chapter & verse, but the book''s downstairs & I''m too lazy to move. Heheheh.

Sutter is making an assumption based on his experience.

##### Share on other sites
null_pointer, i know you love to debate about useless filigrane details..

but it is, in C++0x, and, well, all compilers are in that specific case yet C++0x standart (or bether, all stl implementations).. so what? its like ARB_extensions in opengl. not yet standart but yet approved to be standard and this because its by standard used everywhere yet as standard.. are those enough standarts to get your standard "no i''m not with you" away?

"take a look around" - limp bizkit

##### Share on other sites
quote:
Original post by null_pointer

*sigh*
"Until 2001, a minor fly in the ointment was that the 1998 C++ standard didn''t actually guarantee that..(this)..would work portably on every C++ platform you might buy. This is because (this) assumes that the internal contents of the vector are stored contiguously in the same format as is an array, but the original C++ standard didn''t require vendors to implement vector that way...This was fixed in 2001 as part of Technical Corrigendum #1 to the C++ standard, which now requires that the contents of a vector are stored contiguously, just like an array."
Sutter, "More Exceptional C++".

##### Share on other sites
So the Technical Corregendum is part of the standard?

##### Share on other sites
quote:
Original post by null_pointer
So the Technical Corregendum is part of the standard?

From: http://www.cuj.com/experts/2002/sutter.htm
----
TCI (Technical Corrigendum 1): Completed in 2001, the first "mid-course correction" (a.k.a. "patch," a.k.a. "service pack," a.k.a. "maintenance release") to the C++98 Standard. Contains the resolutions to Defect Reports submitted by the global C++ community.
----
IMO, that constitutes a "yes, it''s part of the standard". However, IANASL.

##### Share on other sites
yes, corrections are standard ... as soon as they are published as complete ... and they are the only type''s of things that can change about the standard until either 5 or 10 years have passed (can''t remember but i think it''s 5 years before they can begin meeting to define the next version of the standard ... and then however long it takes to agree on it) ... between now and then they can put out calls for suggestions, proof of concept and reference implementations, and technical corrections and clarifications.

##### Share on other sites
quote:
IANASL

Sometimes I wonder if the tech community proceeds at its current pace whether we will eventually have more acronyms than words in the English language.

What does IANASL mean?

##### Share on other sites
AFAICT (hee hee), it means "I Am Not A Standards Lawyer".

Don''t listen to me. I''ve had too much coffee.

##### Share on other sites
IIRC, AFAIK, AFAICT, IANASL, IMO, IMHO, WTF!@#\$@#

##### Share on other sites
Sneftel guesses correctly.

PCMCIA: people can''t memorize computer industry acronyms.

##### Share on other sites
and whoever decided they should refer to User Mode Linux by that name and the acronym UML is seriously deranged ... I can just see new computer science students flooding the gates now ... I have downloaded package X, which requires UML, which I think I have installed allready (at least my Java programs can see it just fine), but I can''t seem to find the config files anywhere ...

##### Share on other sites
(T)echnology (W)ithout (A)n (I)nteresting (N)ame

##### Share on other sites
quote:
Original post by Sneftel
Both of these approaches, however, don't allow for field separators. And certain field separators (commas between values, but not before the first or after the last value) would be extremely difficult to handle gracefully within STL algorithms.

template<class OS, typename FI>OS& write_cvs(OS& os, const FI& begin, const FI& end)   {   if(begin!=end)      {      copy(begin, end-1, ostream_iterator<int>(os, ", "));      cout << *(end-1);      cout << endl;      }   return os;   }