Some questions regarding c++ class

  • On 23/03/2017 at 03:21, xxxxxxxx wrote:

    Thanks you Andreas !

    Another suggestion but again it's just a suggestion. And you won't believe me but I actually find an advantage from python sdk to the c++ one. :p
    It would be really nice like in the python sdk to have a state or when those functions where implemented.
    But it's a huge work for something we can directly check in API changes. But when you work is always good to have the informations directly and not to check another page.

    In the c++ sdk what does exactly mean "the owner own the pointer".
    Does it mean if I free the ressource linked to his it will also be delete for other?
    Or does I just own the pointer, so I can't set/delete the data but I can create a new one and replace the pointed data?

  • On 23/03/2017 at 10:57, xxxxxxxx wrote:


    actually we do mark updated functions in the C++ SDK as well. Unfortunately this wasn't done all times, so there are many without such marks. But a tleast for R17 or R18 you should see these. For example on VoronoiFracture class or BaseObject::FindBestEulerAngle() function it says "Since R18". And we'll of course continue with this in the future.

    Regarding ownership of objects, we had quite an extensive discussion (in a thread which "fortunately" was about a completely different topic...) : Create and insert material
    I recommend you check this thread and afterwards, if there are still open questions, then please open a new thread and we'll continue the discussion in there.

  • On 23/03/2017 at 14:06, xxxxxxxx wrote:

    Hoo yeah I didn't see thoses. You really make fantasric stuff at maxon and specialy you support guys ! :)

    Thanks for the topic it's very interesting and he probably should be stiky or at least be added to the Code style guide :)
    I guess I have to re-read it 2/3 time in a couple of week just to be sure to have fully understand it but it's nice. And moreover the difference beetwen AutoAlloc and Alloc shoud be more exposed (But Maybe it is like all my other questions in this thread :p).

    I just got a litlle question about this code

            //Create the empty material pointer
            BaseMaterial* mymat = nullptr;
            //Check if the material already exists
            mymat = doc->SearchMaterial("my mat");
            if (!mymat)
                myMat = BaseMaterial::Alloc(Mmaterial);
                if (!myMat)
                myMat->SetName("my mat");
                myMat->SetParameter(MATERIAL_COLOR_COLOR, Vector(1, 1, 0), DESCFLAGS_SET_0);
            // Here myMat is a valid pointer to your material
            // But remember, the owner of the material pointed to by myMat is C4D at this point
            // ...

    Then after passing the lead to c4d each time I will use my myMat pointer I have to check if it's not a nullptr? If yes that mean each time we saw c4d own the pointer we have to check if it's not a nullptr.

    Since the topic cover error checking and so on.
    What's the best way for cehcking if a function who must return a Vector (or Matrice or anything like that which is not a bool or pointer) fails.
    1 - Never do this but make them returning a pointer to this datatype. Like that I can return a nullptr in case of fail. (I guess it's this one ^^)
    2 - Add a bool / int pointer varible to my paramater. And in case of fail write some value to them. And after checking the value.
    3 - Maybe there is a better way? Is it possible to detect if variable is just initialized but not assigned?

    Anyway thanks you for everything it's a gold mine of informations !

  • On 24/03/2017 at 06:43, xxxxxxxx wrote:


    you check the pointer once, regardless, if you allocated the object yourself or received it from C4D (except cases where it is explicitly mentioned that the pointer can not be nullptr). This has nothing to do with ownership, but with memory allocations and chances of these failing.
    Then for example at the "// ..." point of your code you can rely on the object existing. But lets assume, Cinema 4D is the owner, as in your code example. Either you are running in main thread or you are running in threaded context. In first case there's no one, who could delete the object (remember scene changes only from main thread, as stated everywhere). And in the later case, somebody wanting to delete the object would need to call stop all threads before modifying the scene.
    So there's nothing to be afraid of, if Cinema own a certain object.

    Regarding your last compound of questions, I'm not sure I understand and furthermore I'm not sure we are not leaving the area of C4D SDK related questions. In general there are many ways to achieve things in C++. And maybe references should also be considered in this group of questions.

  • On 24/03/2017 at 08:33, xxxxxxxx wrote:

    The material creation code you posted is basically the smallest amount of code you can use to create a material. It will work in most typical use cases. But it's really just the base starting point.
    If you do anything more complex than creating a material(it's hard to give you an example).  Then using smart pointers like AutoAlloc can be very helpful in keeping your code safe from accidental memory leaks.
    This will very often not be needed if you do simple common tasks that the SDK was designed for.
    But if you start doing complex things that the are not the norm. Then smart pointers become much more important to use. Since you can't always think of every single way the code can fail while it's still holding onto some memory.
    That's really what the overall message of that thread is.

    IMO. The most important tool the C4D SDK has for new C++ users is the Debug tool (not the one inside of VS).
    It makes a command window open when running C4D from VS. And when you close C4D. It will list out any memory leaks you have created in your code.
    When I started out, I was new to C++ and writing lots of BaseBitmap code. Which often does not get owned by C4D. And I was not using the debug tool.
    When I finally used it. I discovered that I had lots of memory leaks in my code that I didn't know about.
    So my advice is to use that tool every time you write a C++ plugin. If nothing else. Just for peace of mind that you didn't accidentally miss something.


  • On 24/03/2017 at 08:45, xxxxxxxx wrote:

    Good point, Scott. We actually call it the debug mode.
    And we have an article on debugging also showing how to activate this debug mode.

  • On 27/03/2017 at 01:59, xxxxxxxx wrote:

    Thanks you both it's very helpfull.
    Sadly I didn't succely lunch C4D with his white console in debug mode, while I succefully get it lunched via cmd.
    I currently use R17 and this is my configuration for arguments.

    -debug g_console=true

    Btw I don't really understand what the difference beetween g_alloc=debug and -debug. Using the cmd for lunching the litlle debug console. That said me Release or Debug.
    What the prefered one? Or should I choose one and don't care? :)

    Another question but I guess it's related to how tool behave with toolData plugin.
    But why this function is overloaded in the header of exemple project? Should I let it or not?

    Bool AddUndo(BaseDocument* doc, AtomArray* arr, UNDOTYPE type);

  • On 27/03/2017 at 08:41, xxxxxxxx wrote:

    I personally find the documentation for setting up the debugging a bit hard to understand. Because the command line setup is sandwiched in the middle of setting up the VS debugger.
    I find this to be confusing. Especially for people new to C++ and VS.

    In R13. There are two ways I can set up the VS debugger with the pop up command window:
    In configuration properties Debugging
      -Set Command to:            C:\Program Files\MAXON\CINEMA 4D R13\CINEMA 4D.exe
      -Set Working Directory to: C:\Program Files\MAXON\CINEMA 4D R13\
    Put an empty c4d_debug.txt file in the MAXON\R13 folder where the .exe files are

    In configuration properties Debugging
      -Set Command to:             C:\Program Files\MAXON\CINEMA 4D R13\CINEMA 4D.exe
      -Set Working Directory to:  Leave this empty
    Put your empty c4d_debug.txt file in the plugin's folder

    I could be wrong about this.
    But AFAIK. The -debug g_console=true thing a separate subject.
    It's a different way to debug using the command line. And should not be mixed into the VS instructions. And should be done after you have the VS debugger figured out and working.


  • On 27/03/2017 at 09:35, xxxxxxxx wrote:


    @gr4ph0s: I really think for the ToolData question you should open a separate thread, otherwise this thread will derail completely.

    -debug in general enables the debug mode, providing for example certain warnings.
    g_alloc=debug on the other hand sets the C4D's memory allocator into debug mode, providing you with nice features like a leak report, when quitting C4D.

    @gr4ph0s: I'm not sure I understand the questions after "Using the cmd for launching...". Who's saying what? And prefers whom? Probably you will need to care, but please try to explain the questions to me once more.

    @Scott: Nope, I wouldn't regard this different topics. You can set the command line options in VS (Project Properties->Debugging). And you'll get the output in VS's Output window, no need for a dedicated command line window.

    And for future readers, since R15 there's no need anymore for the c4d_debug.txt file, Scott is talking about.

  • On 27/03/2017 at 09:58, xxxxxxxx wrote:

    LOL. I'm falling so far behind with the changes that I'm starting to feel out dated.
    Grampa Scott says: "Back in my day. We used an empty .txt file to debug. And we walked to school barefoot...uphill....both ways. And we liked it that way." 😂


  • On 27/03/2017 at 12:10, xxxxxxxx wrote:

    Ok I will open new thread after some time cause I'm sure it's something I miss in the sdk, and I don't really dive into it for the moment.

    Here is my project setting for debugging. I can succefully lunch it in debug mode, but I don't get the console.

    By lunching it via cmd I succefully get the maxon console.
    "C:\Program Files\MAXON\CINEMA 4D R17_dev\CINEMA 4D.exe" g_alloc=debug g_console=true

    Haha maybe you are old but you got the knowledge then who care?
    The .txt method worked but I really prefer to use the maxon's console  :p

  • On 27/03/2017 at 23:42, xxxxxxxx wrote:


    Scott, you made my day (and it's just 8:37 around here) 🙂
    Maybe we should compare our mileage one day (of course in secrecy, otherwise the rest of the community probably starts making fun of the elder)? Or we could have an old people's home sub-forum, where we discuss the APIs of early releases?

    @gr4ph0s: When running in debugger, the VS output window takes over the role of the command line window.

Log in to reply