Re: pointer arithmetic and std::vector
On Jul 4, 4:44 pm, aaragon <alejandro.ara...@gmail.com> wrote:
On Jul 3, 12:00 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
I found that using pointer arithmetic, the subtraction is
of type ptrdiff_t, and according to the cplusplus.com: "A
subtraction of two pointers is only granted to have a
valid defined value for pointers to elements of the same
array (or for the element just past the last in the
array). For other values, the behavior depends on the
system characteristics and compiler implementation."
From the standard (concerning subtraction between two
pointers): "Unless both pointers point to elements of the
same array object, or one past the last element of the array
object, the behavior is undefined." And also: "If the
result [of the subtraction] does not fit in the space
provided [by std::ptrdiff_t], the behavior is undefined"
(although that's not likely to be a problem for anything
other than char*).
So this is probably why my other code (the one I'm unable to
post because it is too big) is unable to get the difference
between two addresses as a displacement to the function I
wanted to use. We were testing this pointer subtraction with 5
vectors, taking the address of the array of one of them as our
reference. For some reason I really don't understand, one you
obtain the pointer difference with respect to the first vector
and then compute the addresses of the beginning of the 4 other
vectors we couldn't obtain the original addresses back. The
addresses were offsets by 4, 8, 12 and 16 bytes for each of
the vectors. Do you have an idea why this is the case?
Without knowing the exact platform, it's hard to say. On a
Sparc, under Solaris, I would expect it to work. On a modern
Intel, it should probably work as well, provided that all of
allocated memory is in the same segment (the case under Linux
and Windows). Provided, of course, that all of the vector are
instantiated over the same type (and you systematically obtained
the address with &v[0]). Several possibilities for problems,
however, do exist: reallocation, overflow, etc.
I guess the only solution to my problem is then to use a
buffer and copy everything to contiguous memory before sending
it through MPI. This will definitely play against the speedup
of the parallel implementation.
If you're not concerned about portability, and you really do
have a performance problem, it's probably worth trying to find
out why your code isn't working, and repare that. Unless you've
actually got a measurable performance problem, however, I
wouldn't bother.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34