what could cause pragma once in c / cpp file [closed] - c++

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I'm wondering what could go wrong when I will have bigger C / C++ project with multiple modules and I will by mistake type #pragma once into some c / cpp file. Will it just spit warnings at me and ignore the pragma or can it somehow break my project?
EDIT:
This is just teoretical question. There are no more details.

#pragma once serves as a header guard similar to:
#ifndef MY_INCLUDED_FILE
#define MY_INCLUDED_FILE
....
#endif
This just makes sure that a certain file is compiled only once even if it is included multiple times.
If a compiler doesn't support a certain pragma it will simply ignore it.
On older compilers it may not be known, so you have to use the ifdef solution. If the compiler doesn't understand it, and you don't have the header guard, then you probably will get a lot of errors for duplicate definitions and similar.

Related

Use OpenGL types in header files without including OpenGL header [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 months ago.
Improve this question
I want to be able to use OpenGL types i.e. GLenum, GLuint, GLint etc. in my header files but I would like to avoid including glad.h (avoid including it in the HEADER files, but it will be included in .cpp files) to make sure OpenGL calls cannot be made if someone includes my file. I believe a concept like "fundamental type forward declaration" would do the trick - this is obviously not a thing.
Code example (image to allow syntax errors highlight):
You can provide typedefs for these separate from the GLAD headers. The simplest approach would be to just copy-and-paste the entire portion of the GLAD header the declares the typedefs (for all platforms) into a forward declaration header.

Best Programming Practise, C++ Headers and Include [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
OK, I have done some looking around but to nothing.
As I have been learning C++, I have been told by some to have my includes stored into the .h file is available, and by others, to keep them in the .cpp file.
My question is what is the preferred industry standard and why?
Includes in the .cpp are only included when that one file is compiled, but the includes for the .h are to included everytime it the file is invoked.
Hence putting your includes in cpp files will most likely speed up compilation (less cross-referencing)

When to use include guards or #pragma once C++ [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it good practice to use your choice of either/both include guards and #pragma once in every header file, or just those with something such as a class declaration?
I am tempted to put it in every header, but I'm afraid it would be unneeded and only add to the compile time. What is good practice or common to do?
Let me clarify: I understand the difference between the two. I am asking whether by experience programmers use it in every file or just those that require it.
Summarizing the comment by Galik and what I realized:
Include guards should be put in every header file in the case that something in the future conflicts. Furthermore, the small time it takes the compiler to process the include guards will make the compilation faster since the extra header does not need to be processed.
#pragma once is compiler specific, while normal include guard definitions, should work with any c++ preprocessor.
Thus for sake of portability, always stick to "ye good old" include guards idiom.
The use of include guards is essential to prevent multiple symbol declaration errors in your code. You shouldn't bother about assumptions, or implications, how this is handled by the c++ preprocessor (modern ones are pretty optimized to do this efficiently).
If you want your code to be portable to all C++ compilers you'll need to use include guards. If you feel the compiler you use is inferior and benefits from the use of #pragma once you can also add this pragma: compilers not understanding it will just ignore it. Personally, I don't bother with use of #pragma once. It is a solution to a non-existing problem: compilers can absolutely detect include guards to avoid opening files already included.

In MFC/C++ taking too much time to build [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am having one big project in which I have kept all Headers in one common header file and where all I needed i included that header file.. by doing like this project is working fine but if I do changes in any header file its taking too much to build so I want to know is there any resolution to reduce the build time?
This isn't really specific to MFC, it is a general C++ thing. Basically don't put everything in 1 common header. Make use of forward declarations wherever possible. Use include guard macros in headers unless doing some special preprocessor magic.
Use a precompiled header and only put stuff in there that very rarely changes. Don't let this header get too big though as that can decrease build times.
Reduce the amount of code in headers. In some cases the pimpl idiom can make headers more terse and less prone to change due to 'internal' implementation changes at the cost of run-time efficiency.
http://www.cplusplus.com/forum/articles/10627/

Why and when do we need to use #pragma [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I was learning a winsock client server program and came up through #pragma comment(lib,"ws2_32.lib"). Understood its need here. But what are the other instances I can use it and why do I need to use it?
#pragma 's are implementation defined compiler commands.
That means, each compiler could treat or support pragmas in a different way.
They are used for example for generating user defined warnings or errors as with
#pragma warning WARNINGMSG
or #pragma error ERRORMSG
or as include guard with #pragma once at the top of a headerfile.
What #pragma comment is used for, you can find nice explained here:
What does "#pragma comment" mean?
But after all, I would advise you to avoid pragmas as far it is possible, because as they are almost all, implementation defined, your code will be limited in portability if you use them.