A number of compilers provide 128-bit integer types, but none of the ones I&#39;ve used provide the typedefs `int128_t`. Why?

As far as I recall, the standard

   * Reserves `int128_t` for this purpose
   * Encourages implementations that provide such a type to provide the typedef
   * Mandates that such implementations provide an `intmax_t` of at least 128 bits

(and, I do not believe I&#39;ve used an implementation that actually conforms to that last point)

Why isn&#39;t there int128_t?

According to [cppreference](https://en.cppreference.com/w/cpp/types/type_info/operator_cmp), `std::type_info::operator!=` gets removed with C++20, however, `std::type_info::operator==` apparently remains.

What&#39;s the reasoning behind? I might agree on comparing for inequality being meaningless, but then comparing for equality would be just as meaningless as well, wouldn&#39;t it?

Similarly, `operator!=` of many other standard library types, including containers such as [`std::unordered_map::operator!=`][2] and [`std::unordered_set::operator!=`][3] will be removed in C++20 according to cppreference.

Having to write `if(!(id1 == id2))` doesn&#39;t make any code any clearer compared to `if(id1 != id2)`, in contrast, just the opposite...

[2]: https://en.cppreference.com/w/cpp/container/unordered_map/operator_cmp
[3]: https://en.cppreference.com/w/cpp/container/unordered_set/operator_cmp

Why is operator!= removed in C++20 for many standard library types?

According to [cppreference][1], the `operator!=` of many standard library types, including [`std::unordered_map::operator!=`][2] and [`std::unordered_set::operator!=`][3] is *removed* in C++20.

**What is the committee&#39;s rationale behind the decision?** Won&#39;t this make the comparison support asymmetric?


  [1]: http://en.cppreference.com/w/cpp
  [2]: https://en.cppreference.com/w/cpp/container/unordered_map/operator_cmp
  [3]: https://en.cppreference.com/w/cpp/container/unordered_set/operator_cmp

Removed operator!= in C++20 standard library

The question is pretty clear. The following gives the reason why I think these expressions might yield undefined behavior. I would like to know whether my reasoning is right or wrong and why.

**Short read**:

(IEEE 754) `double` is not *Cpp17LessThanComparable* since `&lt;` is not a strict weak ordering relation due to `NaN`. Therefore, the *Requires* elements of `std::min&lt;double&gt;` and `std::max&lt;double&gt;` are violated.

**Long read**:

All references follow [n4800](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4800.pdf). Specifications of `std::min` and `std::max` are given in 24.7.8:
&gt; `template&lt;class T&gt; constexpr const T&amp; min(const T&amp; a, const T&amp; b);`  
`template&lt;class T&gt; constexpr const T&amp; max(const T&amp; a, const T&amp; b);`  
Requires: [...] type T shall be *Cpp17LessThanComparable* (Table 24).

Table 24 defines *Cpp17LessThanComparable* and says:
&gt; Requirement: `&lt;` is a strict weak ordering relation (24.7)

Section 24.7/4 defines *strict weak ordering*. In particular, for `&lt;` it states that &quot;if we define `equiv(a, b)` as `!(a &lt; b) &amp;&amp; !(b &lt; a)` then `equiv(a, b) &amp;&amp; equiv(b, c)` implies `equiv(a, c)`&quot;.

Now, according to IEEE 754 `equiv(0.0, NaN) == true`, `equiv(NaN, 1.0) == true` but `equiv(0.0, 1.0) == false` we conclude that `&lt;` is **not** a strict weak ordering. Therefore, (IEEE 754) `double` is **not** *Cpp17LessThanComparable* which is a violation of the *Requires* clause of `std::min` and `std::max`.

Finally, 15.5.4.11/1 says:
&gt; Violation of any preconditions specified in a function’s *Requires:* element results in undefined behavior [...].

**Update 1:**

The point of the question is not to argue that `std::min(0.0, 1.0)` is undefined and anything can happen when a program evaluates this expression. It returns `0.0`. Period. (I&#39;ve never doubted it.)

The point is to show a (possible) defect of the Standard. In a laudable  quest for precision, the Standard often uses mathematical terminology and weak strict ordering is only one example. In these occasions, mathematical precision and reasoning must go all the way.

Look, for instance, Wikipedia&#39;s definition of [strict weak ordering](https://en.wikipedia.org/wiki/Weak_ordering#Strict_weak_orderings). It contains four bullet points and every single one of them starts with &quot;For every x [...] in S...&quot;. None of them say &quot;For some values x in S that make sense for the algorithm&quot; (What algorithm?). In addition, the specification of `std::min` is clear in saying that &quot;`T` shall be *Cpp17LessThanComparable*&quot; which entails that `&lt;` is a strict weak ordering on `T`. Therefore, `T` plays the role of the set S in Wikipedia&#39;s page and the four bullet points must hold when values of `T` are considered in its entirety.

Obviously, NaNs are quite different beasts from other double values but they are *still* possible values. I do not see anything in the Standard (which is quite big, 1719 pages, and hence this question and the language-lawyer tag) that **mathematically** leads to the conclusion that `std::min` is fine with doubles provided that NaNs are not involved.

Actually, one can argue that NaNs are fine and other doubles are the issue! Indeed, recall that there&#39;s are several possible NaN double values (2^52 - 1 of them, each one carrying a different payload). Consider the set S containing all these values and one &quot;normal&quot; double, say, 42.0. In symbols, S = { 42.0, NaN_1, ..., NaN_n }. It turns out that `&lt;` is a strict weak ordering on S (the proof is left for the reader). Was this set of values that the C++ Committee had in mind when specifying `std::min` as in &quot;please, do not use any other value otherwise the strict weak ordering is broken and the behavior of `std::min` is undefined&quot;? I bet it wasn&#39;t but I would prefer to read this in the Standard than speculating what &quot;some values&quot; mean.

**Update 2:**

Contrast the declaration of `std::min` (above) with that of `clamp` 24.7.9:

&gt; `template&lt;class T&gt; 
constexpr const T&amp; clamp(const T&amp; v, const T&amp; lo, const T&amp; hi);`  
Requires: The value of `lo` shall be no greater than `hi`. For the first form, type
T shall be *Cpp17LessThanComparable* (Table 24).
[...]  
[Note : If `NaN` is avoided, T can be a floating-point type. — end note]

Here we clearly see something that says &quot;`std::clamp` is fine with doubles provided that NaNs are not involved.&quot; I was looking for the same type of sentence for `std::min`.

It&#39;s worth taking notice of the paragraph [structure.requirements]/8 that Barry has mentioned in his [post](https://stackoverflow.com/a/55211539/1137388). Apparently, this was added post-C++17 coming from [P0898R0](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0898r0.pdf)):
&gt; Required operations of any concept defined in this document need not be total functions; that is, some arguments to a required operation may result in the required semantics failing to be satisfied. [Example: The required `&lt;` operator of the *StrictTotallyOrdered* concept (17.5.4) does not meet the semantic requirements of that concept when operating on NaNs. — end example
] This does not affect whether a type satisfies the concept.

Which is a clear attempt to address the issue I&#39;m raising here but in the context of concepts (and as pointed out by Barry, *Cpp17LessThanComparable* is not a concept). In addition, IMHO this paragraph also lacks precision.


Do std::min(0.0, 1.0) and std::max(0.0, 1.0) yield undefined behavior?

Is it possible to forward declare an standard container in a header file?  For example, take the following code:

    #include &lt;vector&gt;
    
    class Foo
    {
    private:
        std::vector&lt;int&gt; container_;
        ...
    };

I want to be able to do something like this:

    namespace std
    {
        template &lt;typename T&gt; class vector;
    }
    
    class Foo
    {
    private:
        std::vector&lt;int&gt; container_;
        ...
    };

Can this be done?

Forward declare a standard container?

I want to convert a `std::string` to lowercase. I am aware of the function `tolower()`. However, in the past I have had issues with this function and it is hardly ideal anyway as using it with a `std::string` would require iterating over each character.

Is there an alternative which works 100% of the time?


How to convert an instance of std::string to lower case

I need to go through a set and remove elements that meet a predefined criteria.

This is the test code I wrote:

    #include &lt;set&gt;
    #include &lt;algorithm&gt;

    void printElement(int value) {
        std::cout &lt;&lt; value &lt;&lt; &quot; &quot;;
    }

    int main() {
        int initNum[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
        std::set&lt;int&gt; numbers(initNum, initNum + 10);
        // print &#39;0 1 2 3 4 5 6 7 8 9&#39;
        std::for_each(numbers.begin(), numbers.end(), printElement);

        std::set&lt;int&gt;::iterator it = numbers.begin();

        // iterate through the set and erase all even numbers
        for (; it != numbers.end(); ++it) {
            int n = *it;
            if (n % 2 == 0) {
                // wouldn&#39;t invalidate the iterator?
                numbers.erase(it);
            }
        }

        // print &#39;1 3 5 7 9&#39;
        std::for_each(numbers.begin(), numbers.end(), printElement);

        return 0;
    }

At first, I thought that erasing an element from the set while iterating through it would invalidate the iterator, and the increment at the for loop would have undefined behavior. Even though, I executed this test code and all went well, and I can&#39;t explain why.

**My question:**
Is this the defined behavior for std sets or is this implementation specific? I am using gcc 4.3.3 on ubuntu 10.04 (32-bit version), by the way.

Thanks!

**Proposed solution:**

Is this a correct way to iterate and erase elements from the set?

    while(it != numbers.end()) {
        int n = *it;
        if (n % 2 == 0) {
            // post-increment operator returns a copy, then increment
            numbers.erase(it++);
        } else {
            // pre-increment operator increments, then return
            ++it;
        }
    }

**Edit: PREFERED SOLUTION**

I came around a solution that seems more elegant to me, even though it does exactly the same.

    while(it != numbers.end()) {
        // copy the current iterator then increment it
        std::set&lt;int&gt;::iterator current = it++;
        int n = *current;
        if (n % 2 == 0) {
            // don&#39;t invalidate iterator it, because it is already
            // pointing to the next element
            numbers.erase(current);
        }
    }

If there are several test conditions inside the while, each one of them must increment the iterator. I like this code better because the iterator is incremented **only in one place**, making the code less error-prone and more readable.

Deleting elements from std::set while iterating

I like vectors a lot. They&#39;re nifty and fast. But I know this thing called a valarray exists. Why would I use a valarray instead of a vector? I know valarrays have some syntactic sugar, but other than that, when are they useful?

C++ valarray vs. vector

Are there guidelines on how one should write new container which will behave like any `STL` container?

Writing your own STL Container

What are the iterator invalidation rules for C++ containers?

&lt;sub&gt;
(&lt;strong&gt;Note:&lt;/strong&gt; This Q&amp;A is an entry in &lt;a href=&quot;https://stackoverflow.com/questions/tagged/c++-faq&quot;&gt;Stack Overflow&#39;s C++ FAQ&lt;/a&gt;. Meta-discussion about the question itself should be posted on &lt;a href=&quot;https://meta.stackexchange.com/questions/68647/setting-up-a-faq-for-the-c-tag&quot;&gt;the Meta question that started all of this&lt;/a&gt;, not here.)
&lt;/sub&gt;

Iterator invalidation rules for C++ containers

[This answer](https://stackoverflow.com/a/10319672/1805388) gives a nice high-level overview of short string optimization (SSO). However, I would like to know in more detail how it works in practice, specifically in the libc++ implementation:

 - How short does the string have to be in order to qualify for SSO?
   Does this depend on the target architecture?
   
 - How does the implementation distinguish between short and long
   strings when accessing the string data? Is it as simple as `m_size &lt;= 16` or is it a flag that is part of some other member variable? (I
   imagine that `m_size` or part of it might also be used to store
   string data).

I asked this question specifically for libc++ because I know that it uses SSO, this is even mentioned on the [libc++ home page](http://libcxx.llvm.org/).

Here are some observations after looking at [the source](http://llvm.org/svn/llvm-project/libcxx/trunk/include/string):

libc++ can be compiled with two slightly different memory layouts for the string class, this is governed by the `_LIBCPP_ALTERNATE_STRING_LAYOUT` flag. Both of the layouts also distinguish between little-endian and big-endian machines which leaves us with a total of 4 different variants. I will assume the &quot;normal&quot; layout and little-endian in what follows.


Assuming further that `size_type` is 4 bytes and that `value_type` is 1 byte, this is what the first 4 bytes of a string would look like in memory:

    // short string: (s)ize and 3 bytes of char (d)ata
    sssssss0;dddddddd;dddddddd;dddddddd
           ^- is_long = 0

    // long string: (c)apacity
    ccccccc1;cccccccc;cccccccc;cccccccc
           ^- is_long = 1

Since the size of the short string is in the upper 7 bits, it needs to be shifted when accessing it:

    size_type __get_short_size() const {
        return __r_.first().__s.__size_ &gt;&gt; 1;
    }

Similarly, the getter and setter for the capacity of a long string uses `__long_mask` to work around the `is_long` bit.

I am still looking for an answer to my first question, i.e. what value would `__min_cap`, the capacity of short strings, take for different architectures?

**Other standard library implementations**

[This answer](https://stackoverflow.com/a/28003328/1805388) gives a nice overview of `std::string` memory layouts in other standard library implementations.

What are the mechanics of short string optimization in libc++?

What does the phrase `std::string::npos` mean in the following snippet of code?

    found = str.find(str2);

    if (found != std::string::npos)
        std::cout &lt;&lt; &quot;first &#39;needle&#39; found at: &quot; &lt;&lt; int(found) &lt;&lt; std::endl;


What does string::npos mean in this code?

I have to format [`std::string`](http://en.cppreference.com/w/cpp/string/basic_string) with [`sprintf`](http://en.cppreference.com/w/cpp/io/c/fprintf) and send it into file stream. How can I do this?

std::string formatting like sprintf

Are there pitfalls for specific operating systems, I should know of?

There are many duplicates ([1][1], [2][2], [3][3], [4][4], [5][5]) of this question but they were answered decades ago. The very high voted answers in many of these questions are wrong today.   

Methods from other (old QA&#39;s) on .sx
------------------------------
 * [stat.h][6] (wrapper [sprintstatf][7]), uses syscall

 * [tellg()][8], returns per definition a **position** but **not necessarily bytes**. The return type is not `int`. 



  [1]: https://stackoverflow.com/questions/5840148/how-can-i-get-a-files-size-in-c
  [2]: https://stackoverflow.com/questions/22984956/tellg-function-give-wrong-size-of-file
  [3]: https://stackoverflow.com/questions/2641639/fstreams-tellg-seekg-returning-higher-value-than-expected
  [4]: https://stackoverflow.com/questions/54237341/how-can-i-determine-the-current-size-of-the-file-opened-by-stdofstream
  [5]: https://stackoverflow.com/questions/32057750/how-to-get-the-filesize-for-large-files-in-c
  [6]: http://pubs.opengroup.org/onlinepubs/009695399/functions/stat.html
  [7]: https://github.com/hpc/sprintstatf
  [8]: https://en.cppreference.com/w/cpp/io/basic_istream/tellg

How to get the file size in bytes with C++17

Someone brought [this article][1] to my attention that claims *(I&#39;m paraphrasing)* the STL term is misused to refer to the entire C++ Standard Library instead of the parts that were taken from SGI STL.

&gt; (...) it refers to the &quot;STL&quot;, despite the fact that very few people still use the STL (which was designed at SGI).
&gt;
&gt; Parts of the C++ Standard Library were based on parts of the STL, and it is these parts that many people (including several authors and the notoriously error-ridden cplusplus.com) still refer to as &quot;the STL&quot;. However, this is inaccurate; indeed, the C++ standard never mentions &quot;STL&quot;, and there are content differences between the two.
&gt;
&gt; (...) &quot;STL&quot; is rarely used to refer to the bits of the stdlib that happen to be based on the SGI STL. People think it&#39;s the entire standard library. It gets put on CVs. And it is misleading.

I hardly know anything about C++&#39;s history so I can&#39;t judge the article&#39;s correctness. Should I refrain from using the term STL? Or is this an isolated opinion?


  [1]: http://kera.name/articles/2010/08/it-is-not-called-the-stl-mmkay/

What&#39;s the difference between &quot;STL&quot; and &quot;C++ Standard Library&quot;?

A use case emerged when wanting to do a contitional copy (1. doable with `copy_if`) but from a container of values to a container of pointers to those values (2. doable with `transform`). 

With the available tools I can&#39;t [do it](http://ideone.com/p5zLzr) in less than two steps : 

    #include &lt;vector&gt;
    #include &lt;algorithm&gt;
    
    using namespace std;
    
    struct ha { 
        int i;
    	explicit ha(int a) : i(a) {}
    };
    
    int main() 
    {
    	vector&lt;ha&gt; v{ ha{1}, ha{7}, ha{1} }; // initial vector
    	// GOAL : make a vector of pointers to elements with i &lt; 2
    	vector&lt;ha*&gt; ph; // target vector
    	vector&lt;ha*&gt; pv; // temporary vector
    	// 1. 
    	transform(v.begin(), v.end(), back_inserter(pv), 
    		[](ha &amp;arg) { return &amp;arg; }); 
    	// 2. 
    	copy_if(pv.begin(), pv.end(), back_inserter(ph),
    		[](ha *parg) { return parg-&gt;i &lt; 2;  }); // 2. 
    	
    	return 0;
    }

Ofcourse we could call `remove_if` on `pv` and eliminate the need for a temporary, better yet though, it&#39;s not difficult to [implement](http://ideone.com/v77m3d) (for unary operations) something like this : 

    template &lt;
    	class InputIterator, class OutputIterator, 
    	class UnaryOperator, class Pred
    &gt;
    OutputIterator transform_if(InputIterator first1, InputIterator last1,
                                OutputIterator result, UnaryOperator op, Pred pred)
    {
    	while (first1 != last1) 
    	{
    		if (pred(*first1)) {
    			*result = op(*first1);
    			++result;
    		}
    		++first1;
    	}
    	return result;
    }

    // example call 
    transform_if(v.begin(), v.end(), back_inserter(ph), 
	[](ha &amp;arg) { return &amp;arg;      }, // 1. 
	[](ha &amp;arg) { return arg.i &lt; 2; });// 2.

1. **Is there a more elegant workaround with the available C++ standard library tools ?**
2. **Is there a reason why `transform_if` does not exist in the library? Is the combination of the existing tools a sufficient workaround and/or considered performance wise well behaved ?**

Why is there no transform_if in the C++ standard library?

Section 23.3.7 Class `vector&lt;bool&gt;` [vector.bool], paragraph 1 states:

    template &lt;class Allocator&gt; class vector&lt;bool, Allocator&gt; {
    public:
        // types:
        typedef bool              const_reference;
        ...

However this program fails to compile when using libc++:

    #include &lt;vector&gt;
    #include &lt;type_traits&gt;

    int
    main()
    {
        static_assert(std::is_same&lt;std::vector&lt;bool&gt;::const_reference, bool&gt;{}, &quot;?&quot;);
    }

Furthermore I note that the C++ standard has been consistent in this specification all the way back to C++98.  And I further note that libc++ has consistently not followed this specification since the first introduction of libc++.

What is the motivation for this non-conformance?

Why is libc++&#39;s vector&lt;bool&gt;::const_reference not bool?

I need to iterate over `std::queue`.
www.cplusplus.com says:

&gt; By default, if no container class is specified for a particular queue class, the standard container class template deque is used.

So can I somehow get to the queue&#39;s underlying deque and iterate over it?

std::queue iteration

I have a project that currently uses C++11/14, but it requires something like `std::filesystem`, which is only available in C++17, and hence I don&#39;t have a chance to currently use it. I see, however, that it&#39;s available in my current compiler as `std::experimental::filesystem`. Is it a good idea to use experimental features, assuming that I could in the future add something like:

    #ifdef CXX17 //if this is C++17
    std::filesystem::something ...;
    #else
    std::experimental::filesystem::something ...;
    #endif

My concerns are:

**1. Is it guaranteed that all compliant compilers have the same experimental features?**

**2. Are experimental features prone to big changes that make them unreliable?**

Maybe there&#39;s more things to wonder about. Why should I or should I not use them? I&#39;m puzzled with a new project and don&#39;t know what to decide.


Are the experimental features of modern C++ reliable for long-term projects?

What&#39;s the difference between `ios::ate` and `ios:app` when writing to a file.  
In my view, `ios::app` gives you the ability to move around in the file, whereas with `ios::ate` it can only read/write at the end of the file. Is this correct?


C++ Filehandling: Difference between ios::app and ios::ate?

Does the C++ Standard Library define this function, or do I have to resort to Boost?

I searched the web and couldn&#39;t find anything except Boost, but I thought I&#39;d better ask here.


std::lexical_cast - is there such a thing?

Most C++ users that learned C prefer to use the `printf` / `scanf` family of functions even when they&#39;re coding in C++.

Although I admit that I find the interface way better (especially POSIX-like format and localization), it seems that an overwhelming concern is performance.

Taking at look at this question:

&gt; [How can I speed up line by line reading of a file][1]

It seems that the best answer is to use `fscanf` and that the C++ `ifstream` is consistently 2-3 times slower.

I thought it would be great if we could compile a repository of &quot;tips&quot; to improve IOStreams performance, what works, what does not.

Points to consider

 - buffering (`rdbuf()-&gt;pubsetbuf(buffer, size)`)
 - synchronization (`std::ios_base::sync_with_stdio`)
 - locale handling (Could we use a trimmed-down locale, or remove it altogether ?)

Of course, other approaches are welcome.

*Note: a &quot;new&quot; implementation, by Dietmar Kuhl, was mentioned, but I was unable to locate many details about it. Previous references seem to be dead links.*

  [1]: https://stackoverflow.com/questions/5164538/how-can-i-speed-up-line-by-line-reading-of-an-ascii-file-c/

How to get IOStream to perform better?

While looking into https://stackoverflow.com/questions/5625431 and reviewing the C++98 and C++11 standards I noticed that apparently the `std::pow(double, int)` overload was removed in C++11.

In C++98 26.5/6 it has the `double pow(double, int);` signature.

In C++11 26.8 all I could find was overloads taking a pair of `float`, `double`, or `long double`, and an explicit note that in case of a mixture of parameter types integral&amp;double, that the `pow(double, double)` overload should be picked.

Is this just a clarification of the previous intention, were they incorrectly added in C++98, were they actually removed in C++11, or something else?

Obviously the `pow(double, int)` version provides a nice opportunity for optimization so it seems odd that they would be removed. Would a compiler still be standards conforming to provide such an optimized overload?


All C++ Standard-Library Solutions on Gang of Coders

Total of 23 C++ Standard-Library Solutions

Why isn't there int128_t?