On Wednesday 17 December 2008 07:53:31 Przemyslaw Czerpak wrote:
> Hi Jose,
>
> > Sorry for the off-topic and sorry for my low C level...
> > I saw that __GETMESSAGE in classes.c is defined as:
> > HB_FUNC( __GETMESSAGE )
> > {
> > hb_retc(
> > hb_stackItem(hb_stackBaseItem()->item.asSymbol.stackstate->lBaseItem
> > )->item.asSymbol.value->szName ); }
> > Then, in my proyect I want to integrate that piece of code. I do this:
> > #pragma BEGINDUMP
> > #include "hbapi.h"
> > #include "hbstack.h"
> > HB_FUNC ( __MYFUNCTION )
> > {
> > char * cMessage = (hb_stackItem(
> > hb_stackBaseItem()->item.asSymbol.stackstate->lBaseItem
> > )->item.asSymbol.value->szName) ; /* My code will go below */
> > }
> > #pragma ENDDUMP
> > But when compiling this little example I have these messages error:
> > tdatabase.c
> > tdatabase.prg(220) : error C2223: left of '->item' must point to
> > struct/union tdatabase.prg(220) : error C2198: 'hb_stackItem' : too few
> > actual parameters tdatabase.prg(220) : error C2223: left of '->item' must
> > point to struct/union And this is my problem: I cannot understand these
> > errors and also I cannot understand why in classes.c compile OK whilst in
> > my project throws these errors. If someone could light me I shall
> > appreciate too much.
>
> In Harbour internal HVM structures are not public. It's done intentionally
> because we want to be free in farther Harbour developing and adding new
> extensions with problems with backward binary compatibility with 3-rd
> party code. It's very important issue and how big problems it can create
> you can see in xHarbour where even simple fix in structures used by
> profiler breaks binary compatibility and people cannot use existing FWH
> binaries. Hiding internal structures also resolves the problem with
> alignment so you do not have to ask 3-rd party developers to use exactly
> the same alignment as you when they compile code for libraries.
> So developers creating code for Harbour should use only public Harbour API
> and accessing item internals like in your above example is bad practice
> and we strongly suggest to not make anything like that.
> Anyhow we cannot stop you or anyone else and forbid it. This is only our
> suggestion and if you want you can ignore it but in such case you will
> have to accept that if we change sth in HVM internals then you will have
> to follow this changes and update your code to respect them or at least
> recompile it.
> So if your real want to unblock access to HVM internals for your code
> then it's enough to include hbvmint.h before any other harbour header
> files (please do not use hbvmopt.h as Teo suggested because this file
> will force creating separated binaries for MT and ST HVM).
> Please only remember that it will not work for #pragma BEGINDUMP because
> in final .c file the sections inside BEGINDUMP/ENDDUMP are included _AFTER_
> harbour header files used for generated PCODE so #include "hbvmint.h" will
> not be the 1-st included harbour header file. It can be used only in
> separated .c files or you can edit manually .c file generated by Harbour
> compiler and add #include "hbvmint.h" at beginning.
>
> But I strongly suggest to use only documented Harbour API and change your
> code to work without "hbvmint.h", f.e.;
>
> /********************************/
> proc main()
> ? __MYFUNCTION()
> return
>
> #pragma begindump
> #include "hbapiitm.h"
> #include "hbstack.h"
> HB_FUNC ( __MYFUNCTION )
> {
> long lOffset = hb_stackBaseProcOffset( 1 );
> const char * cMessage = hb_itemGetSymbol( hb_stackItem( lOffset )
> )->szName;
>
> hb_retc( cMessage );
> }
> #pragma enddump
> /********************************/
>
> If there is sth important for developers what cannot be done using public
> harbour API then please inform us. We will add new public functions or we
> explain why some internal structures should not be accessible by user code.
> But I do no think you will find many of such things. In Harbour only HVM
> lib needs it and rest of code (with the exception to emulation of some low
> level xHarbour HVM behavior in XHB lib) do not use it at all so it's
> possible to write code without it.
>
Thanks Przemek for your detailed explanation.
best regards,
Teo
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
