Deleting Pointers
-
On 07/11/2016 at 03:14, xxxxxxxx wrote:
Hi Scott,
you are not mistaken, the AutoAlloc (AutoFree, AutoMem...) functions are not available in the Melange SDK.
But perhaps you should take a step back.
Your questions and confusion have nothing to do with the Melange SDK (or any of the other MAXON SDKs).
Forget about AutoAlloc and unique pointers for a moment and try to look into the underlying basics. I'd really suggest to follow some of the links I provided in the "Create and insert material" thread and then use a search engine of your liking to dive a bit deeper into these topics. If the concepts of scope, local variable, heap and stack/call stack don't mean anything to you, it will be tedious (if not impossible) to discuss memory allocation, memory leaks or different pointer types.
For example are you aware, that your machine sees no difference between the following three variable definitions (on a modern 64-Bit machine)?UInt64 myUInt; void* myPtr; BaseObject* myOp;It really does not. Only the compiler applies some different rules, when working with these.
Lastly, I don't think, this is the right forum to learn/teach about programming basics. Sites as StackOverflow are probably way better suited for this and basically all answers to your questions have been discussed there already. Please, don't get me wrong, I really like to discuss with you, but these forums are dedicated to MAXON's SDKs and we are supposed to provide support for these, not for general programming or C++ questions.
Having said that, please go on in this thread to discuss these matters with the community, but please, don't expect the SDK Team to contribute. We will most likely do, if we see misinformation, but otherwise (and I really hope you don't mind) we are lacking the time to get into such topics.
-
On 07/11/2016 at 07:21, xxxxxxxx wrote:
Hi Andreas,
My only source of confusion was if there was another step beyond Freeing a pointer in the C4D SDK. Because in raw C++ there are ways to delete the pointer after it has been nulled. But in the SDK there doesn't appear to be. That's where I wanted some clarification.
Thanks to Remo. I now know that they get automatically deleted based on scope.-ScottA
-
On 07/11/2016 at 09:34, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Because in raw C++ there are ways to delete the pointer after it has been nulled.
It may be your wording, but this statement doesn't make any sense (to me). Would you show an example of what you mean?
It's important to understand that it's not the pointer you usually delete, but the memory that the pointer is pointing to.
Cheers,
Niklas -
On 07/11/2016 at 10:05, xxxxxxxx wrote:
Sure Niklas.
Here's an example from my notes.
I don't know where I picked up this code. But it must have been from either a tutorial or a Stack Overflow post:int x = 10; int *ptr = &x; //Manually delete the pointer //Probably not necessary. But the compiler will let me do it. delete ptr;The compiler won't let me delete an C4D SDK *pointer this way. Even after I use Free on it.
-ScottA
*Edit:
There is also gDelete(classPointer) in the C4D SDK. Which also made me wonder if I was also supposed to be manually deleting my *BaseObject, *BaseMaterial, etc. pointers.
But I'm guessing what gDelete() does is more akin to Free. Rather than delete. -
On 07/11/2016 at 15:44, xxxxxxxx wrote:
It doesn't clarify on the "after is has been nulled" part, actually that was the one which was most likely
making me think you might have a misconception in that regard.Anyway, regarding the snippet above, it is not just not necessary, it is actually invalid/illegal to delete the
pointer in that case, because it is not pointing to memory that you have previously allocated on the heap.The reason why the compiler will not let you delete pointers to BaseObject or the like is because the
destructors are (intentionally) marked as private. Also, you must only use delete on a pointer when you
know that it the memory it points to has been allocated with new.Same as with the destructor, the constructors of BaseObject etc. are also marked as private, that is why
you can not create an instance of these classes with new or on theheap*stack.gDelete() was available in the R15 SDK and earlier as a counterpart to gNew() which where both basically
the same as delete and new (respectively) but they are using the Cinema 4D's own memory management.Now the reason why the constructors and destructors of many of Cinema 4D's classes are marked private
and instead have Alloc() and Free() static functions is because of the way the C4D SDK is structured.
As you probably already know, all of the code of all the member functions in these classes is actually
implemented in Cinema 4D itself. There's a big structure in the C4D SDK that contains pointers to the
actual implementation of these methods and in the C4D SDK you can see that the methods that you
actually call just forward to these function pointers.Bool BaseContainer::operator == (const BaseContainer& c) const { return C4DOS.Bc->Compare(*this, c); }Best,
-Niklas -
On 07/11/2016 at 16:49, xxxxxxxx wrote:
Ok.
Thanks for the information Niklas.-ScottA
-
On 20/11/2016 at 06:30, xxxxxxxx wrote:
Using Melange. I think I'm forced to use Alloc and manage the memory manually.
No you are not forced to manage the memory manually !May be you can read about std::unique_ptr for example here:
http://shaharmike.com/cpp/unique-ptr/The behavior of AutoFree and Co. are mostly the same.
regards,
Remo -
On 20/11/2016 at 07:31, xxxxxxxx wrote:
I meant that I'm forced to handle them manually if I stick with using the SDK.
With Melange we end up in a sort of a bizzaro world of C4D development.
We get told repeatedly here by support not to use standard C++ stuff in our plugins. And that makes sense 99% of the time.
But using Melange it's all about making programs in outside applications. Instead of plugins hosted inside C4D. Which require using all of those bad things we are told not to use.
So we can't follow that rule of not using standard C++ stuff anymore.
But on the other hand. We do still need to follow the Melange SDK practices. So it becomes a challenging game of figuring out the best way to combine both things.
A tug of war.When using the Melange SDK. I kinda feel like a child of divorced parents(Standard & SDK).
I have to visit each one. But each one tells me not to use the other.-ScottA
-
On 21/11/2016 at 08:43, xxxxxxxx wrote:
Well, I find this perfectly reasonable and not very bizarro at all.
After all the C4D and the Melange SDK have two completely different purposes.A plugin obviously has to live inside of the Cinema 4D application and thus its application binary interface has to match and it should make use of the services provided by Cinema 4D.
Melange on the other hand is made to be used in other/stand-alone applications. So it doesn't come with its own memory management, but instead you use the one most suitable there. You can even tell Melange not to use "standard" memory management for its own allocations, but instead to use a custom memory management provided by the application it is used in.
-
On 21/11/2016 at 09:36, xxxxxxxx wrote:
Yes. But there are rules to this. And I don't have anyone looking over my shoulder warning me if I do something wrong.
And since we are constantly told not to use standard C++ here. Rather than told how to properly mix standard C++ with the SDK's. When we use Melange we are basically on our own.When I'm using Melange. I'm constantly wondering if I'm breaking some rule.
When I'm left on my own. I can invent some very cool things that should probably never be done.
I'm really excited about using Qt and Melange together. It's really fun to take full advantage of Qt's wonderful gui stuff, and also be able to target things for c4d.
I've written a couple of apps so far. But I think I've only begun to tap the potential there.
But it's also kinda scary without knowing much about the rules.
I hope Maxon keeps pushing Melange further. It's really been great fun using it with Qt.-ScottA
-
On 21/11/2016 at 09:54, xxxxxxxx wrote:
TL;DR the reason we are supposed not to use the standard
library is because Cinema does not use exception handling and
the majority of the C++ STL uses exceptions. You can use
exceptions in your plugins, but any exception reaching the
Cinema 4D loop will crash the app.In Melange, you're in your own environment and you are free to
use exceptions if you want to. Since no call in the Melange SDK
gets "out of your scope" you could for example (not a good
practice though) simply put abugbig try-catch block in your main()
function.Best,
-NiklasPS: Oh and BaseArray and HashMap are usually pretty fast
compared to vector and unordered_map. Some time ago there
was a thread with benchmarks of them compared to various
implementations of the STL containers.