Skip to content
Snippets Groups Projects
  1. Jun 25, 2008
  2. Jun 23, 2008
  3. Jun 20, 2008
    • Fons Rademakers's avatar
      From Axel: · 94da4769
      Fons Rademakers authored
      Allow --enable-cint7 to build CINT7 in parallel to CINT5.
      This builds root7.exe, rootcint7, cint7 which will pick up libCint7.
      CINT includes are now in include/cint and include/cint7. Many #include
      statements changed because of that. We still provide backward compatible
      wrapper headers in include/ pointing to the include/cint ones.
      Dictionaries for CINT5 and CINT7 are now (mostly) compatible.
      When --enabled-cint7, TCint for CINT5 is in libMetaTCint and TCint for CINT7
      is in libMetaTCint_7. The classes' source is identical for now (except for the
      cases marked with #ifdef R__BUILDING_CINT7); they pick up different CINT
      implementations, though.
      Without --enable-cint7, TCint.o is linked into libCore, just like it used to
      be. With --enable-cint7, TROOT() dlopens libMetaTCint / libMetaTCint_7,
      depending on which libCint the binary is linked against (determined via
      G__cint_version). TCint contains and sets a global factory pointer that
      creates the appropriate TCint object for TROOT.
      
      The cintdlls are built for CINT5 and CINT7 separately, cintdlls.mk is
      included twice, with different contexts set by cint/Module.mk and cint7/Module.mk.
      
      --enable-/--disable-cint7 (i.e. (TCint.o in libCore vs libMetaTCint)
      triggers a re-build of TROOT.o
      
      Remove dependency from TGWin32ProxyDefs to bare CINT
      Add implementation of G__alloc_tempobject_val to cint5
      Add a rule how to build C-dictionaries, needed for G__c_stdfunc.c.
      
      No rootmap entries for TCint - CINT should never ever try to autoload it.
      It's either linked anyway or we dlopen it by hand.
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24423 27541ba8-7e3a-0410-8455-c3a389f83636
      94da4769
  4. Jun 18, 2008
  5. Jun 16, 2008
  6. Jun 13, 2008
    • Paul Russo's avatar
      Fix G__rate_parameter_match so that a conversion from · 0dd35ff6
      Paul Russo authored
      an argument of integral type with value 0 to char* is
      considered viable only if the integral type is const.
      
      See
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24277 27541ba8-7e3a-0410-8455-c3a389f83636
      0dd35ff6
    • Paul Russo's avatar
      Fix G__is_cppmacro, it just did not work, it was · c6572e71
      Paul Russo authored
      checking for a typename of $MACRO$ instead of
      macroInt$ or macroDouble$.
      
      This change comes from Philippe Canal.
      
      -- Paul Russo
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24276 27541ba8-7e3a-0410-8455-c3a389f83636
      c6572e71
    • Paul Russo's avatar
      Revise the handling of type macroInt$ and macroDouble$ · 749a16fd
      Paul Russo authored
      in G__getvariable and G__letvariable.  We were not testing
      their constness correctly and we were converting them
      to long on assignment.
      
      This change is from Philippe Canal.
      
      -- Paul Russo
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24275 27541ba8-7e3a-0410-8455-c3a389f83636
      749a16fd
    • Paul Russo's avatar
      Make type macroInt$ have rawtype "int const" instead of · 6542fdbd
      Paul Russo authored
      "int" so that NULL translates to a constant integral type.
      
      The C++ standard has this to say in section
      4.10 Pointer conversions [conv.ptr]:
      
           A "null pointer constant" is an integral constant
           expression (5.19) rvalue of integer type that
           evaluates to zero.
      
      This is a problem in a function overloading situation
      like this:
      
      void f(double);
      void f(char*);
      
      int main()
      {
         for (int i = 1; i < 10; ++i) {
            f(i);
         }
      }
      
      The rule in section 4.10 on null pointer constants
      and the rules in Chapter 13 Overloading, make f(char*)
      a non-viable function for overloading purposes
      because i is not a "integral constant expression".
      
      However given:
      
           #define POGO 0
      
      then in the same loop a call written:
      
           f(POGO);
      
      is ambiguous since both of the functions are viable
      (because POGO is substituted with 0, which is an
      integral constant expression).
      
      In cint "#define int MyType" is implemented as a variable
      definition using the special type macroInt$.  So we need
      to make that type const so that overloading works correctly.
      
      Note that this is all a gross hack to paper over the fact
      that cint does not have a proper preprocessor.
      
      -- Paul Russo and Philippe Canal
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24273 27541ba8-7e3a-0410-8455-c3a389f83636
      6542fdbd
  7. Jun 12, 2008
  8. Jun 06, 2008
  9. Jun 03, 2008
  10. Jun 02, 2008
  11. May 30, 2008
  12. May 29, 2008
    • Paul Russo's avatar
      Fix the way G__memberfunc_setup() calculates the · be4b5219
      Paul Russo authored
      function property ptradjust.  The translation from
      cint5 missed initializing the pointer to zero,
      and the return type for the cast which is done to
      calculate the pointer adjustment was incorrect,
      it was the class type instead of a pointer to the
      class type.
      
      Make sure that reflex properties are copied correctly,
      there are some non-default copy semantics and we
      must be sure to have real copy constructors
      and operator= functions for the type heirarchy.
      
      -- Paul Russo
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24058 27541ba8-7e3a-0410-8455-c3a389f83636
      be4b5219
    • Paul Russo's avatar
      Fix Next(), it was returning functions from the global · cbf01337
      Paul Russo authored
      scope in addition to the class methods.
      
      Fix handling of data members which are cached values
      derived from calling member functions of other data
      members.  They were not always reset when their master
      data member was changed.
      
      -- Paul Russo
      
      
      git-svn-id: http://root.cern.ch/svn/root/trunk@24057 27541ba8-7e3a-0410-8455-c3a389f83636
      cbf01337
  13. May 27, 2008
  14. May 23, 2008
  15. May 22, 2008
  16. May 16, 2008
  17. May 12, 2008
  18. May 11, 2008
  19. May 09, 2008
  20. May 05, 2008
  21. May 02, 2008
  22. May 01, 2008
  23. Apr 28, 2008
Loading