Some Useful trick in Competitive Coding

general
,
5

It’s literally the complete opposite of the truth: including individual headers - which include only what you need - is really best practice for C++, and completely portable. So it’s good for portability and pretty much universally viewed as a good habit.

On the other hand, #include<bits/stdc++.h> is completely non-portable (it works only with gcc’s implementation of the C++ Standard Library) and includes a ton of stuff that you don’t need.

If they’d just said "#include <bits/stdc++.h> saves typing", then that wouldn’t be so bad, but this “justification” … yeesh.

12 Likes
6

Cong for being promoted to Leader

2 Likes
7

Thanks - you can thank @everule1 for that :slight_smile:

2 Likes
8

So, was there voting for leader?

9

No idea how it works :slight_smile: :man_shrugging:

1 Like
10

You said thank @everule1. So I thought there was some kind of voting.

11

Umm, The thing is, no voting is required. Any moderator can kinda do whatever they want basically.

5 Likes
12

That is the best thing you did :smiley:

4 Likes
13

This is such a bad resource. Promoting bad practices, giving wrong reasons, half-ass explanations that can easily lead to extremely slow code.

I’ll mention the problematic tricks:

Trick 4:
Already have been explained in this thread, it is very bad practise and makes your code lose portability. In CP its justified to use it though.

Trick 5:
Why should use of make_pair be avoided? Literally no reason supplied.
auto p1 = make_pair(x, y);
pair<string, string> p2 = {x, y};

Both are equally good, infact make_pair can shorten your code (with auto).
One thing I would like to mention is that advice: “use {} instead of make_pair” is REALLY bad, what if someone learns about auto and tries:
auto p3 = {x, y};
This code fails miserably.

Trick 7:
The advice is good, using for (auto it : container) is actually pretty good and prevents from falling into some unexpected copying and hence wrong results, but it’s a half-ass advice.
Please mention that you should use for (auto &it : container) in case of data type being bigger than a normal pointer size, otherwise big copies will happen and slow down the program.

Heck another problem is what if someone wants to change elements and they use auto without &, the actual values won’t even change => WA.

Trick 8:
Just WHY recommend this? Neither does it shorten the code or speeds it. It only makes it more difficult to debug.

Trick 11:
Yes emplace_back should be preferred, but the reasoning seems incomplete(to me). I’m not proficient at STL so won’t comment, but seems incomplete if not wrong.

So whoever wrote this, I would like to request you to first learn before making tutorials/tricks/tips. Not only you’re making yourself look like a clown, you’re also teaching wrong things to beginners, which contrary to your goal of helping the community, sabotages it a little.

6 Likes
14

If someone need explanation with video you can find it Here.

15

yes i do agree with your statement.
But when we are in the live contest then rather than focusing on the header file we should focus on the problem statement.
So without wasting time you can go with this one line.

1 Like
16

I think you are not familiar with c++ 11.
And talking about the explanations. Well explanations are given in the web links provided in the pdf.
And for your kind information , all the given short tricks are taken from the geeks for geeks articles and codeforces articles.
So d0 check out their website , although links are given in pdf itself.

17

I’m the one not familiar with C++11??? What are you even saying.

I watched your video and you said modern c++ has bits/stdc++.h header file. WRONG, it depends on compiler. MSVC doesn’t have this header file for even c++17.

I have given longass explanations of which tricks mentioned are problematic, it’d be better if you at least tried to understand where you’re wrong.

Seeing the video gave me the impression you’ve no idea of what’s modern c++. Again, go back to basis of the language then try to teach others.

TL DR; some of your tricks are wrong/incomplete/unnecessary bad practice and when pointed out you fail to accept it.

4 Likes
18

In CP it’s justified to use it, but I think @ssjgz was pointing out the reasoning provided behind it:

Get rid of those includes ! instead of individual standard headers like <string> , <iostream> and <vector> . It ruins portability and fosters terrible habits.

1 Like
19

Would also like to point out that don’t use __gcd instead use the normal recursive gcd function #define it and use it because __gcd wont work for large values.

2 Likes
20

Do you mean __gcd does not work for long int?

21

yeah if values are large __gcd might fail thats why I use my own gcd function

22

why it fails?

24

You are mistaken, also misleading people without proper proof.

#include <bits/stdc++.h>
using namespace std;

int main() {
    long long int a = ((long long int)(1e18));
    long long int b = ((long long int)(1e17));
    cout << a << ' ' << b << endl;
    cout << __gcd(a,b) << endl;
    return 0;
}

This code prints the expected output. Inbuilt functions are designed to operate on maximum possible data types.
So, __gcd() works on Long Long int as well.

2 Likes
25

It’s a joke in 2021, Come on man. any trash shared before dosn’t mean working now