double^ x_ptr = x;    // implicit boxing

y = (double)x_ptr;    // no implicit unboxing

/clr:safe is "stronger" than /clr:pure.

/clr - may generate mixed-mode code
/clr:pure - generates only IL
/clr:safe - generates only verifiable IL

-cd

Note that double^ is a reference type (it's what e.g. C# treats as
an object)
double x = 7.;
object o = (object)x; // boxing

If you want a managed pointer (this is what ref/out in C# yield, or
a float64& in CLR speak) you can use

// has C++ reference semantics x_ref = 1 assigns to x
double% x_ref = x;

// managed pointer, has C++ pointer semantics
interior_ptr<double> x_ptr = &x;

There is a performance overhead associated with boxing (essentially
it creates a full object - supporting several interfaces, strong object
identity etc. - around the data value)

Why the language designers chose to deviate from the semantics for
reference types is beyond me.

y =*x_ptr;

double* __gc corresponds with interior_ptr<double>
__box double* corresponds with double^
__box(x) is used to box a value. This conversion is implicit with C++/CLI,
but you probably want to be explicit and use a box(_cast) helper function
template.

You should be able to use /clr:pure with almost everything including
native pointers (double* in C++/CLI). /clr:pure can operate on "unmanaged
data" (i.e. memory that is not managed by the CLR execution engine).
MSIL can describe such operations. There is almost nothing you get by
going from /clr to /clr:pure except maybe making things much more simple
for a certain type of static analysis tools.

/clr:safe is much more strict and won't let you do anything with native
pointers
(at least almost). But many things involving managed pointers are not
verifiable
as well. Essentially, they're only useful for parameter passing (e.g. ref
and out
in C#). Managed pointers can only be used in contexts with automatic storage
duration.

hth
-hg