P/Invoke tries to make your life easier by automatically converting (“marshalling”) data types from managed code to native code and the other way around.
In my last job interview I got a (rather vague) question about traversing a tree and operating on the tree nodes. I think I’ve a lot of experience in programming but I couldn’t figure out the answer on my own. The answer the guy wanted to hear was: visitor pattern.
I had never heard of it before. So, in preparation for my next job interview, I thought I take a look at it.
While trying to figure it out, I stumbled over this quote:
The Visitor pattern is possibly the most complicated design pattern you will face. (Source)
I totally agree. (And this is probably why I’ve never heard or used it before.)
But since I’m not a quitter I went on and tamed it. So, in this article I’m going to shed some light on this mysterious design pattern.
Sometimes a C/C++ function needs to store data you pass to it for later reference. If such data is a managed object (like a
class) you need to make sure that the garbage collector doesn’t delete it while it’s still used/stored in the native code.
That’s what pinning is for. It prevents the garbage collector from deleting and moving the object.
Security is hard. In a current project I saw some code that created some access tokens based on a random number generator – .NET’s
Random class. The code used an instance of
Random stored in
static field and I got curious:
If you have such a long living
Randominstance, could you predict the random values after generating a few of them?
It turns out, it is possible. And you only need to read 56 55 “random” values to predict all future values.