The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Printed |
Page 72
last items in the table of the page 72 |
I think "Signaled" and "Nonsignaled" explanation is mixed. I think correct
explanation should be like the below.
1. "Signaled" section of Pipe
When there is unread data in the pipe. Data can be read from a pipe using the
ReadFile functionon the read handle associated with a given pipe.
2. "Nonsignaled" section of Pipe
When the pipe is empty. Dta can be placed in a pipe using the WriteFile operation on
the write handle associated with a given pipe.
And "Named pipe" explanation in the page 73 should be changed like "Pipe".
|
Anonymous |
|
| Printed |
Page 86
8th line |
This is near the end of the DuelingThreads1.cpp file. On this line, the
file reads:
if (dwResult != WAIT_OBJECT_0) {
to check to see if WaitForMultipleObjects() returned any errors. From my
understanding, this call should assume that any result between
WAIT_OBJECT_0 and (WAIT_OBJECT_0 + nCount - 1) should be considered
okay. That would mean this code should read:
if (!((dwResult >= WAIT_OBJECT_0) && (dwResult <= WAIT_OBJECT_0 + 3 - 1))) {
Please let me know if I am missing something.
|
Anonymous |
|
| Printed |
Page 169
|
The first two sentences of the 5th paragraph now read:
"Usually it is easist to have a CMclThread-derived object create its
own CMclThreadHandler object inside the derived class constructor.
This will be demonstrated in the Bees1.cpp example..."
Is Bees1.cpp right?
If so, I think these sentences should read:
"Usually it is easist to have a CMclThreadHandler-derived object
create its own CMclThread object inside the derived class constructor.
This will be demonstrated in the Bees1.cpp example..."
If this is not right, should Bees1.cpp be changed to Bees2.cpp?
|
Anonymous |
|
| Printed |
Page 201-216
?] I have found a bug in CMclMailbox.cpp |
CopyMemory( lpMsg, GetHeadPtr(), m_pHdr->cbMsgSize)
"m_pHdr->cbMsgSize" is the buffer size when I create this object.
But, in run time actual message size will be different. Since it is a shared
memory I was getting part of the messages from other slots of the mailbox.
I changed to:
CopyMemory( GetTailPtr(), lpMsg, strlen((char*)lpMsg))
CopyMemory( lpMsg, GetHeadPtr(), strlen((char *)GetHeadPtr()))
and I get a message from only my slot.
|
Anonymous |
|
| Printed |
Page 289
CMclEvent object in SeatDataBase |
I think the m_ceNoReaders object should create a manual, signaled event. The default
arguments of the Event class create a non-signaled, auto_event. Therefore the
following statement in the program:
CMclEvent m_ceNoReaders;
should change to:
CMclEvent m_ceNoReaders(TRUE, TRUE);
|
Anonymous |
|
| Printed |
Page 341-344
The program listings for cfixedthreadpool.cpp (example 10-3) and |
ftptest.cpp (example 10-4) appear to be identical. This doesn't match the
source code on the disc.
|
Anonymous |
|
| Printed |
Page 418
3rd paragraph |
Text states that CMclWinThread::MclInitInstance calls the original MFC implementation CWinThread::InitInstance. But a look at the M
cl4Mfc.cpp file reveals this:
// these functions call the original MFC base
// class implementations...
BOOL CMclWinThread::MfcInitInstance(void) {
// we MUST return TRUE here or MFC will shutdown
// the newly created thread...
return TRUE;
}
Should not the correct implementation look like this:
BOOL CMclWinThread::MfcInitInstance(void) {
// we MUST return TRUE here or MFC will shutdown
// the newly created thread...
CWinThread::InitInstance();
return TRUE;
}
|
Anonymous |
|