[I really shouldn't have said "most" in the above. "Some"
would be more appropriate, because there are a lot of
techniques which can be applied to free development.]
I'm not sure what you are referring to, but one thing we
agree is important to software quality is code reviewing.
That can be done in a small company and I'm sometimes
given feedback on code in newsgroups and email.
To be really effective, design and code review requires a
physical meeting. Depending on the organization of the project,
such physical meetings are more or less difficult.
Code review is *not* just some other programmer happening to
read your code by chance, and making some random comments on
it. Code review involves discussion. Discussion works best
face to face. (I've often wondered if you couldn't get similar
results using teleconferencing and emacs's make-frame-on-display
function, so that people at the remote site can edit with you.
But I've never seen it even tried. And I note that where I
work, we develop at two main sites, one in the US, and one in
London, we make extensive use of teleconferencing, and the
company still spends a fortune sending people from one site to
the other, because even teleconferencing isn't as good as face
to face.)
It hadn't really dawned on me that my approach might be
thought of like that. The rabbis teach that G-d controls
everything; there's no such thing as chance or coincidence.
The Bible says, "And we know that all things work together
for good to them that love G-d, to them who are the called
according to His purpose." Romans 8:28. I get a lot of
intelligent and useful discussion on gamedev.net, here and
on Boost. It's up to me though to sift through it and
decide how to use the feedback. I've incorporated at
least three suggestions mentioned on gamedev and quite a
few more from here. The latest gammedev suggestion was to
use variable-length integers in message headers -- say for
message lengths. I rejected that though as a redundant
step since I'm using bzip for compression of data. I
thought for awhile that was the end of that, but then
remembered that there's a piece of data that wasn't
compressed -- the length of the compressed data that is
sent just ahead of the compressed data. So now, when
someone uses compression, the length of the compressed
data is generally also compressed with the following:
(I say generally because it depends on the length of
data.)
uint8_t
CalculateIntMarshallingSize(uint32_t val)
{
if (val < 128) { // 2**7
return 1;
} else {
if (val < 16384) { // 2**14
return 2;
} else {
if (val < 2097152) {
return 3;
} else {
if (val < 268435456) {
return 4;
} else {
return 5;
}
}
}
}
}
// Encodes integer into variable-length format.
void
encode(uint32_t N, unsigned char* addr)
{
while (true) {
uint8_t abyte = N & 127;
N >>= 7;
if (0 == N) {
*addr = abyte;
break;
}
abyte |= 128;
*addr = abyte;
++addr;
N -= 1;
}
}
void
Flush()
{
uint8_t maxBytes =
CalculateIntMarshallingSize(compressedBufsize_);
uint32_t writabledstlen = compressedBufsize_ - maxBytes;
int bzrc = BZ2_bzBuffToBuffCompress(reinterpret_cast<char*>
(compressedBuf_ + maxBytes),
&writabledstlen,
reinterpret_cast<char*>
(buf_), index_,
7, 0, 0);
if (BZ_OK != bzrc) {
throw failure("Buffer::Flush -- bzBuffToBuffCompress failed ");
}
uint8_t actualBytes = CalculateIntMarshallingSize(writabledstlen);
encode(writabledstlen, compressedBuf_ + (maxBytes - actualBytes));
PersistentWrite(sock_, compressedBuf_ + (maxBytes - actualBytes),
actualBytes + writabledstlen);
index_ = 0;
}
Those functions are from this file --
http://webEbenezer.net/misc/SendCompressedBuffer.hh.
compressedBuf_ is an unsigned char*. I've thought that the
calculation of maxBytes should be moved to the constructor,
but I have to update/improve the Resize() code first.
We've discussed the Receive function previously. I now have
a SendBuffer class and a SendCompressedBuffer class. This is
the SendCompressedBuffer version of Receive --
void
Receive(void const* data, uint32_t dlen)
{
unsigned char const* d2 = reinterpret_cast<unsigned char
const*>(data);
while (dlen > bufsize_ - index_) {
memcpy(buf_ + index_, d2, bufsize_ - index_);
d2 += bufsize_ - index_;
dlen -= bufsize_ - index_;
index_ = bufsize_;
Flush();
}
memcpy(buf_ + index_, d2, dlen);
index_ += dlen;
}
I doubt it. Making something free doesn't change your
development process. (On the other hand, if it increases the
number of users, and thus your user feedback, it may help. But
I don't think any quality problems with VC++ can be attributed
to a lack of users.)
I think it changes the development process. If it doesn't
then they probably haven't thought much about the implications
of making it free. They are in a battle of perception. Many
people have thought that Microsoft is a greedy company that
makes mediocre products. Giving away some software, while
going against their nature, is done, I think, to help improve
their image. They are forced into what 25 years ago would
have been unthinkable. I don't really think it will radically
improve their product either, though. As I've indicated I
don't think they are coming to the decision because they've
had a change of heart. It's more of a necessity being
imposed upon them. However, as I often say -- better late
than never.
Brian Wood
http://webEbenezer.net
(651) 251-938
