pragma

http://en.wikipedia.org/wiki/Pragma_once Should I still use include guards when all of these compilers support #pragma once ? A lot of responses on stack overflow say to use both for compatibility, but I'm not sure if that still rings true. What compilers today don't support #pragma once ? I am not sure if using both was just a recommendation before it became widley adopted, or if there are still very good reasons to use both methods. Any examples of when only using #pragma once will cause problems? It depends on how much portable your program is expected to be. As long as you are writing a

I would like to use g++ and -Werror , so I have now to disable warnings for 3rd-party libraries I have no control of. The solution provided by http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html works very well, allowing simply to wrap the includes of 3rd party headers with pragmas. Unfortunately, that did no longer work for me in a certain setup where templates are involved. I created the following minimal example of where this approach did not work as expected: Source file main.cpp #pragma GCC diagnostic ignored "-Wunused-parameter" #include "hdr.hpp" #pragma GCC diagnostic error "

Function poisoning is very useful technique in C++. In general it refers to making a function unusable, e.g. if you want to ban the use of dynamic allocation in a program you could "poison" the malloc function so it can't be used. 'Poisoning' an identifier means that any reference to the identifier after the 'poisoning' is a hard compiler error For example (See live demo here ) #include <iostream> #include <cstdlib> #pragma GCC poison malloc int main() { int* p=(int*)malloc(sizeof(int)); // compiler error use of poisoned function malloc *p=3; std::cout<<*p<<'\n'; free(p); } I found this

In the latest two weeks, without releasing an update to my app, I have started getting a bunch of reports with corrupted databases. Below is the stacktrace. Android cannot open the database, and neither could the sqlite-manager program on my computer. However, the SQLite manager-addon to firefox could open it. After running the command "compact database", the database was fixed and I could open it in android. Is there any way I could do something like this within my app? The big problem is that I cannot even attempt to open the database, because newer versions of Android will immediately

I would like to be able to group similar methods and have them appear in my Outline view in Eclipse. This makes navigating large swaths of code a little easier on the eye, and easier to find methods you need. In Objective-C there was a pragma mark command that you could set. Anything like that for java/eclipse? I use the Coffee Bytes plugin for code folding, specifically configuring it for folding code that has start and end tags. Although the plugin is not downloadable off the page listed on the Google Code page, it has been recompiled against Eclipse 3.5 and made available elsewhere ; the

I'm using the OpenCV library and one of its header files, cxoperations.hpp, generates "warning C4793: 'anonymous namespace'::CV_XADD' : function compiled as native" , if my C++ project is compiled with CLR support. I can prevent the warning by surrounding the OpenCV header include like this: #pragma managed(push,off) #include <cv.h> #pragma managed(pop) But the project that actually uses OpenCV isn't compiled with CLR support, it's a native C++ static library. The project that does have CLR support, and generates this warning without the pragma statements, simply uses this static library. So I

I want to be able to break on Exceptions when debugging... like in Visual Studio 2008's Menu Debug/Exception Dialog, except my program has many valid exceptions before I get to the bit I wish to debug. So instead of manually enabling and disabling it using the dialog every time is it possible to do it automatically with a #pragma or some other method so it only happens in a specific piece of code? The only way to do something close to this is by putting the DebuggerNonUserCodeAttribute on your method. This will ensure any exceptions in the marked method will not cause a break on exception.