🚀 go-pugleaf

W dniu środa, 1 lutego 2017 09:24:35 UTC+1 użytkownik Borneq napisał:
> Skonstruowałem niewielką ale fajną klasę do plików ini. Można między 
> innymi wczytywać zawartość sekcji do wektora kluczy, do wektora par 
> klucz:wartość a nawet do mapy kluczu:wartość.
> Klasa obsługuje nie tylko odczyt ale i zapis, przy czym gdy ręcznie 
> napiszemy ini, a potem coś zapiszemy, to nie psuje nam kolejności a 
> nawet nie psuje nam komentarzy zamieszczanych w ini.
> Można czytać wartości tak, że w przypadku nie wystąpienia będzie 
> wyjątek, albo funkcje ..Def które podadzą domyślną wartość.
> Licencja MIT.
> link: https://github.com/borneq/IniParser
> 
> Pozdrawiam

dla mnie ok, [ jak na c++ ;o ] 

dosyc czytelne jesli chodzi o powierzchnie kodu
(co do samej mechaniki to sie nie wczytywalem ale 
pewnie tez z grubsza ok) [w sumie to mozna mowic o
trzech warstwach bo jeszcze dochodzi "kompozycja
interfejsu" czy podobna, to ew troche kuleje o czym nizej]


pewien bład to te nazwy z z Def na końcu, troszeczke
tez kompozycja (kolejnosc deklaracji i funkcji w kodzie
moglabybyc chyba lepsza

mozna sie tez pewnie nieco przyczepic do nazw - nazwy powinny byc raczej pisane dla czytalnika kodu a nie dla jego tworcy - tj nie powinny chyba zakladac ze czytelnik wie co kod robi, pisarz nieststy wie i te nazwy pisze jakby pod siebie - wtedy czytelnik musi dedukowac co to wlasciwie robi i to zajmuje troche czasu - tutaj akurat kod jest jasny i maly ogolnie wiadomo co robi tak ze da sie wydedukowac w stosunkowo krotkim czasie ale jednak 
moglobybyc to chyba nieco lepiej

dla przykladu czy nie za duzo tu funkcji publicznych ?
ktore z tych musza byc publiczne a ktore raczej 
prywatne:

	IniParser(const string &filename, bool mustExist);
	~IniParser();
	void beginUpdate();
	void endUpdate();
	void reload(bool mustExist);
	void clearAll();
	bool sectionExists(const string &sectStr);
	bool keyExists(const string &sectStr, const string &keyStr);
	vector<string> readSections();
	vector<string> readSectionKeys(const string &sectStr);
	vector<pair<string, string>> readSectionPairs(const string &sectStr);
	unordered_map<string, string> readSectionMap(const string &sectStr);
	static string mapValue(unordered_map<string, string> map, const string &key);
	static string mapValueDef(unordered_map<string, string> map, const string &key, const string &def);
	
czy user tego obiektu moze recznie operowac na tych zwroconych mapach (w sensie pisania) czy raczej tylko do odczytu czy raczej nie powinien wogole?


pozatym to styl c++ ja nie pisze w c++ i dla mnie c++ 
jest co nieco crazy ale pominawszy to styl samego kodu dosyc ok


 

W dniu niedziela, 5 lutego 2017 11:18:27 UTC+1 użytkownik (fir) napisał:
> W dniu środa, 1 lutego 2017 09:24:35 UTC+1 użytkownik Borneq napisał:
> > Skonstruowałem niewielką ale fajną klasę do plików ini. Można między 
> > innymi wczytywać zawartość sekcji do wektora kluczy, do wektora par 
> > klucz:wartość a nawet do mapy kluczu:wartość.
> > Klasa obsługuje nie tylko odczyt ale i zapis, przy czym gdy ręcznie 
> > napiszemy ini, a potem coś zapiszemy, to nie psuje nam kolejności a 
> > nawet nie psuje nam komentarzy zamieszczanych w ini.
> > Można czytać wartości tak, że w przypadku nie wystąpienia będzie 
> > wyjątek, albo funkcje ..Def które podadzą domyślną wartość.
> > Licencja MIT.
> > link: https://github.com/borneq/IniParser
> > 
> > Pozdrawiam
> 
> dla mnie ok, [ jak na c++ ;o ] 
> 
> dosyc czytelne jesli chodzi o powierzchnie kodu
> (co do samej mechaniki to sie nie wczytywalem ale 
> pewnie tez z grubsza ok) [w sumie to mozna mowic o
> trzech warstwach bo jeszcze dochodzi "kompozycja
> interfejsu" czy podobna, to ew troche kuleje o czym nizej]
> 
> 
> pewien bład to te nazwy z z Def na końcu, troszeczke
> tez kompozycja (kolejnosc deklaracji i funkcji w kodzie
> moglabybyc chyba lepsza
> 
> mozna sie tez pewnie nieco przyczepic do nazw - nazwy powinny byc raczej pisane dla czytalnika kodu a nie dla jego tworcy - tj nie powinny chyba zakladac ze czytelnik wie co kod robi, pisarz nieststy wie i te nazwy pisze jakby pod siebie - wtedy czytelnik musi dedukowac co to wlasciwie robi i to zajmuje troche czasu - tutaj akurat kod jest jasny i maly ogolnie wiadomo co robi tak ze da sie wydedukowac w stosunkowo krotkim czasie ale jednak 
> moglobybyc to chyba nieco lepiej
> 
> dla przykladu czy nie za duzo tu funkcji publicznych ?
> ktore z tych musza byc publiczne a ktore raczej 
> prywatne:
> 
> 	IniParser(const string &filename, bool mustExist);
> 	~IniParser();
> 	void beginUpdate();
> 	void endUpdate();
> 	void reload(bool mustExist);
> 	void clearAll();
> 	bool sectionExists(const string &sectStr);
> 	bool keyExists(const string &sectStr, const string &keyStr);
> 	vector<string> readSections();
> 	vector<string> readSectionKeys(const string &sectStr);
> 	vector<pair<string, string>> readSectionPairs(const string &sectStr);
> 	unordered_map<string, string> readSectionMap(const string &sectStr);
> 	static string mapValue(unordered_map<string, string> map, const string &key);
> 	static string mapValueDef(unordered_map<string, string> map, const string &key, const string &def);
> 	
> czy user tego obiektu moze recznie operowac na tych zwroconych mapach (w sensie pisania) czy raczej tylko do odczytu czy raczej nie powinien wogole?
> 
> 
> pozatym to styl c++ ja nie pisze w c++ i dla mnie c++ 
> jest co nieco crazy ale pominawszy to styl samego kodu dosyc ok

pmietm ze kiedys pisalem chyba podobne procedury ale to bylo z 10 lat temu i niewiele pamietam nie wiem tez czy nie uzywalem wbudowanych funkci z winapi

ogolnie co do tego interfeju to chyba wolalbym prostszy
i nawet ograniczony interfejs cos w stylu:

void main()
{
 
 inifile_write("my.ini", "my_section", 
            "my_key3", "zzz");

 char* v = inifile_read("my.ini", "my_section", 
                       "my_key3");
  
}

jak ktoby chcial wykonywac jakies chocki klocki na tych 
plikach ini to mona zwracac mapy sekcji itd ale tak naprawde to raczej nie jest od tego

co do tego kodu wyzej to ja zwykle (wlaciwie niemal zawsze) uzywam dlugich nazw pascalem (ktore wygladaja gorzej) choc otatnio zastanawiam sie czy funkcji bibliotecznych (a te a biblioteczne) nie piac wlanie moze malymi