Are malware used in C / C ++?

Question

What are the negative consequences of unused?

I know that they lead to an increase in binary size (or are they?), Anything else?

Answer 1

• Increases compilation time (potentially serious problem)
• Contaminates the global namespace.
• Potential collision of preprocessor names.
• If unused headers are included in third-party libraries, this may make it unnecessary to use such libraries as dependencies.

Answer 2

They do not necessarily increase binary size, but increase compilation time.

Answer 3

The main problem is the mess. These are the three main aspects in which the disorder manifests itself:

• Visual pollution; while you are trying to understand that others include what you need.

• Logical pollution; it has a greater likelihood of a collision of functions, more time to compile (this can be very small for a couple of inclusions, but if it becomes a “policy”, so as not to clear unnecessary ones, this can become a significant obstacle).

• Dependency transparency , since there are more headers for analysis, it is more difficult to define dependency cycles in your code. Knowing what depends on your code is crucial when your code base grows to any significant level that goes beyond the hobby level.

Answer 4

In general, yes, this causes some problems. Logically speaking, if you do not need it, do not turn it on.

• Any singlets declared as external in the header and defined in the source file will be included in your program. This obviously increases memory usage and possibly improves productivity by forcing the user to access their page file more often (now this is not a big problem, since single games usually have small and medium sizes, and since most of the people I know have 6+ GB of RAM).

• Compilation time increases, and for large commercial projects where it is often compiled, this can lead to a loss of money. This can only add a few seconds to your total time, but multiply it by several hundred compilations, or you may need to test and debug, and you have a huge waste of time, which thus leads to a loss of profit.

• The more headers you have, the greater the likelihood that you may have a pre-collision with a macro that you defined in your program or another header. This can be avoided by the proper use of namespaces, but still such a hassle to find. Again, lost profits.

• Contributes to code bloat (longer files and therefore more readable), and can significantly increase the number of results you will find in the IDE auto-install tool (some people are religiously against these tools, but they increase performance to a degree).

• You can accidentally link other external libraries to your program without even knowing it.

• You can inadvertently cause the end of the world by doing this.

Answer 5

I assume that the headers may be considered “sincere,” that is, they are definitely not written to sabotage your code.

• This usually slows down compilation (precompiled headers will reduce this point)

• it implies dependencies in which nobody exists (these are semantic errors, not the actual error)

• macros will pollute your code (softened by macro prefixes with names similar to names, as in BOOST_FOREACH instead of FOREACH)

• the title may mean a link to another library. In some cases, an unused header may ask the linker to link your code to an external library (see MSCV # pragma comment (lib, "") ). I believe that a good linker will not save the link to the library if it is not used (IIRC link, MSVC will not contain a link to an unused library).

• remote header is another source of unexpected errors. if you do not trust the header (some encoders are better than others ...), and then deleting removes the risk ( you will not like the inclusion of a header that changes the alignment of the structure after it: generated errors ... lighting ... ).

• declaring a static header variable will pollute your code. Each declaration of a static variable will result in the declaration of a global variable in your compiled source.

• C character names will pollute your code. The headline declarations will pollute your global or structural namespace (and most likely both, since structures are typically typed to bring them into the global namespace). This is mitigated by libraries prefixing their characters with some kind of "namespace name", for example SDL_CreateMutex for SDL.

• names that do not contain names C ++ characters will pollute your code. For the same reasons above. The same goes for headers that use the using namespace statement incorrectly. Now the correct C ++ code will contain spaces in characters. Yes, this means that you usually should not trust the C ++ header declaring its characters in the global namespace ...

Answer 6

Regardless of whether the binary size is increased, it really depends on what is in them.

The main side effect is probably a negative effect on compilation speed. Again, how much influence depends on what is in them, how many and whether they include other headers.

Answer 7

Well, if you leave them there to extend the compilation time and add unnecessary compilation dependencies.

Answer 8

They are a clumsy design.

If you are not sure what to include and what not to include, this shows that the developer had no idea what he was doing.

Included files should be included only when necessary. Perhaps this is not so important, because the memory and speed of a computer these days are growing not by the day, but for some reason.

If inclusion is not required, but enabled in any case, I would recommend putting a comment next to it, saying why you included it. If new developers get your code, he will be very grateful if you did it right.

Answer 9

include means you are adding a few more ads. Therefore, when you write your own global function, you need to be careful if this function is already declared in the included header.

Ex. if you write your own class auto_ptr {} without including "memory", it will work fine. but whenever you turn on the memory, the compiler gives an error because it is already declared in the memory header file

Answer 10

Yes, they can increase binary size due to external unused variables.

 //---- in unused includes ---- extern int /* or a big class */ unused_var; //---- in third party library ---- int unused_var = 13;