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.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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...

Thanks for the answer guys...

cb

Chris Brodie
http:\\fourth.flipcode.com

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


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


No, it is not. We have had enough debates about this.


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 this post


Link to post
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
www.google.com

Share this post


Link to post
Share on other sites
quote:
Original post by null_pointer
No, it is not. We have had enough debates about this.


*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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.



This isn't that bad:

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



[edited by - Magmai Kai Holmlor on September 16, 2002 8:53:19 PM]

Share this post


Link to post
Share on other sites