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.

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to