Thank you for your attention. I'm new to some VS2013 code which is a mixture of C++ plus some microsoft specific extensions. The code has a class like
ref class Foo {
Bar^ bar_; // somewhere else, bar_ = gcnew Bar...
};
Now I'd need to add an unmanaged member, from online search it seems like I can do
ref class Foo {
Bar ^ bar_;
Unmanaged* ptr_; // somewhere else, ptr = new Unmanaged();
~Foo() {
this->!Foo();
}
!Foo() {
delete ptr_;
// do I need anything to deal with bar_?
}
};
The questions are:
1) is this finalizer/destructor the way to go?
2) do I need to write anything extra for bar_ now that I'm explicitly writing the finalizer/destructor?
3) are there cleaner way to do it?
1) is this finalizer/destructor the way to go?
Yes.
2) do I need to write anything extra for bar_
Nothing that is obvious from the snippets. But if the Bar class is disposable as well then you probably ought to add delete bar_; to the destructor. Not to the finalizer. And not if you passed the reference to other code so you can't be sure that this reference is the last one still using the Bar object.
3) are there cleaner way to do it?
No. There are other ways to do it. You could for example consider to not add the destructor. Having one gives the code that uses the class the burden of calling it. Typically that would be C# or VB.NET code, it would have to use the using statement or call Dispose() explicitly. Keep in mind that they often forget. Or don't have a good way to call it.
If such code is not expected to create a lot of instances of Foo and the Unmanaged class merely uses a bit of memory then the finalizer might well be good enough. Or if the Foo object is expected to live for the lifetime of the app, pretty common, then disposing is pointless. Even if it does use a lot of memory then GC::AddMemoryPressure() is a pretty nice alternative. Makes your class easier to use.
And you could consider wrapping the Unmanaged pointer in its own class so Foo doesn't need a finalizer anymore. Along the pattern of the SafeHandle classes in .NET, SafeBuffer is the closest match. That tends to be overkill however in a C++/CLI wrapper, delete failure in particular is nothing you want to hide.
But what you have gets the job done.
Related
Is it possible to create an object that can register whether the current thread leaves the method where it was created, or to check whether this has happened when a method on the instance gets called?
ScopeValid obj;
void Method1()
{
obj = new ScopeValid();
obj.Something();
}
void Method2()
{
Method1();
obj.Something(); //Exception
}
Can this technique be accomplished? I would like to develop a mechanism similar to TypedReference and ArgIterator, which can't "escape" the current method. These types are handled specially by the compiler, so I can't mimic this behavior exactly, but I hope it is possible to create at least a similar rule with the same results - disallow accessing the object if it has escaped the method where it was created.
Note that I can't use StackFrame and compare methods, because the object might escape and return to the same method.
Changing method behavior based upon the source of the call is a bad design choice.
Some example problems to consider with such a method include:
Testability - how would you test such a method?
Refactoring the calling code - What if the user of your code just does an end run around your error message that says you can't do that in a different method than it was created? "Okay, fine! I'll just do my bad thing in the same method, says the programmer."
If the user of your code breaks it, and it's their fault, let it break. Better to just document your code with something like:
IInvalidatable - Types which implement this member should be invalidated with Invalidate() when you are done working with this.
Ignoring the obvious point that this almost seems like is re-inventing IDisposible and using { } blocks (which have language support), if the user of your code doesn't use it right, it's not really your concern.
This is likely technically possible with AOP (I'm thinking PostSharp here), but it still depends on the user using your code correctly - they would have to have it in the build process, and failing to function if they aren't using a tool just because you're trying to make it easy on them is evil.
Another point - If you are just attempting to create an object which cannot be used outside of one method, and any attempted operation outside of the method would fail, just declare it a local inside the method.
Related: How to find out which assembly handled the request
Years laters, it seems this feature was finally added to C# 7.2: ref struct.
Another related language feature is the ability to declare a value type that must be stack allocated. In other words, these types can never be created on the heap as a member of another class. The primary motivation for this feature was Span and related structures. Span may contain a managed pointer as one of its members, the other being the length of the span. It's actually implemented a bit differently because C# doesn't support pointers to managed memory outside of an unsafe context. Any write that changes the pointer and the length is not atomic. That means a Span would be subject to out of range errors or other type safety violations were it not constrained to a single stack frame. In addition, putting a managed pointer on the GC heap typically crashes at JIT time.
This prevents the code from moving the value to the heap, which partly solves my original problem. I am not sure how returning a ref struct is constrained, though.
In some code reviews of legacy c# code i've been doing recently I've seen a number of examples like this:
class ManagerParentClass
{
public string CustomProperty{get;set;}
public void Log(string message);
void DoABunchOfTasks()
{
new SomethingService().DoSomething(this);
}
}
with the following:
public class SomethingService
{
ManagerParentClass _manager;
void DoSomething(ManagerParentClass manager)
{
_manager = manager;
// do something
_manager.CustomProperty = "hello world";
_manager.Log("said hello world");
}
}
While this works fine on the surface, I'm concerned that this is a bit of an anti-pattern that may cause evil things with garbage collection.
Will this break the generational garbage collector in .Net's ability to clean the parent and child objects up properly or anything else negative?
Oh yes, this is a terrible anti-pattern in general. I work with a code base that uses this a lot and it is sheer madness.
The biggest offense? Violation of encapsulation and the tight coupling between the classes that comes with it: SomethingService knows too much about ManagerParentClass, and ManagerParentClass gives up control of itself to SomethingService.
Two better alternatives:
Make DoSomething() an instance method of ManagerParentClass, this is in closer keeping with an essential point of object orientation: data structures carry their operators
Make SomethingService a pure method that does some calculation and returns a value, the caller may then make the assignment to the ManagerParentClass
Of course, both of these refactorings involve an end-game mutation of ManagerParentClass, and coming from a functional programming angle, I would try to avoid that altogether. But without more information, I can't recommend a course for that.
This is actually a decent way of de-coupling classes from each other - what you've written looks a lot like the visitor pattern.
Your example as written doesn't have much of a memory impact at all, because SomethingService doesn't hold onto ManagerParentClass except for the length of that method. If we were to assume instead that SomethingService would save such an instance during construction or regular methods, then it's slightly more complicated.
Having SomethingService hold a reference to ManagerParentClass means that ManagerParentClass is going to be held in reference 1) as long as SomethingService is held in memory through some chain of references that lead back to a GC root and 2) as long as SomethingService maintains its reference to MPC.
If SS were to release its reference (null it out), then problem solved. If SS were itself to no longer be referenced by anything, then the GC will know that SS can be GCd, and if MPC is then only held by SS, then MPC can be in turn GCd.
I've been looking for this info for a loooong time. Never seen anyone asking stuff like this before.
I know that we can use pointer in C# inside unsafe code, but thats not the case.
The problem is:
MyClass beta = new MyClass();
MyClass alpha = beta;
beta = null;
What I need to do now is set beta to null and ALSO set alpha to null.
Let's say that i have returned alpha in a function, so I dont have access to it anymore, so, how can I set it to null?
In c++ if beta and alpha were pointer I could just free the memory that beta points to, but I dont know a way to do that in c#.
In a more basic way, lets say that I have to set both variables to null, but i have acces only to one of them.
Edit
I did see some answers that have nothing to deal with the question i did... Ill try to explain again.
I'm creating a class that do some motion effect and return a instance that can be used to pause or stop this motion.
The programmers that use this class are used to test variables with if(variable != null) before using it.
What i need is when the motion is over the instance they have is turned into null, so they know that its not usefull anymore.
Is there any way of doing it?
You need to add an additional layer of indirection. To put things in C++ terms, MyClass is a pointer to an object, so to set both pointers to null you need to be passing around pointers to pointers instead, so that you can resolve the pointer to pointer to just a pointer, set that to null, and both double pointers will resolve to null.
Adding an extra layer of indirection in C# usually means creating a new class.
public class Wrapper<T>
{
public T Value { get; set; }
}
Using that, we can make alpha and beta each be Wrapper<MyClass> objects (make sure they are both the same instance of Wrapper), and to affect both "pointers" you can just set Value of the Wrapper to null.
Unless your class contains a disposable object there isn't a need to Dispose of the object, and setting it to null simply makes the object null which doesn't free memory but instead would help if you need to check the object later...
If your class needs to be marked as disposable because it needs to clean up it's memory usage please look into making your class inherit from the IDisposable! interface.
If you need to get some sort of AV/exception (to match C++ behavior of accessing deleted object) the closest you can get is make object IDisposable and make all methods/properties to thrown after object is disposed (similar to how Stream-derived objects behave).
MyClass beta = new MyClass();
MyClass alpha = beta;
beta.Dispose();
alpha.Method(); // should throw ObjectDisposedException.
You don't need to do either. C# memory is automatically managed, so things get freed when there are no more references to them. If you specifically want to free something because you've caught an OutOfMemoryException, then yes, you can start setting things to null and forcing the garbage collector as #JanesAbouChleih points out. It is much better to call the .Dispose method and implement any other clean up code MyClass may require (closing files, flushing buffers, etc.).
Some references:
http://msdn.microsoft.com/en-us/magazine/bb985010.aspx
http://msdn.microsoft.com/en-us/library/ms973837.aspx
Also, similar question on how/when/why to dispose things: Do you need to dispose of objects and set them to null?
I have a piece of software written with fluent syntax. The method chain has a definitive "ending", before which nothing useful is actually done in the code (think NBuilder, or Linq-to-SQL's query generation not actually hitting the database until we iterate over our objects with, say, ToList()).
The problem I am having is there is confusion among other developers about proper usage of the code. They are neglecting to call the "ending" method (thus never actually "doing anything")!
I am interested in enforcing the usage of the return value of some of my methods so that we can never "end the chain" without calling that "Finalize()" or "Save()" method that actually does the work.
Consider the following code:
//The "factory" class the user will be dealing with
public class FluentClass
{
//The entry point for this software
public IntermediateClass<T> Init<T>()
{
return new IntermediateClass<T>();
}
}
//The class that actually does the work
public class IntermediateClass<T>
{
private List<T> _values;
//The user cannot call this constructor
internal IntermediateClass<T>()
{
_values = new List<T>();
}
//Once generated, they can call "setup" methods such as this
public IntermediateClass<T> With(T value)
{
var instance = new IntermediateClass<T>() { _values = _values };
instance._values.Add(value);
return instance;
}
//Picture "lazy loading" - you have to call this method to
//actually do anything worthwhile
public void Save()
{
var itemCount = _values.Count();
. . . //save to database, write a log, do some real work
}
}
As you can see, proper usage of this code would be something like:
new FluentClass().Init<int>().With(-1).With(300).With(42).Save();
The problem is that people are using it this way (thinking it achieves the same as the above):
new FluentClass().Init<int>().With(-1).With(300).With(42);
So pervasive is this problem that, with entirely good intentions, another developer once actually changed the name of the "Init" method to indicate that THAT method was doing the "real work" of the software.
Logic errors like these are very difficult to spot, and, of course, it compiles, because it is perfectly acceptable to call a method with a return value and just "pretend" it returns void. Visual Studio doesn't care if you do this; your software will still compile and run (although in some cases I believe it throws a warning). This is a great feature to have, of course. Imagine a simple "InsertToDatabase" method that returns the ID of the new row as an integer - it is easy to see that there are some cases where we need that ID, and some cases where we could do without it.
In the case of this piece of software, there is definitively never any reason to eschew that "Save" function at the end of the method chain. It is a very specialized utility, and the only gain comes from the final step.
I want somebody's software to fail at the compiler level if they call "With()" and not "Save()".
It seems like an impossible task by traditional means - but that's why I come to you guys. Is there an Attribute I can use to prevent a method from being "cast to void" or some such?
Note: The alternate way of achieving this goal that has already been suggested to me is writing a suite of unit tests to enforce this rule, and using something like http://www.testdriven.net to bind them to the compiler. This is an acceptable solution, but I am hoping for something more elegant.
I don't know of a way to enforce this at a compiler level. It's often requested for objects which implement IDisposable as well, but isn't really enforceable.
One potential option which can help, however, is to set up your class, in DEBUG only, to have a finalizer that logs/throws/etc. if Save() was never called. This can help you discover these runtime problems while debugging instead of relying on searching the code, etc.
However, make sure that, in release mode, this is not used, as it will incur a performance overhead since the addition of an unnecessary finalizer is very bad on GC performance.
You could require specific methods to use a callback like so:
new FluentClass().Init<int>(x =>
{
x.Save(y =>
{
y.With(-1),
y.With(300)
});
});
The with method returns some specific object, and the only way to get that object is by calling x.Save(), which itself has a callback that lets you set up your indeterminate number of with statements. So the init takes something like this:
public T Init<T>(Func<MyInitInputType, MySaveResultType> initSetup)
I can think of three a few solutions, not ideal.
AIUI what you want is a function which is called when the temporary variable goes out of scope (as in, when it becomes available for garbage collection, but will probably not be garbage collected for some time yet). (See: The difference between a destructor and a finalizer?) This hypothetical function would say "if you've constructed a query in this object but not called save, produce an error". C++/CLI calls this RAII, and in C++/CLI there is a concept of a "destructor" when the object isn't used any more, and a "finaliser" which is called when it's finally garbage collected. Very confusingly, C# has only a so-called destructor, but this is only called by the garbage collector (it would be valid for the framework to call it earlier, as if it were partially cleaning the object immediately, but AFAIK it doesn't do anything like that). So what you would like is a C++/CLI destructor. Unfortunately, AIUI this maps onto the concept of IDisposable, which exposes a dispose() method which can be called when a C++/CLI destructor would be called, or when the C# destructor is called -- but AIUI you still have to call "dispose" manually, which defeats the point?
Refactor the interface slightly to convey the concept more accurately. Call the init function something like "prepareQuery" or "AAA" or "initRememberToCallSaveOrThisWontDoAnything". (The last is an exaggeration, but it might be necessary to make the point).
This is more of a social problem than a technical problem. The interface should make it easy to do the right thing, but programmers do have to know how to use code! Get all the programmers together. Explain simply once-and-for-all this simple fact. If necessary have them all sign a piece of paper saying they understand, and if they wilfully continue to write code which doesn't do anythign they're worse than useless to the company and will be fired.
Fiddle with the way the operators are chained, eg. have each of the intermediateClass functions assemble an aggregate intermediateclass object containing all of the parameters (you mostly do it this was already (?)) but require an init-like function of the original class to take that as an argument, rather than have them chained after it, and then you can have save and the other functions return two different class types (with essentially the same contents), and have init only accept a class of the correct type.
The fact that it's still a problem suggests that either your coworkers need a helpful reminder, or they're rather sub-par, or the interface wasn't very clear (perhaps its perfectly good, but the author didn't realise it wouldn't be clear if you only used it in passing rather than getting to know it), or you yourself have misunderstood the situation. A technical solution would be good, but you should probably think about why the problem occurred and how to communicate more clearly, probably asking someone senior's input.
After great deliberation and trial and error, it turns out that throwing an exception from the Finalize() method was not going to work for me. Apparently, you simply can't do that; the exception gets eaten up, because garbage collection operates non-deterministically. I was unable to get the software to call Dispose() automatically from the destructor either. Jack V.'s comment explains this well; here was the link he posted, for redundancy/emphasis:
The difference between a destructor and a finalizer?
Changing the syntax to use a callback was a clever way to make the behavior foolproof, but the agreed-upon syntax was fixed, and I had to work with it. Our company is all about fluent method chains. I was also a fan of the "out parameter" solution to be honest, but again, the bottom line is the method signatures simply could not change.
Helpful information about my particular problem includes the fact that my software is only ever to be run as part of a suite of unit tests - so efficiency is not a problem.
What I ended up doing was use Mono.Cecil to Reflect upon the Calling Assembly (the code calling into my software). Note that System.Reflection was insufficient for my purposes, because it cannot pinpoint method references, but I still needed(?) to use it to get the "calling assembly" itself (Mono.Cecil remains underdocumented, so it's possible I just need to get more familiar with it in order to do away with System.Reflection altogether; that remains to be seen....)
I placed the Mono.Cecil code in the Init() method, and the structure now looks something like:
public IntermediateClass<T> Init<T>()
{
ValidateUsage(Assembly.GetCallingAssembly());
return new IntermediateClass<T>();
}
void ValidateUsage(Assembly assembly)
{
// 1) Use Mono.Cecil to inspect the codebase inside the assembly
var assemblyLocation = assembly.CodeBase.Replace("file:///", "");
var monoCecilAssembly = AssemblyFactory.GetAssembly(assemblyLocation);
// 2) Retrieve the list of Instructions in the calling method
var methods = monoCecilAssembly.Modules...Types...Methods...Instructions
// (It's a little more complicated than that...
// if anybody would like more specific information on how I got this,
// let me know... I just didn't want to clutter up this post)
// 3) Those instructions refer to OpCodes and Operands....
// Defining "invalid method" as a method that calls "Init" but not "Save"
var methodCallingInit = method.Body.Instructions.Any
(instruction => instruction.OpCode.Name.Equals("callvirt")
&& instruction.Operand is IMethodReference
&& instruction.Operand.ToString.Equals(INITMETHODSIGNATURE);
var methodNotCallingSave = !method.Body.Instructions.Any
(instruction => instruction.OpCode.Name.Equals("callvirt")
&& instruction.Operand is IMethodReference
&& instruction.Operand.ToString.Equals(SAVEMETHODSIGNATURE);
var methodInvalid = methodCallingInit && methodNotCallingSave;
// Note: this is partially pseudocode;
// It doesn't 100% faithfully represent either Mono.Cecil's syntax or my own
// There are actually a lot of annoying casts involved, omitted for sanity
// 4) Obviously, if the method is invalid, throw
if (methodInvalid)
{
throw new Exception(String.Format("Bad developer! BAD! {0}", method.Name));
}
}
Trust me, the actual code is even uglier looking than my pseudocode.... :-)
But Mono.Cecil just might be my new favorite toy.
I now have a method that refuses to be run its main body unless the calling code "promises" to also call a second method afterwards. It's like a strange kind of code contract. I'm actually thinking about making this generic and reusable. Would any of you have a use for such a thing? Say, if it were an attribute?
What if you made it so Init and With don't return objects of type FluentClass? Have them return, e.g., UninitializedFluentClass which wraps a FluentClass object. Then calling .Save(0 on the UnitializedFluentClass object calls it on the wrapped FluentClass object and returns it. If they don't call Save they don't get a FluentClass object.
In Debug mode beside implementing IDisposable you can setup a timer that will throw a exception after 1 second if the resultmethod has not been called.
Use an out parameter! All the outs must be used.
Edit: I am not sure of it will help, tho...
It would break the fluent syntax.
I have various classes that wrap an IntPtr. They don't store their own data (other than the pointer), but instead use properties and methods to expose the data at the pointer using an unmanaged library. It works well, but I've gotten to the point where I need to be able to refer to these wrapper objects from other wrapper objects. For example:
public class Node {
private IntPtr _ptr;
public Node Parent {
get { return new Node(UnmanagedApi.GetParent(_ptr)); }
}
internal Node(IntPtr ptr) {
_ptr = ptr;
}
}
Now, I can simply return a new Node(parentPtr) (as above), but there is the potential for having tens of thousands of nodes. Wouldn't this be a bad idea, since multiple wrapper objects could end up referring to the same IntPtr?
What can I do to fix this? I thought about using a static KeyedCollection class that uses each IntPtr as the key. So, instead of returning a new Node each time, I can just look it up. But that would bring up threading issues, right?
Is there a better way?
The biggest problem I can see is who is responsible for deleting the objects referred to by the pointer?
Reusing the same object is not necessarily a threading issue, although if you are responsible for calling delete on the unmanaged objects you'll need to implement some sort of reference counting in your objects.
Using multiple objects with the same pointer might be easier if your objects are read-only. If they have state that can be changed then you'll need to understand the impact of making a change if multiple objects hold a pointer to that state.
You might also want to look at C++/CLI (managed C++) to provide a layer between the C# and unmanaged library and do the hard work of translation/manipulation in there and provide a simpler API for the C# to work with.
This whole code doesn't look right.
Your use of the GetParent function seems to imply that you have a tree-like structure. Let me make a few guesses about your code, they could be wrong.
You want to make extensive use of the UnmanagedAPI and don't want to duplicate this code in your .NET code.
You simply want to make sure you don't end up with memory problems by accessing your unamaged code.
I would suggest that instead of creating .NET code on a node-by-node basis, you create a .NET wrapper for the entire tree/graph structure and provide a .NET API that may pass unmanaged API pointers as arguments, but handles strictly the allocation/deallocation so that you avoid memory problems. This will avoid the unnecessary allocation of a new memory structure simply to allocate something that already exists, i.e. the GetParent function.
I had a related issue. Deleting unmanaged objects was done explicitly. So what I did was making a base class for all wrappers that contained static dictionary for available wrappers instances. Objects were added to dictionary in constructor and deleted in WrapperBase.Delete() method. Note that it is important to have explicit Delete() method for such approach - otherwise GC will never free wrappers instances because of references from static dictionary.