1. 22 May, 2019 1 kayıt (commit)
  2. 20 May, 2019 1 kayıt (commit)
  3. 29 Kas, 2018 1 kayıt (commit)
  4. 05 Eyl, 2018 1 kayıt (commit)
  5. 11 Ara, 2017 1 kayıt (commit)
  6. 01 Şub, 2017 1 kayıt (commit)
  7. 28 Ock, 2017 1 kayıt (commit)
  8. 26 Ock, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Remove dynamic exception specifications · e57ca028
      Stephan Bergmann yazdı
      ...(for now, from LIBO_INTERNAL_CODE only).  See the mail thread starting at
      <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
      "Dynamic Exception Specifications" for details.
      
      Most changes have been done automatically by the rewriting loplugin:dynexcspec
      (after enabling the rewriting mode, to be committed shortly).  The way it only
      removes exception specs from declarations if it also sees a definition, it
      identified some dead declarations-w/o-definitions (that have been removed
      manually) and some cases where a definition appeared in multiple include files
      (which have also been cleaned up manually).  There's also been cases of macro
      paramters (that were used to abstract over exception specs) that have become
      unused now (and been removed).
      
      Furthermore, some code needed to be cleaned up manually
      (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
      configurations available that would actually build that code.  Missing @throws
      documentation has not been applied in such manual clean-up.
      
      Change-Id: I3408691256c9b0c12bc5332de976743626e13960
      Reviewed-on: https://gerrit.libreoffice.org/33574Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      e57ca028
  9. 02 Ara, 2016 1 kayıt (commit)
  10. 13 Eyl, 2016 1 kayıt (commit)
    • Stephan Bergmann's avatar
      loplugin:override: No more need for the "MSVC dtor override" workaround · 91dd2db1
      Stephan Bergmann yazdı
      The issue of 362d4f0c "Explicitly mark
      overriding destructors as 'virtual'" appears to no longer be a problem with
      MSVC 2013.
      
      (The little change in the rewriting code of compilerplugins/clang/override.cxx
      was necessary to prevent an endless loop when adding "override" to
      
        OOO_DLLPUBLIC_CHARTTOOLS    virtual ~CloseableLifeTimeManager();
      
      in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
      OOO_DLLPUBLIC_CHARTTOOLS macro.  Can't remember what that
      isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
      
      Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
      91dd2db1
  11. 12 Eyl, 2016 1 kayıt (commit)
  12. 04 Tem, 2016 1 kayıt (commit)
  13. 17 Mar, 2016 1 kayıt (commit)
  14. 15 Kas, 2015 1 kayıt (commit)
  15. 19 Eki, 2015 1 kayıt (commit)
  16. 12 Eki, 2015 1 kayıt (commit)
  17. 07 Eyl, 2015 1 kayıt (commit)
  18. 20 Agu, 2015 1 kayıt (commit)
  19. 09 Nis, 2015 4 kayıt (commit)
  20. 28 Ock, 2015 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Use vector::data · cead54b6
      Stephan Bergmann yazdı
      ...in some places where it is obvious that it does not hurt that for an empty
      vector the obtained pointer is not necessarily a nullptr.
      
      Change-Id: Id5d66b1559ca8b8955d379bcdbfae6986ef46a51
      cead54b6
  21. 16 Ara, 2014 1 kayıt (commit)
  22. 22 May, 2014 2 kayıt (commit)
  23. 01 Nis, 2014 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Explicitly mark overriding destructors as "virtual" · 362d4f0c
      Stephan Bergmann yazdı
      It appears that the C++ standard allows overriding destructors to be marked
      "override," but at least some MSVC versions complain about it, so at least make
      sure such destructors are explicitly marked "virtual."
      
      Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
      362d4f0c
  24. 26 Mar, 2014 1 kayıt (commit)
  25. 26 Şub, 2014 1 kayıt (commit)
  26. 22 Ock, 2014 1 kayıt (commit)
    • Jan Holesovsky's avatar
      Introduce static inline cppu::acquire(), and make use of that. · c2c530da
      Jan Holesovsky yazdı
      This is much better approach compared to the callback function, as it allows
      passing arguments to the c++ constructor directly, while still allowing some
      additional initialization after having acquired the instance.
      
      Change-Id: I5a0f981915dd58f1522ee6054e53a3550b29d624
      c2c530da
  27. 21 Ock, 2014 1 kayıt (commit)
    • Jan Holesovsky's avatar
      Change _get_implementation()'s not to do initialization directly. · f2783977
      Jan Holesovsky yazdı
      Many of the initalizations (in eg. framework) have to be done on an
      acquire()'d object, so instead of doing the initialization directly, return
      the initialization member function back to the createInstance() /
      createInstanceWithContext() / ... and perform the initialization there.
      
      As a sideeffect, I belive the calling initialize() from servicemanager is not
      that much a hack any more - whoever converts the implementation to be
      constructor-base has the choice to provide the callback, or still initialize
      through XInitialization, where the callback is preferred by servicemanager
      when it exists.
      
      Change-Id: I8a87b75c54c1441ca0f184967d31ff4902fc4081
      f2783977
  28. 20 Ock, 2014 1 kayıt (commit)
    • Jan Holesovsky's avatar
      Minimize the constructor functions to a bare minimum. · 306efefe
      Jan Holesovsky yazdı
      Most of the constructors are supposed to be only a call of
      
        new TheInstance(arguments)
      
      or an equivalent; so let's just change the constructor caller accordingly, to
      accept unacquired new instance.
      
      If there are exceptions that need to do more heavy lifting, they do not have
      to use the constructor feature, or there can be a wrapper for the real
      implementation, doing the additional work in their (C++) constructor.
      
      Change-Id: I035c378778aeda60d15af4e56ca3761c586d5ded
      306efefe
  29. 18 Ock, 2014 1 kayıt (commit)
    • Matúš Kukan's avatar
      Unify ctor functions for component implementations. · 73eca35b
      Matúš Kukan yazdı
      There is no need to use different styles for writing the same thing.
      It also makes it easier in future to use search & replace.
      But of course, there are also some more complicated functions.
      
      Change-Id: I773da20378af0e0d5a27689d3903df7063fb8ac0
      73eca35b
  30. 15 Ock, 2014 2 kayıt (commit)
  31. 19 Ara, 2013 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Add .component <implementation constructor="..." feature · ae3a0c8d
      Stephan Bergmann yazdı
      ...to directly call constructor functions of ComponentContext-based C++
      implementations of (non-single-instance) UNO services.  The case where these
      calls would need to be bridged across different environments (e.g., from gcc3
      to gcc3:affine) is not yet implemented.
      
      bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
      concept (which had previously been adapted to use the prefix="direct" feature,
      which may become unnecessary again in the end, depending on how to handle
      single-instance services/singletons).  More to follow.
      
      Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
      ae3a0c8d
  32. 18 Ara, 2013 1 kayıt (commit)
  33. 08 Kas, 2013 1 kayıt (commit)
  34. 06 May, 2013 2 kayıt (commit)