global memory allocation and STL



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 15/08/2008 at 05:16, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:   10.506 
    Platform:   Windows  ;   
    Language(s) :     C++  ;

    ---------
    What is the status on global memory allocation and STL? I've got some problems using STL in my compiled libraries and it looks like it is due to the runtime allocating objects before the C4DOS is initialized, causing a crash in the STL deallocation. I found an old workaround here

    Has there been any updates in this aspect since version 8 and is this still the recommended workaround?

    Thanks,
    Marodern



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 19/08/2008 at 02:48, xxxxxxxx wrote:

    no input anyone?



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 19/08/2008 at 09:49, xxxxxxxx wrote:

    I don't do global memory allocations or use the STL in the C4D C++ SDK. I suspect that the workaround is still valid and required to avoid these problems unless there is an official response here.



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 21/08/2008 at 01:32, xxxxxxxx wrote:

    Note: regarding global allocations

    Allowed are elementary data types and data types that don't need to be allocated (LONG, Real, CHAR, GE_SPINLOCK etc.).

    Any other SDK data type cannot be placed in the global scope.

    cheers,
    Matthias



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 21/08/2008 at 10:44, xxxxxxxx wrote:

    Hi Marodern,
    Fwiw, I use a pretty simple template  to deal with global objects, C4D or otherwise:

        
        
        
        
        template<typename T>  
        struct lazy_ptr  
        {    
            typedef T  type;  
            typedef T* pointer;  
            typedef T& reference;
        
        
        
        
            lazy_ptr<T>(void) : t(0) {  
                }  
            void free(void) {  
                gDelete(t);  
                }  
            pointer get(void) {  
                if (!t) t = gNew type();  
                return t;  
                }  
            pointer operator ->(void) {  
                return get();  
                }  
            reference operator &(void) {  
                return *get();  
                }  
            reference operator *(void) {  
                return *get();  
                }    
        
        
        
        
        private:  
            pointer t;     
        };
        
        
        
    

    It sure would be nice to be able to overload '.' in this case, but as it is you just have to use '->' for direct member selection on the contained type. As far as I've found, it is safe to clean up by calling lazy_ptr::free() for all types of T in PluginEnd().
    Cheers,
    JD


Log in to reply