// Statements like:
// #pragma message(Reminder "Fix this problem!")
// Which will cause messages like:
// C:\Source\Project\main.cpp(47): Reminder: Fix this problem!
// to show up during compiles. Note that you can NOT use the
// words "error" or "warning" in your reminders, since it will
// make the IDE think it should abort execution. You can double
// click on these messages and jump to the line in question.
#define Stringize( L ) #L
#define MakeString( M, L ) M(L)
#define $Line \ MakeString( Stringize, __LINE__ )
#define Reminder \ __FILE__ "(" $Line ") : Reminder: "

This is an addendum to the answer for those who find it tedious to punch in #pragma directives every-time they need to put a bookmark in the code: You can save a few keystrokes by whipping up a macro to do this for you! While in general, you cannot have a #pragma directive within macros, MS C/C++ compilers 2008 and above do support a special vendor-specific extension called the __pragma which can be used with macros. See Pragma Directives and the __Pragma Keyword.

You can easily extend it to suit your needs and add more warnings. The good part of having such a system is that you can selectively turn-on say, only code-review items and not have to worry about anything else by setting the appropriate macro in the build settings.

This one allows it to be used without #pragma (Microsoft specific I think) and when you click it takes you to the line since it shows the file and line number just like a regular err/warning message does since none of the other ones seem to do this. This used to work without the __pragma but newer versions of msvc require it. Ive been using it since sometime in the 90's. I use Visual Studio 2013

It's the format of your message that decides whether it's 'clickable' in VS. Indeed, __pragma, with it's two leading underscores, is toolchain-specific. On top of that, #pragma, while not being standard, is supported by most toolchains (gcc, clang, vs...) too.
–
xtoflNov 5 '13 at 5:59

its no so simple, you need to expand __LINE__ to its integer form before turning that into a string
–
NecrolisMay 11 '11 at 15:26

@Necrolis: Found the MSDN KB article for this and posted a snippet
–
JacobMay 11 '11 at 15:27

2

While Microsoft is within their rights to define symbols with double underscores, you should avoid them. The standard reserves them for identifiers created by the compiler manufacturer.
–
Mark RansomMay 11 '11 at 20:39