massiv-devel

[Massiv-devel] novosti

[Stepan V. <sv...@vo...>]

Cau,

Spousta drobnych nezajimavosti.

Asi nejdulezitejsi pro markoida je, ze IDL uz umi nove dva "externi" typy - 
class a enum. Takze jde delat pole objektu. Aspon doufam, ze to vygeneruje 
spravnej kod.

Zacal jsem taky delat na RPC results, neco je tam nacommitovano, ale nic to 
nedela, takze se nesnazte v tom vrtat.

Dalsi zavazna zmena je, ze misto:
 Remote< C > r;
 r->foo();
se pise
 r->async_foo();
aby bylo jasno, co se tim volanim mysli.

Protoze vim, ze me to kdysi davno prudilo, dodelal jsem do neremote pointeru 
trapnou metodu remote(), kterou se prevede na remote pointer. Takze lze:
 WeakPointer< C > p;
 p.remote()->async_foo();

Taky jsem vyresil problem s forward-deklaracemi trid v IDL (pokud se pouzil 
napr. pointer na tudle forward deklarovanou vec, nesel prelozit generovany 
kod). Kouknete se do zmen v node_object.idl - uz tam muze byt pointer na 
AccountObject a ne jak bylo driv na AccountObjectInterface (a pak se to 
konvertilo dynamicky).

-- Stoupik

Re: [Massiv-devel] novosti

[Marek V. <mvo...@ce...>]

> Dalsi zavazna zmena je, ze misto:
>  Remote< C > r;
>  r->foo();
> se pise
>  r->async_foo();
> aby bylo jasno, co se tim volanim mysli.

A.. to se mi nelibi. Doufam, ze pro synchronni verzi bude akorat "foo". Dale
by bylo pekne, kdyby ta asynchronni verze sla pouzit pro "deferred
synchronni volani" a nasledne pro "pure synchronni volani". Tj. objekt
vraceny asynchronni verzi by mel metodu wait_for_completion(), coz by slo
vyuzit nasledovne:
f_result = r->async_f();
r->async_g();
r->async_h();
f_result.wait_for_completion();

A ciste synchronni volani by znamenalo rovnou wait_for_completion().

> Protoze vim, ze me to kdysi davno prudilo, dodelal jsem do neremote
pointeru
> trapnou metodu remote(), kterou se prevede na remote pointer. Takze lze:
>  WeakPointer< C > p;
>  p.remote()->async_foo();

Mozna by se to mohlo trochu vylepsit/optimalizovat, ze by to umelo rovnou
vratit ten RPCStub, tj. semantika by odpovidala pretypovani na Remote<C> a
okamzitemu vyvolani operator->(), ale bez nutnosti konstruovat novy pointer.

> Taky jsem vyresil problem s forward-deklaracemi trid v IDL (pokud se
pouzil
> napr. pointer na tudle forward deklarovanou vec, nesel prelozit generovany
> kod). Kouknete se do zmen v node_object.idl - uz tam muze byt pointer na
> AccountObject a ne jak bylo driv na AccountObjectInterface (a pak se to
> konvertilo dynamicky).

Znamena to, ze teda funguje i to forward deklarovani trid v C++ a nasledne
vytvareni PPointeru na nedefinovane (ale deklarovane) tridy? Mel jsem obavu,
ze to mozna vubec nebude mozne kvuli tem cast objectum, ktere maji virtualni
funkci pouzivajici dynamic_cast() [ pricemz virtualni funkce se instanciuji
vzdy a dynamic_cast nelze pouzit na nedefinovany typ ].

-- Markoid

Re: [Massiv-devel] novosti

[Stepan V. <sv...@vo...>]

On Friday 16 of May 2003 15:26, Marek Vondrak wrote:

> Znamena to, ze teda funguje i to forward deklarovani trid v C++ a nasledne
> vytvareni PPointeru na nedefinovane (ale deklarovane) tridy? Mel jsem
> obavu, ze to mozna vubec nebude mozne kvuli tem cast objectum, ktere maji
> virtualni funkci pouzivajici dynamic_cast() [ pricemz virtualni funkce se
> instanciuji vzdy a dynamic_cast nelze pouzit na nedefinovany typ ].

To nevim, asi nejde. Jde to, ze dve tridy muzou mit pointer na sebe vzejemne, 
i kdyz jsou definovane v ruznych souborech (a tudiz jedna je jenom forward 
deklarovana v dobe, kdy se trida definuje; kdyz se ale trida pouziva, jsou uz 
definovane obe).

-- Stoupik