Thoughts on function

[Ebenezer]

Why does google put in these huge gaps?  I didn't include it.

Not sure. Sorry.

Everything at after your ending label could be in a bool returning
member function.

OK, so if I work on an implementation like that would you
suggest making some of the local variables member variables?
The added function needs to access numWritten, all and partialFlush.

 

[Ian Collins]

OK, so if I work on an implementation like that would you
suggest making some of the local variables member variables?
The added function needs to access numWritten, all and partialFlush.

Well you've already made partialFlush static, so it's a obvious
contender for a a member variable. The other two could be parameters.

 

[Ebenezer]

Well you've already made partialFlush static, so it's a obvious
contender for a a member variable.  The other two could be parameters.

bool
SendBuffer::ending (uint32_t all, uint32_t numWritten)
{
buf_.erase(buf_.begin(), buf_.begin() + numWritten);
if (numWritten == all) return true;

partialFlush_ = true;
return false;
}


bool
SendBuffer::Flush ()
{
uint32_t const all = buf_.size();
uint32_t numWritten = 0;
if (partialFlush_) {
::neolib::segmented_array<unsigned char, chunk_size>::segment&
segment =
segmented_iterator<unsigned char,
chunk_size>(buf_.begin()).segment();

numWritten = Write(sock_, &buf_[0], segment.size());
if (numWritten < segment.size()) return ending(all, numWritten);
partialFlush_ = false;
}

int32_t const chunks = (all - numWritten) / chunk_size;
for (int32_t ii = 0; ii < chunks; ++ii) {
uint32_t bytes = Write(sock_, &buf_[numWritten], chunk_size);
numWritten += bytes;
if (bytes < chunk_size) return ending(all, numWritten);
}

if (numWritten < all) {
numWritten += Write(sock_, &buf_[numWritten], all - numWritten);
}

return ending(all, numWritten);
}


The .o file is 48 bytes bigger in this form when using
g++ 4.5.1 and -O3. I'm not sure this is a step in the
right direction.

 

[Ian Collins]

bool
SendBuffer::ending (uint32_t all, uint32_t numWritten)

What is your objection to size_t?

The .o file is 48 bytes bigger in this form when using
g++ 4.5.1 and -O3. I'm not sure this is a step in the
right direction.

Are you programming for a PIC? Otherwise why worry about 48 bytes?

 

[Ebenezer]

What is your objection to size_t?

None really. I may change it.

Are you programming for a PIC?  Otherwise why worry about 48 bytes?

I'm not worried about it, but am looking for some clues
as to whether that form is a step in the right direction.
The 48 additional bytes makes me wonder a little.