Commit Graph

23 Commits

Author SHA1 Message Date
Przemyslaw Czerpak
32f17091b8 2007-10-26 03:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbstack.h
  * harbour/include/hboo.ch
  * harbour/ChangeLog
  * harbour/utils/hbmake/hbmlang.c
  * harbour/utils/hbpp/hbppcore.c
  * harbour/utils/hbpp/hbpp.c
  * harbour/source/pp/ppcore.c
  * harbour/source/rtl/cdpapi.c
  * harbour/source/rtl/gtcrs/gtcrs.c
  * harbour/source/rtl/gtalleg/fixedth.sfc
  * harbour/source/rtl/fstemp.c
  * harbour/source/rtl/idle.c
  * harbour/source/rtl/gtstd/gtstd.c
  * harbour/source/rtl/gttrm/gttrm.c
  * harbour/source/rtl/gtpca/gtpca.c
  * harbour/source/rtl/hbffind.c
  * harbour/source/rtl/hbregex.c
  * harbour/source/vm/hvm.c
  * harbour/contrib/xhb/hboutdbg.c
  * harbour/contrib/xhb/hbxml.c
  * harbour/contrib/xhb/hbxml.h
  * harbour/contrib/xhb/cstructc.c
  * harbour/contrib/xhb/hbsyslog.c
  * harbour/contrib/libmisc/hb_f.c
  * harbour/contrib/libnf/fttext.c
  * harbour/contrib/libnf/mouse.c
  * harbour/contrib/tip/encmthd.c
  * harbour/contrib/rdd_ads/ads1.c
  * harbour/contrib/rdd_ads/ace.h
  * harbour/contrib/btree/hb_btree.c
  * harbour/contrib/samples/status.c
  * harbour/contrib/samples/gauge.c
  * harbour/contrib/odbc/odbc.c
  * harbour/contrib/bmdbfcdx/hbrddbmcdx.h
  * harbour/contrib/bmdbfcdx/bmdbfcdx1.c
    * cleanup errors in strict ANSI C compilation
2007-10-26 01:47:21 +00:00
Przemyslaw Czerpak
046d1ea4d7 2007-04-11 22:00 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/compiler/harbour.y
  * harbour/source/compiler/harbour.yyc
    ! fixed some possible false warning messages

  * harbour/include/hboo.ch
  * harbour/source/vm/classes.c
    + added support for HB_OO_MSG_PROPERTY and HB_OO_MSG_CLASSPROPERTY
      to make some xHarbour users happy ;-)

  * harbour/common.mak
  * harbour/harbour.spec
  * harbour/include/hbcompdf.h
  * harbour/source/compiler/Makefile
  + harbour/source/compiler/hbcmplib.c
    + added HB_COMPILE() function - it accepts exactly the same parameters
      as harbour compiler and makes the same job :-)

  * harbour/utils/hbrun/Makefile
  * harbour/utils/hbrun/hbrun.prg
    + added support for compilation and direct execution of .prg files
      Now hbrun can accept as first parameter .hrb or .prg file and if
      it's .prg file it's compiled and then executed just like .hrb one.
      In *nixes if you copy compiled hbrun to /usr/bin directory then
      you can add to your .prg files as first line:
         #!/usr/bin/hbrun
      and then after setting executable attribute you can directly
      execute them, f.e.:
         ./test.prg
      If you are using Linux then you can also chose default gt driver
      by dding to above line: //gt<name>
      F.e.
         #!/usr/bin/hbrun //gtstd
2007-04-11 20:01:18 +00:00
Przemyslaw Czerpak
0fae2fdd2c 2006-10-07 04:25 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbclass.ch
    + added validation for class data names. As additional preprocessor
      rule to not use <!marker!>

  * harbour/include/hboo.ch
  * harbour/source/rtl/tclass.prg
  * harbour/source/vm/classes.c
    + added delegate messages

  * harbour/include/hbstack.h
  * harbour/source/vm/arrays.c
  * harbour/source/vm/estack.c
  * harbour/source/vm/hvm.c
  * harbour/source/vm/proc.c
    + added startup symbol to hb_stack. It gives very good stop
      condition for all procedures which trace stack calls and
      resolves the problem with hb_stack.pBase which was never
      pointing to valid function/procedure symbol when no symbol
      was put on HVM stack. Now after hb_stackInit() the first
      item is allocated for "hb_stackInit()" symbol so hb_stack.pBase
      is always a pointer to valid function/procedure symbol.
    * changed the guard condition for buggy code in hb_stackPop()
      and similar code from:
         hb_stack.pPos < hb_stack.pItems
      to:
         hb_stack.pPos <= hb_stack.pBase
      The old condition was generating usable error message only in the
      startup function. In deeply called functions it was only waste of
      CPU time on one of the most often call functions. Before it was
      activated internal stack structures were corrupted.
      If we were leaving for many years without really working stack
      underflow protection then maybe we should think about disabling
      it at when HB_STACK_MACROS are used and keep it only in real
      stack functions for HVM developers. Single protection in
      hb_stackOldFrame() I've just added is enough for basic C code
      validation.
      I created the second version of stack macros without it in
      hbstack.h but I would like to hear other developers opinion.
2006-10-07 02:35:52 +00:00
Przemyslaw Czerpak
e47d291938 2006-10-04 02:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbclass.ch
    * most of the rules rewritten
    ! fixed some wrong rules and general cleanup
    + added additional code validation
    ! fixed compilation of more then one class in single file.
      Now it's even possible to declare all classes at beginning of
      single file and then implementing their methods in any order
    ! fixed using static classes and classes
    ! fixed compilation without <ClassName>_ prefix in method names
    + added support for HB_CLS_NO_DECORATION macro which disable
      adding <ClassName>_ prefix to method names - this macro is
      set by default when HB_SHORTNAMES is set.
    + added support for declared parameters validation - it can be
      disabled with HB_CLS_NO_PARAMS_ERR and I had to disable it
      by default due to problems with our preprocessor.
      Ryszard seems that our PP has serious problems with decoding
      directives when there is no space between symbol and some other
      non symbol character. I had to add some workarounds and even
      introduce buggy rules to make it working. Please look at it.
      You can remove #define HB_CLS_NO_PARAMS_ERR from hbclass.ch
      and try to rebuild Harbour core code to see the problem.

  * harbour/include/hboo.ch
  * harbour/source/vm/classes.c
    + added support for new primitive message: HB_OO_MSG_PERFORM

  * harbour/source/rtl/tclass.prg
    - removed <lPersistent> parameter from HBClass messages and
      internals data. Persistent is supported as scope bit and
      separate variable was redundant.
    - removed stripping of () from message names. Here is not a place
      to fix wrong preprocessor rules.

  * harbour/utils/hbtest/rt_class.prg
    * use: METHOD PROCEDURE ... CALSS ...
      instead of: PROCEDURE ... CALSS ...
      The first version is preferable syntax.

  * harbour/source/debug/dbgtmenu.prg
  * harbour/source/rtl/checkbox.prg
    ! fixed some parameters in method declaration - global cleanup
      will have to wait for preprocessor fixes

   Hi all,
   Please make test with current hbclass.ch code.
   I hope that I haven't broken too much things ;-) but I rewrite
   from scratch most rules and it's possible that I missed sth or
   made some stupid typos. Current version is much shorter and should
   be easier to updated. For sure I've intentionally changed one thing.
   CLASSDATA was ignoring SHARED attribute and always created shared
   class variables. Seems that it was long existing typo but the fix
   may interact with already existing code which needs SHARED class
   variables but does not use SHARED clause in CLASSDATA declaration.
   In such case please update it and add missing SHARED.
   Also in the end of CLASS declaration we have:
      [ ; #translate Super( <SuperClassN> ): => ::<SuperClassN>: ] ;
      [ ; #translate Super( <SuperClass1> ): => ::<SuperClass1>: ] ;
      [ ; #translate Super(): => ::<SuperClass1>: ] ;
      [ ; #translate Super: => ::<SuperClass1>: ] ;
      [ ; #translate ::Super : => ::<SuperClass1>: ]
   These rules introduce very serious bug - they are breaking supercasting
   in code which makes sth like:
      ::super:super:super:msg
   or in any other code which sends SUPER message to some other class
   objects. I will have to remove them. At least the last three ones.
   There were some other things I wanted to write about but it's too late
   and I'm to tired - sorry. If you will have any question please ask. if
   you will notice some problems with current rules please inform me.
2006-10-04 00:33:00 +00:00
Przemyslaw Czerpak
a35053003b 2006-09-15 04:55 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
+ harbour/doc/destruct.txt
    + added description for object destructors in Harbour

  * harbour/include/error.ch
    + added new error code EG_DESTRUCTOR

  * harbour/source/lang/msgpl852.c
  * harbour/source/lang/msgpliso.c
  * harbour/source/lang/msgplmaz.c
  * harbour/source/lang/msgplwin.c
  * harbour/source/rtl/langapi.c
    + added desription for new error code - other language modules
      have to be updated

  * harbour/include/hbapi.h
    + added hb_gcRefCheck() and cover some hb_gc* functions by
      _HB_API_INTERNAL_ macro

  * harbour/source/vm/itemapi.c
    ! fixed possible RT error generation when some exception is active

  * harbour/include/hbapicls.h
  * harbour/include/hbclass.ch
  * harbour/include/hboo.ch
  * harbour/source/rtl/tclass.prg
  * harbour/source/vm/arrays.c
  * harbour/source/vm/classes.c
    + added support for object destructors

  * harbour/source/vm/garbage.c
    + added support for object destructors
    + added logic to detect buggu .prg code which uses destructors
      see doc/destruct.txt for more info.
      It's also possible that this code will exploit some bugs
      in other code which uses GC allocated memory blocks.
2006-09-15 03:10:38 +00:00
Przemyslaw Czerpak
7463296f9e 2006-09-11 20:10 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapicls.ch
    * added HB_EXPORT to public functions and some internal covered by
      _HB_API_INTERNAL_ macro

  * harbour/include/hboo.ch
    + added HB_OO_CLSTP_NONVIRTUAL and HB_OO_CLSTP_OVERLOADED

  * harbour/source/rtl/tclass.prg
    ! do not add supercast class messages - now it's done automatically
      by __clsNew() function with proper instance area offset updating
    ! enumerate instance class datas in __clsAddMsg() from 1 - inherited
      instance variables are managed internally by classy code with
      proper instance area offset updating
    ! use __CLS_CNTCLSDATA() as start offset for class data. Do not
      try to calculate it yourself - some of super classes can be ignored
      when they are appear in the inheritance tree more then once so it's
      not possible to calculate class data or instance data start offset
      using simple sum of class or instance variables in super classes.

  * harbour/source/vm/classes.c
    ! fixed instance area casting
    ! fixed class variables casting
    ! fixed multi-inheritance when the same class can apear more then
      once in super classes tree.
    ! Do not add unnecessary instance variables for the same class when
      it's inherited more then once.
    ! Do not add unnecessary class variables for the same class when
      it's inherited more then once.
    ! Do not add unnecessary initialization class and instance variables
    + added support for non virtual messages
    + added support for static and casted scoping
    + super cast messages added automatically. They are used to dynamic
      recalculation of instance are offsets and to avoid multiple inheritance
      of the same class so please do not overload them or you will have as
      result something what we have before recent modifications in the
      instance and class data area. Just simply run tests/clsccast.prg
      and tests/clsicast.prg compiled with current CVS code and last
      release code or with xHarbour and compare the results.
      Also Class(y) does not pass these tests and I do not know if any
      other dynamic OOP model in xbase languages can properly address it.
      BTW maybe I should add RT error when .prg code will try to delete
      or overwrite class cast message. For me it seems to be reasonable
      and what's your opinion?
    * make hidden class members non virtual by default. It can be disabled
      by compiling classes.c with -DHB_VIRTUAL_HIDDEN but IMHO keeping
      HIDDEN members as virtual causes that they are not really HIDDEN
      because subclasses can simply overwrite them. It also means that
      it's not possible to create class with some private data and
      methods which will never interact with any subclass code created
      by other programmers where name conflict can appear. So one of
      the most important OOP features is missing in such case.
      See tests/clsnv.prg as an example for non virtual hidden members.

  + tests/clsicast.prg
    + added test code for proper instance area allocating and casting

  + tests/clsccast.prg
    + added test code for proper class data allocating and casting

  + tests/clsnv.prg
    + added test code for non virtual hidden class members

   Now we should be able to create and class model even replicate the
   static one like in C++ using current class engine which still fully
   supports dynamic bindings. It consumes less memory and due to much
   more efficient hashing it should be faster then it was though some
   other minor optimization can be add and I'll plan to make them in
   some spare time.
   The item type verification in assignment is still missing. I'll add
   it when I'll collect some statistic informantion I'd like to ask
   [x]Harbour users. I need these information to tune some internal
   structures where I can balance between speed and memory allocation
   to statistically optimal form.

   Marek asked me to add passing object datas by reference and I'll do
   that but I'd like to ask Ryszard to add support for:
      @<oVar>:<message>
   to compiler. I'll implement all other HVM modifications. If you can
   please also add support for:
      <oVar>:&<cMsgName>[(...)]
   For this we do not need any HVM modifications or new PCODEs.
   We are supporting xBase++ macro list compilation in:
      cList:="1,2,3"
      x := aVar[ &cList ]
      aVar:={ &cList }
      func( &cList )
   But we do not support:
      <oVar>:<message>( &cList )
   IMHO it looks ugly. If we have this syntax for function call then we
   should also support it in message sending.
   Ryszard can you make necessary compiler modifications?
   I'm also thinking about adding support for variable parameters
      func myfunc(...)
      [...]
      return xVar
   In few cases it will help to encode some function much more efficient
   then now.

   I'll add Class(y) compatible functions used in class(y) header files
   so it will be possible to use original class(y) .ch files in Harbour
   though it will not be the most efficient because we have @func() operator
   which gives better performance then using codeblocks. Anyhow classy
   create separate meta class for each class with CLASS members and
   <clasName>() function always return such meta class object so for full
   Class(y) compatibility we need to generate differ .prg code.
   But all such modifications now can be done on preprocessor and
   .prg level and they will not need .c code modification.
   We should make them to give user interface for our new OOP features.

   Now I'm waiting for reports about any problems with current classy
   code.
2006-09-11 18:14:41 +00:00
Przemyslaw Czerpak
43d20b8eb6 2006-09-10 13:05 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapi.h
  * harbour/source/vm/hvm.c
  * harbour/source/vm/codebloc.c
  * harbour/source/vm/arrays.c
    * moved static base offset from hb_struBlock structure
      to HB_CODEBLOCK structure
    + added hclass member to hb_struBlock - it will be used in
      the future for checking codeblock scope in classy so we will
      real scope checking also for messages sent from codeblocks.
    - removed supercast and superoffset members from hb_struArray
      structure.

  * harbour/include/hbclass.ch
    * added class(y) like
         @:<MessageName>([<MsgParams,...>])
      send operator. It's not exactly the same as in class(y) where
      this operator is hardcoded to executing function directly,
      needs method name instead of message name and is linked statically.
      In Harbour this operator uses message name so can be used also for
      instance variables and make dynamic casting to the class from which
      current method is inherited. In short words sending messages to @:
      instead of :: causes that they work like non-virtual messages in
      C++ mode.
      If you do not use the same method body in different classes
      then you can also use explicitly self casting:
         ::<myclass>:<msgname>[(...)]
      and it will be a little bit faster

  * harbour/include/hboo.ch
    + added: HB_OO_MSG_ASSIGN, HB_OO_MSG_ACCESS,
             HB_OO_MSG_CLSASSIGN, HB_OO_MSG_CLSACCESS
      They should be used insted of HB_OO_MSG_DATA and HB_OO_MSG_CLSDATA
      This resolves problems with name conflicts when we were detecting
      type of message (ACCESS/ASSIGN) by checking the first character
      in message name. F.e. now it's possible to create exported instance
      variable called __WithObject and it will be used in all WITH OBJECT
      statement instead of the base object value. It's simple and effective
      WITH OBJECT overloading.
      I kept backward compatibility for HB_OO_MSG_DATA and HB_OO_MSG_CLSDATA
      but I strongly suggest to update code to use new constants.
    + added HB_OO_MSG_REALCLASS

  * harbour/source/rtl/objfunc.prg
  * harbour/source/rtl/tobject.prg
  * harbour/source/rtl/tclass.prg
    * use HB_OO_MSG_[CLS]{ASSIGN,ACCESS} instead of HB_OO_MSG_[CLS]DATA

  * harbour/source/rtl/tclass.prg
    + added REALCLASS message to creted classes - it's used for @: operator

  * harbour/source/vm/classes.c
    * updated for above modifications
    * calculate instance area offset in supercasting dynamically - it
      will allow to eliminate multiple instance area allocating when
      in the inheritance tree the same class exists more then once and
      also quite easy add support for non-virtual messages.
    ! fixed GPF in __CLSINSTSUPER() class function generate HVM exception
    % do not inherit unaccessible inline blocks
    * some other minor optimization, fixes and code cleanups

  * harbour/source/rdd/usrrdd/usrrdd.c
    ! fixed HB_TRACE message

  * harbour/source/rtl/errorapi.c
    ! generate internal error if ErrorNew() function does not return an object
2006-09-10 11:16:43 +00:00
Przemyslaw Czerpak
69503c8a2b 2006-09-03 16:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hboo.ch
    + added HB_OO_CLSTP_PERSIST and HB_OO_MSG_INITIALIZED

  * harbour/include/hbapi.h
  * harbour/include/hbvmpub.h
  * harbour/source/vm/dynsym.c
    % changed HB_HANDLE hArea to USHORT uiArea to reduce HB_DYNS size.
      RDD code internally uses USHORT as area number so it's not
      necessary to keep it as HB_HANDLE value.

  * harbour/source/vm/arrays.c
    * modified internal static function name

  * harbour/source/vm/itemapi.c
    + added missing HB_TRACE in hb_itemClone()

  * harbour/source/vm/classes.c
    ! moved initialization values to separate structure not bound with
      methods. We can inherit the same method names from more then one
      object so we will store only the first one but we are inheriting
      whole instance area which is accessible with super casting (last
      fixes) so we have to properly initialize it even if methods does
      not exist. This modification also fixes some possible memory leaks.
    % replaced bIsPersistent by HB_OO_CLSTP_PERSIST in uiScope in method
      definition
    ! added basic parameter validation to __CLSADDMSG() to avoid some
      possible strange behavior at runtime when broken messages are
      defined.
    * updated __OBJHASMSG() and __OBJSENDMSG() to accept SYMBOL items
      too (@funcName()). Using symbol items it faster then strings.
      Also added support to use non array parametes. F.e. now
         __OBJHASMSG( {||NIL}, "EVAL" )
      returns TRUE
    * some other fixes, reduced memory consumption and speed optimizations
2006-09-03 14:30:26 +00:00
Tomaz Zupan
3a020b8283 2003-02-18 22:05 UTC+0100 Tomaz Zupan <tomaz.zupan@orpo.si> 2003-02-18 21:02:54 +00:00
Antonio Linares
0dc46b0c99 Added new defines HB_OO_DATA_PERSISTENT and HB_OO_MTHD_PERSISTENT 2001-09-02 12:26:02 +00:00
Viktor Szakats
37b052fc7a 2001-05-15 15:02 UTC+0100 Viktor Szakats <viktor.szakats@syenar.hu> 2001-05-15 13:02:07 +00:00
Jean-Francois Lefebvre
cb8fa099bd 2001-05-13 22:30 UTC+1 JFL (mafact) <jfl@mafact.com> 2001-05-13 20:30:28 +00:00
Viktor Szakats
610a4f3195 2000-05-29 02:47 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-05-29 00:54:26 +00:00
Viktor Szakats
9217251a5a 2000-05-29 02:47 UTC+0100 Victor Szakats <info@szelvesz.hu> 2000-05-29 00:51:57 +00:00
Jean-Francois Lefebvre
937101dd91 *harbour/include/hboo.ch
*harbour/include/hbclass.ch
 Now support MI, scoping, fowarding and delegating
 Also support 10 chars limit by not prefixing the Classname when in 10 chars mode

*harbour/include/hbsetup.ch
 Allow the configuration of Hidden message

*harbour/source/rtl/objfunc.prg
 added function __objDerivedFrom(oSelf, oObj | cClassName)

*harbour/source/rtl/tclass.prg
 Major modification to implement MI & scoping
 Added message :Super to acces frist superclass object instance
 Added message :IsDerivedFrom(oObj | cClassName ) (Xbase++ comp.)

*harbour/source/vm/proc.c
  added char * hb_procname( int iLevel, char * szName )
  extracted from HB_FUNC( PROCNAME ) to allow it to be called from c
  HB_FUNC( PROCNAME ) modified to call the previous'one

*harbour/source/vm/classes.c
  Major modification to implement MI & Scoping
  Added function Sender() used by delegating to allow full polymorphism
  Added function __CLS_PARAM used by the preprocessor
2000-05-28 20:09:56 +00:00
Viktor Szakats
08d94a340e 20000210-23:53 GMT+1 Victor Szakats <info@szelvesz.hu> 2000-02-10 22:55:12 +00:00
Antonio Linares
d79f3a39c3 *** empty log message *** 1999-12-15 09:58:43 +00:00
Viktor Szakats
521ffcf660 19991025-12:37 GMT+1 Victor Szel <info@szelvesz.hu> 1999-10-25 11:25:54 +00:00
Viktor Szakats
fbf0ac5776 19991010-02:05 GMT+1 1999-10-10 00:18:35 +00:00
Antonio Linares
1fc6222e6c *** empty log message *** 1999-10-06 05:55:48 +00:00
Viktor Szakats
c3c3486de0 19990915-15:50 GMT+1 1999-09-15 14:03:38 +00:00
Viktor Szakats
f6d4ffd9ed 19990817-07:30 GMT+1 1999-08-17 05:52:08 +00:00
Viktor Szakats
5d4c16f38f 19990816-02:45 GMT+1 1999-08-16 01:07:21 +00:00