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 7 years ago.
Improve this question
I asked a question about global variables and one of the answers raised another question which is what is the risk of very large cpp file?
Is the concern here is the maintainability of the program or something else?
My original question
Only maintainability. There is no compilation issues, as it is common for compilers to combine all #include files into a translation unit and then compile that. Thus each .cpp file winds up being many times larger than the input anyway, before moving on to later stages of compilation.
For a single programmer working on his own program, when size become an issue is a personal choice. For a team of programmers at some company, having some reasonable number of C++ files for an application allows each team member to work on a separate file in parallel. Although there are tool sets that can merge separate edits made to the same source file(s), dealing with potential conflicts (someone has to check and/or fix the conflicts), is an issue.
Related
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 4 years ago.
Improve this question
I am new to C++ and I have a general question. In order to solve any question in the exercises of the book I am learning from, while I am able to successfully solve the questions, I usually end up creating a lot of new variables within functions in addition to the ones that I have already initialised. For some reason, this worries me because I feel that I am writing inefficient code that might hog resources if I follow this practice for more complex programmes. Am I wrong in thinking this way? Are there any best practices regarding initialising and declaring new variables?
EDIT: I forgot to add, before resolving any question, I tend to convert the solution into plain English and then attempt to draw the program structure.
Normally compilers do liveness analysis of variables during the compilation of your code. Variables are considered live only starting from their assignment till their last use - optimizing compilers are capable of reducing the amount of local storage on the stack that is required by sequentially used variables (sometimes they even can eliminate their use entirely or keep them in registers only for a short period of time).
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 5 years ago.
Improve this question
Some boost libraries are header-only, some are not, and for various reasons etc.
Is there a specific reason/design decision why Boost.ProgramOptions is not header-only?
I'm wondering because it claims to be a "small" library in its the documentation and I don't see any system-related reason (like threads or asio).
Program Options claims to be small, but it turns out to be the second largest library we were building, after Regex. (It is bigger than boost Filesystem and Thread libraries.) I believe that you should be glad they're building a library for it instead of choking your project with a ton of included headers. Perhaps the author thought it would be small when he started and forgot to change the comment when it continued to grow and add features.
Not all C++ code can be written in just headers due to one-definition-rule violations.
For example, the storage reservation for a static member of a class needs to be in exactly one translation unit (although future C++ standards may obviate that).
The original intention was for Boost to be header only, but they had to quickly relinquish that aspiration.
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/
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 have been programming for 2 years now and always have faced difficulty when dealing with the compilation process.
I did not study Computer Science during my Engineering, but necessity drove me towards learning C++.
I tried understanding the compilation process from some blogs, but they were always in a language I could not understand.
So I searched this site for a similar question, but could find none.
So I would like to know how the text from a .cpp is converted to a binary executable?
Basically, the preprocessor runs first resolving all your #includes, #defines, etc with simple text substitution. Then the compiler creates a compilation-unit for each .cpp file which pretty much boils everything down to machine-code except for "connections" or linkages between shared data and functions. There may be many levels of optimisation for speed and/or space performed. This is repeated for all your .cpp files. Finally, a link phase ties all these compilation-units and the libraries they use together into an executable.
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 8 years ago.
Improve this question
I have the following problem:
I have a configuration file that consists a description of fields , which I read it and then parse it. I want to move it into the code to compile it inside.
How would you do that as bug structure ??? or else ?
Thanks
I wouldn't move it into the code, I'd leave the configuration file as a configuration file.
If you really must do this, you can just embed the file as a string resource into the application and use that - that way you'd change only a minimal amount of existing code. The way you do this depends upon your platform.
If thats not feasible (for whatever reason) I'd set up a single configuration class / namespace to contain all the values.
It's not very clear what are you exactly asking.
If you are looking for on-the-fly code execution (like eval() function in some languages), then there is no such thing in C++. It's not an interpreted language which can be read and executed line-by-line, it needs to be compiled every time code changes. While it technically is possible to write self-changing code, it's probably not worth the effort.