C

__PRETTY_FUNCTION__
__FUNCSIG__ const char *szFile = __FILE__; int iLine = __LINE__; const char *szFunc = __FUNCTION__; // Func name const char *szFunD = __FUNCDNAME__; // Decorated const char *szFunS = __FUNCSIG__; // Signature
 * http://stackoverflow.com/questions/4384765/whats-the-difference-between-pretty-function-function-func
 * http://stackoverflow.com/questions/4434282/visual-c-equivalent-of-file-line-and-pretty-function

Operator new
void* operator new (size_t size) { void *p=malloc(size); if (p==0) // did malloc succeed? throw std::bad_alloc; // ANSI/ISO compliant behavior return p; }
 * http://www.velocityreviews.com/forums/t288468-overriding-global-new.html
 * http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=40

// The matching delete looks as follows:

void operator delete (void *p) { free(p); } Now you can use try and catch blocks to handle potential allocation exceptions properly, even if your compiler isn't yet fully-compliant in this regard: int main { try { int *p=new int[10000000]; // user-defined new //..use p delete p; // user-defined delete } catch (std::bad_alloc & x) { std::cout << x.what; // display exception } } Experts like Herb Sutter, recommend that if you create it, then you should delete it. In other words, if your translation unit creates an object, then it should be responsible for deleting the object
 * http://bytes.com/topic/c/answers/439570-overriding-new-delete

Heap Creation
"Look up the pattern called 'factory method'." "to prevent object creation/destruction on stack, one just needs to declare a private destructor" "The bottom line is that once you decide to use reference counted objects, you don't control the lifetime of the object, all you do is control the lifetime of a reference to the object. And declaring the destructor private forces you to recognise this."
 * http://bytes.com/topic/c/answers/637493-friend-operator-new-delete-allow-obj-instantiation-only-heap-howto
 * http://meditation-art.blogspot.com/2007/04/c-heap-only-object.html
 * http://blogs.msdn.com/b/larryosterman/archive/2005/07/01/434684.aspx

Templates

 * http://www.codeguru.com/forum/archive/index.php/t-211709.html
 * Final Class

Memory Management
"You should not explicitly call the destructor, since doing so won't release the memory that was allocated for the Fred object itself. Remember: delete p does two things: it calls the destructor and it deallocates the memory." "A derived class's destructor (whether or not you explicitly define one) automagically invokes the destructors for base class subobjects. Base classes are destructed after member objects" This is about the only time you ever explicitly call a destructor. void someCode {  char memory[sizeof(Fred)]; void* p = memory; Fred* f = new(p) Fred; ...  f->~Fred;   // Explicitly call the destructor for the placed object } [11.14] Is there a way to force new to allocate memory from a specific memory area?
 * http://www.parashift.com/c++-faq-lite/dtors.html

Yes. The good news is that these "memory pools" are useful in a number of situations. The bad news is that I'll have to drag you through the mire of how it works before we discuss all the uses. But if you don't know about memory pools, it might be worthwhile to slog through this FAQ — you might learn something useful!

Other
switch (i) { case 0: int j = 1; break; } "You actually can declare variables within a switch if you do it according to the syntax of the language. You're getting an error because 'case 0:' is a label, and in C it's illegal to have a declaration as the first statement after a label — note that the compiler expects an expression, such as a method call, normal assignment, etc. (Bizarre though it may be, that's the rule.)"
 * http://boredzo.org/pointers/
 * http://stackoverflow.com/questions/2036819/compile-error-with-switch-expected-expression-before
 * http://stackoverflow.com/questions/1231198/declaring-variables-inside-a-switch-statement
 * http://stackoverflow.com/questions/1231198/