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
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 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 7 years ago.
Improve this question
Hello I'm new to coding in C++, thankfully I'm quickly learning how to use it. So far I've heard of libraries and how they can be used in an application.
My questions is are:
What do I need to do after I download ANY library?
How do I #include "library.h" or #include <library> and use it
in a project without intellisense or the compiler going nuts?
What if the library is header only?
What should I look for?
Are there any apps I need?
What if there's no build folder?
Usually the instructions are unclear to me, maybe it's because I'm still green.
Please try to explain this in an easy to follow manner like if you were teaching it to someone that knows NOTHING: I've tried to follow other guides but with no luck.
Beforehand, thank you very much!
If it's header-only, including the header is enough. Otherwise, a library can be any piece of code in any form (source in various languages, binary, shared, static, ...). It's impossible to cover all the cases, each library is supposed to come with its own documentation.
Each and every library has a specific license (eg MIT, GPL, LGPL etc) for it's use. There can be differences between uses (eg personal, academic and commercial etc) but often not. It's quite easy to learn about the major licenses and how they might apply to your use case on the internet. But if you are doing this for commercial purposes or have any doubt whatsoever consult a lawyer.
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 9 years ago.
Improve this question
I have seen recently that people use xml files as a database to store the settings. However, I don't know why exactly is it done. I am from a C/C++, Linux background. Thus, please help me to understand this concept. Any simple C/C++ example will help me to understand it's benefit better?
XML is a very common tool with tons of libraries to handle it. Although it isn't the most beautiful format in the world, it is possible to read and modify it by both hand and program. Probably one want to use it when program configuration modified by some gui or tool. If you intend manual configuration, it's probably better to choose something else, for example ini. This is why linux tools rarely use XML, BTW.
As a C++ programmer you'd probably find interesting the "boost::property_tree" library to deal with configs. Examples of usage included in the documentation. Also it provides with plenty of different backends to store configuration, so you haven't to stick to some one format.