Stare pliki INI

A tam przestarzale… Spelniaja swoja role, wiec czemu ich nie uzywac ? Do jakiejs prostej konfiguracji gdzie taki XML moze byc zbyt przerosniety i zaciemniajacy, czemu nie….

Co do tego API obecnego w Windowsie, warto podkreslic ze kazda taka funkcja parsuje caly plik od nowa, co moze miec znaczenie gdy bedziemy odwolywac sie wiele razy do takiej zmiennej badz miec spory plik .ini ;)

Tak właściwie to zawsze się zastanawiałem w czym właściwie rejestr jest lepszy od plików ini… fakt, wygodnie się dzięki niemu grzebie w systemie, ale po niedługim czasie jest zaśmiecony kluczami utworzonymi przez oprogramowanie, w tym to które już zostało usunięte. Rozrasta się to i tylko spowalnia wszystko ;P

po co bawić się w takie antyki skoro od dawna do c++ są dobre biblioteki do xmla (a w c# to już wogle jest poezja).

Bo XML jest duży, brzydki i nieczytelny :).
W przypadku prostych aplikacji XML to totalny overkill, a w przypadku ciut bardziej złożonych wolałbym już widzieć s-expressions (z grubsza to samo, tylko nie tak przeładowane tekstem). Może to kwestia osobistej preferencji, ale ja XMLa nigdy nie lubiłem :).

@vashpan: W Delphi była (jest?) klasa TMemIniFile, która ładowała cały plik INI do pamięci i go tam buforowała, więc takiego problemu w niej nie było. Zapewne jednak nie korzystała ona z funkcji, które opisałem.

@Sharp: Chyba największą wadą plików INI jest to, że sekcje nie mogą tworzyć hierarchii (czyli nie można ich zagnieżdżać). Kiedyś opracowałem nawet coś w rodzaju ulepszonego formatu INI (opartego trochę na DirectX-owych plikach X), który to ograniczenie usuwał, oczywiście za cenę trochę innej składni. Będę musiał wygrzebać kod parsera i może go zamieścić :)

@jewjews: Popularność rozwiązań takich jak YAML czy JSON dowodzi, że rozwlekły XML nie wszędzie może/powinien być stosowany. A odrzucanie jakiegoś rozwiązania tylko dlatego, że jest stare, jest niespecjalnie logiczne.

iii tam, przesadzacie trochę z tą alergią na XMLa. Jak się dobrze zdefiniuje format, to wychodzi jakieś 5 znaków więcej na linijce niż .ini, a jednocześnie mamy całe dobrodziejstwo hierarchiczności.

Z drugiej strony, kompletnie nie widzę sensu używania tej funkcji. Napisanie takiego parsera samemu to pół godziny roboty, nie mamy problemu z dodawanie nowych funkcjonalności (wczytywanie całego pliku, dodatkowe rodzaje danych), nie mamy problemu z wieloplatformowością (Linux albo Windows 12), no i (w moim przypadku) nie musimy wygrzebywać jakiegoś dziwnego API ;)

@Liosan, tylko po co mam definiowac jakis format XML jak potrzebna mi jest prosta konfiguracja, bez zadnej hierarchii czy innych pierdol ? Sporo softu uzywa nadal plikow .ini i .ini-podobnych i jakos nikt nie placze :) , nawet jezeli do innych celow uzywa sie XML. Zreszta porownywanie XML i starych pliczkow .ini nie ma wiekszego sensu bo w sumie maja nieco inne zastosowanie, mimo ze XML mozna uzyc do tego do czego najlepiej nadaje sie .ini…

@Sharp Rejestr nie jest zly, jego idea byla dobra :) Zintegrowana konfiguracja zamiast gazyliona plikow .ini czy roznorakich pliczkow w gazylionie roznych formatow, jak w Uniksach… Problem w tym ze sie troche rozrosl, nie ma jakiegos zintegrowanego zarzadzania nim przez system i jego struktura nie jest zbyt “intuicyjna”

Powinni zakazać używania tych okropnych, brzydkich i nieprzenośnych funkcji do plików .ini z WinAPI. W kilka sekund można przecież napisać własny parser korzystający na przykład z kliku klas z STL’a.