Each file has a nice table of contents but for that you need to download the PDF and view it in e.g. Foxit or Adobe Acrobat. Ch 1, the Introduction, is just 1 page, though. Ch 2, tooling up with Visual C++ and learning about some Windows stuff, is more pages. And so is ch 3, about basic C++ such as loops and decisions. And ch 4, about creating console programs (all programs so far just GUI), chimes in at some 50 pages!
Perhaps it’ll become a book…
Here’s a table of contents generated by (1) using a Word TOC field and half-documented RD fields to refer to the chapters, (2) [Shift Ctrl F9] in Word (is that still documented anywhere?) to “lock” the text, (3) edit, removing unwanted entries, (4) copy as text to Crimson Editor, save, and (5) run a very very hairy C++ program to generate the HTML.
Oh, I see in the preview that instead of a purely numbered list, in the WordPress blog I get letters and roman numerals!
So be it – but there’s also a PDF of the original over at Google docs (link above).
Introduksjon. | 1
Første program, etc. | 1
Gratis verktøy. | 1
Muligens ikke helt typiske installasjonsproblemer… | 2
“Hallo, verden!” i Visual Studio / om IDE prosjekter. | 6
Feilretting i Visual Studio / generelt om C++ typesjekking. | 15
Hva “Hallo, verden!” programteksten betyr. | 18
Spesielt aktuelle Windows-ting for nybegynneren. | 21
Makroer og Unicode/ANSI-versjoner av Windows API-funksjoner. | 22
Moderne utseende på knapper etc. / om DLL-er og manifest-filer. | 23
Ikon og versjonsinformasjon / [.exe]-fil ressurser. | 28
Gir C++ ekstra mye kode og kompleksitet? | 32
Å finne relevant informasjon om ting. | 32
Tipsruter og automatisk fullføring. | 32
Å gå direkte til en aktuell deklarasjon eller definisjon. | 33
Full teknisk dokumentasjon / hjelp / kort om Microsofts “T” datatyper. | 34
Dokumentasjon av C++ språket og C++ standardbiblioteket. | 36
Diskusjonsfora på nettet / FAQ-er. | 38
Et første subsett av C++. | 1
Gjenbruk av egendefinerte headerfiler. | 1
En wrapper for [windows.h]. | 2
Å konfigurere en felles headerfil søkesti i Visual Studio 2010. | 6
En muligens enklere & mer pålitelig måte å konfigurere Visual Studio på. | 9
How often have you declared a variable and invented an ungrokkable three-letter name for that variable, just to temporarily hold the result of some API function so that you can check it immediately after the call? Let me guess, you’ve done that thousands of times. And if so then here are happy tidings: you can completely avoid introducing all those helper variables! 🙂
Evidently some people get to my blog by googling up C4099, the MSVC warning that you’ve used struct in one place and class in another place, for the same class. This is one of the alleged sillywarnings in my sillywarnings suppression header. But given e.g. the discussion at StackOverflow, is it really a sillywarning, or perhaps something to take seriously?
In part I I showed how to use the cppx library’s exception translation support, which decouples the specification of how non-standard exceptions should be translated, from each routine’s invocation of such translation. The translation can be customized by dynamically installing and uninstalling exception translator routines. And essentially each routine that wants exception translation must use a catch (this will most often be a generic catch(...)) where it invokes cppx::rethrowAsStdX, which in turn invokes the installed exception translator routines and performs a default translation if none of them apply.
In this second part I discuss how that translation machinery works.
In part III I’ll discuss the support for installation and uninstallation of exception translator routines. And perhaps I’ll need a part IV to discuss the cppx exception types! Anyway, now, diving down into the code…
MFC throws pointers, Xerces throws various types not derived from std::exception, and as I recall the Lotus Notes API throws integers. An interesting diversity. But as the Chinese curse goes: may you live in interesting times! Such non-standard exceptions generally require you to have multiple catches every place such an exception could otherwise escape to higher levels, or where you want to handle any exception with a given general meaning. It’s not that the designers have tried to be clever or that they’re out to get you: it’s just that these libraries stem from before C++ was standardized, i.e., before 1998.
One partial remedy is exception translation. Somehow arrange for any non-standard exception to be caught and result in some corresponding exception derived from std::exception. It does not solve all the problems – but it sure beats doing it by copy-n’-paste coding of exception handlers!
With C++98 exception translation cannot be completely centralized in a portable, reusable way. As far as I know that’s not possible even with the upcoming C++0x standard. But it’s possible to provide portable and application-independent support that does most of the job, and that provides a general convention that largely eliminates the chance of any non-standard exception slipping through, and that’s what I discuss here. [… More] Read all of this posting →
Like my posting about cloning this posting about unique identifier values is in preparation for discussing the cppx library’s exception translation support. In short the aspect discussed here is how to let the calling code choose an id for a set of installed translators, so that it can remove them all in one operation (specifying that id). And the simplest id you have in C++ is a type with external linkage. You can obtain a unique-wrt.-comparisions id for a class from the typeid operator. The only problem is that that id, of type std::type_info, is not copyable and not generally comparable, so it can’t be used directly as a key in a std::map, say, and the standard fails to guarantee that you will always obtain the same std::type_info instance for the same type, so it’s a bit risky to use a pointer to that instance…
If you’re already familiar with casting to inaccessible base, disambiguation casts, casting to most derived object, casting to/from first member of a POD, and accessing the built-in address operator via a cast, then this blog entry is perhaps not for you. 🙂 It’s basics, but for some reason even seasoned C++ programmers are not always aware of all these special cast operations. This is about special case semantics, not syntax or general operations.
To clone an object is to create a dynamically allocated copy of the object, of the same dynamic type, generally without knowing the exact dynamic type. The common way to do that is a virtual method, e.g. called clone, that simply invokes the type’s copy constructor. And the main problem with cloning in C++ is: how to reduce the extreme redundancy of zillions of essentially identical clone methods everywhere?