Michal Kleczek wrote:
> Krzysiek Kowaliczek wrote:
>
> [ciach]
>> np.:
>> struct Item
[ciach]
>>
>
> Ja chyba potrzebuje jasniej :)
> Nadal nie widze tutaj pobierania obiektow Item z mapy.
> Co robi mapa::getId() ?
>

Powiedzmy, że jest to globalny obiekt z dwoma
funkcjami statycznymi getId, releaseId za którymi
kryje się mapa :).

Pozdrawiam
KK

do góry

Krzysiek Kowaliczek wrote:

[ciach]
>
> Powiedzmy, że jest to globalny obiekt z dwoma
> funkcjami statycznymi getId, releaseId za którymi
> kryje się mapa :).
>

Prosze...
Wezmy scenariusz:
1. mamy sobie mape long->Item
2. przychodzi komunikat
3. parsujemy komunikat i odczytujemy id obiektu ktorego dotyczy
4. musimy w mapie znalezc obiekt odpowiadajacy temu id
5. jezeli program nie trzyma (poza mapa) referencji do danego obiektu -
musimy usunac mapowanie z mapy

Moge zobaczyc ten kod w cpp?

--
Michal

do góry

Michal Kleczek wrote:
> Krzysiek Kowaliczek wrote:
>
> [ciach]
>> Powiedzmy, że jest to globalny obiekt z dwoma
>> funkcjami statycznymi getId, releaseId za którymi
>> kryje się mapa :).
>>
>
> Prosze...
> Wezmy scenariusz:
> 1. mamy sobie mape long->Item
> 2. przychodzi komunikat
> 3. parsujemy komunikat i odczytujemy id obiektu ktorego dotyczy
> 4. musimy w mapie znalezc obiekt odpowiadajacy temu id
> 5. jezeli program nie trzyma (poza mapa) referencji do danego obiektu -
> musimy usunac mapowanie z mapy
>

Z dokładnością do tego, że należałoby przenieść
definicje metod do .cpp, aby uniknąć cyklicznych zależności.

struct mapa
{
static void setId ( Item& item )
{
int id = findFreeId ();
map_.insert ( std::make_pair ( id, &item ) );
}


static void releaseId ( Item& item )
{
map_.erase ( item.id_ );
}

static Item* findItem ( int id )
{
std::map<int, Item*>::iterator it =
map_.find ( id );
if ( it != map_.end () )
return it-> second;
else
return 0;
}

private:
static std::map<int, Item*> map_;

}

struct Item
{
~Item ()
{
mapa::releaseId ( *this );
}

Item ()
{
mapa::setId ( *this );
}

int id_;

};

I teraz niezależnie czy tworzymy obiekty na stosie
czy alokujemy dynamicznie ( pod warunkiem, że go zwolnimy ),
zawsze zadziała.

Pozdrawiam
KK

do góry

Krzysiek Kowaliczek wrote:

> Michal Kleczek wrote:
>> Krzysiek Kowaliczek wrote:
>>
>> [ciach]
>>> Powiedzmy, że jest to globalny obiekt z dwoma
>>> funkcjami statycznymi getId, releaseId za którymi
>>> kryje się mapa :).
>>>
>>
>> Prosze...
>> Wezmy scenariusz:
>> 1. mamy sobie mape long->Item
>> 2. przychodzi komunikat
>> 3. parsujemy komunikat i odczytujemy id obiektu ktorego dotyczy
>> 4. musimy w mapie znalezc obiekt odpowiadajacy temu id
>> 5. jezeli program nie trzyma (poza mapa) referencji do danego obiektu -
>> musimy usunac mapowanie z mapy
>>
>
> Z dokładnością do tego, że należałoby przenieść
> definicje metod do .cpp, aby uniknąć cyklicznych zależności.
>
> struct mapa
> {
> static void setId ( Item& item )
> {
> int id = findFreeId ();
> map_.insert ( std::make_pair ( id, &item ) );
> }
>
>
> static void releaseId ( Item& item )
> {
> map_.erase ( item.id_ );
> }
>
> static Item* findItem ( int id )
> {
> std::map<int, Item*>::iterator it =
> map_.find ( id );
> if ( it != map_.end () )
> return it-> second;
> else
> return 0;
> }
>
> private:
> static std::map<int, Item*> map_;
>
> }
>
> struct Item
> {
> ~Item ()
> {
> mapa::releaseId ( *this );
> }
>
> Item ()
> {
> mapa::setId ( *this );
> }
>
> int id_;
>
> };
>
> I teraz niezależnie czy tworzymy obiekty na stosie
> czy alokujemy dynamicznie ( pod warunkiem, że go zwolnimy ),
> zawsze zadziała.

Eee... dla mnie to kicha, bo nie mozna sobie na boku zapamietac (referencji
do) obiektu Item ktorym jestem zainteresowany (np. na czas zycia okienka,
ktore pokazuje dany Item - kazde takie okienko bedzie mialo swoja kopie lub
wskaznik wskazujacy w kosmos).

--
Michal

do góry

Michal Kleczek wrote:

> Eee... dla mnie to kicha, bo nie mozna sobie na boku zapamietac (referencji
> do) obiektu Item ktorym jestem zainteresowany (np. na czas zycia okienka,
> ktore pokazuje dany Item - kazde takie okienko bedzie mialo swoja kopie lub
> wskaznik wskazujacy w kosmos).
>

Jak to nie można? Czas życia Item zależy od tego,
kto tworzy ten obiekt. Dla alokacji na stosie będzie
to zakres w którym obiekt żyje. Dla alokacji dynamicznej
można użyć np.: "sprytnych wskaźników", które będą dzielone
pomiędzy kilku użytkowników.

Pozdrawiam
KK

do góry

Krzysiek Kowaliczek wrote:

> Michal Kleczek wrote:
>
>> Eee... dla mnie to kicha, bo nie mozna sobie na boku zapamietac
>> (referencji do) obiektu Item ktorym jestem zainteresowany (np. na czas
>> zycia okienka, ktore pokazuje dany Item - kazde takie okienko bedzie
>> mialo swoja kopie lub wskaznik wskazujacy w kosmos).
>>
>
> Jak to nie można? Czas życia Item zależy od tego,
> kto tworzy ten obiekt. Dla alokacji na stosie będzie
> to zakres w którym obiekt żyje. Dla alokacji dynamicznej
> można użyć np.: "sprytnych wskaźników", które będą dzielone
> pomiędzy kilku użytkowników.
>

:)
Na poczatku wlasnie pytalem o kawalek kodu w cpp, ktory robi to _bez_ uzycia
smart pointerow - ktore defacto sa namiastka GC.

--
Michal

do góry

Michal Kleczek wrote:
> :)
> Na poczatku wlasnie pytalem o kawalek kodu w cpp, ktory robi to _bez_ uzycia
> smart pointerow - ktore defacto sa namiastka GC.
>

Wcale nie musisz używać "sprytnych wskaźników", np.:
zapamiętujesz obiekty Item w liście, wyświetlasz okna
lub inaczej "cudujesz" z obiektami Item. Po przetwarzaniu
usuwasz obiekty z listy.

Pozdrawiam
KK

do góry

On 27 Lip, 11:30, Jacek Czerwinski <x...@...z.pl> wrote:

> 1. Eclipse SWT [...]
> Obiekty pierwszego poziomu trzeba niestety dispose() czyli plus/minus
> close()
>
> Nie wyczułem jednak w twoim 'opowiadaniu' relacji rodzicielskich.

Bo ich nie ma a w szczególności to właśnie Item jest rodzicem.

> 2. Inna idea Spring JDBC odnośnie często źle zwalnianych zasobów
> (bazodanowych), zamyka je w przedział czasu.

Nie różni się to niczym od tego, co mam z wątkiem czyszczącym.

> 3. Trzecia idea, też z baz. Pule.

Tak naprawdę to bazy danych nie są w żaden sposób szczególne. Systemy
bazodanowe też są systemami rozproszonymi i ostatecznie wszystkie
problemy z zarządzaniem czegokolwiek są tam do siebie podobne - i mają
podobne rozwiązania.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

Krzysiek Kowaliczek wrote:

> Michal Kleczek wrote:
>> :)
>> Na poczatku wlasnie pytalem o kawalek kodu w cpp, ktory robi to _bez_
>> uzycia smart pointerow - ktore defacto sa namiastka GC.
>>
>
> Wcale nie musisz używać "sprytnych wskaźników", np.:
> zapamiętujesz obiekty Item w liście, wyświetlasz okna
> lub inaczej "cudujesz" z obiektami Item. Po przetwarzaniu
> usuwasz obiekty z listy.
>

A skad wiesz _kiedy_ mozna juz usunac Item z listy?

--
Michal

do góry

On 27 Lip, 12:09, Michal Kleczek <k...@g...com> wrote:

> > Nie trzeba watku skanujacego - wystarczy usuwajacy. Od skanowania jest
> > java.lang.ref.ReferenceQueue
>
> Sprobuj moze jakos tak:

[...]

Tak, to wygląda ciekawie. W moim przypadku mogłoby to być nawet trochę
prostsze, ale rdzeń rozwiązania pasuje do problemu. Dziękuję za
pomysł.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry