Статические члены и наследование

Очень необходимо реализовать то, что по принципу джавы могло бы писаться как:
class A {public:    static char visible = 1;};class B : public A {public:    static char visible = 0;};class C : public A {};A a;a.visible - 1B b;b.visible - 0C C;c.visible - 1
14 ответов

class A {public:    char visible;    A():      visible(1)    {};};class B : public A {public:    static char visible;    B() {};};class C : public A {public:    C() {};};char B::visible = 0;int main(){    A a;    B b;    C c;    return 0;}
Добавлено через 1 минуту и 2 секундыТолько непонятно зачем данные-члены делать public. 


Пардон, забыл статик в первом классе... А публичные - чтобы видеть извне.


 А публичные - чтобы видеть извне.
это и есть принципы джавы? небольшая "лекция"в любом ООП языке не рекомендуется делать переменные-члены публичнымиесли нужно - сделай функции геттер и сеттер для нужных переменныха если уж совсем ООП следовать, то переменные - это часть реализации и юзер класса вообще не должен знать о их существавонии и работать только через функции (для того в джаве интерфейсы и ввели)


Вообще, лучше бы уточнить, чего конкретно ты хочешь добиться. 


Вообще в любом ооп по лекциям требуется писать так, чтобы было красиво и медленно. Есть места, где такого делать не стоит (не все же сводится к офисным приложениям).А требуется делать так, чтобы у меня были объекты N разных типов (у меня N классов). Некоторые объекты visible, некоторые нет (ясно что visible относится к классам, поэтому если объекты относятся к одному классу, они все видимые скажем). Большинство видимые, поэтому главный класс visible = 1, и лишь в некоторых visible = 0.Чтобы потом экземпляр.visible возвращал правильные значения.


Есть места, где такого делать не стоит (не все же сводится к офисным приложениям).
Т.е. ты утверждаешь, что если сделать все данные-члены открытыми, то приложение будет работать быстрее? Ты не прав. Простейшие геттеры заменяются прямым обращение самим компилятором при оптимизации по скорости. К тому же есть inline. 
А требуется делать так, чтобы у меня были объекты N разных типов (у меня N классов). Некоторые объекты visible, некоторые нет (ясно что visible относится к классам, поэтому если объекты относятся к одному классу, они все видимые скажем). Большинство видимые, поэтому главный класс visible = 1, и лишь в некоторых visible = 0.
Здесь нельзя использовать static-данные. Они ведь общие для всех объектов. Скажем, будет у тебя 9 видимых объектов класса A, один ты решишь сделать невидимым, обнулив переменную visible. В итоге получишь, что все объекты, так или иначе, связанные с этой переменной станут невидимыми.Создай простой флаг visible типа bool, размести его в private секции и работай как обычно. Что тебя смущает то?


Так я ж сказал что все объекты одного типа либо видимые, либо нет. Другими словами изначально (то есть const) известно, что (возьму пример уже свой) косяк рыбы невиден для игрока (так как под водой), а дерево видимое. Ну хоть косяки окуней, хоть лосося, хоть в море хоть в реке - они все РЫБА, и они невидимые, а деревья хоть дуб хоть еще что-то - все ДЕРЕВЬЯ, и они видимые.


это и есть принципы джавы? smileнебольшая "лекция"в любом ООП языке не рекомендуется делать переменные-члены публичнымиесли нужно - сделай функции геттер и сеттер для нужных переменныха если уж совсем ООП следовать, то переменные - это часть реализации и юзер класса вообще не должен знать о их существавонии и работать только через функции (для того в джаве интерфейсы и ввели)
Интерестно кто такое сказал что "не рекомендуется", стандарт С++?вообще давайте подумаем почему член класса делать public не гуд - Пользователь класса может изменить содержание членов класса, и не более того, так вот Anton Vatchenko , привел пример где пользователь менят содержимое поля класса (visible) что в этом плохого?Может быть потому что он не делал вызов функции?  


Интерестно кто такое сказал что "не рекомендуется"
кроме стандарта есть еще куча литературы от неглупых людей + собственный опытзаново объяснять, чем хороша инкапсуляция, не очень хочетсядостаточно доступно объяснено в Новых сложных задачах на C++ Саттера (задача 17)


Люди, не спорьте. Просто объясните как реализовать то, что я указал.


вообще давайте подумаем почему член класса делать public не гуд
Так уже тысячу раз об этом передумано..Объект должен сам руководить своими внутреннеми процессами, а не полагаться на внешнее управление. Открытые переменные говорят об незакончености объекта.  Кастати объект состояших из Гетеров и Сеттеров тоже плох. В таком случае он объект, а блок данных.  Даже просто поняв разницу между двумя последними понятиями , можно почуствовать проблему открытых членов.А сводится все к тому что, если реализация класса выполнена приватно, то все связи находятся в одной локальной области и легки для проверки и контроля.Если объект предоствляет открытый доступ к реализации, то она расползается по всему коду программы и любая модификация исходника с каждым таким шагом сильно затрудняется... И не только модификация, но и просто понимание проги.ООП чем и хорош что предполагает что каждый объект можно протестировать(и понять) без участия остальных.Естественно , чем меньше  связей тем легче .. 


Так я ж сказал что все объекты одного типа либо видимые, либо нет. Другими словами изначально (то есть const) известно, что (возьму пример уже свой) косяк рыбы невиден для игрока (так как под водой), а дерево видимое. Ну хоть косяки окуней, хоть лосося, хоть в море хоть в реке - они все РЫБА, и они невидимые, а деревья хоть дуб хоть еще что-то - все ДЕРЕВЬЯ, и они видимые.
Ну ок. Делай несколько базовых классов(рыба, дерево), которые хранят static-флаг visible. 


Люди, не спорьте. Просто объясните как реализовать то, что я указал.
виртуальная ф-я  IsVisible
class A {public:    virtual bool IsVisible() { return true; }};class B : public A {public:    virtual bool IsVisible() { return false; }};class C : public A {    virtual bool IsVisible() { return true; }};


Вообще в любом ооп по лекциям требуется писать так, чтобы было красиво и медленно. 
Нет.. глядеть надо не стороны лекций, а со сторны инструментария предоставляемго языком.. ООП помогает писать так, чтоб это было красиво, понятно и при этом без ушерба в скорости...Например казалось бы что программа написанная в машиных кодах будет работаь быстрей, чем такая же прога на Си,однако зачастую наблюдается обратная ситуация.. Потому что чтоб выйграть в скорости при писании в маешинах кодах, надо знать архитектура компа  и сопотимизировать под нее свою лучше, чем это сделает компилятор..(а сравниться с компиляторами, особенно заточенными под нужную платформу, смогут лишь единицы). То же происходит если сравнить С и Сpp.. При компиляции весь ооп разворачивается и в результате имеем тот же си код . Зато при составлении, инструментарий ООП позволяет значительно снизить нагрузку с программиста, если он правильно его использует.То есть имеем те же пряники, но за меньшее время и с меньшей головной болью..Добавлено через 2 минуты и 41 секунду
Люди, не спорьте. Просто объясните как реализовать то, что я указал. 
Очень необходимо реализовать то, что по принципу джавы могло бы писаться как:
нельзя ли объяснить что именно Вы хотите..потому как например в этой строчке
a.visible - 1
найти смысл очень сложно ...