I'm currently having a small issue which i thought would be easy, but not, so,(maybe it is easy, but i don't know) i need to convert a String^ into a String^* so basically a string pointer, small snippet of code:
ARPLC_command_byuser = textBox1->Text;
I've already tried various of methods, but all seem to fail(well, they don't, i do).
If you have any idea, please tell me what to do.
That's not possible. A managed object is moved around in memory when the garbage collector compacts the heap. Which will invalidate any pointer. This is the primary reason that C++/CLI uses the ^ hat to indicate object references, they are pointers under the hood that the garbage collector can recognize and update when the object is moved.
Technically it is possible to pin a managed object to ensure that it doesn't get moved. Something you can do with pin_ptr<> or GCHandle::Alloc(). This should be avoided. Convert the managed string to a native pointer by copying it into unmanaged memory using the Marshal class.
Related
How do I define a pointer to a variable or list element in Julia? I have tried reading some resources but I am really confused about using a pointer in Julia.
You cannot have a pointer to a variableâunlike C/C++, Julia doesn't work like that: variables don't have memory locations as part of the language semantics; the compiler may store a variable in memory (or in a register), but that's none of your business đ. Mutable objects, however, do generally live in memory and you can get a pointer to such an object using the pointer_from_objref function:
pointer_from_objref(x)
Get the memory address of a Julia object as a Ptr. The existence of
the resulting Ptr will not protect the object from garbage collection,
so you must ensure that the object remains referenced for the whole
time that the Ptr will be used.
This function may not be called on immutable objects, since they do
not have stable memory addresses.
See also: unsafe_pointer_to_objref.
Why the awful name? Because, really why are you taking pointers to objects? Probably don't do that. You can also get a pointer into an array using the pointer function:
pointer(array [, index])
Get the native address of an array or string, optionally at a given
location index.
This function is "unsafe". Be careful to ensure that a Julia reference
to array exists as long as this pointer will be used. The GC.#preserve
macro should be used to protect the array argument from garbage
collection within a given block of code.
Calling Ref(array[, index]) is generally preferable to this function
as it guarantees validity.
This is a somewhat more legitimate use case, especially for interop with C or Fortran, but be careful. The interaction between raw pointers and garbage collection is tricky and dangerous. If you're not doing interop then think hard about why you need pointersâyou probably want to approach the problem differently.
I get the impression that Rust is intended to be used in highly safe systems. Then I noticed that raw pointers allow arbitrary pointer arithmetic, and they can cause memory safety and security issues.
Basically, a pointer is an object that refers to another object. In most programming languages (I guess) a pointer is actually just a number that refers to a memory address. Rust's raw pointers are really just that - memory addresses. There are other pointer types in Rust (& references, Box, Rc, Arc), for which the compiler can verify that the memory is valid and contains what the program thinks it contains. This is not the case for raw pointers; they can in principle point to any memory location, regardless of the content. Refer to The Book for more details.
Raw pointers can only be dereferenced inside unsafe blocks. These blocks are a way for the programmer to tell the compiler "I know better than you that this is safe and I promise not to do anything stupid".
It is generally best to avoid raw pointers if possible because the compiler cannot reason about their validity, which makes them unsafe in general. Things that make raw pointers unsafe are the potential to...
access a NULL pointer,
access a dangling (freed or invalid) pointer,
free a pointer multiple times,
All these points boil down to dereferencing the pointer. That is, to use the memory pointed to.
However, using raw pointers without dereferencing them is perfectly safe. This has a use case in finding out if two references point to the same object:
fn is_same(a: &i32, b: &i32) -> bool {
a as *const _ == b as *const _
}
Another use case is the foreign function interface (FFI). If you wrap a C function that takes raw pointers as arguments, there is no way around providing them to the function. This is actually unsafe (as is the whole FFI business), because the function is likely to dereference the pointer. This means you are responsible for making sure the pointer is valid, stays valid, and is not freed multiple times.
Finally, raw pointers are used for optimization. For example, the slice iterator uses raw pointers as internal state. This is faster than indices because they avoid range checks during iteration. However, it is also unsafe as far as the compiler is concerned. The library author needs to pay extra attention, so using raw pointers for optimization always comes at the risk of introducing memory bugs that you normally do not have in rust.
In summary, the three main uses of raw pointers are:
"just numbers" - you never access the memory they point to.
FFI - you pass them outside Rust.
memory-mapped I/O - to trigger I/O actions you need to access hardware registers at fixed addresses.
performance - they can be faster than other options, but the compiler won't enforce safety.
As to when raw pointers should be used, the first three points are straight-forward: You will know when they apply because you have to. The last point is more subtle. As with all optimizations, only use them when the benefit outweighs the effort and risk of using them.
A counter example when not to use raw pointers is whenever the other pointer types (& references, Box, Rc, Arc) do the job.
I'm wondering if there is any perf benchmark on raw objects vs pointers to objects.
I'm aware that it doesn't make sense to use pointers on reference types (e.g. maps) so please don't mention it.
I'm aware that you "must" use pointers if the data needs to be updated so please don't mention it.
Most of the answers/ docs that I've found basically rephrase the guidelines from the official documentation:
... If the receiver is large, a big struct for instance, it will be much cheaper to use a pointer receiver.
My question is simply what means "large" / "big"? Is a pointer on a string overkill ? what about a struct with two strings, what about a struct 3 string fields??
I think we deal with this use case quite often so it's a fair question to ask. Some advise to don't mind the performance issue but maybe some people want to use the right notation whenever they have to chance even if the performance gain is not signifiant. After all a pointer is not that expensive (i.e. one additional keystroke).
An example where it doesn't make sense to use a pointer is for reference types (slices, maps, and channels)
As mentioned in this thread:
The concept of a reference just means something that serves the purpose of referring you to something. It's not magical.
A pointer is a simple reference that tells you where to look.
A slice tells you where to start looking and how far.
Maps and channels also just tell you where to look, but the data they reference and the operations they support on it are more complex.
The point is that all the actually data is stored indirectly and all you're holding is information on how to access it.
As a result, in many cases you don't need to add another layer of indirection, unless you want a double indirection for some reason.
As twotwotwo details in "Pointers vs. values in parameters and return values", strings, interface values, and function values are also implemented with pointers.
As a consequence, you would rarely need a to use a pointer on those objects.
To quote the official golang documentation
...the consideration of efficiency. If the receiver is large, a big struct for instance, it will be much cheaper to use a pointer receiver.
It's very hard to give you exact conditions since there can be different performance goals. As a rule of thumb, by default, all objects larger than 128 bits should be passed by pointer. Possible exceptions of the rule:
you are writing latency sensitive server, so you want to minimise garbage collection pressure. In order to achieve that your Request struct has byte[8] field instead of pointer to Data struct which holds byte[8]. One allocation instead of two.
algorithm you are writing is more readable when you pass the struct and make a copy
etc.
The Rust Programming Language, first edition says that Rust does not have a garbage collector:
It maintains these goals without having a garbage collector
However, in discussing choosing your guarantees it also says:
Rc<T> is a reference counted pointer. In other words, this lets us have multiple "owning" pointers to the same data, and the data will be dropped (destructors will be run) when all pointers are out of scope.
As far as I understand, this is exactly how pointers work in a garbage-collected language like Python.
I consider garbage collection to be any process which prevents the need for manual deallocation of dynamically-allocated memory. I think I don't understand what the Rust guide considers to be garbage collection however.
I consider garbage collection to be any process which prevents the need for manual deallocation of dynamically-allocated memory
Then Rust does have "garbage collection"!
fn make_stuff() {
// Allocate memory on the heap and store `true` in it
let thing = Box::new(true);
// Allocate memory on the heap and store 1000 numbers in it.
let things = vec![42; 1000];
} // Look Ma! No manual deallocation!
When thing and things go out of scope (in this case, at the end of the method), then the memory they had allocated will be freed for you.
Rc and Arc allow more flexibility than this; you should give their docs a read to know more.
In addition to #Manishearth's answer, there's also this detail (emphasis mine):
automatically freed at the end of its last owner's lifetime
In many garbage-collected languages, garbage collection happens out-of-band with the rest of your code. In Rust, the location of deallocation will be known.
Given this Java:
public static ArrayList alpha()
{
return new ArrayList();
}
public static void beta()
{
alpha(); // Unused result
}
I do not believe that you can say with certainty when the ArrayList will be removed from memory. In the equivalent Rust code, you know that an Arc or Rc will be destructed as soon as it goes out of scope.
This article is a bit old, regarding how Rust has changed now, but it highlights what it means that Rust does not have GC. Only RAII and ownership are intrinsic to Rust. They helps writing reference-counting alike GCs such as Rc and Arc, but those are not part of the language, they're part of the standard library. And it makes a huge difference.
If you consider writing an operating system in Rust, you can't use any form of GC in part of your code or use the standard library. At this level, it's important to know what is part of the language and what is not. For a simple example, have look here.
In contrast, in a language such as Java or Python, you can't prevent your code from using the GC as it use it implicitly by design of the language.
In Rust, like in C/C++ a GC is part from a library and it's use is explicit.
Rc has no cycle collection. If you create a cycle of references, you will probably crash the program as it tries to increment the refcount.
Though this technically counts as a garbage collector too, it's not a universally useful one since you have the restriction on the types it can contain.
If you insist on being correct, a garbage collector collects. It collects a list of memory locations to free. Rc/Arc on the other hand does not, so I don't think you can call it garbage collection.
However rust has the std::gc module, so yea rust has in fact an optional garbage collector for now.
I recently read a discussion regarding whether managed languages are slower (or faster) than native languages (specifically C# vs C++). One person that contributed to the discussion said that the JIT compilers of managed languages would be able to make optimizations regarding references that simply isn't possible in languages that use pointers.
What I'd like to know is what kind of optimizations that are possible on references and not on pointers?
Note that the discussion was about execution speed, not memory usage.
In C++ there are two advantages of references related to optimization aspects:
A reference is constant (refers to the same variable for its whole lifetime)
Because of this it is easier for the compiler to infer which names refer to the same underlying variables - thus creating optimization opportunities. There is no guarantee that the compiler will do better with references, but it might...
A reference is assumed to refer to something (there is no null reference)
A reference that "refers to nothing" (equivalent to the NULL pointer) can be created, but this is not as easy as creating a NULL pointer. Because of this the check of the reference for NULL can be omitted.
However, none of these advantages carry over directly to managed languages, so I don't see the relevance of that in the context of your discussion topic.
There are some benefits of JIT compilation mentioned in Wikipedia:
JIT code generally offers far better performance than interpreters. In addition, it can in some or many cases offer better performance than static compilation, as many optimizations are only feasible at run-time:
The compilation can be optimized to the targeted CPU and the operating system model where the application runs. For example JIT can choose SSE2 CPU instructions when it detects that the CPU supports them. With a static compiler one must write two versions of the code, possibly using inline assembly.
The system is able to collect statistics about how the program is actually running in the environment it is in, and it can rearrange and recompile for optimum performance. However, some static compilers can also take profile information as input.
The system can do global code optimizations (e.g. inlining of library functions) without losing the advantages of dynamic linking and without the overheads inherent to static compilers and linkers. Specifically, when doing global inline substitutions, a static compiler must insert run-time checks and ensure that a virtual call would occur if the actual class of the object overrides the inlined method.
Although this is possible with statically compiled garbage collected languages, a bytecode system can more easily rearrange memory for better cache utilization.
I can't think of something related directly to the use of references instead of pointers.
In general speak, references make it possible to refer to the same object from different places.
A 'Pointer' is the name of a mechanism to implement references. C++, Pascal, C... have pointers, C++ offers another mechanism (with slightly other use cases) called 'Reference', but essentially these are all implementations of the general referencing concept.
So there is no reason why references are by definition faster/slower than pointers.
The real difference is in using a JIT or a classic 'up front' compiler: the JIT can data take into account that aren't available for the up front compiler. It has nothing to do with the implementation of the concept 'reference'.
Other answers are right.
I would only add that any optimization won't make a hoot of difference unless it is in code where the program counter actually spends much time, like in tight loops that don't contain function calls (such as comparing strings).
An object reference in a managed framework is very different from a passed reference in C++. To understand what makes them special, imagine how the following scenario would be handled, at the machine level, without garbage-collected object references: Method "Foo" returns a string, which is stored into various collections and passed to different pieces of code. Once nothing needs the string any more, it should be possible to reclaim all memory used in storing it, but it's unclear what piece of code will be the last one to use the string.
In a non-GC system, every collection either needs to have its own copy of the string, or else needs to hold something containing a pointer to a shared object which holds the characters in the string. In the latter situation, the shared object needs to somehow know when the last pointer to it gets eliminated. There are a variety of ways this can be handled, but an essential common aspect of all of them is that shared objects need to be notified when pointers to them are copied or destroyed. Such notification requires work.
In a GC system by contrast, programs are decorated with metadata to say which registers or parts of a stack frame will be used at any given time to hold rooted object references. When a garbage collection cycle occurs, the garbage collector will have to parse this data, identify and preserve all live objects, and nuke everything else. At all other times, however, the processor can copy, replace, shuffle, or destroy references in any pattern or sequence it likes, without having to notify any of the objects involved. Note that when using pointer-use notifications in a multi-processor system, if different threads might copy or destroy references to the same object, synchronization code will be required to make the necessary notification thread-safe. By contrast, in a GC system, each processor may change reference variables at any time without having to synchronize its actions with any other processor.