If your C++ implementation uses IEEE754 then yes, this is guaranteed. (The division operator is required to return the best possible floating point value). 

The *only* exceptions for `y / y`, in general, not being `1.f` are the cases when `y` is `NaN`, `+Inf`, `-Inf`, `0.f`, and `-0.f`, or if you are on a platform where  `int` is so wide that certain instances of it cannot be represented in a `float` without that `float` being set to `+Inf` or `-Inf`&lt;sup&gt;1&lt;/sup&gt;. Setting aside that final point, in your case that means that `int x = 0;` will produce the only exception.

IEEE754 is extremely common. But to check for sure, test the value of

    std::numeric_limits&lt;float&gt;::is_iec559;

&lt;hr&gt;

&lt;sup&gt;1&lt;/sup&gt;A platform, for example, with a 128 bit `int` and an IEEE754 32 bit `float` would exhibit this behaviour for certain values of `x`.

No, not in all cases, even for IEEE754.

For example, with `int x = 0;`, you&#39;ll get NaN. ([Live][1])


  [1]: https://wandbox.org/permlink/O8j5aSzbTLyFOBYA

Always when I use lambda expressions like this:

    .map(obj -&gt; foo.makeSomething(obj))

IntelliJ suggests: &quot;Can be replaced with method reference...&quot;. And when I try then:

    .map(Foo::makeSomething)

I get the following statement: &quot;Non-static method cannot be referenced from a static context&quot;. 

Why Idea suggests me I should use method reference if it&#39;s not correct?

Intellij - can be replaced with method reference

I get what the new f strings in python 3.6 do, but what about the ending !r as found in the code snip below. 

    def __repr__(self):
        return (f&#39;Pizza({self.radius!r}, &#39;f&#39;{self.ingredients!r})&#39;)

In Python format (f-string) strings, what does !r mean?

If I write:

    int x = /* any non-zero integer value */;
    float y = x;
    float z = y / y;

Is `z` guaranteed to be exactly 1.f ?



Is a whole number float divided by itself guaranteed to be 1.f?

If I write:
<pre><code class="hljs language-ini">int x = /* any non-zero integer value */;
float y = x;
float z = y / y;
</code></pre>
Is <code>z</code> guaranteed to be exactly 1.f ?

I have started learning C++ for my programming class. I have downloaded this &quot;Hello World&quot; program:

    #include &lt;iostream&gt;
    using namespace std;
    
    int main() 
    {
        cout &lt;&lt; &quot;Hello, World!&quot;;
        return 0;
    }

but Turbo C++ complains:

    Error D:\HELLO.CPP 1: Unable to open include file &#39;IOSTREAM&#39;
    Error D:\HELLO.CPP 2: Declaration syntax error
    Error D:\HELLO.CPP 6: Undefined symbol &#39;cout&#39;

What&#39;s wrong with this very simple program? How can I correct these errors?

Why doesn&#39;t a simple &quot;Hello World&quot;-style program compile with Turbo C++?

I have a a set of overloads of a commutative binary function named `overlap`, which accepts two distinct types:

    class A a; class B b;
    bool overlap(A, B);
    bool overlap(B, A);

My function `overlap` returns true if and only if one shape overlaps the other - this is one common example used when discussing [multimethods][1].

Because `overlap(a, b)` is equivalent to `overlap(b, a)`, I only need to implement one &quot;side&quot; of the relation.  One repetitive solution is to write something like this:

    bool overlap(A a, B b) { /* check for overlap */ }
    bool overlap(B b, A a) { return overlap(a, b);   }

But I would prefer not to write an extra `N! / 2` trivial versions of the same function by allowing them to be generated instead, using a template.

    template &lt;typename T, typename U&gt; 
    bool overlap(T&amp;&amp; t, U&amp;&amp; u) 
    { return overlap(std::forward&lt;U&gt;(u), std::forward&lt;T&gt;(t)); }
 

Unfortuately, this is prone to recurse infinitely, which is not acceptable: see
http://coliru.stacked-crooked.com/a/20851835593bd557

How can I prevent such infinite recursion?  Am I approaching the problem correctly?

  [1]: https://en.wikipedia.org/wiki/Multiple_dispatch


Reducing code duplication while defining a commutative operation

In the following piece of code, I use the standard [`[[fallthrough]]`](http://en.cppreference.com/w/cpp/language/attributes) attribute from C++1z to document that a fallthrough is desired:

    #include &lt;iostream&gt;

    int main() {
        switch (0) {
            case 0:
                std::cout &lt;&lt; &quot;a\n&quot;;
                [[fallthrough]]
            case 1:
                std::cout &lt;&lt; &quot;b\n&quot;;
                break;
        }
    }

With GCC 7.1, the code compiles without an error. However, the compiler still warns me about a fallthrough:

    warning: this statement may fall through [-Wimplicit-fallthrough=]
        std::cout &lt;&lt; &quot;a\n&quot;;
        ~~~~~~~~~~^~~~~~~~

Why?


Why is GCC warning me about a fallthrough even when I use [[fallthrough]]?

I seem to see many answers in which someone suggests using `&lt;random&gt;` to generate random numbers, usually along with code like this:

    std::random_device rd;  
    std::mt19937 gen(rd());
    std::uniform_int_distribution&lt;&gt; dis(0, 5);
    dis(gen);

Usually this replaces some kind of &quot;unholy abomination&quot; such as:

    srand(time(NULL));
    rand()%6;

We might [criticize](https://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful) the old way by arguing that `time(NULL)` provides low entropy, `time(NULL)` is predictable, and the end result is non-uniform.

But all of that is true of the new way: it just has a shinier veneer. 

* `rd()` returns a single `unsigned int`. This has at least 16 bits and probably 32. That&#39;s not enough to seed MT&#39;s 19937 bits of state.

* Using `std::mt19937 gen(rd());gen()` (seeding with 32 bits and looking at the first output) doesn&#39;t give a good output distribution. 7 and 13 can never be the first output. Two seeds produce 0. Twelve seeds produce 1226181350. ([Link](http://www.pcg-random.org/posts/cpp-seeding-surprises.html))

* `std::random_device` can be, and sometimes is, implemented as a simple PRNG with a fixed seed. It might therefore produce the same sequence on every run. ([Link](https://stackoverflow.com/questions/18880654/why-do-i-get-the-same-sequence-for-every-run-with-stdrandom-device-with-mingw)) This is even worse than `time(NULL)`.

Worse yet, it is very easy to copy and paste the foregoing code snippets, despite the problems they contain. Some solutions to the this require acquiring [largish](http://www.pcg-random.org/) [libraries](http://www.boost.org/doc/libs/1_64_0/doc/html/boost_random.html) which may not be suitable to everyone.

In light of this, my question is **How can one succinctly, portably, and thoroughly seed the mt19937 PRNG in C++?**

Given the issues above, a good answer:

* Must fully seed the mt19937/mt19937_64.
* Cannot rely solely on `std::random_device` or `time(NULL)` as a source of entropy.
* Should not rely on Boost or other libaries.
* Should fit in a small number of lines such that it would look nice copy-pasted into an answer.

**Thoughts**

* My current thought is that outputs from `std::random_device` can be mashed up (perhaps via XOR) with `time(NULL)`, values derived from [address space randomization](https://en.wikipedia.org/wiki/Address_space_layout_randomization), and a hard-coded constant (which could be set during distribution) to get a best-effort shot at entropy.

* `std::random_device::entropy()` [does not](https://stackoverflow.com/questions/28390843/how-to-find-the-true-entropy-of-stdrandom-device) give a good indication of what `std::random_device` might or might not do.

How to succinctly, portably, and thoroughly seed the mt19937 PRNG?

We are catching warnings from GCC 7 for implicit fall through in a switch statement. Previously, we cleared them under Clang (that&#39;s the reason for the comment seen below):

    g++ -DNDEBUG -g2 -O3 -std=c++17 -Wall -Wextra -fPIC -c authenc.cpp
    asn.cpp: In member function ‘void EncodedObjectFilter::Put(const byte*, size_t)’:
    asn.cpp:359:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
        m_state = BODY;  // fall through
                      ^
    asn.cpp:361:3: note: here
       case BODY:
       ^~~~

The [GCC manual](https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) states to use `__attribute__ ((fallthrough))`, but its not portable. The manual also states *&quot;... it is also possible to add a fallthrough comment to silence the warning&quot;*, but it only offer `FALLTHRU` (is this really the only choice?):

    switch (cond)
      {
      case 1:
        bar (0);
        /* FALLTHRU */
      default:
        …
      }

Is there a portable way to clear the fall through warning for both Clang and GCC? If so, then what is it?

GCC 7, -Wimplicit-fallthrough warnings, and portable way to clear them?

Could someone give me an explanation why I get two different 
numbers, resp. 14 and 15, as an output from the following code?

    #include &lt;stdio.h&gt;  

    int main()
    {
        double Vmax = 2.9; 
        double Vmin = 1.4; 
        double step = 0.1; 

        double a =(Vmax-Vmin)/step;
        int b = (Vmax-Vmin)/step;
        int c = a;

        printf(&quot;%d  %d&quot;,b,c);  // 14 15, why?
        return 0;
    }

I expect to get 15 in both cases but it seems I&#39;m missing some fundamentals of the language.

I am not sure if it&#39;s relevant but I was doing the test in CodeBlocks. However, if I type the same lines of code in some on-line compiler ( [this one for example][1]) I get an answer of 15 for the two printed variables.


  [1]: https://www.onlinegdb.com/online_c_compiler

Nonintuitive result of the assignment of a double precision number to an int variable in C

**Case 1:**

    #include &lt;iostream&gt;
    
    int main()
    {
        double d = 15.50;
        std::cout&lt;&lt;(d/0.0)&lt;&lt;std::endl;
    }

It compiles without any warnings and prints `inf`. OK, C++ can handle division by zero, ([see it live](https://wandbox.org/permlink/qnpr8cM4W7rKlNid)).

But,

**Case 2:** 

    #include &lt;iostream&gt;
    
    int main()
    {
        double d = 15.50;
        std::cout&lt;&lt;(d/0)&lt;&lt;std::endl;
    }

The compiler gives the following warning ([see it live](https://wandbox.org/permlink/9cRSsWqewKxqN2CT)):

    warning: division by zero [-Wdiv-by-zero]
         std::cout&lt;&lt;(d/0)&lt;&lt;std::endl;
	 
Why does the compiler give a warning in the second case? 

Is `0 != 0.0`?

**Edit:**

    #include &lt;iostream&gt;
    
    int main()
    {
        if(0 == 0.0)
            std::cout&lt;&lt;&quot;Same&quot;&lt;&lt;std::endl;
        else
            std::cout&lt;&lt;&quot;Not same&quot;&lt;&lt;std::endl;
    }

**output:**

    Same



C++ warning: division of double by zero

I have this code in C where I&#39;ve declared 0.1 as double.

    #include &lt;stdio.h&gt; 
    int main() {
        double a = 0.1;

        printf(&quot;a is %0.56f\n&quot;, a);
        return 0;
    }
This is what it prints, `a is 0.10000000000000001000000000000000000000000000000000000000`

Same code in C++,

    #include &lt;iostream&gt;
    using namespace std;
    int main() {
        double a = 0.1;

        printf(&quot;a is %0.56f\n&quot;, a);
        return 0;
    }

This is what it prints, `a is 0.1000000000000000055511151231257827021181583404541015625`

What is the difference? When I read both are alloted 8 bytes? How does C++ print more numbers in the decimal places?

Also, how can it go until 55 decimal places? IEEE 754 floating point has only 52 bits for fractional number with which we can get 15 decimal digits of precision. It is stored in binary. How come its decimal interpretation stores more? 


Why does double in C print fewer decimal digits than C++?

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?

The hash of infinity in Python has digits matching [pi](https://en.wikipedia.org/wiki/Pi):

    &gt;&gt;&gt; inf = float(&#39;inf&#39;)
    &gt;&gt;&gt; hash(inf)
    314159
    &gt;&gt;&gt; int(math.pi*1e5)
    314159

Is that just a coincidence or is it intentional?


Content Type	Original Author	Original Content on Stackoverflow
Question	j b	View Question on Stackoverflow
Solution 1 - C++	Bathsheba	View Answer on Stackoverflow
Solution 2 - C++	Baum mit Augen	View Answer on Stackoverflow

Is a whole number float divided by itself guaranteed to be 1.f?

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Solution 2 - C++

In Python format (f-string) strings, what does !r mean?

Intellij - can be replaced with method reference

Attributions