Is it good to use STL in making new softwares? [closed] - c++

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Hi I am currently working on an open source project and want to use STL in it. But I am confused that is correct to depend on STL only or it will be good to use Qt like libraries. Because I want to make it cross platform supported. Please suggest.
STL: Standard Template Library for C++

That is some confusion in this question.
STL is a part of Standard Library of C++; specifically covering containers and algorithms (and iterators, as a glue between the two).
Qt is cross-platform application framework which purpose is, first and foremost, to provide facilities for abstracting you from platform. It also covers some of functionality provided by STL (i.e. it provides its own containers: as I understand, mostly for historical reasons).
You can freely mix'n'match both libraries. AFAIK you can even use STL algorithms on Qt containers (meaning that Qt containers are STL compliant).
So, answering your question, it is of course good to use STL for new software: provided it is properly supported by your compiler, and you know how to use it.

Related

When will ranges be included in the c++ standard? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I could find two proposals to include ranges in C++:
N1871 is fairly old (2005), and N3513
However I could not find anything about ranges in the current C++14 draft (N3690). Does this mean that it will not be part of C++14? If that is the case, why is it so cumbersome to introduce ranges?
Does this mean that it will not be part of C++14?
Yes, indeed it will not be part of C++14. Unfortunately, nobody cared enough to work on a proposal.
If that is the case, why is it so cumbersome to introduce ranges?
Hard to tell. Sometimes the reason is that different people have different expectations on what should be standardized and how (see modules or concepts), and sometimes it is just because the feature is more complex to formalize than urgent.
Also, what most often happens is that Boost libraries are taken as an experimental, proto-standard implementation; and while there was enough experience and common consensus on libraries such as Boost.Thread, Boost.Function, and Boost.Bind - so they got standardized quite smoothly - not everybody is satisfied with Boost.Range, mostly because of its lack of an extensive, high-level support for functional programming.

Can Boost be used as a full replacement of the C++ Standard library? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Say I have minimal headers like <new>, <initializer_list>, and maybe some other stuff, is it possible to use Boost to function as a std C++ library, or is there a lot of code missing?
I'm assuming a C standard library, which might have sucky versions of things like printf (think Windows), will Boost provide better implementations in <boost/cstddef> (or something)?
No. Boost is not designed to replace the C++ standard library; it is designed to complement and extend the C++ standard library. Also, Boost depends heavily on the C++ standard library.
Well, no. For example, Boost doesn't define a stream encapsulating standard out. Sure, you can use STDOUT itself with some lower-level functions, but by that logic you can do pretty much everything without using the standard library at all.
I would recommend using Boost or any other truly cross platform libraries for anything that is even remotely likely to be platform dependent. Networking / locking etc.
For everything else, I would stick to the standard libraries - they're well documented, they're often optimized for the OS and with the exception of a few ifdefs you may need to endure here and there, they'll compile and run fine on most platforms.

Is there any Linux alternative for Windows Path API? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In Windows API there are a big set of methods for manipulating of paths and URLs at Shell Path Handling Functions. The functions include helpers like PathAddBackslash, PathCanonicalize, PathCombine, and PathIsDirectory.
The question is: are there any Posix provided functionality or Linux-based library that gives analogous functionality? That is, simplifies paths combination, canonicalization, parsing, as well as URLs parsing?
I know that it is possible to write such functions with C++ (not small but not complex job), but my question is: are there any ready "official" libraries on Linux that already have similar functionality?
I am quite happy with boost_filesystem. Best part of it is that it is cross-platform, so it also works on Windows.
Another possibility is leveraging the capabilities of Qt or GLIB (GTK+).
Finally, most path-mangling operations are already in the POSIX standard and available out-of-the-box. For an example see the manpage of basename(3), dirname(3):
http://www.kernel.org/doc/man-pages/online/pages/man3/dirname.3.html
You could also use POCO C++ libraries, take a look here:
http://pocoproject.org/features.html
And here you could find more on filesystem api:
http://pocoproject.org/slides/080-Files.pdf

Should one use built in classes? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've started programming C++ and I want to start programming useful stuff.
I know that for strings, one can use std::string or char-arrays. One can also use std::vectors as well, instead of arrays.
What should one do? Reinvent the wheel, or use the built in utilities?
The point of the question is to find out what people actually do. Do people use the STL a lot or do people use char[] instead of std::string?
Reinventing the wheel can be good as a training assignment, but If you want to write useful stuff - of course use the standard library ("the built in utilities").
The standard library (as well as boost, and other libraries) is validated and optimized, and it will let you write the useful stuff much easier, so you can focus on your logic instead of reinventing the wheel.
Always use standard libraries (STLs, Boost, etc) unless there is a reason for doing otherwise (e.g STL not available on platform). These libraries are time tested for both correctness and performance
If your goal is to program useful and stable software, use the standard libraries.
If your goal is to explore a specific topic, such as strings, then reinvent the string class and learn from your mistakes.
Usse the built in utilities. They are optimized and will ensure that your code is fully portable!
Note that you should use them skillfully: vectors can be rendered WAY faster if you reserve space before using them, etc.

Dependency Injection framework for C++ [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is there a DI framework comparable to Google Guice? And what does Google use?
There is nothing as mature or standard as Guice in the C++ world. However, some people have put together simplistic implementations on their own. Here's a couple.
http://adam.younglogic.com/2008/07/dependency-injection-in-c/ (source for implementation is at the end of the post)
http://sourceforge.net/projects/qtioccontainer/ (requires Qt)
http://code.google.com/p/autumnframework/ (hasn't been touched since 2007)
http://programmaticallyspeaking.blogspot.com/2010/04/beautiful-dependency-injection-in-c.html (more of a description, really)
http://sourceforge.net/projects/cpp-resolver/ ("Alpha" quality)
You're unlikely to be satisfied by any of these.
If you really wanted to put in the effort to rally the world around a DI framework for C++, probably the way to go about it would be to make a proposal to the Boost guys.
I'm the author of wallaroo. It's actively developed and has the following features:
it's lightweight but powerful
its interface supports both C++11 and C++98 with boost
it's type safe
it doesn't need custom preprocessors / code generators
you can load classes defined in shared libraries
you can use a DSL syntax for object creation and wiring or
you can get object creation and wiring by parsing one or more xml / json file.
Any comment, suggestion or request are welcome.
There is a recent one that looks very interesting called Hypodermic, i haven't tested it but it looks pretty active
I am currently authoring one called sauce, whose design (and name) is directly inspired by guice. I still consider it alpha, but you may find it useful.