Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Can QScopedPointer be used as a static member?

    General and Desktop
    2
    8
    3469
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      Asperamanca last edited by

      Is the behavior for QScopedPointer defined when used as a static member? (Documented it is not).

      @
      class MyClass
      {
      private:
      static QScopedPointer<AnotherClass> sm_OtherClass;
      };
      @

      Once allocated, will QScopedPointer ensure sm_OtherClass will be deleted once the application terminates?

      1 Reply Last reply Reply Quote 0
      • A
        Asperamanca last edited by

        Initial tests reveal that it does work (Windows@Visual Studio 2010).

        The deleter of QScopedPointers is called within atexit.

        The question is: If this is cleanly implemented, why isn't it documented in the class description of QScopedPointer?

        1 Reply Last reply Reply Quote 0
        • G
          giesbert last edited by

          The more interesting question is: does it work on all platforms? and on all windows versions?

          A scoped pointer is mean to be used in a scope. Typically a scope is not the process end :-)
          Are you sure that deletion of the global object works in all cases on all pülatforms? windopws for example has clear restictions what you might use and what not before main is entered (or before and during DllMain).
          Everything that is not explicitly allowed, might work in 99.9% of the cases, but might also crash or do something else (= undefined behavior).

          Nokia Certified Qt Specialist.
          Programming Is Like Sex: One mistake and you have to support it for the rest of your life. (Michael Sinz)

          1 Reply Last reply Reply Quote 0
          • A
            Asperamanca last edited by

            A thread on stackoverflow suggested to use std::autoPtr. Since I consistently use Qt, I wondered whether I could use QScopedPointer instead.

            I am asking myself exactly the same questions you are asking. I can see that it works on my current platform, for my current compiler. Nothing more.

            Alternatively, what is a proper way to clean up static pointers? One thread suggests using atexit, which seems to e exactly what QScopedPointer is using. atexit is covered by the C++ standard

            From the 2003 version:

            bq. If a function is registered with atexit (see <cstdlib>, 18.3) then following the call to exit, any objects with static storage duration initialized prior to the registration of that function shall not be destroyed until the registered function is called from the termination process and has completed. For an object with static storage duration constructed after a function is registered with atexit, then following the call to exit, the registered function is not called until the execution of the object’s destructor has completed. If atexit is called during the construction of an object, the complete object to which it belongs shall be destroyed before the registered function is called.

            Link to the stackoverflow discussion:
            http://stackoverflow.com/questions/2429408/c-freeing-static-variables

            EDIT:
            It should be safe to use QScopedPointer in such a manner. According to the C++ standard

            bq. Destructors (12.4) for initialized objects of static storage duration (declared at block scope or at namespace scope) are called as a result of returning from main and as a result of calling exit

            The destructor for QScopedPointer does what I want.

            1 Reply Last reply Reply Quote 0
            • G
              giesbert last edited by

              That might be safe if you only create an executable. If you are inside a dll, it is not (not on Windows).
              Dlls on windows have some special behavior, which can be found in msdn (but I don't know exatcly where... :-( )

              Nokia Certified Qt Specialist.
              Programming Is Like Sex: One mistake and you have to support it for the rest of your life. (Michael Sinz)

              1 Reply Last reply Reply Quote 0
              • A
                Asperamanca last edited by

                Good point. Don't we all love dlls?

                1 Reply Last reply Reply Quote 0
                • G
                  giesbert last edited by

                  Have a look at the following link for more information:

                  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx

                  IIRC, global variables are created before DLLMain,and destroyed afterwards, but I'm not 100% sure...

                  Nokia Certified Qt Specialist.
                  Programming Is Like Sex: One mistake and you have to support it for the rest of your life. (Michael Sinz)

                  1 Reply Last reply Reply Quote 0
                  • G
                    giesbert last edited by

                    [quote author="Asperamanca" date="1360247282"]Good point. Don't we all love dlls?[/quote]

                    Sure, that's my daily business, I nearly never create an executable...

                    By the way, s copy from MSDN:

                    bq. If your DLL is linked with the C run-time library (CRT), the entry point provided by the CRT calls the constructors and destructors for global and static C++ objects. Therefore, these restrictions for DllMain also apply to constructors and destructors and any code that is called from them.

                    Nokia Certified Qt Specialist.
                    Programming Is Like Sex: One mistake and you have to support it for the rest of your life. (Michael Sinz)

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post