
C++ basics for competitive programming - aj_jaswanth
https://www.topcoder.com/community/data-science/data-science-tutorials/power-up-c-with-the-standard-template-library-part-1/
======
btilly
First important mistake, _By the way, vector is the only container that is
backward-compatible to native C code – this means that vector actually IS the
array, but with some additional features._

No, it is not. A C array under the hood is a pointer to the start of the
array. A vector is a data structure that includes a pointer to the start of an
array. This is needed because that data structure is where it includes things
like the size. But you can easily get out the array pointer, so no big deal,
right? Wrong.

The problem is that there are vector operations which do weird stuff with the
array. For example suppose you pass the array to one data structure, then
push_back on the vector. The vector may now realize it doesn't have enough
room to add more data, so moves the actual array to a new location and frees
the old.

You may not realize this because the freed array still contains something that
looks like the array. But it isn't any more!

Want another fun difference? In C programming you can easily allocate arrays
in an mmapped block backed by a file, exit, then do another run and simply
load the mmapped block. Try that with a vector and you'll get metadata
pointing at random memory that you haven't allocated. BOOM!

So it is really wrong to say that a vector IS just a C array with extra
features. They are different, and the differences can bite you pretty hard.

(That's the point I decided that continuing with this article was more likely
to mislead than be helpful for me.)

~~~
jjnoakes
> No, it is not. A C array under the hood is a pointer to the start of the
> array. A vector is a data structure that includes a pointer to the start of
> an array.

I don't think the article meant a vector is identical to a C array. I think
the article meant a view into the vector can be passed to a C routine
expecting a C array.

This is guaranteed by the C++ standard for the vector standard container:

    
    
        extern "C" void consume(int *x, size_t len);
    
        void f(std::vector<int> v)
        {
          consume(&v[0], v.size()); // C++98
          consume(v.data(), v.size()); // C++11
        }
    

> The problem is that there are vector operations which do weird stuff with
> the array.

This is a problem in C and C++ with any memory. If you change the memory while
someone else has a pointer to it, you lose. This has nothing to do with vector
vs arrays, and actually works the same for vectors and arrays (if you realloc
a C array, you have the same issue as if you append to a vector).

> Want another fun difference? In C programming you can easily allocate arrays
> in an mmapped block backed by a file, exit, then do another run and simply
> load the mmapped block.

Since you can't "point" a vector at a section of memory and tell it to use it,
this is nonsensical. In C++ you would use a pointer or array_view if you
already have contiguous memory allocated and want to refer to it by using an
index.

~~~
xorblurb
>This has nothing to do with vector vs arrays, and actually works the same for
vectors and arrays (if you realloc a C array, you have the same issue as if
you append to a vector).

If you realloc a C array, you have "realloc" written somewhere in your source
code. And a pointer that you updates.

> Since you can't "point" a vector at a section of memory and tell it to use
> it, this is nonsensical. In C++ you would use a pointer or array_view if you
> already have contiguous memory allocated and want to refer to it by using an
> index.

Yes. This is just not "backward-compatible to native C code", and the vector
actually is NOT the array (which is also not a pointer, but anyway...). Deal
with it.

~~~
jjnoakes
> This is just not "backward-compatible to native C code", and the vector
> actually is NOT the array (which is also not a pointer, but anyway...). Deal
> with it.

No one claimed any of the things you seem to be arguing against...

~~~
xorblurb
It's preemptive arguing :P

------
svalorzen
This article is probably one of the reasons why C++ gets the reputation it
has. Please do not program like this. Aside from the fact that this is C++98,
which lacks tons of features now widely accepted and useful in C++, the code
in this article has no consistency, uses most bad practices I know, and is
most certainly not geared towards competitive programming.

All this information is readily found in any online docs about C++. Please
read those.

~~~
thrownaway2424
Seriously. Nobody needs to think about stuff like this any more:

    
    
      vector< vector<int> >
    

Who even does that?

~~~
spdionis
Just curious, what should you use instead?

~~~
scott_s

      vector<vector<int>>
    

Prior to C++11, the code above would fail to compile. The lexer would see the
final ">>" and assume it was the out-stream operator. This was such an
annoying issue that they eventually changed the grammar so that the above
would compile as expected.

