This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: GCC vector element access pointers in C++
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Marius Miknis <marius dot miknis at southwales dot ac dot uk>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 26 Jan 2016 10:52:19 +0000
- Subject: Re: GCC vector element access pointers in C++
- Authentication-results: sourceware.org; auth=none
- References: <E38AAE8FDF3A2E44AE4D3F0E1D1C5C7CB5F34F64 at MailDB1 dot uni dot glam dot ac dot uk> <alpine dot DEB dot 2 dot 20 dot 1601261003430 dot 1885 at laptop-mg dot saclay dot inria dot fr> <E38AAE8FDF3A2E44AE4D3F0E1D1C5C7CB5F34F88 at MailDB1 dot uni dot glam dot ac dot uk>
On 26 January 2016 at 09:13, Marius Miknis wrote:
> Hi Marc,
>
> Thanks for such a quick reply, I appreciate it.
>
> Yes I am trying to speed up my testing in debug as working with point clouds of +600,000 points stored in vectors is really really slow, thus using _ MyFirst and _MyLast removes all the dereferencing/accessing overheads as I work directly with pointers and can just increment pointer addresses, plus even if the vector gets resized _ MyFirst and _MyLast are not affected.
We don't provide direct access to members like that and never will.
> I did look through the stl_vector.h but it sadly seems that I can not use ._M_impl._M_start. I am aware that compiler will remove all the overheads in release but currently in debugging I need a fast way to access and move through the vector.
GCC doesn't have "release" and "debug". Compile with -Og and you can
still debug the result easily, but a lot of the abstraction penalty is
removed.
Or you could compile with -fno-access-control but I don't recommend it.
I am surprised that when accessing 600000+ points you will even notice
the cost of doing v.data() and v.data+v.size() once to calculate those
pointers each time the vector is modified. It certainly shouldn't be
"really really slow".