__CLSMSGSCOPE( oObject:ClassH, cMsgName ) --> nScope

[Antonio Linares]

I needed this function and I think it may be useful to include it in
classes.c. It is working fine.

HB_FUNC( __CLSMSGSCOPE )
{
PHB_DYNS pMessage = hb_objGetMsgSym( hb_param( 2, HB_IT_ANY ) );

if( pMessage )
{
HB_STACK_TLS_PRELOAD
HB_USHORT uiClass = ( HB_USHORT ) hb_parni( 1 );
PMETHOD pMethod = NULL;

if( uiClass && uiClass <= s_uiClasses )
pMethod = hb_clsFindMsg( s_pClasses[ uiClass ], pMessage );

hb_retni( pMethod ? pMethod->uiScope : -1 );
}
else
hb_errRT_BASE_SubstR( EG_ARG, 1099, NULL, HB_ERR_FUNCNAME,
HB_ERR_ARGS_BASEPARAMS );
}

thanks,

Antonio

[Manu]

In English ...

In line with what Antonio said ...

Will it be possible to do an entire class C Language?

I say this because just the functions that manage the creation of
classes with inheritance and visibility of instance variables are all
static ... and those that are not compatible with Cli*per do not have
all its functionality ...

Sorry for the English translation ...

Thanks
Manu Exp�sito

--------------------------------------------------------

En espa�ol...

Al hilo de lo que comenta Antonio...

�Se podr� hacer una clase entera en Lenguaje C?

Lo digo porque precisamente las funciones que gestionan la creaci�n de
las clases con herencia y la visibilidad de las variables de instancia
son todas est�ticas... y las que no lo son por compatibilidad con
Cli*per no tienen toda su funcionalidad...

Gracias
Manu Exp�sito

El 14/09/2011 22:36, Antonio Linares escribi�:

> I needed this function and I think it may be useful to include it in
> classes.c. It is working fine.
>
> HB_FUNC( __CLSMSGSCOPE )
> {
> PHB_DYNS pMessage = hb_objGetMsgSym( hb_param( 2, HB_IT_ANY ) );
>
> if( pMessage )
> {
> HB_STACK_TLS_PRELOAD
> HB_USHORT uiClass = ( HB_USHORT ) hb_parni( 1 );
> PMETHOD pMethod = NULL;
>

> if( uiClass&& uiClass<= s_uiClasses )

[Teo Fonrouge]

Hello Manu,

qtHarbour, at sourceforge, shows how to create full working and MT protected
Harbour classes and subclasses from C/C++. The procedure replicates what
HB prgs does.

Check the sources there to see how it's accomplished.

best regards,

Teo

On Sep 15, 2011, at 6:31 AM, Manu wrote:

> In English ...
>
> In line with what Antonio said ...
>
> Will it be possible to do an entire class C Language?
>
> I say this because just the functions that manage the creation of classes with inheritance and visibility of instance variables are all static ... and those that are not compatible with Cli*per do not have all its functionality ...
>
> Sorry for the English translation ...
>
> Thanks

> Manu Expósito
>
> --------------------------------------------------------
>
> En español...

>
> Al hilo de lo que comenta Antonio...
>

> ¿Se podrá hacer una clase entera en Lenguaje C?
>
> Lo digo porque precisamente las funciones que gestionan la creación de las clases con herencia y la visibilidad de las variables de instancia son todas estáticas... y las que no lo son por compatibilidad con Cli*per no tienen toda su funcionalidad...
>
>
> Gracias
> Manu Expósito

[Viktor Szakáts]

Which C method is now also implemented in HBQT, with MT compatibility fixes.

(except strtok() usage which makes it still broken in MT mode)

Viktor

[Manu]

Thanks Teo ...
I mean there are basically two functions in classes.c ...

-> HB_USHORT hb_clsCreate (HB_USHORT usSize, const char * szClassName)
and
-> Void hb_clsAdd (HB_USHORT usClassH, const char * szMethodName, PHB_FUNC pFuncPtr)

The two functions that are visible from outside classes.c really call two other functions that contain everything you need to make language classes from C. These static functions are:

HB_USHORT static hb_clsNew (const char * szClassName, HB_USHORT UIData,
                             PHB_ITEM pSuperArray, PHB_SYMB pClassFunc,
                             HB_BOOL fModuleFriendly)

and

HB_BOOL static hb_clsAddMsg (HB_USHORT uiClass, const char * szMessage,
                              HB_USHORT uiType, HB_USHORT uiScope,
                              PHB_ITEM pFunction, PHB_ITEM Pinit)

These functions do stain all that I want to create classes in C

Do not know if I understand Teo?. And because Viktor is here ... I ask myself that question to him.

Thanks to all
Manu Exposito

------------------------------------------------------------

En español

Gracias Teo...
Me refiero a basicamente dos funciones que hay en classes.c...

-> HB_USHORT hb_clsCreate( HB_USHORT usSize, const char * szClassName )
y
-> void hb_clsAdd( HB_USHORT usClassH, const char * szMethodName, PHB_FUNC pFuncPtr )

Esta dos funciones que son visibles desde fuera de classes.c, realmente llaman a otras dos funciones que contienen todo lo necesario para hacer clases desde lenguaje C. Estas funciones estaticas son:

static HB_USHORT hb_clsNew( const char * szClassName, HB_USHORT uiDatas,
                            PHB_ITEM pSuperArray, PHB_SYMB pClassFunc,
                            HB_BOOL fModuleFriendly )

y

static HB_BOOL hb_clsAddMsg( HB_USHORT uiClass, const char * szMessage,
                             HB_USHORT uiType, HB_USHORT uiScope,
                             PHB_ITEM pFunction, PHB_ITEM pInit )

Estas funciones sí tinenen todo eso que yo quiero para poder crear las clases en C

No sé si me entiendes Teo. Y ya que está Viktor por aquí... le hago esa pregunta a él.

Gracias a todos
Manu Expósito

[Przemysław Czerpak]

On Thu, 15 Sep 2011, Manu wrote:

Hi,

> In line with what Antonio said ...
> Will it be possible to do an entire class C Language?
> I say this because just the functions that manage the creation of
> classes with inheritance and visibility of instance variables are
> all static ... and those that are not compatible with Cli*per do not
> have all its functionality ...

I'm very interesting in Cli*per interface you are talking about
which we are not compatible.
Can you present list of missing functions which exist in Cli*per
but not in Harbour?

best regards,
Przemek

[Manu]

Hello Przemek ...

I am very grateful that I have answered ...

I say not really missing functions are self Harbour and Cli*per.
What I mean is that if it were possible to remove the STATIC these
functions to be accessible from outside classes.c ...

static HB_USHORT hb_clsNew(...)
static HB_BOOL hb_clsAddMsg(...)

Remove the "static" or creating a bridge as there is in the function:
static PHB_ITEM hb_clsInst(...)
and
void hb_clsAssociate (...)
These functions are source could pass all the parameters ...

--------------------------------------------------------

Hola Przemek...

Te agradezco muchísimo que me hayas contestado...
Realmente no digo que falten funciones en Harbour y que sí estén en Cli*per.
Lo que digo es que si fuera posible quitar el STATIC a estas funciones
para hacerlas accesibles desde fuera de classes.c...

static HB_USHORT hb_clsNew(...)
static HB_BOOL hb_clsAddMsg(...)

Quitar el "static" o crear una función puente como hay en la función:
static PHB_ITEM hb_clsInst(...)
y
void hb_clsAssociate( ... )
Esas funciones fuente se les podría pasar todos los parámetros...

No sé si la traducción de Google es buena. Si no es así, ¿puedes
traducir tú Teo?

[Viktor Szakáts]

Hi Manu,

At the moment, creating classes from C is rather a hack than a real 

("official") solution, and I believe current C APIs not published are not 

published for a good reason. Hopefully in the future there will be 

a clean C level class API, but until this happens, you will need to resort 

to the quoted HBQT solution to implement it.

Another option to consider, is to keep your class creation code on .prg 

level, unless you absolutely need C.

See contrib/hbqt/hbqtcore/hbqt_pointer.cpp @ hbqt_defineClassBegin() 

and related functions.

Viktor

[Manu]

Thanks Victor ...

I understand what you have exposed.

Do you have any idea when it will be available the new API for
creating classes in C?

[Przemysław Czerpak]

On Fri, 16 Sep 2011, Manu wrote:

Hi,

> I am very grateful that I have answered ...

> I say not really missing functions are self Harbour and Cli*per.
> What I mean is that if it were possible to remove the STATIC these
> functions to be accessible from outside classes.c ...
> static HB_USHORT hb_clsNew(...)
> static HB_BOOL hb_clsAddMsg(...)
> Remove the "static" or creating a bridge as there is in the function:
> static PHB_ITEM hb_clsInst(...)
> and
> void hb_clsAssociate (...)
> These functions are source could pass all the parameters ...

hb_clsCreate(), hb_clsAdd() and hb_clsAssociate() were added for
Cli*per compatibility and they cover undocumented Clipper OOP API:
__mdCreate(), __mdAdd() and __mdAssociate(). I do not know any
other Cli*per functions. so looks that there is no Cli*per compatibility
problem. If I'm wrong then please fix me.
The second part is much more complicated then you may think.
Harbour OOP interface still miss very important class(y) functionality.
It does not support real class objects like Class(y) or xbase++. We
plan to add it in the future and it means that we cannot document current
API as official one because it will have to be replaced by new one not
backward compatible.
In theory I can document it as temporary solution but practice shows
that later it makes serious problems when we want to remove obsolete
code.

best regards,
Przemek

[Viktor Szakáts]

> Do you have any idea when it will be available the new API for 
> creating classes in C? 

Cannot tell you any estimates for that. It will depend 

on someone feeling it important enough to deal with 

it and actually developing it.

I personally don't feel this the most important missing 

feature in Harbour (i.e. this is about the third time it came 

up in the last 6 years), and I could think a lot of other 

more useful additions even in the general area of class 

implementation that have higher priority.

I'd say go for what Harbour offers now.

If you'd describe what do you need such feature for, 

and why do you need it, it'd help shaping future plans or 

help offering you alternative solutions.

Viktor

[Teo Fonrouge]

Viktor,

On Sep 16, 2011, at 4:29 AM, Viktor Szakáts wrote:

> Which C method is now also implemented in HBQT, with MT compatibility fixes.
>
> (except strtok() usage which makes it still broken in MT mode)

As you know, in my first version of the procedure to create HB classes from C
I was using strtok() which is not MT safe, besides the whole procedure has some
other problems when I made some MT tests on it building classes.

Then I made a new procedure which simply replicates the code generated
by compiling (-gc3) an HB PRG source that is creating a HB class, resulting in
a class creation procedure in C that basically identical to the one with pure prg.

best regards,

Teo

[Viktor Szakáts]

Hi Teo,

That sounds good, I didn't know.

Can you comment on the further MT problems you've found with 

current HBQT code?

Regardless of where we'll end up, I'd like to commit Bacco's strtok() 

patch to sort out this issue in current code.

Viktor

[Teo Fonrouge]

Hi Viktor,

On Sep 16, 2011, at 11:33 AM, Viktor Szakáts wrote:

> Hi Teo,
>
> That sounds good, I didn't know.
>
> Can you comment on the further MT problems you've found with
> current HBQT code?

Fundamentally the whole implementation is not reentrant nor thread-safe
because it's using unprotected static vars to hold states. I don't remember
more details but the most obvious is:

static PHB_DYNS s___HBCLASS = NULL;

>
> Regardless of where we'll end up, I'd like to commit Bacco's strtok()
> patch to sort out this issue in current code.

okay

best regards,

Teo

[Teo Fonrouge]

Hello Manu,

I understand what you mean; to made public:

hb_clsNew
hb_clsAddMsg

This very issue has been discussed right on this list, you can check the
archives to see the threads.

As long as I understand the need for these functions in order to create
hb classes from pure C, I think that there is a subject that would need
to be addressed first: it would be necessary to port also the functionality
at tclass.prg in order to obtain classes that will be guaranteed to be
100% compatibles with the ones created from pure prg sources,
otherwise you'll be end with C code that will end up calling again to a
prg stub function in order to build the class structure. Of course that
you can replicate the functionality at tclass.prg but is here when
I think that is would create more problems than the solved ones. One
of them would be to keep synched the possible changes at tclass.prg
with your C counterpart. Also there is the base class HBOBJECT
that is also defined at PRG level. Of course that the entire current
tclass.prg can be ported to C (even the HBOBJECT definition) but
again I prefer to have this complex definitions at a much simpler PRG
format. IMHO.

This is the reason why I choose to keep using the functionality at
tclass.prg in order to keep things simpler.

HTH,

Teo

[Teo Fonrouge]

Hi Manu,

La traducción al inglés es exactamente igual a la version en español.

>
>
>
> El 16/09/2011 12:06, Przemysław Czerpak escribió:
>> On Thu, 15 Sep 2011, Manu wrote:
>>
>> Hi,
>>
>>> In line with what Antonio said ...
>>> Will it be possible to do an entire class C Language?
>>> I say this because just the functions that manage the creation of
>>> classes with inheritance and visibility of instance variables are
>>> all static ... and those that are not compatible with Cli*per do not
>>> have all its functionality ...
>> I'm very interesting in Cli*per interface you are talking about
>> which we are not compatible.
>> Can you present list of missing functions which exist in Cli*per
>> but not in Harbour?

best regards,

Teo

[Manu]

Muchas gracias Teo.
Nos estamos viendo.

[Viktor Szakáts]

Hi Teo,

On Fri, Sep 16, 2011 at 7:29 PM, Teo Fonrouge <tfon...@gmail.com> wrote:
> Hi Viktor,

>
> Fundamentally the whole implementation is not reentrant nor thread-safe
> because it's using unprotected static vars to hold states. I don't remember
> more details but the most obvious is:
>
>       static PHB_DYNS s___HBCLASS = NULL;

This is supposed to be fixed by enclosing access to
these static vars inside a global mutex, so they are
serialized now.

It was added recently by Pritpal to trunk.

Please tell if you still find problem with latest version
of this.

Viktor

[Teo Fonrouge]

I've checked in the current SVN and seems that Pritpal has been taken care to
to protect the section that defines the hb class in the final cpp sources. So if it
will be used in this way, I don't see further MT problems with usage of this code.

best regards,

Teo

[Viktor Szakáts]

Thank you Teo.

Viktor