Определение шаблона-члена вне класса?
От: о_О
Дата: 13.11.11 18:56
Оценка:
Прювет.

Какие за и против вы могли бы высказать насчет этого?

template <typename T> template <typename U> ComPtr<T>::ComPtr(const ComPtr<U>& other) : _Ptr(0)
{
  if (other)
    other->QueryInterface<T>(&_Ptr);
}
Re: Определение шаблона-члена вне класса?
От: licedey  
Дата: 13.11.11 19:06
Оценка:
Здравствуйте, о_О, Вы писали:

о_О>Прювет.

о_О>Какие за и против вы могли бы высказать насчет этого?

о_О>
о_О>template <typename T> template <typename U> ComPtr<T>::ComPtr(const ComPtr<U>& other) : _Ptr(0)
о_О>{
о_О>  if (other)
о_О>    other->QueryInterface<T>(&_Ptr);
о_О>}
о_О>


— Многословно
— Код из рязряда неясных. Я смутился увидев такую декларацию, признаться в первый или второй (в стандарте 1-ый) раз вижу.
— Шаблоны все равно хранятся в хэдерах. Дублирование кода сигнатуры — будет дергать от одного места в файле к другому.
Re[2]: Определение шаблона-члена вне класса?
От: о_О
Дата: 13.11.11 19:14
Оценка:
Здравствуйте, licedey, Вы писали:

L>- Многословно
ну дык шаблонная функция-член шаблона класса но это реализация, которая мало кого беспокоит.

L>- Код из рязряда неясных. Я смутился увидев такую декларацию, признаться в первый или второй (в стандарте 1-ый) раз вижу.
это же определение. и сделано ради того, чтобы объявление шаблона было чистым и понятным.
Re[3]: Определение шаблона-члена вне класса?
От: licedey  
Дата: 13.11.11 19:23
Оценка:
Здравствуйте, о_О, Вы писали:

о_О>Здравствуйте, licedey, Вы писали:

L>>- Код из рязряда неясных. Я смутился увидев такую декларацию, признаться в первый или второй (в стандарте 1-ый) раз вижу.
о_О>это же определение. и сделано ради того, чтобы объявление шаблона было чистым и понятным.

Мое имхо, чище и понятней когда все в одном месте. Обычные методы меньше десятка строк, тоже есть сенс определять в том же месте.
Re: Определение шаблона-члена вне класса?
От: okman Беларусь https://searchinform.ru/
Дата: 13.11.11 19:37
Оценка: +1
Здравствуйте, о_О, Вы писали:

о_О>Какие за и против вы могли бы высказать насчет этого?
o_O>
template <typename T> template <typename U> ComPtr<T>::ComPtr(const ComPtr<U>& other) : _Ptr(0)


Я бы переписал так (меня слишком длинная горизонтальная "выкладка" пугает):
template <typename T>
template <typename U>
ComPtr<T>::ComPtr(const ComPtr<U>& other) :
    _Ptr(0)
{
    // ...
}
Re[2]: Определение шаблона-члена вне класса?
От: о_О
Дата: 13.11.11 19:41
Оценка:
Здравствуйте, okman, Вы писали:

O>Здравствуйте, о_О, Вы писали:

о_О>>Какие за и против вы могли бы высказать насчет этого?
o_O>>
template <typename T> template <typename U> ComPtr<T>::ComPtr(const ComPtr<U>& other) : _Ptr(0)


O>Я бы переписал так (меня слишком длинная горизонтальная "выкладка" пугает):
O>
O>template <typename T>
O>template <typename U>
O>ComPtr<T>::ComPtr(const ComPtr<U>& other) :
O>    _Ptr(0)
O>{
O>    // ...
O>}
O>


да, так лучше. но я нигде не видел подобного определения вне класса. все пишут в теле класса.
Re: Определение шаблона-члена вне класса?
От: rg45 СССР  
Дата: 13.11.11 19:43
Оценка: 12 (1) +1
Здравствуйте, о_О, Вы писали:

о_О>Прювет.

о_О>Какие за и против вы могли бы высказать насчет этого?

о_О>
о_О>template <typename T> template <typename U> ComPtr<T>::ComPtr(const ComPtr<U>& other) : _Ptr(0)
о_О>{
о_О>  if (other)
о_О>    other->QueryInterface<T>(&_Ptr);
о_О>}
о_О>


У такого стиля кодирования есть большое (я бы сказал, огромное) преимущество: определение класса очищается от огромного числа деталей реализации в лице определений его функций-членов. При хорошем дизайне после этого семантика класса и его использование в клиентских приложения становятся легко понимаемыми даже без документации, что особенно важно для библиотечного API. Я стараюсь весь код писать именно в таком стиле.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[2]: Определение шаблона-члена вне класса?
От: о_О
Дата: 13.11.11 19:50
Оценка:
Здравствуйте, rg45, Вы писали:

R>У такого стиля кодирования есть большое (я бы сказал, огромное) преимущество: определение класса очищается от огромного числа деталей реализации в лице определений его функций-членов. При хорошем дизайне после этого семантика класса и его использование в клиентских приложения становятся легко понимаемыми даже без документации, что особенно важно для библиотечного API. Я стараюсь весь код писать именно в таком стиле.

+100500 именно по этой причине я и стал так писать
Re[2]: Определение шаблона-члена вне класса?
От: rg45 СССР  
Дата: 14.11.11 07:02
Оценка: 2 (2) +1
Здравствуйте, okman, Вы писали:

O>Я бы переписал так (меня слишком длинная горизонтальная "выкладка" пугает):
O>
O>template <typename T>
O>template <typename U>
O>ComPtr<T>::ComPtr(const ComPtr<U>& other) :
O>    _Ptr(0)
O>{
O>    // ...
O>}
O>


А оформление списков инициализации, на мой взгляд, весьма удобно в таком стиле:
A::A(/*any parameters*/)
: foo(/*some expression*/)
, bar(/*some expression*/)
, baz(/*some expression*/)
{
  //...
}
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[3]: Определение шаблона-члена вне класса?
От: о_О
Дата: 14.11.11 07:50
Оценка:
Здравствуйте, rg45, Вы писали:


R>А оформление списков инициализации, на мой взгляд, весьма удобно в таком стиле:
R>
R>A::A(/*any parameters*/)
R>: foo(/*some expression*/)
R>, bar(/*some expression*/)
R>, baz(/*some expression*/)
R>{
R>  //...
R>}
R>


на прием йоды не смахивает?

A::A(/*any parameters*/) :
  foo(/*some expression*/),
  bar(/*some expression*/),
  baz(/*some expression*/)
{
  //...
}
Re[3]: Определение шаблона-члена вне класса?
От: PM  
Дата: 14.11.11 08:53
Оценка: +2
Здравствуйте, rg45, Вы писали:

R>А оформление списков инициализации, на мой взгляд, весьма удобно в таком стиле:
R>
R>A::A(/*any parameters*/)
R>: foo(/*some expression*/)
R>, bar(/*some expression*/)
R>, baz(/*some expression*/)
R>{
R>  //...
R>}
R>


я еще оформляю в таком стиле списки наследования:

class FooBar
    : public Foo
    , public Bar
{
};
Re[4]: Определение шаблона-члена вне класса?
От: Кодт Россия  
Дата: 14.11.11 09:17
Оценка: +1
Здравствуйте, о_О, Вы писали:

о_О>на прием йоды не смахивает?
В стиле йоды — легко дописывать новые строки в середину и конец, а в стиле юного падавана — в середину и в начало (а в конец — придётся изменять предыдущую строку).
Это критично при слиянии изменений в системах контроля версий, т.к. уменьшает количество коллизий.
Перекуём баги на фичи!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.