Jak fungují řetězce (String) – Visual Basic – Fórum – Programujte.com

Chtěl bych vědět co se děje na pozadí VBA, když dojde třeba na přiřazení řetězce.

dim retezec as string
dim retezec2 as string
retezec="aaa"
retezec2="bbbbbb"
retezec = retezc2

Moje představa je, že se nejdřív uvolní paměť proměnné retezec, aby nezůstal navždy v paměti a pak se předá ukazatel na nový řetězec, nebo je to jinak? Řetězce ve VBA jsou typu BSTR, BSTR je ukazatel na data řetězce, která jsou (aspoň v mojí knihovně) uložené na hromadě přes new... Taky jestli se VBA při rušení řetězce postará a smazaní toho co bylo alokováno přes new, což jsou všechny data toho BSTR (prefix, data, terminator)?

#1 Kartik
O dealokaci stringu a související defragmentaci paměti se postará až Garbage Collector.

#1 Kartik
String je immutable, takže se to chová trochu zvláštně. Tady to docela pěkně vysvětlují sice pro javu, ale princip bude stejný.

Jde mě o to VBAčko, kde se uvolňování děje aniž to mohu ovlivnit... Ať už to tedy funguje jak chce, tak hlavní je teď pro mě, jestli to správně uvolní i řetězec, který pochází z mojí dll knihovny, nebo jestli se o jeho zrušení musím postarat taky já. Jestli v tom VBAčko nevidí rozdíl odkud řetězec pochází, nebo jestli musí být nějak speciálně alokovaný...

Nevim jak přesně funguje Garbage Collector, ale tedy nejspíš sníží počet referencí a pokud je počet 0, tak to tu paměť až se mu zachce uvolní?

#4 Kartik
Je to navržreno tak, aby ses o dealokaci vůbec nemusel starat. Stačí opustit scope, string se stane nedostupným a časem je zlikvidován.

Jen si dávej pozor, abys v cyklu nepřidával na konec stringu znak po znaku, protože při každé takové operaci se vytváří nový string a ten původní se zahodí. U delších stringů je to pak dost neefektivní.

#5 Kit
Takže ještě pro jistotu, ať už tedy vytvořim ten řetězec kdekoliv mimo VBA, tak se o něj VBA postará?

Jo tohle jsem před časem řešil.. udělat na začátku dostatečně dlouhý řetězec a pak tam vepisovat ty kratší je o dost rychlejší. Teď právě kvůli operacím s řetězci dělam knihovnu v C++.

#6 Kartik
A proč děláš takové vylomeniny?

#6 Kartik
a co zkusit StringBuilder?

#7 Kit
Tak jednak se snažím přejít na C++, navíc ten kód je použitelnej jak ve VBA tak v C a mělo by to i běhat rychlejš než kdyby to bylo čistě ve VBA, alespoň ty místa kde to nejvíc drhne přepisuju do C. Další věc co mě na VBAčku štve, je že nejde kompilovat a zdrojový kód nejde zabezpečit, heslo je tam spíš jen tak na okrasu.

#8 BDS
Neznám a jak mi to pomůže?

#9 Kartik
Předčasná optimalizace je kořenem všeho zla.

#10 Kartik
Dělá totéž, co se snažíš pytlíkovat v C++, ale nemusíš přitom opouštět VBA.

#10 Kartik
V podstatě to funguje jako pole znaků, takže je to ideální pro modifikaci textových řetězců. Na rozdíl od stringu se při editaci nezakládá vždy nový objekt (dokud nepřekročíš jeho kapacitu). Více..

#13 BDS
Ale já potřebuju ten BSTR dostat do VBA, ve kterém je to jediný typ pro řetězce. Problém není s operacemi s řetězcem. Třeba nevim proč, nebo jaký je rozdíl mezi řetězcem vytvořeným přes SysAllocString nebo pokud ho vytvořím binárně... následně SysFreeString funguje jen ty vytvořené přes funkci, otázka je tedy jak ten řetězec uvolňuje VBA.

#14 Kartik
Proč se tímto vůbec zabýváš? Pokud tu aplikaci napíšeš správně v tom VBA, tak nemůžeš mít žádné potíže s výkonem na stringových operacích.

Hlavně proto, že když napíšu nějaké základní funkce, které nadále používám skoro ve všem co dělám, tak je mohu použít jak ve VBA tak v C, místo toho abych se pak se vším do C přepisoval a psal tedy vše 2x. O dalších výhodách jsem psal už výše.

Ano s řetězci až tak zásadní problém s výkonem není, ten je spíš až při práci s geometrií, jen jsem chtěl začít s něčím snadným.

Já v tom případě stále nechápu, co Ti nefunguje.

Zatím, jsem to pochopil tak, že máš nějakou aplikaci, kterou píšeš ve VBA a do ní importuješ funkci, vracející pointer na řetězec BSTR z dll knihovny, kterou píšeš v C++. Chápu to správně?

Pokud ano, tak se  podle mě, o uvolnění řetězce, který si v dll alokoval, se musíš postarat v dll. Případně můžeš zavolat funkci v dll, která se postará o uvolnění paměti. Každopádně aplikace, nemůže vědět co funkce v dll alokují, pokud jí to nezdělíš. Obvykle se dll předává v parametrech funkce pointer na již alokovaný prostor a jeho velikost a dll do tohoto prostoru zapíše výsledek (u řetězců v .NET to bývá většinou zmíněný StringBuilder, nebo pole).

ps, tím jak pracuje GC bych se nezabýval, protože se domnívám, že to nebude jen o tom, že něco co již program nepotřebuje, to ihned smaže. Předpokládám, že tu budou hrát roli aktuální stav a vytíženost paměti, povaha aplikace atd.

Ikdyž teď mě napadá, že pomocí bstr předáš i délku, a importuješ pomocí "Marshalu" tak by se vlastně o likvidaci mohla postarat i VBA aplikace... Tohle nevím.

#17 BDS
Ano chápeš to správně. Jde mě o to jestli právě to VBA nějak rozliší co si alokovalo samo a to co přišlo odjinud, nebo jestli to zruší úplně stejně, nebo jak to udělat, aby se k tomu chovalo jako ke svému.

A vy co tomu rozumíte, tak jak jsem psal zrovna u těch řetězců je funkce SysAllocString, řetězec z té funkce se uvolňuje zas přes SysFreeString a podobně je spousta jiných funkcí, kde jedna vytváří a další ruší. Vrtá mě hlavou co zrovna v tomto, nebo jiných případech ta funkce udělá, že ta rušící funkce pozná, odkud jsou ta samá data, to znamená, že pokud nejsou vytvořena pomocí funkce, tak mazací funkce hlásí chybu.