Re: help with realignment of void*
andrew_nuss@yahoo.com wrote:
James Kanze wrote:
long long temp = reinterpret_cast<long long>(buf); // all
platforms???
Not guaranteed.
I saw another posting which simply used a C-style cast to cast
a void* to a size_t variable. My thinking is that this
assumes that regardless of the sizes of size_t and void* the
platforms are likely to put the least significant bits of the
void* into the size_t.
Likely, perhaps. I don't have my current copies of the standard
here to check, but if I remember, if the integer isn't big
enough, one of the directions (integer to pointer, or pointer to
integer) requires a diagnostic. For the other, the mapping is
at best implementation defined (although in that case, returning
the low order bits is the most reasonable definition).
Since you're only concerned with alignment, if you count on
this, using just about any (unsigned) integral type is
sufficient. I'd go with a simple unsigned int, rather than
bother with size_t.
C provides a uintptr_t typedef in stdint.h. Provided such a
thing exists on the platform (and I don't know of any
platform today where it might not, given a long long
guaranteed to be at least 64 bits).
I'll look for this on my platform. Again, is a C-style cast
better than a reinterpret_cast?
No, in no way. You're doing something tricky, so you really
should call attention to it by means of the reinterpret_cast.
(The semantics are exactly the same, in this case.
if ( temp % align != 0 ) {
temp += align - temp % align ;
}
Looks right.
This solution still counts on using uintptr_t, and casting the
integer back to a pointer. If you want to avoid this, using
e.g. unsigned int for temp, even if it isn't as large as a
poinetr, you need to also cast the pointer to char*, add the
value to it, and cast it back, e.g.:
void*
alignTo( void* p, unsigned alignment )
{
unsigned align
= reinterpret_cast< unsigned >( p ) % alignment ;
return align == 0
? p
: static_cast< char* >( p ) + (alignment - align) ;
}
This is probably the safest solution overall. It does count on
implementation defined behavior, however, so I would arrange
some sort of test program to be run each time you encounter a
new platform. (Maybe take an arbitrary pointer, and increment
it through a number of values, verifying that the conversion to
unsigned also increments in the same manner.)
At any rate, the problem isn't so much how to do whatever
you need to do in C++ (because I'm pretty sure that
adjusting alignment is not necessary), but knowing exactly
what you need to do to use the buffer correctly. A priori,
a Java group would be more appropriate, since it is really a
question of knowing what java.nio requires. All the
documentation says is " allows native code to access the
same memory region that is accessible to Java code", which
is fine IF you know how the Java code organizes this memory
region.
"nio" means new io. The idea is that using it allows the
native io implementation (likely from stdio.h) to read and
write directly to a native buffer, while at the same time
allowing the Java code to write and read directly to same
buffer. The Java io code is therefore much much faster.
Ultimately it allows 3D simulators to be written entirely in
Java that write to screen memory.
Which isn't stdio.h:-).
I'm using it for a different purpose. I let the JVM create
the buffer for me, so that it counts against the total Java
memory space, and then use it in C++ for all my needs rather
than using malloc/free in my JNI library. Thus when my native
library is unloaded (happens in J2EE apps) with native
libraries that are not in the boot classpath, I don't have to
free any memory at all. Nor have I stolen memory from the OS
that JVM doesn't know about. As you can see, since I am never
doing any stdlib malloc/free at all, I have to take over
memory management, and reimplement all of the STL-like
containers that I need.
As to the alignment of the nio void* buffer, documentation
says nothing about it.
The documentation describes certain use cases. That's about all
you'll get from Java.
And using any program module for other than its intended use is
playing with fire, so good luck.
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]