Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов.
Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
Код мог бы выглядеть, например, вот так:
typedef struct
{
long long int timestamp;
} my_time_t;
class DLLEXPORTS exported_class
{
my_time_t time; // no problems to export/import POD type...
};
inline extention SYSTEMTIME my_time_t::to_systemtime() const
{
// inline implemetation using "this"
}
inline extention string my_time_t::format(const char * format) const
{
// inline implemetation using "this"
}
int main()
{
exported_class instance;
cout << "Day: " << instance.time.to_systemtime().wDay;
}
На сколько я понимаю ничего подобного не намечается на ближайший стандарт (11?). Есть ли этому логичное обяснение? (Это нужно мне одному/ есть неразрешимые конфликты с другими правилами)
Здравствуйте, Caracrist, Вы писали: C>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
В C++ нет понятия экспортируемого класса.
C>На сколько я понимаю ничего подобного не намечается на ближайший стандарт (11?). Есть ли этому логичное обяснение? (Это нужно мне одному/ есть неразрешимые конфликты с другими правилами)
Здравствуйте, Caracrist, Вы писали:
C>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
C>На сколько я понимаю ничего подобного не намечается на ближайший стандарт (11?). Есть ли этому логичное обяснение? (Это нужно мне одному/ есть неразрешимые конфликты с другими правилами)
Caracrist:
C>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов.
Механизм добавления функций в интерфейс пользовательских типов уже существует — это делается через объявление обычных non-member functions в соответствующих пространствах имён (там, где объявлены эти типы). ADL, в свою очередь, концептуально является механизмом доступа к таким функциям интерфейса.
namespace N
{
struct X;
}
namespace N
{
void f(X &); // f - часть интерфейса X
}
void g(N::X &x)
{
f(x); // используем интерфейс класса X
}
Re[2]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, gegMOPO4, Вы писали:
MOP>Здравствуйте, Caracrist, Вы писали: C>>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
MOP>В C++ нет понятия экспортируемого класса.
Странный аргумент, если речь идет об изменении стандарта. В стандарте 2003 года нет понятия thread, что совершенно, не помешало добавить в стандарт 2011 года thread support library.
Здравствуйте, Caracrist, Вы писали:
C>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
Здравствуйте, Masterkent, Вы писали:
M>Механизм добавления функций в интерфейс пользовательских типов уже существует — это делается через объявление обычных non-member functions в соответствующих пространствах имён (там, где объявлены эти типы).
С тем же успехом любую функцию принимающую указатель или ссылку на объект в качестве (первого?) параметра, можно назвать частью интерфейса. Но что-то подсказывает мне, что это не так.
Да и в темплеитах это не поможет... синтаксис обращения уже другой. Я уже не говорю про возможное получение указателя на эту функцию, а не структуру обёртку.
M> ADL, в свою очередь, концептуально является механизмом доступа к таким функциям интерфейса.
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Здравствуйте, Caracrist, Вы писали: C>>>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>>>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
MOP>>В C++ нет понятия экспортируемого класса.
KO>Странный аргумент, если речь идет об изменении стандарта. В стандарте 2003 года нет понятия thread, что совершенно, не помешало добавить в стандарт 2011 года thread support library.
<
Бросьте, не станете же вы утверждать, что thread support library — это такой же синтаксический сахар, как то, что просит автор?
Re[4]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, anomander, Вы писали:
A>Здравствуйте, k.o., Вы писали:
KO>>Здравствуйте, gegMOPO4, Вы писали:
MOP>>>Здравствуйте, Caracrist, Вы писали: C>>>>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>>>>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
MOP>>>В C++ нет понятия экспортируемого класса.
KO>>Странный аргумент, если речь идет об изменении стандарта. В стандарте 2003 года нет понятия thread, что совершенно, не помешало добавить в стандарт 2011 года thread support library.
A><
A>Бросьте, не станете же вы утверждать, что thread support library — это такой же синтаксический сахар, как то, что просит автор?
Вы о чём? Прочитайте, что-ли, сначала о чём речь идёт.
Re[3]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, Caracrist, Вы писали:
C>Здравствуйте, Masterkent, Вы писали:
M>>Механизм добавления функций в интерфейс пользовательских типов уже существует — это делается через объявление обычных non-member functions в соответствующих пространствах имён (там, где объявлены эти типы).
C>С тем же успехом любую функцию принимающую указатель или ссылку на объект в качестве (первого?) параметра, можно назвать частью интерфейса. Но что-то подсказывает мне, что это не так. C>Да и в темплеитах это не поможет... синтаксис обращения уже другой. Я уже не говорю про возможное получение указателя на эту функцию, а не структуру обёртку.
А в чём, конкретно, проблема с шаблонами? А выделенное я вообще не понял можно пример какой-нибудь? Пока, единственным недостатком по сравнению с extension methods видится невозможность выстраивать цепочки вызовов. Да и то, есть возможность эмуляции этого дела, как, например, в FC++.
Re[5]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, Caracrist, Вы писали:
U>уже правильно отметили, что подобный сахар есть в C#, однако в сях его нет и не будет (имхо), зато есть вышибающий мозг ADL U>это C++way
Увы это так.
Хотя мне кажется, что методы расширения вместе с ADL будут вышибать мозг еще больше.
Здравствуйте, Caracrist, Вы писали:
C> С тем же успехом любую функцию принимающую указатель или ссылку на объект в качестве (первого?) параметра, можно назвать частью интерфейса. Но что-то подсказывает мне, что это не так.
А по-моему так. Мейерс, например, с этим тоже согласен.
Здравствуйте, Caracrist, Вы писали:
C>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
C>Код мог бы выглядеть, например, вот так: C>
C>На сколько я понимаю ничего подобного не намечается на ближайший стандарт (11?). Есть ли этому логичное обяснение? (Это нужно мне одному/ есть неразрешимые конфликты с другими правилами)
В таком виде расширения нарушают инкапсуляцию. В C# аргумент в ExtensionMethod передается явно и инкапсуляция не нарушается. По сути это просто статическая функция с возможностью вызова obj.foo() вместо foo(obj), помечаемая для такового использования атрибутом. В общем, сахар. Если же говорить о шаблонах и отнаследоваться никак не получается, то всё и так решается перегрузкой операций в виде non-member функций:
// общий методtemplate<typename T> SYSTEMTIME to_systemtime(const T& obj) { obj.to_systemtime(); }
// ну а дальше расширения
SYSTEMTIME to_systemtime(const my_time_t& obj) { ... }
Re[2]: Почему нет и планируется ли расширения в цпп?
А в плане инкапсуляции хотелось бы такого сахара — назначать member функциям права доступа. Т.е. те функции которые вроде как надо бы static non-member'ами делать всё таки писать как member, но с ограниченными правами доступа к this, т.е. что то типа void foo(...) : public { ... } При этом получая уверенность, что эта неконстантная member-функция сможет изменить состояние объекта класса только через public интерфейс.
Re[3]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, sokel, Вы писали:
S>А в плане инкапсуляции хотелось бы такого сахара — назначать member функциям права доступа. Т.е. те функции которые вроде как надо бы static non-member'ами делать всё таки писать как member, но с ограниченными правами доступа к this, т.е. что то типа void foo(...) : public { ... } При этом получая уверенность, что эта неконстантная member-функция сможет изменить состояние объекта класса только через public интерфейс.
Зачем?
Re[2]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, sokel, Вы писали:
S>Здравствуйте, Caracrist, Вы писали:
C>>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
S>В таком виде расширения нарушают инкапсуляцию. В C# аргумент в ExtensionMethod передается явно и инкапсуляция не нарушается. По сути это просто статическая функция с возможностью вызова obj.foo() вместо foo(obj), помечаемая для такового использования атрибутом.
А откуда следует, что ТС предлагал нарушить инкапсуляцию? Просто ещё больше сахара, чтобы явно аргумент не описывать.
Re[3]: Почему нет и планируется ли расширения в цпп?
Здравствуйте, k.o., Вы писали:
KO>Здравствуйте, sokel, Вы писали:
S>>Здравствуйте, Caracrist, Вы писали:
C>>>Мне лично очень нехватает возможности расширять интерфейс POD или просто конечных типов. C>>>Возможность добавления member functions в качетсве расширения позволил бы отделить inline интерфейс от экспортируемого класса. Помог бы создать обёртки для POD структур для дальнейшего использования в темплейтах.
S>>В таком виде расширения нарушают инкапсуляцию. В C# аргумент в ExtensionMethod передается явно и инкапсуляция не нарушается. По сути это просто статическая функция с возможностью вызова obj.foo() вместо foo(obj), помечаемая для такового использования атрибутом.
KO>А откуда следует, что ТС предлагал нарушить инкапсуляцию? Просто ещё больше сахара, чтобы явно аргумент не описывать.
Т.е. комментарий -- implemetation using "this" -- предполагает необычное использование this.
можно пример какой-нибудь? Пока, единственным недостатком по сравнению с extension methods видится невозможность выстраивать цепочки вызовов. Да и то, есть возможность эмуляции этого дела, как, например, в FC++.
