-2

i am stuck on a problem where, after taking input of an array and sorting it and not doing any operation on it at all, the output shows a different array?

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

int main() {
// your code goes here
int t;
cin>>t;
while(t--){
    int n;
    cin>>n;
    long long int c[n],h[n],a[n];
    for(int i=0;i<n;i++){
        cin>>c[i];
    }
    for(int i=0;i<n;i++){
        cin>>h[i];
    }
    sort(h,h+n);
    for(int i=0;i<n;i++){
        a[i]=0;
    }
    int i=0;
    int begin=(i+1)-c[i];
    int end = (i+1)+c[i];
    int j=begin;
    while(i<n){
        a[j-1]++;
        j++;
        if(j>end){
            i++;
            begin=(i+1)-c[i];
            end= (i+1)+c[i];
            j=begin;
        }
    }

    sort(a,a+n);
    for(int i=0;i<n;i++){
        cout<<h[i]<<" ";
    }
 }
 return 0;
 }

input for h[]={8,8,8,8,8}..n=5 output h[]={10,10,9,9,8}

Abhishekk
  • 5
  • 3
  • 9
    `#include using namespace std;` - Don't do that. – Jesper Juhl Aug 07 '19 at 15:23
  • 5
    `cin >> n; long long int c[n],h[n],a[n]` is not C++. See https://stackoverflow.com/questions/1887097/why-arent-variable-length-arrays-part-of-the-c-standard – alter_igel Aug 07 '19 at 15:23
  • 3
    Also, if you know the input already, why are you posting input statements, like the variable `t`, and `cin`? Just give us a code sample with the variables already filled in with the data. Not only will your example become a [mcve], you will make it easier to focus on the issue, and make it easier to debug for yourself. – PaulMcKenzie Aug 07 '19 at 15:26
  • This probably happens due to `j` becoming zero or negative. But your [mcve] is missing half the required inputs... What do you see when you step through this program in a debugger? – Max Langhof Aug 07 '19 at 15:27
  • What numbers should go into `c[]`? What does that variable represent? – Beta Aug 07 '19 at 15:29
  • 1
    This isn't C++ code. –  Aug 07 '19 at 15:31
  • *and not doing any operation on it at all,* -- What?? It looks like you're doing a whole lot of "stuff" in-between after you get the input and before you output the results. – PaulMcKenzie Aug 07 '19 at 15:32
  • 5
    **Recommended reading:** [Why should I not #include ?](https://stackoverflow.com/q/31816095/560648) – Lightness Races in Orbit Aug 07 '19 at 15:33
  • 3
    Use `std::vector` instead of variable sized arrays, and then use `at` instead of `operator[]`. That will show you where your bug is. – hegel5000 Aug 07 '19 at 15:55
  • 2
    `begin` and `end` are terrible variable names after doing `using namespace std;` - the `std` namespace contains `std::begin` and `std::end`. – Jesper Juhl Aug 07 '19 at 16:44

2 Answers2

2

Here is a version of your code written in reasonably decent C++. I didn't touch the loop in the middle because I have no clue what it's doing. You're using obscure variable names and no comments and doing all kinds of bizarre things with indexes and mixing them up with user input.

Now, reading indexes from user input and using them isn't bad, though in a real program you'd want to be doing lots of bounds checking on that input to make sure people weren't feeding you bad data. But doing all that stuff with such poorly named variables with no explanation is going to leave anybody looking at it scratching their head. Don't do that.

Also, avoid the use of begin and end as variable names, especially if they hold indexes. In most cases it will confuse things terribly as begin and end are important identifiers in the standard library and always refer to iterators, which are sort of like indexes, but most definitely not indexes, adding greatly to the confusion. beginidx and endidx could be acceptable substitutes in this case.

#include <vector>
#include <algorithm>
#include <iostream>
#include <iterator>

using ::std::vector;
using ::std::sort;
using ::std::copy_n;
using ::std::copy;
using ::std::fill;
using ::std::istream_iterator;
using ::std::ostream_iterator;
using ::std::cin;
using ::std::cout;

int main() {
// your code goes here
   using vec_el_t = long long int;
   int t;
   cin >> t;
   while (t--) {
      int const n = []() { int n; cin >> n; return n; }();
      vector<vec_el_t> c{n}, h{n}, a{n};
      copy_n(istream_iterator<vec_el_t>{cin}, n, c.begin());
      copy_n(istream_iterator<vec_el_t>{cin}, n, h.begin());

      // Suggested debugging code:
      // cout << "h before sort: "
      // copy(h.begin(), h.end(), ostream_iterator<vec_el_t>{cout, " "});
      // cout << '\n';

      sort(h.begin(), h.end());

      // Suggested debugging code:
      // cout << "h after sort: "
      // copy(h.begin(), h.end(), ostream_iterator<vec_el_t>{cout, " "});
      // cout << '\n';

      fill(a.begin(), a.end(), 0);

      // Weird, unexplained algorithm begins here
      int i = 0;
      int begin = (i + 1) - c[i];
      int end = (i + 1) + c[i];
      int j = begin;
      while (i < n) {
         a[j - 1]++;
         j++;
         if (j > end){
            i++;
            begin = (i + 1) - c[i];
            end = (i + 1) + c[i];
            j = begin;
         }
      }
      // Weird unexplained algorithm ends here

      sort(a.begin(), a.end());
      copy(h.begin(), h.end(), ostream_iterator<vec_el_t>{cout, " "});
   }
   return 0;
}

Changes made... Use vector not a variable length array, which isn't valid C++ anyway and will only work in g++ and clang. Don't use explicit loops if there is an algorithm that will do the job. Try to make as many things const as you can so you can make sure that the compiler catches it if you try to change things you didn't mean to change. Avoid using std; and if you want to import names from ::std import exactly the ones you need. Don't use compiler or library implementation specific header files and use the ones from the standard instead (i.e. no bits/stdc++.h).

As for your problem, I have no idea. I suspect that the index manipulation combined with looping isn't doing what you expect. If you print out the arrays before and after sorting, you will discover that sort only alters order, and not content.

As a general rule, always suspect your own code first and make absolutely sure it's correct. And if you really think it's the library code, prove it beyond a shadow of a doubt before coming here to ask why the library isn't doing what it says it does.

The complicated code I didn't touch looks rife with opportunities for out-of-bounds access, and that results in undefined behavior, which means your program might do absolutely anything in that case. You might change uses of operator [] with calls to the at function (one of the many perks of using vector) instead. That way, attempts at out-of-bounds access will throw an exception.

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
1

Within these lines you are accessing a outside its limits:

int i=0;
int begin=(i+1)-c[i];  // begin = 1 - c[0]; <<-- this could be arbitrarily small!
int end = (i+1)+c[i];  // unrelated
int j=begin;           // also equal to 1-c[0]
while(i<n){
    a[j-1]++;          // increment a[-c[0]] which is UB unless c[0]==0

This means undefined behavior (UB), i.e., it could do nothing, it could segfault, or (what apparently happened in your case) access elements of an adjacent data structure.

chtz
  • 17,329
  • 4
  • 26
  • 56