Ключ доступа protected

что значит рекомендовано?
к свойствам с доступом protected имеют доступ классы наследники..

сравни два этих кода. Один из них не компилируется.

p.s: еще есть опция наследования proected.

ISergey, это опечатка видите ли, когда я печатаю не на своей клавиатуре - это частое явление.

а.. тогда вам повезло... (бывает )

ISergey, это опечатка видите ли, когда я печатаю не на своей клавиатуре - это частое явление.

В книге Лафоре , которую вы мне посоветовали сказано, что любой программист
сможет получить доступ к членам класса, объявленными, как protected просто создавая производные классы.

В книге Павловской сказано что при наследовании сс спецификатором protected
доступ в производном классе отсутствует.

Элементы protected при наследовании с ключом доступа private становятся в производном классе private, в остальных случаях права доступа не изменяются.

Skirmisher, ты меня запутал. Ты сейчас о чем? О свойствах protected и их доступности или о protected-наследовании?

я тебе советую больше верить Лафоре, чем Пвловской.

p.s: открой Лафоре стр.367, там есть таблица 9.1. Там описано взаимодействие всех видов наследования со свойствами с разными видами доступа.

Protected - это уже не public, но еще и не private, со всеми вытекающими из этого последствиями

15.2.2. protected Members
The protected access label can be thought of as a blend of private and public:

Like private members, protected members are inaccessible to users of the class.

Like public members, the protected members are accessible to classes derived from this class.

In addition, protected has another important property:

A derived object may access the protected members of its base class only through a derived object. The derived class has no special access to the protected members of base type objects.

As an example, let's assume that Bulk_item defines a member function that takes a reference to a Bulk_item object and a reference to an Item_base object. This function may access the protected members of its own object as well as those of its Bulk_item parameter. However, it has no special access to the protected members in its Item_base parameter:

void Bulk_item::memfcn(const Bulk_item &d, const Item_base &b)
{
// attempt to use protected member
double ret = price; // ok: uses this->price
ret = d.price; // ok: uses price from a Bulk_item object
ret = b.price; // error: no access to price from an Item_base
}



The use of d.price is okay, because the reference to price is through an object of type Bulk_item. The use of b.price is illegal because Bulk_item has no special access to objects of type Item_base

Key Concept: Class Design and Protected Members
In the absence of inheritance, a class has two kinds of users: members of the class itself and the users of that class. This separation between kinds of users is reflected in the division of the class into private and public access levels. Users may access only the public interface; class members and friends may access both the public and private members.

Under inheritance, there is now a third kind of user of a class: programmers who will define new classes that are derived from the class. The provider of a derived class often (but not always) needs access to the (ordinarily private) base-class implementation. To allow that access while still preventing general access to the implementation, an additional access label, protected, is provided. The data and function members in a protected section of a class remain inaccessible to the general program, yet are accessible to the derived class. Anything placed within a private section of the base class is accessible only to the class itself and its friends. The private members are not accessible to the derived classes.

When designing a class to serve as a base class, the criteria for designating a member as public do not change: It is still the case that interface functions should be public and data generally should not be public. A class designed to be inherited from must decide which parts of the implementation to declare as protected and which should be private. A member should be made private if we wish to prevent subsequently derived classes from having access to that member. A member should be made protected if it provides an operation or data that a derived class will need to use in its implementation. In other words, the interface to the derived type is the combination of both the protected and public members.

Camera.h

const char *idCameraPosition:ositionStr[] =

Защищенные члены
Защищенные члены имеют доступ к метке и могут рассматриваться, как смешение свойств закрытых и открытых полей:

Схожее свойство закрытым членам: защищенные члены недоступны пользователям
класса.

Схожее свойство с открытыми членами: защищенные члены доступны в классах производных от этого класса.

В дополнение защищенные члены имееют другое значительное свойство:

Объект производного класса может получить доступ к защищенными членами
этого базового клсса только через объект производного класса. Производный класс
не имеет специального доступа к защищенным членам объектов этого базового класса(типа).

Например: позволим принимать определения Bulk_item методу, который ссылается на объект Bulk_item и ссылается на объект Item_base. Эта функция может иметь доступ к защищенным членам основного объекта также, как все эти параметры Bulk_item/
Однако, он не имеет специального доступа к защищенным членам в параметре Bulk_item:
void Bulk_item::memfcn(const Bulk_item &d, const Item_base &b)
{
// доступ для того чтобы использовать защищенный член
double ret = price; // ok: используй this->price
ret = d.price; // ok: использую price от объекта Bulk_item
ret = b.price; // ошибка: нет доступа к price от Item_base
}
Когда проектируешь класс, для того чтобы продолжить работать с базовым классом,
критерий проектирования члена, такого как public не изменяйте: он по-прежнему, является случаем интерфейса функций должны быть как public и данные в основном должны быть, как не public. Класс спроектированный для того чтобы наследовать от
должных решенных частей выполнения, для того чтобы объявить их, как защищенные
и некоторые должны быть закрытыми . Член должен быть закрытым, если мы желаем предотвратить более поздние производные классы от доступа к этому члену. Член должен быть защищенным, если он поставляет операцию или данные, которые будут нуждаться к использованию в производном классе при его выполнении. Другими словами интерфейс производного класса является комбинацией обоих защищенных
и открытых членов.

Статичекое защищенное поле:
Camera.h
Camera.cpp
Вот такой код, однако все равно выдает lnk2001
Возникает ошибка линковки 2001

Skirmisher, удалите свой некорректный перевод текста.