@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.

http://pastebin.com/mWUCsqXt

@nargil: już chciałem plusnąć a tu nagle z makrami wyskoczyłeś. masz ty rozum i godność?

@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.

@kamil062: w zależności jakiego kompilatora używasz, są gotowe różne sposoby na definiowanie właściwości.
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.

@Ingvarr100th: VS2013
Czyli że co? Lepiej używać właściwości na styl C#?

@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.

@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, jakPokaż całość

@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ć.

@kamil062: Ogólnie zależy od projektu - są 2 szkoły jedna będzie mniej więcej tak jak napisałeś, druga, będzie grupowała wg typów i będzie np

int getIntValue(enum myTypes akind);

Jedno i drugie jest używane, w zależności jak są pogrupowane zmienne ect.

@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żePokaż całość

@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ę.