How to add c++ experimental library to mac compiler? [closed] - c++

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 6 years ago.
Improve this question
I want to add experimental library to mac os x.
http://en.cppreference.com/w/cpp/experimental
how can i add this ?

There is no "experimental" library.
All of the C++ technical specifications that add to the standard library put their definitions into the std::experimental namespace. So std::experimental::future comes from the Concurrency TS. That TS effectively defines a few new functions in std::future, but it does so essentially by creating a new type in a new namespace with the old functions plus a few new ones. Should the TS be incorporated into the standard proper, those features will be added directly to std::future.
These technical specifications are effectively optional features that your standard library implementation may or may not support. If it does not support them, you may find libraries that provide the TS's functionality. For example, the FileSystem TS was based on Boost.Filesystem.
But there is no one thing you can download which will ensure that you will have all of the stuff in std::experimental.

Related

What can Boost do that modern C++ cannot? [closed]

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 3 years ago.
Improve this question
Considering latest modern C++, so C++17, are there any features that Boost has that are not available in modern C++?
In other words: is there anything you cannot accomplish (with a reasonable solution) with modern C++ for which you need to include Boost as a dependency in your project?
Can you please provide a list of such features, that are in Boost and NOT in modern C++17?
And what about C++11 and C++14?
Boost has a wide variety of libraries most of which haven't been incorporated into the standard library. They include but are not limited to:
Networking and other inter process communication
Linear algebra
Serialisation
Parsing
Signals & Slots
much more...
Furthermore, using Boost for features that are in
C++17 gives you some compatibility to older compilers.
Date libraries (over which there would be too much of a disagreement to be in the C++ standard - look at the mess in Java), Boost Spirit, multiprecision, and linear algebra libraries are things that are not in the C++ standard.
Plus a definition of pi (although we finally get one of those in C++20).
Because many feature in Boost eventually make themselves into the standard (std::regex, std::unique_ptr, std::thread, std::unordered_map) with minimal changes, Boost is well-worth sticking with.

Should I use the Guidelines Support Library (GSL) in a new C++ project? [closed]

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 4 years ago.
Improve this question
What are the pros and cons in favor of and against using the Guidelines Support Library (GSL) in a new C++ project? I find some constructs there very attractive but am a bit scared of including and relying on such a fundamental library.
The GSL is just a support library for the C++ core guidelines. If you are using the GSL, then these core guidelines should be the guidelines you apply to your code (not Google's or any other found online). You don't need the GSL for the core guidelines nor do you need to use everything in the GSL. Personnally I have started using it for simple bits like index and not_null.
The GSL is not perfect, there are many things that could/should be added, it doesn't impede me for doing crazy things, but it helps adding a framework/some kind of verification to what I'm doing. Also it removes the signed/unsigned issues with index.
I would advise to use it in a new project, as its run-time overhead should be null, but it's a matter of taste. If your project has lots of new developers (or toddlers), then it's something considering to help them growing up.

Why is Boost.ProgramOptions not header-only? [closed]

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.

Is C++ STL a C++ API? [closed]

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
We have an assignment wherein we have been forbidden to use any C++ API. So, this brings me to the following questions:
What exactly is the difference between a library and an API?
Is the C++ STL (http://www.sgi.com/tech/stl/table_of_contents.html) considered a C++ API?
Next time onwards, how do I identify whether I am using a library or an API?
Thanks!
P.S: I understand my instructor can let me know whether we can use STL, but I wanted to know the difference between the libraries and the APIs irrespective of his answer; hence the question.
API (Application programming interface) is the interface of a library. To use a library, you call functions in its API. So you are not allowed to use any library.
Difference of library and API:
An API is the interface. You include a header file that belongs to library, and it has declarations of functions. Those declarations, that header file, they are the API.
A library consists of both API, and the actual implementation of those functions.

Why do almost all of the C++ standard libraries not portable (including those of clang, gcc, and vc++)? [closed]

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 failed to compile gcc's C++ standard library with VC++, and vice versa.
Why do almost all of the C++ standard libraries not portable (including those of clang, gcc, and vc++)?
I also tried STLport, however, it is too old to support C++11.
I'm writing my own mini-STL for embedded systems, where I cannot use the compiler-provided STL because of its non-portability. So, I must care this.
Is there an implementation of the portable C++ standard library?
Part of the standard library's job is to provide portable wrappers around platform-dependent and compiler-dependent functionality. It cannot be fully portable.
There's also no reason why it should be portable. There's no need for it. It is supplied as part of the compiler toolchain. When you have a compiler, you also have a standard library implementation that works with that compiler. No matter which compiler you're using, you already have an implementation of the standard library.