I am buying a compiler and was planning on SourceBoostC. I see they have a C++ version available now as well. Are there arguments to be made in favor of C++ as an embedded systems programming language? Seems a bit overkill, but string handling and the like would be made easier. I just worry about how messy the assembly/machine code might end up with a language that powerful.
Classes and objects aren't a hardware thing. They're software. I don't see any real reason why they wouldn't work in PICs, except that they probably compile to fatter code.
The C++ is post processed to C and then compiled (C++ does not compile directly to binary). This way you completely loose control over the output code. The only gain is "code administration" but as embedded programming usually does not produce million of lines of code, this is really a very small gain. With C you already loose some of the control over the chip but in some time one can "know" what kind of code will be generated (for e.g. if you use branch or loop flow control statements) by what statements. With C++ you totally loose control hence your code is slower/unoptimised.
For the small projects / simple chips (16f(84|628) for e.g.) i recommend asm as if you want anything "smart" done by them, you have to optimise your code... For "bigger" ones, C/Pascal/Basic are fine but C++ is too big of an overkill imho
OO is nice if you have OO experience, Even with OO experience you can easily live without it in most/all uC projects. SourceBoost C has function overloading and templates borrowed from C++, maybe other features check the manual.
My suggestion is to skip the 16F family and move up to the 18F where you can use the free student version of the Microchip compiler. It has unlimited RAM and ROM use. The 18F chips have more memory too.