перегрузка << - pro et contra - C/C++

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

BFE>>Это в каком смысле? В смысле реализации/архитектуры или само понятие потоков чем-то плохо?

E>Ну я бы, для начала напомнил, что перегрузка операторов каким-нибудь необычным способом -- это плохая практика. Ну да для операторов побитового сдвига потоков уже поздно что-то менять.

Я не соглашусь, что в перегрузках подобного рода есть что-то плохое. Перегрузка операторов — обычное дело.
Неужели вот такой код вызовет какие-то проблемы у читающего:

    shared_ptr<MyListBox> oListBox(new oListBox);
    oListBox << Pair(0x6E747363, "NTSC"                   )
             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)")
             << Pair(0x70616C20, "PAL - default"          ) << DefaultIndex
             << Pair(0x32337073, "HD1080p2398"            )
             << Pair(0x32347073, "HD1080p24"              )
             << Pair(0x48703235, "HD1080p25"              );

или, например, такой оператор из boost::filesystem

path operator/ (const path& lhs, const path& rhs);

чем плох?

E>А вот иерархия потоков, то, каким местом туда прикручены локейлы и перекодировки, то, что имя обязано быть строкой байт и т. д. -- это всё, мягко говоря, неудобно. Про реализации вообще и говорить нечего. Это просто мегажуть. Простую, по идее, проблему решают мега сложным способом...

С тем, что это простая проблема, я согласиться не могу, а с остальным соглашусь.

10.11.11 17:45: Ветка выделена из темы Для чего нужно виртуальное наследование? — Кодт

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

BFE>Неужели вот такой код вызовет какие-то проблемы у читающего:
BFE>

BFE>    shared_ptr<MyListBox> oListBox(new oListBox);
BFE>    oListBox << Pair(0x6E747363, "NTSC"                   )
BFE>             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)")
BFE>             << Pair(0x70616C20, "PAL - default"          ) << DefaultIndex
BFE>             << Pair(0x32337073, "HD1080p2398"            )
BFE>             << Pair(0x32347073, "HD1080p24"              )
BFE>             << Pair(0x48703235, "HD1080p25"              );
BFE>

если бы не было iostream, то вызывал бы, и значительные...

BFE>

BFE>path operator/ (const path& lhs, const path& rhs);
BFE>

BFE>чем плох?

Тем, что непонятно, и непереносимо, к тому же...

BFE>С тем, что это простая проблема, я согласиться не могу, а с остальным соглашусь.
А какая именно проблема тебе не кажется простой?..

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

BFE>С тем, что это простая проблема, я согласиться не могу ...

Да уж, пожалуй и в самом деле сложная, если для того чтобы прочитать файл в кодировке UTF-16 средствами стандартной библиотеки понадобилось ждать до 2011 года.

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

BFE>>

BFE>>path operator/ (const path& lhs, const path& rhs);
BFE>>

BFE>>чем плох?
E>Тем, что непонятно,

Неужели

?
По мне — вполне остроумно.

E>и непереносимо, к тому же...
куда непереносимо? Это же boost...

BFE>>С тем, что это простая проблема, я согласиться не могу, а с остальным соглашусь.
E>А какая именно проблема тебе не кажется простой?..

Написать удобную, быструю, переносимую и гибкую библиотеку ввода-вывода — это, на мой взгляд, не простая задача.

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

BFE>>С тем, что это простая проблема, я согласиться не могу ...
I>Да уж, пожалуй и в самом деле сложная, если для того чтобы прочитать файл в кодировке UTF-16 средствами стандартной библиотеки понадобилось ждать до 2011 года.

немножко позанудствую:
UTF-8 был стандартизован после стандарта С++ 2003-го года...
К тому же, если я правильно понимаю, размер байта пришлось расширить до 8 бит....

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

BFE>По мне — вполне остроумно.
"остроумно" и "непонтно" в программировании обозначает примерно одно и тоже.
Хорошо, это когда принцип наименьшего удивления, а не принцип наибольшего остроумия

E>>и непереносимо, к тому же...
BFE>куда непереносимо? Это же boost...

Ну, как бы, один кэп подказывает нам, что слэш разделяет компоненты пути далеко не во всех OS.
Например, в MAC OS было двоеточие...

Ну и вообще, с путями много чего делать бывает нужно. Например, бывает нужно приделать расширение. И какой оператор будет там?..

BFE>Написать удобную, быструю, переносимую и гибкую библиотеку ввода-вывода — это, на мой взгляд, не простая задача.

Так в случае iostream эта задача не решена.
1) Все известные мне реализации крайне неудобны. Подумай сам, если бы были удобны, появился бы в MFC класс CFile, например?

2) Опять же все известные мне реализации очень неторопливы.
3) И ни разу не встречал переносимой. Ровно наоборот -- обычно гвоздями приколочена к компилятору. Хорошо если только к мажорной версии

Так шата... Эта, братан, не про ту сторону аргумент-то получился

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

BFE>Неужели вот такой код вызовет какие-то проблемы у читающего:
BFE>

BFE>    shared_ptr<MyListBox> oListBox(new oListBox);
BFE>    oListBox << Pair(0x6E747363, "NTSC"                   )
BFE>             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)")
BFE>             << Pair(0x70616C20, "PAL - default"          ) << DefaultIndex
BFE>             << Pair(0x32337073, "HD1080p2398"            )
BFE>             << Pair(0x32347073, "HD1080p24"              )
BFE>             << Pair(0x48703235, "HD1080p25"              );
BFE>

И, кстати, о проблемах.
Лично мне тут не очевидно многое.
1) В каком пордке будут идти эти пары.
2) Что за числа соответствуют строкам и почему они не константы.
3) К какой из строк будет относиться DefaultIndex? К "PAL — default" или к "HD1080p2398"?
4) Что такое oListBox? Это переменная типа shared_ptr<MyListBox>? Если так, то откуда у неё оператор сдвига?..
5) И что такое new oListBox, в качестве аргумента конструктора shared_ptr<MyListBox>?

Ну и главное. Неужели такой вот код:

void fillTVStandardsList( MyListBox& oListBox ) 
{
    oListBox.AddTVPair(0x6E747363, "NTSC");
    oListBox.AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)");
    oListBox.AddTVPair(0x70616C20, "PAL - default", MyListBox::Defult);
    oListBox.AddTVPair(0x32337073, "HD1080p2398");
    oListBox.AddTVPair(0x32347073, "HD1080p24");
    oListBox.AddTVPair(0x48703235, "HD1080p25");

Менее понятен?

Кстати, если уж говорить о ясности и понятности, то я бы функцию fillTVStandardsList писал вообще не так.
Я бы имел сатический массив пар, который бы циклом згонял в листбокс...

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

BFE>>Неужели вот такой код вызовет какие-то проблемы у читающего:
BFE>>

BFE>>    shared_ptr<MyListBox> oListBox(new oListBox);
BFE>>    oListBox << Pair(0x6E747363, "NTSC"                   )
BFE>>             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)")
BFE>>             << Pair(0x70616C20, "PAL - default"          ) << DefaultIndex
BFE>>             << Pair(0x32337073, "HD1080p2398"            )
BFE>>             << Pair(0x32347073, "HD1080p24"              )
BFE>>             << Pair(0x48703235, "HD1080p25"              );
BFE>>

E>И, кстати, о проблемах.
Я не говорил, что этот код идеален. К тому же первая строчка должна выглядеть так:

shared_ptr<MyListBox> oListBox(new MyListBox);

Просто я не имею права копипастить код из проекта, так что слегка его переделал...

E>Лично мне тут не очевидно многое.
E>1) В каком пордке будут идти эти пары.

в случае такого добавления:
E> oListBox.AddTVPair(0x6E747363, "NTSC");
E> oListBox.AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)");
это так же не известно.

E>2) Что за числа соответствуют строкам и почему они не константы.

Они как раз константы, но я понимаю о чем здесь речь.

E>3) К какой из строк будет относиться DefaultIndex? К "PAL — default" или к "HD1080p2398"?

Да, этот пункт не очевиден в общем случае.

E>4) Что такое oListBox? Это переменная типа shared_ptr<MyListBox>?
E>5) И что такое new oListBox, в качестве аргумента конструктора shared_ptr<MyListBox>?
да. Из-за ошибки это было не очевидно.

E>Если так, то откуда у неё оператор сдвига?..
Ну, наверное следует предположить, что кто-то переопределил этот оператор для данного типа...

E>Ну и главное. Неужели такой вот код:
E>

void fillTVStandardsList( MyListBox& oListBox ) 
E>{
E>    oListBox.AddTVPair(0x6E747363, "NTSC");
E>    oListBox.AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)");
E>    oListBox.AddTVPair(0x70616C20, "PAL - default", MyListBox::Defult);
E>    oListBox.AddTVPair(0x32337073, "HD1080p2398");
E>    oListBox.AddTVPair(0x32347073, "HD1080p24");
E>    oListBox.AddTVPair(0x48703235, "HD1080p25");
E>

E>Менее понятен?

Нет, ничуть не менее. Этот код вполне понятен, но он специфичен в том смысле, что для каждой инициализации ListBox'а нужно добавить или ещё одну функцию, или "тридцать три раза" скопипастить oListBox, что чревато известно чем. Конечно это можно заменить на

   oListBox.AddTVPair(0x6E747363, "NTSC")
           .AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)")
           .AddTVPair(0x70616C20, "PAL - default", MyListBox::Defult)
           .AddTVPair(0x32337073, "HD1080p2398")
           .AddTVPair(0x32347073, "HD1080p24")
           .AddTVPair(0x48703235, "HD1080p25");

что мне нравится уже больше. А ещё лучше, наверное, применить списки инициализации из нового стандарта, но мы пока этого сделать не можем...

E>Кстати, если уж говорить о ясности и понятности, то я бы функцию fillTVStandardsList писал вообще не так.
E>Я бы имел сатический массив пар, который бы циклом згонял в листбокс...

В большинстве случаев так примерно (через BOOST_ENUM_VALUES(..) ) и сделано

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

BFE>Я не говорил, что этот код идеален. К тому же первая строчка должна выглядеть так:
BFE>

BFE>shared_ptr<MyListBox> oListBox(new MyListBox);
BFE>

BFE>Просто я не имею права копипастить код из проекта, так что слегка его переделал...
1) насмешил
2) Так откуда оператор сдвига у shared_ptr<MyListBox>?

E>>Лично мне тут не очевидно многое.
BFE>в случае такого добавления:
E>> oListBox.AddTVPair(0x6E747363, "NTSC");
E>> oListBox.AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)");
BFE>это так же не известно.
Тут, по крайней мере, очевиден порядок, в котором они будут добавлены...

E>>2) Что за числа соответствуют строкам и почему они не константы.
BFE>Они как раз константы, но я понимаю о чем здесь речь.
Я рад за тебя. Признаком хорошочитабельногонеговнокода является то, что его понимают ВСЕ, а не только автор...

E>>3) К какой из строк будет относиться DefaultIndex? К "PAL — default" или к "HD1080p2398"?
BFE>Да, этот пункт не очевиден в общем случае.

Уже один признанный тобой минус имеем. Угу.

BFE>да. Из-за ошибки это было не очевидно.
E>>Если так, то откуда у неё оператор сдвига?..
BFE>Ну, наверное следует предположить, что кто-то переопределил этот оператор для данного типа...

Очень хорошо, это вот "следует предположить" оно, по твоему повышает читабельность что ли?
Я бы вот после указателя ждал бы ->ИмяМетода, а вовсе и не сдвиг...

BFE>Нет, ничуть не менее. Этот код вполне понятен, но он специфичен в том смысле, что для каждой инициализации ListBox'а нужно добавить или ещё одну функцию, или "тридцать три раза" скопипастить oListBox, что чревато известно чем. Конечно это можно заменить на

Функцию можно и не добавлть, вобще-то. Или араметризовать её массивом данных для инициализации

Ваш КО

BFE>

BFE>   oListBox.AddTVPair(0x6E747363, "NTSC")
BFE>           .AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)")
BFE>           .AddTVPair(0x70616C20, "PAL - default", MyListBox::Defult)
BFE>           .AddTVPair(0x32337073, "HD1080p2398")
BFE>           .AddTVPair(0x32347073, "HD1080p24")
BFE>           .AddTVPair(0x48703235, "HD1080p25");
BFE>

BFE>что мне нравится уже больше.

Мне вариант с Add..., который вернёт ссылку на *this тоже больше нравится. Но, это увело бы в сторону от operator <<...

BFE>А ещё лучше, наверное, применить списки инициализации из нового стандарта, но мы пока этого сделать не можем...
Ну можем в стиле

ListBoxInitInfo x[] = { ... };
MyList oList( x );

E>>Кстати, если уж говорить о ясности и понятности, то я бы функцию fillTVStandardsList писал вообще не так.
E>>Я бы имел сатический массив пар, который бы циклом згонял в листбокс...

BFE>

В большинстве случаев так примерно (через BOOST_ENUM_VALUES(..) ) и сделано

Ну так и вернёмся к О(Б)СУЖДАЕМОМУ вопросу использования перегруженных операторов для необычных операций?

Кстати, в С++ opertor << уже устойчиво имеет семантику "запихать чего-то куда-то"
Так что твой пример не совсем про то. Но даже он показывает, что с "просто методами" выходит прямее и лучше.

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

BFE>Я не соглашусь, что в перегрузках подобного рода есть что-то плохое. Перегрузка операторов — обычное дело.
BFE>Неужели вот такой код вызовет какие-то проблемы у читающего:
BFE>

BFE>    shared_ptr<MyListBox> oListBox(new oListBox);
BFE>    oListBox << Pair(0x6E747363, "NTSC"                   )
BFE>             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)")
BFE>             << Pair(0x70616C20, "PAL - default"          ) << DefaultIndex
BFE>             << Pair(0x32337073, "HD1080p2398"            )
BFE>             << Pair(0x32347073, "HD1080p24"              )
BFE>             << Pair(0x48703235, "HD1080p25"              );
BFE>

Плох! Вызовет!
Почему оператор определён над умным указателем, а не над содержимым?
Как будет вести себя эта конструкция на наследниках? А на посторонних типах?

shared_ptr<OListBox> oListBox(new OListBox);
do_something_specific_with_olistbox(oListBox); // вот почему я использую указатель на финальный, а не базовый класс
oListBox << bla << bla << bla; // взлетит?

shared_ptr<MyEditBox> oEdit(new MyEditBox);
oEdit << bla << bla << bla; // невзлетит?

Кстати сказать, если используется конвенция cdecl (а не fastcall и его частный случай thiscall), такие длинные цепочки выражений создают нагрузку на стек. Пустячок, конечно, но знать об этом стоит.
Сперва на стек кладётся крайний правый аргумент, затем предпоследний, и т.д., наконец, второй аргумент (первый элемент цепочки), первый аргумент (объект-приёмник), и начинается вычисление...
Если промежуточные результаты — не примитивные типы, то их всех нужно сохранить до конца полного выражения. (В данном случае — это shared_ptr'ы). Это сведёт на нет fastcall, сделав её эквивалентной cdecl'у.
Хороший fastcall получается, когда левый операнд — это голый указатель или ссылка, и результат — тоже голый указатель или ссылка.
Например, когда оператор является членом класса, и его левый аргумент — это this.

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

BFE>>Я не говорил, что этот код идеален. К тому же первая строчка должна выглядеть так:
BFE>>

BFE>>shared_ptr<MyListBox> oListBox(new MyListBox);
BFE>>

BFE>>Просто я не имею права копипастить код из проекта, так что слегка его переделал...
E>1) насмешил
E>2) Так откуда оператор сдвига у shared_ptr<MyListBox>?

А в чем сложность добавить, например, такой оператор:

const boost::shared_ptr<MyListBox>& operator << (const boost::shared_ptr<MyListBox>& oList, const Pair& oAddThis) {
    oList->AddTVPair(oAddThis);
    return oList;
}

?

E>>>Лично мне тут не очевидно многое.
BFE>>в случае такого добавления:
E>>> oListBox.AddTVPair(0x6E747363, "NTSC");
E>>> oListBox.AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)");
BFE>>это так же не известно.
E>Тут, по крайней мере, очевиден порядок, в котором они будут добавлены...

Код:

    oListBox << Pair(0x6E747363, "NTSC"                   )
             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)");

равносилен:

operator<<(operator<<(oListBox, Pair(0x6E747363, "NTSC")), Pair(0x6E743233, "NTSC2398 (3:2 pulldown)"));

и порядок добавления тот же. Что смущает?

E>>>3) К какой из строк будет относиться DefaultIndex? К "PAL — default" или к "HD1080p2398"?
BFE>>Да, этот пункт не очевиден в общем случае.
E>Уже один признанный тобой минус имеем. Угу.
А если DefaultIndex назвать SetPreviousItemAsDefaultIndex минус останется?

BFE>>да. Из-за ошибки это было не очевидно.
E>>>Если так, то откуда у неё оператор сдвига?..
BFE>>Ну, наверное следует предположить, что кто-то переопределил этот оператор для данного типа...
E>Очень хорошо, это вот "следует предположить" оно, по твоему повышает читабельность что ли?
В данном контексте мне трудно предположить что-то другое, кроме как переопределённого оператора. Вы, кстати, интуитивно правильно поняли исходный код.

E>Я бы вот после указателя ждал бы ->ИмяМетода, а вовсе и не сдвиг...

Think different

В С++ неожиданности встречаются на каждом шагу

    FILE* pFile = fopen("name", "w");
    if ( NULL == pFile ) return;
    boost::shared_ptr<void> oCloseFileOnExit(pFile, fclose);

E>Ну так и вернёмся к О(Б)СУЖДАЕМОМУ вопросу использования перегруженных операторов для необычных операций?

E>Кстати, в С++ opertor << уже устойчиво имеет семантику "запихать чего-то куда-то"
Вот я и "запихиваю" данные в лист-бокс

E>Так что твой пример не совсем про то. Но даже он показывает, что с "просто методами" выходит прямее и лучше.

По мне это просто дело вкуса, не более.

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

BFE>>Просто я не имею права копипастить код из проекта, так что слегка его переделал...
E>1) насмешил
E>2) Так откуда оператор сдвига у shared_ptr<MyListBox>?

Капрал Обыкновение подсказывает

shared_ptr<MyListBox> operator << (shared_ptr<MyListBox> lbx, Pair item)
{ lbx->AddPair(item); return lbx; }

(Унылость этого подхода и определило звание военного советника).

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

BFE>А в чем сложность добавить, например, такой оператор:
BFE>

BFE>const boost::shared_ptr<MyListBox>& operator << (const boost::shared_ptr<MyListBox>& oList, const Pair& oAddThis) {
BFE>    oList->AddTVPair(oAddThis);
BFE>    return oList;
BFE>}
BFE>

BFE>?

В том, что узнать о его существовании или несуществовании можно только прочитав "все хедеры в проекте"...

BFE>равносилен:
BFE>

BFE>operator<<(operator<<(oListBox, Pair(0x6E747363, "NTSC")), Pair(0x6E743233, "NTSC2398 (3:2 pulldown)"));
BFE>

BFE>и порядок добавления тот же. Что смущает?

То, что могут быть шаблоны выражений...

BFE>А если DefaultIndex назвать SetPreviousItemAsDefaultIndex минус останется?
Да.
Длинно, неудобно, непонятно, фиг найдёшь.

BFE>В данном контексте мне трудно предположить что-то другое, кроме как переопределённого оператора. Вы, кстати, интуитивно правильно поняли исходный код.
Мы, кстати, поняли его, в основном, из-за имён переменных и текстов внутри строчек

Ну и ща мужем не первый раз как бы

BFE>Think с

Вот это-то и контрпродуктивно. Надо не "different", а "наиболее ожидаемо"...

BFE>В С++ неожиданности встречаются на каждом шагу

:
BFE>

BFE>    FILE* pFile = fopen("name", "w");
BFE>    if ( NULL == pFile ) return;
BFE>    boost::shared_ptr<void> oCloseFileOnExit(pFile, fclose);
BFE>

И где тут неожиданность?

BFE>Вот я и "запихиваю" данные в лист-бокс
Да, но когда библу создавали было не так.
BFE>По мне это просто дело вкуса, не более.

Ну-ну. Но "думай иначе" призывал тут не я, а ты...

Или ты не приемлешь "принцип наименьшего удивления"?

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

BFE>UTF-8 был стандартизован после стандарта С++ 2003-го года...
BFE>К тому же, если я правильно понимаю, размер байта пришлось расширить до 8 бит....

Да хотя бы поддержка UCS-2 была как в Java.

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

К>Капрал Обыкновение подсказывает
К>

К>shared_ptr<MyListBox> operator << (shared_ptr<MyListBox> lbx, Pair item)
К>{ lbx->AddPair(item); return lbx; }
К>

К>(Унылость этого подхода и определило звание военного советника).

Капралу, конечно, спасибо, но на ко это всё, если И ТАК УЖЕ ЕСТЬ AddPair?
Вот читаешь ты тот код, вот видишь << у указателя. И что делаешь дальше? -- Строишь редположения? Ну и на кой ребусы-то писать?

Опять же, адекватность она бывает только одна, в отличии от неадекватности.
Ели уж люди столь странные, что приписали << к указателю, то фиг их знает, чего ещё они наворотили. Может они и указаетль как-то хитро специализировали, например?

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

BFE>>Я не соглашусь, что в перегрузках подобного рода есть что-то плохое. Перегрузка операторов — обычное дело.
BFE>>Неужели вот такой код вызовет какие-то проблемы у читающего:
BFE>>

BFE>>    shared_ptr<MyListBox> oListBox(new oListBox);
BFE>>    oListBox << Pair(0x6E747363, "NTSC"                   )
BFE>>             << Pair(0x6E743233, "NTSC2398 (3:2 pulldown)")
BFE>>             << Pair(0x70616C20, "PAL - default"          ) << DefaultIndex
BFE>>             << Pair(0x32337073, "HD1080p2398"            )
BFE>>             << Pair(0x32347073, "HD1080p24"              )
BFE>>             << Pair(0x48703235, "HD1080p25"              );
BFE>>

К>Плох! Вызовет!
К>Почему оператор определён над умным указателем, а не над содержимым?
Для удобства.

К>Как будет вести себя эта конструкция на наследниках? А на посторонних типах?
Никак, для них она не определена. Так как это своего рода инициализация, то и не нужно, чтобы она работала на непредусмотренных типах

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

BFE>>А в чем сложность добавить, например, такой оператор:
BFE>>

BFE>>const boost::shared_ptr<MyListBox>& operator << (const boost::shared_ptr<MyListBox>& oList, const Pair& oAddThis) {
BFE>>    oList->AddTVPair(oAddThis);
BFE>>    return oList;
BFE>>}
BFE>>

BFE>>?

E>В том, что узнать о его существовании или несуществовании можно только прочитав "все хедеры в проекте"...

Если его нет — значит проект не компилируется

Если компилируется — значит есть.

BFE>>Think с

E>Вот это-то и контрпродуктивно. Надо не "different", а "наиболее ожидаемо"...

Понимаете... я долго (4 года) не использовал на работе templates потому, что некоторые коллеги не понимали как они вообще работают и зачем нужны... я знаю людей которые сознательно пишут на "С++" в стиле структуры + наборы функций и ссылка (референс) для них будет неожиданностью. А ещё, однажды, я в перегруженной виртуальной функции вызвал эту же функцию базового класса. На что, один мой коллега сказал, что это хак и такого рода безобразий следует избегать...
Где граница между тем, что ожидаемо, а что нет?

BFE>>В С++ неожиданности встречаются на каждом шагу

:
BFE>>

BFE>>    FILE* pFile = fopen("name", "w");
BFE>>    if ( NULL == pFile ) return;
BFE>>    boost::shared_ptr<void> oCloseFileOnExit(pFile, fclose);
BFE>>

E>И где тут неожиданность?
Как же? Ведь тут shared_ptr использован не для того, чтобы освободить память после использования указателя, а чтобы файл закрыть. Неожиданно!

BFE>>По мне это просто дело вкуса, не более.
E>Ну-ну. Но "думай иначе" призывал тут не я, а ты...

E>Или ты не приемлешь "принцип наименьшего удивления"?

У нас в проекте используется примерно 15 сторонних библиотек. Эти библиотеки были написаны в разное время, разными людьми, в разном стиле и с использованием различных парадигм. Время от времени я наталкиваюсь на ошибки в этих библиотеках. Иногда я их исправляю. А для этого мне приходится "перелопачивать" много исходников. Дак вот, новая библиотека — это новая неожиданность, часто вызывающая удивление "на ровном месте". Так что, "принцип наименьшего удивления" не работает.

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

BFE>Если его нет — значит проект не компилируется

BFE>Если компилируется — значит есть.
Беда тут в том, что это "значит есть" ничего не значит...

Что конкретно сделано -- не ясно. И что ещё МОЖНО делать, тоже не ясно.
Например, можно ли заменить тип указателя? Можно ли заменить MyList на его наследника и т. д...

E>>Вот это-то и контрпродуктивно. Надо не "different", а "наиболее ожидаемо"...

BFE>Понимаете... я долго (4 года) не использовал на работе templates потому, что некоторые коллеги не понимали как они вообще работают и зачем нужны...
BFE>Где граница между тем, что ожидаемо, а что нет?
В чувстве меры граница.
Но, в любом случае, если команда не готова к каким-то новациям, то от новаций будет хуже, а не лучше...

E>>И где тут неожиданность?
BFE>Как же? Ведь тут shared_ptr использован не для того, чтобы освободить память после использования указателя, а чтобы файл закрыть. Неожиданно!

AFAIK, это штатное испольование. shared_ptr предназначен чтобы хранить любой тип хэндэла. Указатель на память выеленну по new -- это стратегия по умолчанию...

В общем, читай документацию и делай прямо и будет тебе счастье

BFE>У нас в проекте используется примерно 15 сторонних библиотек. Эти библиотеки были написаны в разное время, разными людьми, в разном стиле и с использованием различных парадигм. Время от времени я наталкиваюсь на ошибки в этих библиотеках. Иногда я их исправляю. А для этого мне приходится "перелопачивать" много исходников. Дак вот, новая библиотека — это новая неожиданность, часто вызывающая удивление "на ровном месте". Так что, "принцип наименьшего удивления" не работает.

Не-не-не, то, что некоторые его не придерживаются, вернее придерживаются не везде, это же затрудняет тебе поддержку из кода?

Казалось бы, это иллюстрирует то, что принцип, как раз, работает

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

К>>Почему оператор определён над умным указателем, а не над содержимым?
BFE>Для удобства.

Офигеть удобство. Одну маленькую звёздочку лень поставить. Битва за синтаксический оверхед, что ли?
Заодно потащил всюду, где нужно и не нужно, умные указатели...
Заодно намекнул, что операция прекрасно определена и над нулевым указателем. (Что, правда, что ли?! В духе ObjC?)

Как это можно сделать по-нормальному:

shared_ptr<SomeDerivedListBox> lbx(new MostDerivedListBox);
*lbx << bla << bla << bla;

void add_common_contents(MyListBox& lbx) { lbx << bla << bla << bla; }

add_common_contents(*lbx);

К>>Как будет вести себя эта конструкция на наследниках? А на посторонних типах?
BFE>Никак, для них она не определена. Так как это своего рода инициализация, то и не нужно, чтобы она работала на непредусмотренных типах

Порвал завещание, оставил наследников с голой задницей. Ну, тоже подход.

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

К>>Капрал Обыкновение подсказывает
К>>

К>>shared_ptr<MyListBox> operator << (shared_ptr<MyListBox> lbx, Pair item)
К>>{ lbx->AddPair(item); return lbx; }
К>>

К>>(Унылость этого подхода и определило звание военного советника).

E>Капралу, конечно, спасибо, но на ко это всё, если И ТАК УЖЕ ЕСТЬ AddPair?
Поправте если я ошибаюсь, но унылость это нечто противоположное неожиданности.

E>Вот читаешь ты тот код, вот видишь << у указателя. И что делаешь дальше? -- Строишь редположения? Ну и на кой ребусы-то писать?
А иначе и не бывает. Предположения всегда приходится строить. Видя operator << у указателя я бы предположил, что объект должен создаваться, если он пустой, после чего инициализироваться данными.

E>Опять же, адекватность она бывает только одна, в отличии от неадекватности.
Адекватность как функция приспособления бывает разной.

E>Ели уж люди столь странные, что приписали << к указателю, то фиг их знает, чего ещё они наворотили. Может они и указаетль как-то хитро специализировали, например?

Вполне может быть. Я и такое встречал.

	От:	B0FEE664
	Дата:	08.11.11 09:29
	Оценка:

	От:	Erop
	Дата:	08.11.11 11:34
	Оценка:	-1

	От:	igna
	Дата:	08.11.11 12:02
	Оценка:

	От:	B0FEE664
	Дата:	08.11.11 22:20
	Оценка:

	От:	B0FEE664
	Дата:	08.11.11 23:16
	Оценка: