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.
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 6 years ago.
Improve this question
I'm just curious about whether using windows.h a good thing (PS : I don't care about OSindependent code) ,it seems really good with thousands of functions . So is it good ? and where is its Dir ?
Good, bad or indifferent depends on the view.
If you are programming Windows-specific applicaitons, then you'll probably not be able to avoid using it. For generic applications that work on any platform, it's obviously bad, and if you DON'T know that you need some headerfile, don't include it. But do include things that you do need, even if it "works" without - you never know when something changes that header file that dragged in something else you didn't include in your code, and breaks the code.
"Where is it's dir", I presume means "what directory will I find it in", and I'm afraid that's not something I, or anyone else, can tell you. It depends on which compiler you are using, and how/where it was installed - and in some cases, you need to install it separately, in other cases it's included with the compiler. Since there are at least half a dozen different current compilers that work under Windows, and several that no longer are being maintained, but still "works" [to varying degrees], it would be rather pointless to even try to answer this.
Microsoft does publish an "SDK", which contains the headers, should they not be part of your installation of the compiler:
https://dev.windows.com/en-us/downloads/windows-10-sdk
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
}
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 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.
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 2 years ago.
Improve this question
which library would you advise me to use? I don't know any of these libraries.
I heard, that Boost is very often used but also it's hard to code in.
So to make this question as objective as possible:
Just simply from the aspect of beginner programmer (I've coded ~1000 LOC in C++ in my life)
which library would be better to learn?
I'll be using it mainly for HTTP client.
The answer is bound to be subjective but with particular emphasis on for a beginner then I think POCO is clearly the way to go. It actually has some HTTPClient classes and once you get beyond the point of being happy that something works the code is clear enough to follow so that you can dig in and understand why it works if that is where things lead you.
POCO is well written OOP code and does not require much in the way of understanding templates and such. The classes are well integrated with one another, extensive, and the documentation more or less points you to the next (or previous) class that you need. You won't be dashing around 20 separate libs as Boost is likely to have you doing. (There is always time for that later!)