0

I have the following code:

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

typedef long long ll;

int main() {
// your code goes here
int t;
cin>>t;
while(t--)
{
    string a;
    string b;
    cin>>a;
    cin>>b;
    vector<char> v1(a.begin(),a.end());
    vector<char> v2(b.begin(),b.end());

    sort(v1.begin(),v1.end());
    sort(v2.begin(),v2.end());
    vector<char> c;
    auto ls = set_intersection(v1.begin(),v1.end(),v2.begin(),v2.end(),c.begin());
    cout<<"hello"<<endl;
    cout<<ls-c.begin()<<endl;
    cout<<c.size()<<endl;

}
return 0;
}

Nothing is printed after the set_intersection line, not even "hello" which has no relation to the intersection line, why??

Vamsi Mohan
  • 31
  • 6
  • 1
    Please read [Why should I not #include ?](https://stackoverflow.com/q/31816095/5910058) – Jesper Juhl May 06 '20 at 16:09
  • 1
    `typedef long long ll;` - *Why*? Are you trying to intentionally obfuscate your code for future readers? – Jesper Juhl May 06 '20 at 16:11
  • 1
    Also recommend reading [Why is “using namespace std;” considered bad practice?](https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice). – HolyBlackCat May 06 '20 at 16:12
  • This is a competitive programming code, and I have read in many articles to use this to decrease time in coding. Is it ok to do so? – Vamsi Mohan May 06 '20 at 16:13
  • @VamsiMohan Well, nothing stops you from doing it, and it could save a few seconds of typing. But keep in mind that in actual real-world programming, those are considered bad practices. If you're doing competitive programming to learn regular programming, I'd avoid those. – HolyBlackCat May 06 '20 at 16:14
  • Okay, thanks for the suggestion. – Vamsi Mohan May 06 '20 at 16:17
  • @VamsiMohan -- What good will those shortcuts do you if you don't know the basics of how to handle the STL algorithms, such as `std::set_intersection`? Second, if a programmer has a problem with a certain aspect of C++, they would write a very small `main` program using the facility they are having an issue with, and work on the small `main` program to figure out how to use that aspect of C++. Writing `while t--` loops and all of that doesn't help matters. I would expect two vectors filled in with data, and testing `set_intersection` calls -- nothing more, nothing less. – PaulMcKenzie May 06 '20 at 16:34

1 Answers1

5

It doesn't work because c is empty. This means that c.begin() be equal to c.end(), and dereferencing an end iterator leads to undefined behavior.

You need to insert the elements in the vector, for example by using std::back_inserter:

auto ls = set_intersection(v1.begin(),v1.end(),v2.begin(),v2.end(),back_inserter(c));

There's one problem with this though: The iterator that set_intersection will return is the end of the back_inserter iterator you passed to the set_intersection function. That iterator is not related to c.begin() which means you can't really do ls - c.begin().

Unfortunately there's really no way to get the distance between the initial back_inserter(c) iterator and ls.

Some programmer dude
  • 363,249
  • 31
  • 351
  • 550