log in cpp 14 and 17

Question

Online Ide test for GNU c++ 14 and GNU c++17

Input tested: 6 6

Expected output: "="

Actual output: ">"

But in codeBlocks(gcc) I am getting correct ,I know its compiler issue how can I correct it PLease help

#include<bits/stdc++.h>
using namespace std;
int32_t main(){
    int x,y;
    cin>>x>>y;
    double lhs = 1.0*y*log(x);
    double rhs = 1.0*x*log(y);
  //  cout<<"  lhs "<<lhs<<endl;
    //cout<<"  rhs "<<rhs<<endl;
    if(rhs>lhs){
        cout<<"<";

    }
    else if(lhs==rhs){
        cout<<"=";
    }
    else{
        cout<<">";
    }
}

related: https://stackoverflow.com/questions/588004/is-floating-point-math-broken — 463035818_is_not_an_ai, Sep 05 '19 at 14:53
it is interesting why `lhs` and `rhs` do not yield the exact same result, though note that in general if you compare floating points via `==` then you are doing something wrong — 463035818_is_not_an_ai, Sep 05 '19 at 14:54
https://stackoverflow.com/questions/31816095/why-should-i-not-include-bits-stdc-h — , Sep 05 '19 at 14:54
Careful with `using namespace std;`. It makes it hard to be sure which `log` function is being called. — user4581301, Sep 05 '19 at 14:55
@akacodes121 it probably isn't but it is a sound warning. Combining `#include` with `using namespace std;` can turn an ordinary program into a bug nest. — user4581301, Sep 05 '19 at 14:58
can any one tell me what as a good programmer you handle above situation? — akacodes121, Sep 05 '19 at 15:00
Floating point is not deterministic? In such a case it should lead to the same binary representation — BiagioF, Sep 05 '19 at 15:02
Not actually a duplicate, as if IEEE754 semantics are used, this would be illegal. Still C++ does not mandate using IEEE754 (everything about fp math is implementation defined) so a compiler that did this could still be conforming. Its more likely, however, that the `cin>>` read failed, so `x` and `y` are actually uninitialized and not what you think they are... — Chris Dodd, Sep 05 '19 at 15:07
This is awful code but the question is not a duplicate. My best guess is what @ChrisDodd suggested. Try printing `x` and `y`. — Mankka, Sep 05 '19 at 15:11
[Works for me](https://godbolt.org/z/8ClxwT) with all versions of `gcc-x64` which are supporting `c++14` (>=4.9.0) and are properly configured on godbold site. Could you provide more detail about your environment where it fails. — Marek R, Sep 05 '19 at 15:44
What happens if you replace `#include ` with `#include ` (and `#include ` if you want to add the `setprecision(30)` stuff) ?? — Adrian Mole, Sep 05 '19 at 16:39
@ChrisDodd: It’s been a long time since stream extraction left the target uninitialized on failure. — Davis Herring, Sep 05 '19 at 16:43
If `x` and `y` are 0, `lhs` and `rhs` are NaN, which would produce the observed result. — Davis Herring, Sep 05 '19 at 16:44
For starters, `std::cout << "x=" << x << " y=" << y << std::endl;` to be sure you're not doing garbage in garbage out. Also, take away the awful `#include`. I would usually be ok with `using namespace std;` in a cpp but not if you're using `log`. Try removing the `using` and see if it complaints about `log`. If it does, maybe you need `` — Mirko, Sep 05 '19 at 17:22
Maybe more appropriate for the question @Neil Butterworth linked, but maybe use of `#include` should be formally (on SO, at least) declared UB? OP says he "thinks" this is not the issue - so what does he "think" the issue is? — Adrian Mole, Sep 05 '19 at 17:27
@Adrian I don't think the act of #including a file can be UB. But doing so in this instance should certainly be discouraged. I keep meaning to make a meta post on this. — , Sep 05 '19 at 17:36
@Mirko, `Also, take away the awful #include. I would usually be ok with using namespace std; in a cpp but not if you're using log`. Can you please clarify? — , Sep 05 '19 at 17:41
Name clashes with a short, common name like log are usual. It's common for people to use "log" for logging; then someone includes math and you have using namespace std, and two log clashing. — Mirko, Sep 05 '19 at 17:55
not reproducible with both https://wandbox.org/ and https://ideone.com/9SVXbt — phuclv, Dec 29 '19 at 15:13

score -6 · Answer 1 · answered Sep 05 '19 at 17:42

-6

The code, as is has several problems.

The important part: you're not initializing nor checking for errors.

I did type the code at ideone, and if you don't put any input you get UB.

Instead of:

int x,y;

Good practice is:

int x= 0, y= 0;

Better practice is:

auto x= 0;
auto y= 0;

They don't charge you for the line of code, so type and put each variable in it's own line, using auto so you can't forget to initialize them.

Then also instead of just cin >> x you should check it. As an example, if (cin >> x) {}

Second, don't use #include <bits/stdc++.h>. Use the standard C++ headers like #include <iostream>

Third, try not to use using namespace std;.

Bottomline, type code, don't try to save an auto or int, don't try to save an = 0 because "I'll init that variable it later". Don't try to save typing the right include and don't try to save typing the std::

answered Sep 05 '19 at 17:42

Mirko

1,043
6
12

If you want to use `auto`, I'd write `auto x = int{0};`. This way the type is immediately obvious. – HolyBlackCat Sep 05 '19 at 17:44
2

Why would you initialize variable that you are erasing on the next line? It's not about typing more or less, it's about writing code that has meaning. While this answer has some interesting advices, this is not an answer to the current question, and should probably be a comment. – Holt Sep 05 '19 at 17:45
@Holt because if you don't provide input, or provide wrong input, you get UB. See http://ideone.com/OzAjV1 – Mirko Sep 05 '19 at 17:48
@Mirko If you assume that you can get wrong input, then you should be checking the input method, and stop before using the corresponding variables, not try to have a "defined" behavior that makes no sense. – Holt Sep 05 '19 at 17:50
Also, if you later change the program and don't do cin>>x, or it's on a condition, you'll still get an uninitialized variable. **ALWAYS** initialize variables. That's what constructors do: make sure every variable gets initialized. Also, that's why `auto` is recommended. So you **ALWAYS** initialize some variables. Also, see the demo. Also, if you put some value on the next line of code, the compiler will elide that. – Mirko Sep 05 '19 at 17:52
@HolyBlackCat No. I don't care the type. I shouldn't. Unless you *need it to be an `int`*, you should use plain auto imho. – Mirko Sep 05 '19 at 17:54
@Mirko This is your opinion. It's probably a very bad idea to let propagate stream error in your code by putting `0` everywhere you did not get the expected output. If you change the code and don't do a `cin >> x`, any decent compiler will give you a warning about `x` being used uninitialized. And if you are not testing your input/output operations, then you probably have other issues. And I can turn your reasoning about change around: If I remove `cin >> x`, with an initialized variable, I'll see no change in compilation, but if `x` is not initialized, I'll get a warning. – Holt Sep 05 '19 at 17:57
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/199028/discussion-between-mirko-and-holt). – Mirko Sep 05 '19 at 18:01
1

`cin >> foo` always stores to `foo` since C++11. Uninitialized variables are simply not the problem here. – Davis Herring Sep 05 '19 at 19:10
@DavisHerring C++14 (gcc 8.3) says the ideone on the demo. – Mirko Sep 05 '19 at 19:12
2

this is a lot of dos and donts and goods and betters with little rationale and zero answer to the question. Even if you are right on most points, giving advice without explaining the "why" in details leads to cargo cult programming. And the claim about UB is just wrong and misleading – 463035818_is_not_an_ai Sep 06 '19 at 08:13

log in cpp 14 and 17

1 Answers1