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
I am new to c++ and am writing a procedural program to get the hang of that side of it. I will have a collections of functions that call each other and some include statements, namespace statements, and constant declarations.
My questions are:
What are some guidelines for the file structure of the program ? Should I break this apart with some functions in another file(s) if so are their some standards for what categories of functions deserve their own file?
I hope this question is specific enough. I am NOT looking for the "best" way to do this, just some general guidelines people use.
Thanks so much.
Basically, you should group your procedures in some kind of logic and put them together in one file. Then it's a lot easier to read code and it's much more elegant than having only a few extensive files. A good practice is also to make declarations of functions at the top of the file and their definitions at the bottom.
//declarations
void myfun(int a);
/...
//definitions
void myfun(int a)
{
//do sth
}
Related
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 3 years ago.
Improve this question
I've been doing this with my code for quite a while and I wanted the opinions of the experts on if this is a good idea or not.
#include <iostream>
#define OutPut std::cout <<
int main()
{
OutPut "This sentence should appear in console.";
return 0;
};
Is this macro safe to use in terms of shorting things like cout, cin, and the like? Could it potentially cause more harm than good down the line?
No it is not a good idea. A C++ programmer expects to read C++ and not some kind of made up language that someone decided to concoct.
Using the Preprocessor with C++ is almost always a poor idea as there are almost always better alternatives.
See Why are preprocessor macros evil and what are the alternatives?
See https://softwareengineering.stackexchange.com/questions/249767/is-it-a-good-idea-to-define-me-this
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.
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
this might be a strange question, but I don't quite understand this. When I look at let's say string.h, I really have no idea what I'm even looking at... Maybe I'm just inexperienced or something, but those files look nothing like a header file I've ever written.
I could write my own string implementation and it would be so much shorter and more readable than this file I'm looking at here...
So basically I'm just wondering what's going on here that makes it necessary to write all this long and complex code.
Edit: oke thanks for the responses, I get the point. It's kind of what I expected, but it's nice to get some confirmation:p
Driving a car is (arguably) extremely easy, compared to how complicated an engine looks on the inside.
Libraries such as these are meant to be easy to use, but what's behind the scenes might not always be easy to understand. You're better off using the actual documentation for such libraries.
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 9 years ago.
Improve this question
It's a simple question. I'm documenting my code following the documentation of the Doxygen, but I have a question: Where I need to document? On the header, on the source or both of them? I know that this is not a rule, but I want to know your opinion about this and what you do on your code and why you do that. For example: I'm documenting the header, and it's nice, the appearance of the code increased, but when I look the source (.cpp) file, I got scared, because there's no documentation and the code is not beautiful, I mean, not the logic, but in beauty (indentation). And everybody knows that even though the code not beautiful (which is difficult in C++) with a documentation it get coolest and easier to read.
Thank you all. (And remember, before you start writing a moral lesson, know that I know that it's not a rule, I'm just wondering what you do)
Personally I prefer documenting the h file with that sort of thing. People who need to use your APIs might need your header, but not your cpp. People will never need your cpp without the header. Keep the documentation in one place where everyone who needs it gets it.
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
I understand that, in C++, we should never use:
using namespace std;
The two possible alternatives are:
1) adding using std::cout; at the beginning of the file and just type cout whenever required
2) type std::cout every time we need to use cout
My understanding is that the second method is the best. However, is this always followed in professional environments? Is it practical to follow in highly fast paced environments? I am used to the first alternative. Is it an advantage to switch?
Note: I originally posted this in Code Review and I was told that this topic belonged here. Kindly let me know if not.
So I have done a little bit with C++, but I would say the problem falls under the problem of namespaces in all languages. The real problem is that if you have multiple namespaces with the same function, it makes it much more difficult to read whats going on and can cause undesired results.
For example if you have two functions with the same name in two name spaces, how will the code know which one to use? Also another problem comes when you have multiple namespaces added and call a function. How does someone reading the code know which namespace the code is coming from? Having the namespace in front of the function helps make your code more readable.