@kamil062: tak, po co masz bić głową w mur jak to jest już zaimplementowane i dobrze przetestowane. I taki pro tip: kompilator w VS2013 ma problemy z agresywną optymalizacją. Możliwe, że w Update 5 to już poprawili no ale na początku bywały problemy.
@kamil062: zdecydowanie nie. Chyba, że jesteś w 100% pewny, że twój kod ma się kompilować TYLKO pod windowsem i tylko z użyciem "jedynego słusznego" kompilatora. Już bym wolał sobie napisać makro, które się rozwinie do deklaracji, settera i gettera.
@inplaz: nie uważam, by to było dobre, ale jeśli ktoś jest leniwy, to już lepsze to, niż: 1. używanie public memberów 2. użycie jakichś c# w kodzie c++
to powyżej to zdecydowany overkill, ale są fajne makra, jak
@kamil062: Nie jest lepiej, bo jest nieprzenośne... Ogólnie to szkoda, że nie wprowadzono podobnego mechanizmu do języka, ale skoro nie ma, to całkowicie nieprzenośnych (nawet na jednej platformie sprzętowej) rzeczy bym raczej się wystrzegał..
@Kaczus2B: Akurat nie musi być przenośne bo to tylko projekt na studia więc jak się odpali na Windowsie pod VS2013 to będzie luz ale pytam jakie są dobre praktyki bo obiektowo w C++ za dużo do tej pory nie miałem okazji robić.
@nargil: tej przenośności to nie nadużywajmy jeżeli nie potrzeba, a jeżeli zajdzie taka potrzeba to zostawmy to zadanie językom wysokopoziomowym. Jak piszesz super wydajną aplikację to lepiej skroić ją pod konkrenty system (a nawet sprzęt w skrajnych przypadkach). Wyjątkiem mogą tu być gry, ale np. wielowątkowość najczęściej i tak trzeba prawdopodobnie przerabiać jeżeli ma się odpalić aplikacja działająca na Windows, na systemie zgodnym z POSIX.
@Ingvarr100th: Jeśli jest coś nieprzenośne w ramach jednej platformy systemowej, to już nie jest dobrze. Co innego jeśli coś jest zależne od systemu, a co innego jeśli jest tylko rozszerzeniem kompilatora.... Dziś jest, a czy jutro będzie?
@Kaczus2B: w zastosowaniach profesjonalnych, gdzie wsparcie masz wydłużone problem z "znikaniem" rzeczy jest znikomy. Oznacza się najczęściej jako obsolete ale nie usuwa. Nieprzenośność w obrębie jednej platformy to mało spotykany problem (na pewno rozszerzenie o właściwości tego nie powoduje), ale czasami konieczny, tym bardziej jak się pracuje na specyficznym sprzęcie.
@nargil: miałem cię krytykować za te makra, ale jak zobaczyłem propozycję tego property, to faktycznie, masz rację makra są lepsze.
Zastanawia mnie tylko, co jest złego w publicznych zmiennych. Tzn. to, co powstaje z twojego makra, w niczym, w moim przekonaniu, nie różni się od publicznej zmiennej.
@kamil062: jesteś pewien, że aż tak często będziesz potrzebował upubliczniać swoje pola w sposób inny, niż trywialny (tzn. 'domyślny' get/set)? Może
@sasik520: refaktoryzacja. Kiedy wystarczy ci prosty get set, to makro załatwia sprawę. Później możesz ręcznie napisać inny getter / setter i nie zmieniać użyć. Gdy masz public membery, to potem bez parsera c++ ciężko zmienić dużą bazę kodu.
@nargil: jest to jakiś argument ;) Faktycznie w c# czy ruby, których na co dzień używam, zmiana ze zwykłego pola na getter jest darmowa, bo sposób użycia (bez nawiasów) się nie zmienia.
Ale szczerze powiedziawszy, rzadko zdarza mi się robić tego rodzaju zmianę.
class A {
private:
static int var;
public:
static int getVar();
};
Czy takie rozwiazanie jest wystarczające czy są jakieś specjalne konwencje dotyczące tego?
Przykłady które ja znam:
https://msdn.microsoft.com/pl-pl/library/es7h5kch.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/yhfk0thd.aspx
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Property_Implements_Support_for_C%2B%2BBuilder
Jednakże, filozofia pisania w C++ mija się z potrzebą ich używania.
Czyli że co? Lepiej używać właściwości na styl C#?
Już bym wolał sobie napisać makro, które się rozwinie do deklaracji, settera i gettera.
http://pastebin.com/mWUCsqXt
1. używanie public memberów
2. użycie jakichś c# w kodzie c++
to powyżej to zdecydowany overkill, ale są fajne makra, jak
int getIntValue(enum myTypes akind);
Jedno i drugie jest używane, w zależności jak są pogrupowane zmienne ect.
Zastanawia mnie tylko, co jest złego w publicznych zmiennych. Tzn. to, co powstaje z twojego makra, w niczym, w moim przekonaniu, nie różni się od publicznej zmiennej.
@kamil062: jesteś pewien, że aż tak często będziesz potrzebował upubliczniać swoje pola w sposób inny, niż trywialny (tzn. 'domyślny' get/set)? Może
Ale szczerze powiedziawszy, rzadko zdarza mi się robić tego rodzaju zmianę.