Исследуя вопрос 'No arguments that depend on a template parameter' наткнулся на интересный побочный эффект от использования using объявлений.Оказывается помещая их в нужные секции класса ,публичные члены можно сделать защищёнными или закрытыми,а защищённые можно сделать открытими.Что значительно улучшает инкапсуляцию.Может для многих это не ново,для меня просто офигительная находка.

class Base
{
protected:
  
  int one;

public:

  int two;
};

class Derived : public Base
{
public:

  using Base::one;

private:

  using Base::two;
};

Здравствуйте, Аноним, Вы писали:

А>Исследуя вопрос 'No arguments that depend on a template parameter' наткнулся на интересный побочный эффект от использования using объявлений.Оказывается помещая их в нужные секции класса ,публичные члены можно сделать защищёнными или закрытыми,а защищённые можно сделать открытими.Что значительно улучшает инкапсуляцию.Может для многих это не ново,для меня просто офигительная находка.

А>

А>class Base
А>{
А>protected:
  
А>  int one;

А>public:

А>  int two;
А>};

А>class Derived : public Base
А>{
А>public:

А>  using Base::one;

А>private:

А>  using Base::two;
А>};
А>

Где ты был раньше

Автор: Caracrist
Дата: 29.11.09

?

Здравствуйте, Caracrist, Вы писали:
C>Где ты был раньше

Автор: Caracrist
Дата: 29.11.09

?

Судя по количеству обсуждавших не я один такой

Здравствуйте, Аноним, Вы писали:
А>Исследуя вопрос 'No arguments that depend on a template parameter' наткнулся на интересный побочный эффект от использования using объявлений.Оказывается помещая их в нужные секции класса ,публичные члены можно сделать защищёнными или закрытыми,а защищённые можно сделать открытими.Что значительно улучшает инкапсуляцию.Может для многих это не ново,для меня просто офигительная находка.

ИМХО, пользоваться интересным побочным эффектом стоит сто раз подумав, т.к. для него имеются отдельные грабли

Автор: Aznog
Дата: 08.06.05

.

Здравствуйте, Aznog, Вы писали:
A>ИМХО, пользоваться интересным побочным эффектом стоит сто раз подумав, т.к. для него имеются отдельные грабли

Автор: Aznog
Дата: 08.06.05

.
Какой облом
gcc4.4

Здравствуйте, Аноним, Вы писали:

А>Может для многих это не ново,для меня просто офигительная находка.

Это не просто не ново, это уже вторая версия данной фичи (фича называется access declaration, 11.3), и эта вторая версия появилась вместе с пространствами имен.
До пространств имен не было ключевого слово using, так что такая "тонкая настройка" в своей первой версии реализовывалась простым упоминанием члена базы, т.е. так же, как сейчас, но без using:

А>class Derived : public Base
А>{
А>public:
А>  Base::one;
А>private:
А>  Base::two;
А>};

Поскольку using более нагляден, старый синтаксис признан устаревшим и нежелательным (deprecated), см D.3, но в Стандарте, как в текущем, так и в будущем С++0х, он все еще есть и все равно должен работать.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:
...

Уже не важно ,потому-что не должно работать по стандарту(см. пост Aznog'а).Хотя в VS7(2005,2008,2010 не проверял) и gcc4.4 работает.
А не должно,поскольку приведением к базовому классу всё равно можно получить доступ к этим намеренно скрытым идентификаторам.
Посему правило такое — имя находится в той секции класса в которой было создано и using его поменять не может,поэтому для
правильной работы в компиляторах не соответсвующим стандарту ,using нужно помещать именно в ту секцию к которой относится идентификатор.
Хотя для "правильных" компиляторов это не имеет значения.Вот такие грабли.

Здравствуйте, dipso, Вы писали:

D>...и using его поменять не может...
Это не так:

class A { protected: int i; };
class B : public A { public: A::i; };
void f(B&b)
{
  b.i = 5;
}

был protected, стал public

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:
J>Это не так:

Каюсь.Открыл таки стандарт.Значит всё таки можно так делать

11.3 Access declarations [class.access.dcl]
The access of a member of a base class can be changed in the derived class by mentioning its qualified-id in
the derived class definition. Such mention is called an access declaration. The effect of an access declaration
qualified-id ; is defined to be equivalent to the declaration using qualified-id ;.

class A 
{
  public:

    int z;
    int z1;
};

class B : public A 
{
    int a;

  public:
    int b, c;
    int bf();

  protected:
    int x;
    int y;
};

class D : private B 
{
    int d;

  public:
    B::c; // adjust access to B::c
    B::z; // adjust access to A::z
    A::z1; // adjust access to A::z1
    int e;
    int df();

  protected:
    B::x; // adjust access to B::x
    int g;
};

class X : public D 
{
    int xf();
};

int ef(D&);
int ff(X&);

The external function ef can use only the names c, z, z1, e, and df. Being a member of D, the function df
can use the names b, c, z, z1, bf, x, y, d, e, df, and g, but not a. Being a member of B, the function bf
can use the members a, b, c, z, z1, bf, x, and y. The function xf can use the public and protected names
from D, that is, c, z, z1, e, and df (public), and x, and g (protected). Thus the external function ff has
access only to c, z, z1, e, and df. If D were a protected or private base class of X, xf would have the same
privileges as before, but ff would have no access at all. —end example ]

7.3.3.
18 The alias created by the using-declaration has the usual accessibility for a member-declaration.

class A 
{
  private:
         void f(char);
  public:
         void f(int);
  protected:
         void g();
};

class B : public A 
{
  using A::f; // error: A::f(char) is inaccessible

public:
  using A::g; // B::g is a public synonym for A::g
;