Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, sokel, Вы писали:
S>>А в плане инкапсуляции хотелось бы такого сахара — назначать member функциям права доступа. Т.е. те функции которые вроде как надо бы static non-member'ами делать всё таки писать как member, но с ограниченными правами доступа к this, т.е. что то типа void foo(...) : public { ... } При этом получая уверенность, что эта неконстантная member-функция сможет изменить состояние объекта класса только через public интерфейс.
KO>Зачем?
Ну... я ж говорю — сахару хочется
По хорошему конечно такие функции, которым для работы достаточно public данных надо выносить из класса. Но для этого надо какой то namespace завести, названия придумать. Куда как проще когда оно вызывается как member-функция. Но при этом нет уверенности что они, используя привелегии member функций с данными как нибудь не так будут работать. Например, к полям не через аксессоры а напрямую обращаться.
S>Ну... я ж говорю — сахару хочется По хорошему конечно такие функции, которым для работы достаточно public данных надо выносить из класса. Но для этого надо какой то namespace завести, названия придумать. Куда как проще когда оно вызывается как member-функция. Но при этом нет уверенности что они, используя привелегии member функций с данными как нибудь не так будут работать. Например, к полям не через аксессоры а напрямую обращаться.
Т.е. чтобы например вместо t_result do_some_complex_object_analysis(const t_object&) можно было писать t_result t_object::do_some_complex_analysis() не нарушая инкапсуляции.
Здравствуйте, sokel, Вы писали:
S>S>// общий метод
S>template<typename T> SYSTEMTIME to_systemtime(const T& obj) { obj.to_systemtime(); }
S>// ну а дальше расширения
S>SYSTEMTIME to_systemtime(const my_time_t& obj) { ... }
S>
Допустим с написав дополнительных функций, менможко темплейтной магии, заучив все правила ADL и не забыв написать весь код с самого начала расчитывая на такой поворот событий (например, темплейт уже обращающийся к мемберу придётся переписывать), можно отказавшись от чисто эстетического момента, казалось бы, решить все проблемы по другому. Выше, тут уже привели не мало советов — как.
А что предлогаете делать с интелисенсом? А вы уверены что эти функции расширяющие интерфейс я вообще найду и не напишу лишний раз решение той же проблемы... Не заводить же мне для каждого класса теперь отдельный namespace
Здравствуйте, Caracrist, Вы писали:
C>Здравствуйте, sokel, Вы писали:
S>>S>>// общий метод
S>>template<typename T> SYSTEMTIME to_systemtime(const T& obj) { obj.to_systemtime(); }
S>>// ну а дальше расширения
S>>SYSTEMTIME to_systemtime(const my_time_t& obj) { ... }
S>>
C>Допустим с написав дополнительных функций, менможко темплейтной магии, заучив все правила ADL и не забыв написать весь код с самого начала расчитывая на такой поворот событий (например, темплейт уже обращающийся к мемберу придётся переписывать), можно отказавшись от чисто эстетического момента, казалось бы, решить все проблемы по другому. Выше, тут уже привели не мало советов — как.
C>А что предлогаете делать с интелисенсом? А вы уверены что эти функции расширяющие интерфейс я вообще найду и не напишу лишний раз решение той же проблемы... Не заводить же мне для каждого класса теперь отдельный namespace
Вот такой хак
#define INTELLISENSE_MARKER(static_name, ...) template<void* static_name> void
// example
struct X {
INTELLISENSE_MARKER(X_func) func();
int h;
};
int X_func(const X&x)
{
return x.h;
}
Если нечайно написать:
X x;
x.func();
то получаем достаточно информативную ошибку:
error C2783: 'void X::func(void)' : could not deduce template argument for 'X_func'
Здравствуйте, Caracrist, Вы писали:
C>С тем же успехом любую функцию принимающую указатель или ссылку на объект в качестве (первого?) параметра, можно назвать частью интерфейса. Но что-то подсказывает мне, что это не так.
А на самом деле это так.
См. например
Саттер, Решение сложных задач на C++, Задача 5.2. Поиск имен и принцип интерфейса. Можно не согласится с Саттером (и многими другими), но по крайней мере знать эту точку зрения стоит хотя бы для понимания того, почему в C++ нет функций-расширений.