Доступ к приватным методам/полям
От: Sir-G  
Дата: 14.07.11 12:04
Оценка:
По мотивам топика http://rsdn.ru/forum/cpp.applied/4339871.aspx
Автор: _nn_
Дата: 12.07.11
.
Там дали такую ссылку
http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html

Автор статьи утвержает, что его метод делает все по стандарту. Загрузив в MSVC, я обнаружил, что его код не комплируется. Кто не прав — автор или компилятор? Ошибка компиляции такая:
error C2248: 'A::f' : cannot access private member declared in class 'A'

На gcc этот код работает, вот ссылка:
http://codepad.org/LCVu1t6w

И еще, если написать
rob<Af, &A::f> xxx;
вместо
template struct rob<Af, &A::f>; // я так понимаю, это явное инстанциирование?
то компилируется.
Re: Доступ к приватным методам/полям
От: ononim  
Дата: 14.07.11 12:09
Оценка: 1 (1) +3
Откуда такое неуемное стремление прострелить себе ногу?
Как много веселых ребят, и все делают велосипед...
Re[2]: Доступ к приватным методам/полям
От: Sir-G  
Дата: 14.07.11 12:19
Оценка:
Здравствуйте, ononim, Вы писали:

O>Откуда такое неуемное стремление прострелить себе ногу?

Это чисто теоретический интерес. Для более глубокого понимания языка. =)
Re: Доступ к приватным методам/полям
От: _nn_ www.nemerleweb.com
Дата: 14.07.11 12:35
Оценка:
Здравствуйте, Sir-G, Вы писали:

SG>На gcc этот код работает, вот ссылка:

SG>http://codepad.org/LCVu1t6w

VS 2008 не компилируется.
VS 2010 компилируется и работает.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[2]: Доступ к приватным методам/полям
От: Sir-G  
Дата: 14.07.11 12:56
Оценка:
__>VS 2008 не компилируется.
__>VS 2010 компилируется и работает.
Да, на VS 2008 проверял.
Re[2]: Доступ к приватным методам/полям
От: sidorov18 США  
Дата: 14.07.11 13:34
Оценка: +1
Здравствуйте, ononim, Вы писали:

O>Откуда такое неуемное стремление прострелить себе ногу?


А что здесь такого? Ну юнит тесты могу потребовать этого) или какая отладочная информация. мне когда-то хотелось выводить в отладочную информацию размер выделенного буфера в deque.
Вообще политика с приватными полями, имхо, слишком жесткая. сделали бы какой нибудь public_cast и все.
Re: Доступ к приватным методам/полям
От: Sir-G  
Дата: 18.07.11 04:07
Оценка:
Собственно меня интересует, почему возможен доступ к приватному методу извне класса A (а точнее, в шаблоне аргумента другого класса rob). Есть ли специальное правило на этот счет в стандарте?
Re[3]: Доступ к приватным методам/полям
От: dilmah США  
Дата: 18.07.11 04:29
Оценка: 1 (1) -1
S>А что здесь такого? Ну юнит тесты могу потребовать этого) или какая отладочная информация. мне когда-то хотелось выводить в отладочную информацию размер выделенного буфера в deque.

лучше ставить #ifdef UNITTEST в хедере

S>Вообще политика с приватными полями, имхо, слишком жесткая. сделали бы какой нибудь public_cast и все.


private поля дают компилятору больший простор для оптимизации (потому что известно чем ограничен доступ к ним), а public_cast разрушил бы эту возможность
Re: Доступ к приватным методам/полям
От: k.o. Россия  
Дата: 18.07.11 09:13
Оценка: 3 (1)
Здравствуйте, Sir-G, Вы писали:

SG>По мотивам топика http://rsdn.ru/forum/cpp.applied/4339871.aspx
Автор: _nn_
Дата: 12.07.11
.

SG>Там дали такую ссылку
SG>http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html

SG>Автор статьи утвержает, что его метод делает все по стандарту. Загрузив в MSVC, я обнаружил, что его код не комплируется. Кто не прав — автор или компилятор? Ошибка компиляции такая:


автор прав, код работает (должен работать) благодаря 14.7.2/8

The usual access checking rules do not apply to names used to specify explicit instantiations. [Note: In particular,
the template arguments and names used in the function declarator (including parameter types, return
types and exception specifications) may be private types or objects which would normally not be accessible
and the template may be a member template or member function which would not normally be accessible.]

Re[2]: Доступ к приватным методам/полям
От: Sir-G  
Дата: 18.07.11 09:45
Оценка:
KO>автор прав, код работает (должен работать) благодаря 14.7.2/8
Спасибо большое!!! Мой изначальный вопрос полностью разрешился.
Правда возник другой. Зачем сделали такое отступление. Но видимо иногда нужно...
Re[3]: Доступ к приватным методам/полям
От: k.o. Россия  
Дата: 18.07.11 10:37
Оценка: +1
Здравствуйте, Sir-G, Вы писали:

KO>>автор прав, код работает (должен работать) благодаря 14.7.2/8

SG>Спасибо большое!!! Мой изначальный вопрос полностью разрешился.
SG>Правда возник другой. Зачем сделали такое отступление. Но видимо иногда нужно...

Это, похоже, следствие из 14.7.2/5

An explicit instantiation of a class or function template specialization is placed in the namespace in which
the template is defined...


Если бы при явном воплощении шаблонов проверялись модификаторы доступа, не было бы возможности делать явное воплощение для закрытых членов класса. Могли бы, наверно, разрешить явное воплощение внутри декларации класса, но это, практически, убило бы всю идею: компилятору пришлось бы воплощать шаблоны каждый раз, как он видит декларацию такого класса.
Re: Доступ к приватным методам/полям
От: Masterkent  
Дата: 18.07.11 19:21
Оценка:
Sir-G:

SG>По мотивам топика http://rsdn.ru/forum/cpp.applied/4339871.aspx
Автор: _nn_
Дата: 12.07.11
.

SG>Там дали такую ссылку
SG>http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html

Кстати, автор этой статьи — Johannes Schaub — открыл приличное количество дефектов в спецификации C++0x.
Re[4]: Доступ к приватным методам/полям
От: Sir-G  
Дата: 19.07.11 04:16
Оценка:
Здравствуйте, k.o., Вы писали:

SG>>Правда возник другой. Зачем сделали такое отступление. Но видимо иногда нужно...

KO>Если бы при явном воплощении шаблонов проверялись модификаторы доступа, не было бы возможности делать явное воплощение для закрытых членов класса. Могли бы, наверно, разрешить явное воплощение внутри декларации класса, но это, практически, убило бы всю идею: компилятору пришлось бы воплощать шаблоны каждый раз, как он видит декларацию такого класса.

Я вообще никогда не использовал явное инстанциирование. Но дело не в этом, а то что я не могу придумать полезный пример именно для приватных членов. Хотя наверно он есть (раз уж такой пункт есть), интересно было бы на него взглянуть.
Re[5]: Доступ к приватным методам/полям
От: k.o. Россия  
Дата: 19.07.11 06:14
Оценка:
Здравствуйте, Sir-G, Вы писали:

SG>Здравствуйте, k.o., Вы писали:


SG>>>Правда возник другой. Зачем сделали такое отступление. Но видимо иногда нужно...

KO>>Если бы при явном воплощении шаблонов проверялись модификаторы доступа, не было бы возможности делать явное воплощение для закрытых членов класса. Могли бы, наверно, разрешить явное воплощение внутри декларации класса, но это, практически, убило бы всю идею: компилятору пришлось бы воплощать шаблоны каждый раз, как он видит декларацию такого класса.

SG>Я вообще никогда не использовал явное инстанциирование. Но дело не в этом, а то что я не могу придумать полезный пример именно для приватных членов. Хотя наверно он есть (раз уж такой пункт есть), интересно было бы на него взглянуть.


Польза ровно такая же как и для любого другого случая явного воплощения. Например, если у тебя closed-source библиотека можно использовать шаблонные классы не раскрывая их реализации.

// MyCoolLibraryClass.h
class MyCoolLibraryClass
{
public:
// ...
private:
    struct PrivateDataItem
    {
    // ...
    };

    MyCoolPrivateContainer<PrivateDataItem> data;
};

// ExplicitInstantiations.cpp
template class MyCoolPrivateContainer<MyCoolLibraryClass::PrivateDataItem>;
Re[6]: Доступ к приватным методам/полям
От: Sir-G  
Дата: 19.07.11 18:48
Оценка:
KO>Польза ровно такая же как и для любого другого случая явного воплощения. Например, если у тебя closed-source библиотека можно использовать шаблонные классы не раскрывая их реализации.

ААа... Теперь всё стало понятно, спасибо!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.