I had a problem debugging my solution consisting of C#, C++/CLI, and native C++ projects. I was not able to get breakpoints working in the native C++ parts – after running the solution with breakpoints set, they were turning gray with warning sign, and their tooltip stated that “The breakpoint will not currently be hit. No symbols have been loaded for this document.” despite all debug properties were set right on those projects and all debugging symbols existed. After fighting it for a few hours and almost giving up, I started to think that the problem might not be with the native C++ projects, but rather somewhere else, e.g. in the StartUp project, which is C#. Checked that project’s properties, and guess what! Debug > Enable unmanged code debugging option was off!!! Switched it on, and voila – breakpoints work fine in native C++ DLL now!!! :)
Finally I am back! :) Last year or so I was really busy working on our product, but now we are basically ready, and I can spare more time for “hobbies”.
In Google C++ Style Guide they state that they are not using exceptions in C++ code at Google. They have reasons for it (“historical” mostly, as usual), but I do not necessarily agree with their view on it. Anyway, exceptions are quite a controversial topic in C++ community, and a must-read C++ Exceptions: Pros and Cons article at CodeProject goes deeper into the subject.
Personally I think that exceptions are really great, although I see how people can get things messy/wrong when using exceptions in inappropriate contexts and/or in inappropriate ways. Recipe to avoid problems? My own short list:
- Use exceptions when they are really needed, i.e. when something exceptional happened
- Understand Exception guarantees AKA Abrahams guarantees (see more at Exception-Safety in Generic Components – Lessons Learned from Specifying Exception-Safety for the C++ Standard Library by David Abrahams)
- Follow Resource Acquisition Is Initialization AKA Resource Initialization Is Acquisition (or RAII/RIIA in short) principle
memcpy() Is Going to Be Banned article at InfoQ talks about dangers of memcpy (and other memory/string related functions). Microsoft has more in-depth explanations as well as the list of Security Development Lifecycle (SDL) Banned Function Calls at MSDN. Also available from Microsoft is banned.h header file that, once included, will produce warnings for all the banned functions. Alternatively one can use the /W4-C4996 compiler option.
A “healthy set” of Win32 and C++-related links (related stuff, anyway):
- MVP Tips, Techniques, and Goodies by Joseph M. Newcomer has a lot of C++ and Win32 topics, covering all “gray” areas like asynchronous operations, synchronization, threading, memory leaks, optimizations, various Windows APIs, device drivers, etc. For example, there is An introduction to memory damage problems that goes thoroughly through the topic, or absolutely fantastic The n Habits of Highly Defective Windows Applications that nicely enumerates ugliest “no-no’s” one should avoid in his code if he wants to sleep well :)
- C++ In Action, book by Bartosz Milewski. Cool thing is that there is a web edition of the book. Additionally, on the C++ Resources page there is Windows API Tutorial, RSWL: Free Windows Library, and some other papers and presentations, including topics on Resource Management, something called auto_vector ;) , and rather interesting Dealing with Software Complexity presentation.
- Win32 samples has a lot of samples for Net*() APIs, as well as for LSA, NTFS streams, processes, security
Needed to do some “weird” things recently that involved bit operations, e.g. to create masks with certain number of bits set. During my “research” I found few interesting places:
- Bit Twiddling Hacks – lots of snippets related to bit operations, e.g. counting, reversing, swapping, interleaving, testing, etc., etc., etc.
- Creating multiple numbers with certain number of bits set – this was the answer to my need, clean and simple
- Technical Interview Questions – has a lot of interesting topics, nicely categorized, although not all-encompassing, if comparing to the first link above