![]() |
Chapter 7 | ![]() |
Apparently though, there's a deep-rooted revolution within the bowels of the software giant itself, and I have to believe that the #pragma is how the programmers are fighting back.
See, if you know all the secrets of the pragma, you can alter the behavior of so many different things that I don't even know where to start. Suffice to say, some are constant switches (some pragmas work on a number, like, 1 or 2, or 9476), some are macro-like commands, and some determine project settings (like library usage and the sort) during compile time. If you read about the precompiled headers above [section 7.1.2], you can actually use pragmas to cause individual parts of the header file the precompiled header is created from to be excluded, inlined, conditionally included, or the sort. Standard code too can have it's functionality determined by pragma determining things like 'Am I running in a debug release?', and the sort.
If you showed lack of foresight and created a function with the same name as a standard function (log() comes to mind here), supposedly you could use pragmas to dynamically include libraries for only single files at a time, potentially even discrete sections of code.
So, you're going to be good friends with pragma. At the same time, the documentation upon proper use is hidden or non-indexed - searches won't turn it up, it will simply exist in an unrelated file, demonstrating some other (mis)feature. So, you're going to hate it, since it's very hard to tell when your problem is really your problem, or just a pragma problem.
All the same, it's useful to know a handful of pragmas.
#pragma message("I need to finish work here!")will show the following text when I go to compile this file (pragma.cpp);
C:\msvcdebug\pragma.cpp(4):I need to finish work here!The super correct way to do this is;
#pragma message(REMIND("I need to finish work here!"))But it's functionally the same as the other, and either way is terribly useful if you code in spurts like I do.
On to another favorite of mine; using the STL in your code. Circle uses a lot of container and container-like objects. One common modification in the holy quest to turn CircleMUD from a C based mud to a C++ based mud, is to poorly adapt the C code instead of writing from scratch. One of the easiest ways to start this braindead project is to convertlists and such to use the Standard Template Library.
The problem is that the compiler is just as braindead. Due to the use of templates and extended inheritance and the sort, STL headers declare classes and functions with greater than 255 letters in them after they are name-mangled to be entered as an unique entry in the compiler symbol table. Sometimes these are just warnings, but other times you may have turned on the compiler warning switches (I'll cover those in a second). Either way, you don't want them to spam your compile output screen just because you're using the standard template library. So, issue the following pragma:
#pragma warning (disable: 4786)Yes, I know, I'm just being pedantic. Of course, how could ANYONE miss something that was so obvious. It's just intuitive that disabling the warning 4786 will let my program actually compile to completion. Everyone should know that, just to include a standard library that's actually named 'Standard Template Library', you should have to jump through hoops…*angst* *angst*. Moving on ...
Pragmas are good for other things too. Our friend the STL has problems with MSVC running on a high warning level.
I recommend that you set your warning level very high, and force your compiler to treat warnings as errors. To do this,
go to Projects Settings, and click on the 'c/c++' tab, and click 'General' in the category box. Set the warning level
to 4 in the drop down list box, and put a check mark in the "Treat warnings as Errors box." You'll notice quite a few
problems, even with stock CircleMUD, and some of them aren't even 'real' errors. Don't fret - this happens with the
standard windows headers!
That's where the pragma warning really shines; If you are really, REALLY really 100% sure, beyond a doubt that a given warning really isn't a warning, you can go ahead and disable it for just a small section of code at a time!
Here's how;
#pragma warning(push, 1) /* code in here */ #pragma warning(pop)You may have guessed already, but this simply changes the warning level to 1, until that value is popped off the pragma-stack. If you don't know what a stack is (or why you'd pop and push one), re-read the section 6 introduction, where I talk about stacks.
It should go without saying that you should not do this unless you are more than absolutely certain that a given warning can be ignored. This is usually true in the following cases;
I'm not going to list all the pragma warning and disable codes, but most compile time operations can either be controlled, altered, or examined and behavior taken based on their values through pragmas. They're required in windows as well, simply to compile cleanly.
![]() |
Index | ![]() |
7.1.3 The Incredible, Inedible Class Browser | 7.1.5 It's a bird, It's a plane, it's super comment |