What did you look at?
Chapter 4: BDS
What worked well or felt clear?
Very clear chapter.
Did anything break or behave differently than expected?
Example given was titled main.cpp but it is in the repo as Common/tests/BdsTestMain.cpp.
In the description of "Framing" > "Checksums" it's stated "Header checksum covers the header bytes (excluding the checksum itself)" but this isn't exactly right - the header's checksum field isn't excluded (4 bytes not included in checksum calculation), it's zeroed (and 4 zero bytes included).
Additional thoughts
w.r.t. "reader-makes-right" philosophy - description looks good to me but perhaps a sentence contrasting to alternative design choices? Yet OTOH the description of the "latched error model" does have nor does it need a description of alternative designs. Yet again OTOH under "sized field decoding" you explain about rejecting invalid encodings including "(for example, a wide encoding that represents a small value)" - this gives the advantage that it guarantees any message can only be encoded one way which can be useful (this is the only choice to be made during encoding) but that isn't explained ... but could be. Hmm. No general rule to follow I guess.)
By the way the part about "pass-through views" shows that once you accept views on buffers (it came late to C++ standard library) they pay off in many ways, including efficiency in APIs when building one component over another, which is nice and will be more emphasized later I'm sure.
I see that this chapter (unlike the Type Erasure chapter I mentioned in #1 does have big code dumps that don't format well in the PDF. Where the font is kind of large so the line lengths are rather narrow. But I don't care 'cause I'm following along with my printed listings.
What did you look at?
Chapter 4: BDS
What worked well or felt clear?
Very clear chapter.
Did anything break or behave differently than expected?
Example given was titled
main.cppbut it is in the repo asCommon/tests/BdsTestMain.cpp.In the description of "Framing" > "Checksums" it's stated "Header checksum covers the header bytes (excluding the checksum itself)" but this isn't exactly right - the header's checksum field isn't excluded (4 bytes not included in checksum calculation), it's zeroed (and 4 zero bytes included).
Additional thoughts
w.r.t. "reader-makes-right" philosophy - description looks good to me but perhaps a sentence contrasting to alternative design choices? Yet OTOH the description of the "latched error model" does have nor does it need a description of alternative designs. Yet again OTOH under "sized field decoding" you explain about rejecting invalid encodings including "(for example, a wide encoding that represents a small value)" - this gives the advantage that it guarantees any message can only be encoded one way which can be useful (this is the only choice to be made during encoding) but that isn't explained ... but could be. Hmm. No general rule to follow I guess.)
By the way the part about "pass-through views" shows that once you accept views on buffers (it came late to C++ standard library) they pay off in many ways, including efficiency in APIs when building one component over another, which is nice and will be more emphasized later I'm sure.
I see that this chapter (unlike the Type Erasure chapter I mentioned in #1 does have big code dumps that don't format well in the PDF. Where the font is kind of large so the line lengths are rather narrow. But I don't care 'cause I'm following along with my printed listings.