Thoughts on function

E

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.
 
I

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.
 
E

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.
 
I

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?
 
E

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top