Write last half of the vector to std::ofstream

Question

I am writing code to write a vector to file. My aim is to write the last half of the vector to file first and then the first half based on offset. The code below gives me segmentation fault.

std::vector<uint8_t> buffer_(1000); // the vector is filled with values
int offset_ = 300;
std::ofstream output_file (file_name.c_str(), std::ofstream::out | std::ofstream::binary);
if (output_file.is_open()) {
    output_file.write(reinterpret_cast<const char*>(&buffer_[offset_]), (buffer_.size() -offset_)*sizeof(uint8_t));
    // segmentation fault on the line above
    output_file.write(reinterpret_cast<const char*>(&buffer_[0]), (offset_)*sizeof(uint8_t));
}

Can somebody tell me whats wrong with the code?

"`*sizeof(uint8_t)`" o.O I applaud writing generic code that's robust to later type changes, but since you've hardcoded the `uint8_t` anyway this is entirely without purpose. — Lightness Races in Orbit, Aug 11 '15 at 11:03

score 4 · Answer 1 · answered Aug 11 '15 at 11:06

4

You start by treating the offset as a [0-based] array index (&buffer_[300]) but then immediately treat it as a [1-based] element count (buffer_.size()-300). This is going to result in reading 700 elements starting at the 301^st element, which goes past the end of your vector by one element.

Subtract one from either of the arguments, depending on what you actually mean by "offset".

You should get used to working out this basic maths on paper when you have a problem.
Using your debugger wouldn't hurt, either!

answered Aug 11 '15 at 11:06

Lightness Races in Orbit

378,754
76
643
1,055

Could you explain why he is getting a seg fault ? and how will this fix the problem. This is for my learning – Vinay Shukla Aug 11 '15 at 11:11
@VinayShukla: Because he's reading memory that he shouldn't be reading. Changing the code to only read memory that he _should_ be reading will fix the problem. – Lightness Races in Orbit Aug 11 '15 at 11:12
So from your explanation I infer that he is trying to read 300th memory location which doesn't exist – Vinay Shukla Aug 11 '15 at 11:36
@VinayShukla: No, the 1001st (as my answer says). The vector has 1000 elements. – Lightness Races in Orbit Aug 11 '15 at 11:58
1

@VinayShukla He starts at element 301 and then reads 700 elements. 301 + 700 = 1001 so the last element that he reads is not allocated. – Jonathan Mee Aug 11 '15 at 12:03
Thanks @JonathanMee that answers my query :) – Vinay Shukla Aug 11 '15 at 12:07
@Vinay Pretty sure I said exactly that \*confused\* – Lightness Races in Orbit Aug 11 '15 at 12:46
I don't think your comment helped to clarify for @VinayShukla the difference between 0-based and 1-based indexing. I still have to just write out what I'm doing for complex array indexing to be certain that I didn't do something unintended. So the actual numbers always help me. – Jonathan Mee Aug 17 '15 at 12:30

score 0 · Answer 2 · edited May 23 '17 at 12:29

0

The functionality sought by this question is already implemented in rotate and rotate_copy. As a general rule re-implementing behavior already in the standard is wasteful and/or can be fraught with error, as is demonstrated by this question.

Since rotate_copy only uses ForwardIterators for it's input iterators, this answer can be leveraged through the simple use an ostreambuf_iterator. So this can be done instead of the two writes in the question:

const char* pBufferBegin = reinterpret_cast<const char*>(&*buffer_.data());

rotate_copy(pBufferBegin, pBufferBegin + offset_, pBufferBegin + buffer_.size(), ostreambuf_iterator<char>(output_file));

edited May 23 '17 at 12:29

Community

1
1

answered Aug 11 '15 at 12:01

Jonathan Mee

37,899
23
129
288

1

Nice, except your output is not quite right; the OP appears to want to write the binary representations of his `uint8_t`s to disk, not ASCII representations of the same. – Lightness Races in Orbit Aug 11 '15 at 12:45
@LightnessRacesinOrbit Ugh, you're totally right. I've tinkered with my answer, but I can't come up with a way to stream Unformatted Output. In the end I concede that use of the standard's implementation is probably not the best solution here :( I'd give your answer a +1 but I've already done that ;) – Jonathan Mee Aug 17 '15 at 12:25

Write last half of the vector to std::ofstream

2 Answers2

Linked