Převod List<a> na Vect<a,n>

[Ink]

Ja to chápem tak, že pamäť pre vektor sa alokuje ako počet dát krát veľkosť dát, takže musia byť dáta za sebou v pamäti.

Nekonečná kolekcia je niečo ako zreťazený zoznam a má porozhadzované prvky v pamäti a ešte prvý prvok musí mať smerník na samotné dáta a smerník na druhý prvok, druhý prvok má smerník na svoje dáta a smerník na ďalší prvok, atď. Posledný prvok má smerník na ďalší prvok nastavený na Null. Takže sa dajú ľahko pridať ďalšie dáta, stačí správne ponastavovať smerníky na ďalší prvok v predchádzajúcom a pridávanom prvku.

"Nekonečná" kolekce může být taky vektor. A naštěstí většinou i bývá.

[Reklama]

[Karmelos]

Jsem myslel, že dneska se to dělá tak, že si vytvořím třídu ve který bude ten list i jeho délka jako vlastnost. V okamžiku převodu na vektor budu délku pak vědět. No vlastně v tý třídě může být rovnou i ten vektor...
Nebo ne?

[alex6bbc]

Jsem myslel, že dneska se to dělá tak, že si vytvořím třídu ve který bude ten list i jeho délka jako vlastnost. V okamžiku převodu na vektor budu délku pak vědět. No vlastně v tý třídě může být rovnou i ten vektor...
Nebo ne?

deka listu ve tride listu muze byt, ale michat tam i vektor je nadbytecne.

[Ink]

Jsem myslel, že dneska se to dělá tak, že si vytvořím třídu ve který bude ten list i jeho délka jako vlastnost. V okamžiku převodu na vektor budu délku pak vědět. No vlastně v tý třídě může být rovnou i ten vektor...
Nebo ne?

deka listu ve tride listu muze byt, ale michat tam i vektor je nadbytecne.

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.

[BoneFlute]

Jsem myslel, že dneska se to dělá tak, že si vytvořím třídu ve který bude ten list i jeho délka jako vlastnost. V okamžiku převodu na vektor budu délku pak vědět. No vlastně v tý třídě může být rovnou i ten vektor...
Nebo ne?

deka listu ve tride listu muze byt, ale michat tam i vektor je nadbytecne.

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.

To se takhle nedá říct. Pokud tu kolekci používáš tak, že tam často přidáváš a odebíráš prvky na různá místa, bude spojový seznam lepší volba.

[Reklama]

[Ink]

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.

To se takhle nedá říct. Pokud tu kolekci používáš tak, že tam často přidáváš a odebíráš prvky na různá místa, bude spojový seznam lepší volba.

Ano, pro tento velmi specifický případ se spojový seznam celkem hodí (za předpokladu, že moc nepotřebuješ náhodný přístup), sice jsem to v praxi neviděl, ale nezpochybňuju to. Ale když tam přidáš vektor - a to je základ mého příspěvku - už můžeš spojový seznam zahodit, protože režii přidávání a odebírání na vektoru se nevyhneš.

[BoneFlute]

Spíš je tam nadbytečný ten spojový seznam, většinou chceš jenom vektor. A když ho spojíš s vektorem, výhody listu zabiješ úplně.

To se takhle nedá říct. Pokud tu kolekci používáš tak, že tam často přidáváš a odebíráš prvky na různá místa, bude spojový seznam lepší volba.

Ano, pro tento velmi specifický případ se spojový seznam celkem hodí (za předpokladu, že moc nepotřebuješ náhodný přístup), sice jsem to v praxi neviděl, ale nezpochybňuju to. Ale když tam přidáš vektor - a to je základ mého příspěvku - už můžeš spojový seznam zahodit, protože režii přidávání a odebírání na vektoru se nevyhneš.

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

[Ink]

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná? Pokud to nedělá runtimovou analýzu v konkrétním běhu nebo nějakou dlouhodobou statistiku, tak bych na to nespoléhal...

[BoneFlute]

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná?

Jak to píšu. Pozná to na základě znalosti kódu. Koukne a vidí, že ta kolekce se používá tady a tady a tady a tady, způsobem tak a tak a tak. Tudíž nejoptimálnější by bylo mít tu strukturu takto.

Pokud to nedělá runtimovou analýzu v konkrétním běhu nebo nějakou dlouhodobou statistiku, tak bych na to nespoléhal...

JIT je dobrý na něco jiného. Na zohlednění reálných dat a reálného chování.

Ani v jednom případě bych k tomu programátora nepouštěl.

[Ink]

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná?

Jak to píšu. Pozná to na základě znalosti kódu. Koukne a vidí, že ta kolekce se používá tady a tady a tady a tady, způsobem tak a tak a tak. Tudíž nejoptimálnější by bylo mít tu strukturu takto.

A jak z toho (obecně) pozná, jaká je frekvence kterých operací? To přece musí záviset mimo jiné na vstupních datech.

[BoneFlute]

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná?

Jak to píšu. Pozná to na základě znalosti kódu. Koukne a vidí, že ta kolekce se používá tady a tady a tady a tady, způsobem tak a tak a tak. Tudíž nejoptimálnější by bylo mít tu strukturu takto.

A jak z toho (obecně) pozná, jaká je frekvence kterých operací? To přece musí záviset mimo jiné na vstupních datech.

To píšu výše, ne?

[Ink]

No, a moje pointa mého původní příspěvku je, že nevím, proč bych to měl drátovat do typů. Prostě si vytvořím kolekci [Foo] a nechám kompilátor odvodit podle užití, jak moc v kódu používám přístup k počtu prvků (-> přidá count do interní struktury pro Foo), jak často přidávám/odebírám prvky uvnitř seznamu (-> zvolí zda použít vektor, nebo spojový seznam). To mě, jako uživatele typů nezajímá, a kompilátor to dokáže rozhodnout lépe.

A jak to pozná?

Jak to píšu. Pozná to na základě znalosti kódu. Koukne a vidí, že ta kolekce se používá tady a tady a tady a tady, způsobem tak a tak a tak. Tudíž nejoptimálnější by bylo mít tu strukturu takto.

A jak z toho (obecně) pozná, jaká je frekvence kterých operací? To přece musí záviset mimo jiné na vstupních datech.

To píšu výše, ne?

Aha, OK.