Non-GCed types
BlitzMax Forums/BlitzMax Programming/Non-GCed types
| ||
| Since more than 75% of my types have to be manually freed due to circular references, why not allow an option for types to not use GC? It would lighten the load of the garbage collector and give more control to the programmer. Then you could use the garbage collector for types it was appropriate for, like vectors and small structures, and you wouldn't waste the cycles on types the programmer will have to manually free anyways. It would give the best of both worlds. |
| ||
| +1 for that. It's a thing I like about C++, to have total control over your objects. Would be nice if it could be added. Not sure if it's possible though. |
| ||
| Not sure if it's possible though. There's already a NoDebug option on functions isn't there? So a NoGC should go along similar lines, and sounds like a sensible idea to me... |
| ||
| As in a conditional compiler flag? That would work well for the programmer... |
| ||
| It sounds like asking for trouble. |
| ||
| I am suggesting something like this: Type foo {nogc=1} EndType This type would not get managed by the garbage collector. To delete a "foo": foo.Delete() |
| ||
| The ambiguity and unnecessary trouble this would introduce isn't worth it. |
| ||
| The ambiguity and unnecessary trouble this would introduce isn't worth it. The (standard) GC is never going to free these objects as they are self-referencing. Being able to tell the GC to just not bother might conceivably yield some (small) performance improvement. Now if that performance improvement is insignificant (it may be as standard GC is just a bean counter), then you're right. But there could be mileage here. Any potential inconvenience is on the head of the person that uses it, and that inconvenience will be memory leaks, that if they have an ounce of sense they will start looking at the memory they are managing themselves! |
| ||
| The (standard) GC is never going to free these objects as they are self-referencing. Being able to tell the GC to just not bother might conceivably yield some (small) performance improvement. It would be better if BMax had weak references to handle scenarios where cyclic references could occur (or if BMax just handled cyclic references correctly). |
| ||
| I don't see how it would be any more difficult if the type already has to be manually freed. Almost all my types have a Free() method where they unlink all their references. The question is whether relieving the garbage collector of 75% of the objects would make any difference. |
| ||
| Because you're mixing garbage collection with regular memory management. It becomes much more confusing when you have to continually check which objects you have to free manually and which you have to disconnect for the GC. |
| ||
| I already have to do that in every application I write. Circular references are impossible to avoid except in very simple programs. |
| ||
| Circular references are impossible to avoid except in very simple programs. Well, that's certainly not true. This is mostly down to "bad design". |
| ||
| That is not so. Show me how to make an entity class where the children can return the parent, the world can access every entity, and the parent can access the children. All of these linkages are necessary. |
| ||
| Ideally, the reference the children have of the parent would be a weak reference. I could probably do this using the threaded GC (it has a fairly simple way to designate a pointer as weak), but I don't think it's possible to do it with the regular GC without going in and storing a list of weak references to nullify when an object is collected, and even then it would have to have a weak reference assigned in the constructor of the object, so it wouldn't be automatic. |
   |