Olivier Langlois's blog

The hardware aspect of this webcam is impeccable. The image and the sound quality are very good. What is spoiling the package is the bad quality software bundled with this webcam that can bring Windows to become unstable. Casual computer users might never encounter the problem if they just open few programs. For the problem to occur, you have to spawn many processes. Examples of such activities are execution of batch files or using cygwin. The symptom of an unstable system is a dialog box with the following message every time that you start a new program:

Dwwin.exe:
The instruction '0x7c883f9c' referenced memory at '0x7c883f9c'. The memory could not be 'written'.

When that happens, the only thing you can do is reboot your PC. I have been months living with this problem without knowing what was causing it. For this reason, I am very unhappy with this product and I strongly discourage anyone to purchase a Logitech webcam as I think that almost, if not all, Logitech webcams are bundled with the same drivers. After this warning, if you still consider purchasing a Logitech webcam, I can tell you that there is a work around. You can turn off the Logitech Process Monitor. To do so, you go in the services panel that you can find in the 'Administrative tools' menu, find the Logitech service and stop it and set its startup type to manual to be sure that it will never run again on your system.

In my opinion, this book is better than Pthreads Programming because it goes way beyond just presenting the pthreads API. One critic I had on all the other multithreading books that I have read is that they are not covering issues with multithread programs on a SMP system. This book is actually discussing some of these issues on several pages! Beside this quality, it also covers high-level design patterns on how you can use threads such as pipelines, work crew and client/server. There is also a chapter showing how to program with thread cancellation and a section explaining how to create new synchronization objects from the primitives.

This brings me to the only problem that I can think of this book: its age. It is not totally up to date. Learning how you can build new synchronization objects by itself is a very interesting exercise but the problem is that the new synchronization objects built are the barrier and the read/write lock which have been added to the pthreads API since the book publication. Also, except for a small section describing the futur of pthreads, the newest additions to the pthread API are not described.

This book has been recently recommended to me by Amazon based on my previous purchase habits and I decided to go take a look at its description. At first, I was little bit skeptic about the value of a book published in 1993 and prepared with Word for Windows 2.0 because software programming has changed a lot since then! However, it was a very low risk purchase because of its very low price tag so I decided to give it a try and I have been pleasantly surprised!

This book is the proof that that there are few things in programming that are timeless. Errors of the past still occur today. The programming language used for the examples is C but what is taught is also applicable to C++ programming as well. Topics discussed in the book are: assertions, integrity checks, stepping through code with a debugger, how to not design interfaces that are error prone, avoid language features that are error prone and finally the author conclude his book by describing the attitude that a programmer should have. Among other things, a programmer should prioritize safe code before micro-optimizations. All these concepts are written in a style easy to understand filled with anecdotes that make this book a pleasant read.

To conclude, I have not been blown away by the content of this book but I have learn one thing or two and I am glad that I have read it especially with its very low price tag.

Which is better

void f(int &a);

or

void f(int *a);

?

Once compiled, there should not be any difference between the 2 versions as references are most likely implemented with pointers under the compiler hood. The main difference between passing a pointer to a function vs a reference is that with the reference you are sure that the reference points to a valid object where as with pointers you could pass a NULL pointer.

Hence, if a NULL pointer is not a valid value for a function, you can enforce that fact by passing a reference. Some people argue that it is possible to have dangling references by doing:

int &f()
{
    int a;
    a = 5;
    return a;
}

int main(int argc, char *argv)
{
    int &r = f();
    return 0;
}

or

int main(int argc, char *argv)
{
    int *p = new int(5);
    int &r = *p;
    delete p;
    return 0;
}

but I consider these cases pathological and my opinion is that references are safer than pointers because:

1. They behave like const pointers.
2. They must be initialized at their declaration.

With these, it should be much harder to have *unintentionally* dangling references than having uninitialized pointers especially if you do not do the newbie mistake of returning a reference to a local variable. My C++ debugging experience has led to me to fix plenty of pointer problems but I have never seen until now a dangling reference problem in real code.

Also, Scott Meyers, in his book More Effective C++ (item 1: Distinguish between pointers and references), goes in the same way about this issue.