К>(Унылость этого подхода и определило звание военного советника).
Капралу, конечно, спасибо, но на ко это всё, если И ТАК УЖЕ ЕСТЬ AddPair?
Вот читаешь ты тот код, вот видишь << у указателя. И что делаешь дальше? -- Строишь редположения? Ну и на кой ребусы-то писать?
Опять же, адекватность она бывает только одна, в отличии от неадекватности.
Ели уж люди столь странные, что приписали << к указателю, то фиг их знает, чего ещё они наворотили. Может они и указаетль как-то хитро специализировали, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>>>Ну вот у тебя, например E>>>1) Есть лишняя связь между списком и указателем, через функцию инициализации BFE>>Ничего подобного. Код списка и указателя можно менять независимо. Это внешняя операция по отношению к указанным объектам. E>Ага-ага. А как мне заиметь таки список-поле?
E>>>2) Есть негласное соглашение о том, что в несозданный список можно выводить элементы BFE>>Ровно наоборот. У меня нет негласного соглашения, что в не созданный список нельзя выводить элементы. E>Ну-ну. Обычно для указателей оно таки есть.
Один говорил — наша жизнь — это поезд. Другой говорил — перрон.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Erop, Вы писали:
BFE>>Это в каком смысле? В смысле реализации/архитектуры или само понятие потоков чем-то плохо?
E>Ну я бы, для начала напомнил, что перегрузка операторов каким-нибудь необычным способом -- это плохая практика. Ну да для операторов побитового сдвига потоков уже поздно что-то менять.
Я не соглашусь, что в перегрузках подобного рода есть что-то плохое. Перегрузка операторов — обычное дело.
Неужели вот такой код вызовет какие-то проблемы у читающего:
E>А вот иерархия потоков, то, каким местом туда прикручены локейлы и перекодировки, то, что имя обязано быть строкой байт и т. д. -- это всё, мягко говоря, неудобно. Про реализации вообще и говорить нечего. Это просто мегажуть. Простую, по идее, проблему решают мега сложным способом...
С тем, что это простая проблема, я согласиться не могу, а с остальным соглашусь.
Тем, что непонятно, и непереносимо, к тому же...
BFE>С тем, что это простая проблема, я согласиться не могу, а с остальным соглашусь.
А какая именно проблема тебе не кажется простой?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
И, кстати, о проблемах.
Лично мне тут не очевидно многое.
1) В каком пордке будут идти эти пары.
2) Что за числа соответствуют строкам и почему они не константы.
3) К какой из строк будет относиться DefaultIndex? К "PAL — default" или к "HD1080p2398"?
4) Что такое oListBox? Это переменная типа shared_ptr<MyListBox>? Если так, то откуда у неё оператор сдвига?..
5) И что такое new oListBox, в качестве аргумента конструктора shared_ptr<MyListBox>?
Менее понятен?
Кстати, если уж говорить о ясности и понятности, то я бы функцию fillTVStandardsList писал вообще не так.
Я бы имел сатический массив пар, который бы циклом згонял в листбокс...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
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>Если так, то откуда у неё оператор сдвига?..
Ну, наверное следует предположить, что кто-то переопределил этот оператор для данного типа...
Нет, ничуть не менее. Этот код вполне понятен, но он специфичен в том смысле, что для каждой инициализации ListBox'а нужно добавить или ещё одну функцию, или "тридцать три раза" скопипастить oListBox, что чревато известно чем. Конечно это можно заменить на
что мне нравится уже больше. А ещё лучше, наверное, применить списки инициализации из нового стандарта, но мы пока этого сделать не можем...
E>Кстати, если уж говорить о ясности и понятности, то я бы функцию fillTVStandardsList писал вообще не так. E>Я бы имел сатический массив пар, который бы циклом згонял в листбокс... В большинстве случаев так примерно (через BOOST_ENUM_VALUES(..) ) и сделано
Здравствуйте, Erop, Вы писали:
BFE>>Просто я не имею права копипастить код из проекта, так что слегка его переделал... E>1) насмешил E>2) Так откуда оператор сдвига у shared_ptr<MyListBox>?
Здравствуйте, Кодт, Вы писали:
BFE>>Я не соглашусь, что в перегрузках подобного рода есть что-то плохое. Перегрузка операторов — обычное дело. BFE>>Неужели вот такой код вызовет какие-то проблемы у читающего: BFE>>
К>Плох! Вызовет! К>Почему оператор определён над умным указателем, а не над содержимым?
Для удобства.
К>Как будет вести себя эта конструкция на наследниках? А на посторонних типах?
Никак, для них она не определена. Так как это своего рода инициализация, то и не нужно, чтобы она работала на непредусмотренных типах
Здравствуйте, 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>Никак, для них она не определена. Так как это своего рода инициализация, то и не нужно, чтобы она работала на непредусмотренных типах
Порвал завещание, оставил наследников с голой задницей. Ну, тоже подход.
К>>(Унылость этого подхода и определило звание военного советника). E>Капралу, конечно, спасибо, но на ко это всё, если И ТАК УЖЕ ЕСТЬ AddPair?
Поправте если я ошибаюсь, но унылость это нечто противоположное неожиданности.
E>Вот читаешь ты тот код, вот видишь << у указателя. И что делаешь дальше? -- Строишь редположения? Ну и на кой ребусы-то писать?
А иначе и не бывает. Предположения всегда приходится строить. Видя operator << у указателя я бы предположил, что объект должен создаваться, если он пустой, после чего инициализироваться данными.
E>Опять же, адекватность она бывает только одна, в отличии от неадекватности.
Адекватность как функция приспособления бывает разной.
E>Ели уж люди столь странные, что приписали << к указателю, то фиг их знает, чего ещё они наворотили. Может они и указаетль как-то хитро специализировали, например?
Вполне может быть. Я и такое встречал.
Здравствуйте, Кодт, Вы писали:
К>>>Почему оператор определён над умным указателем, а не над содержимым? BFE>>Для удобства. К>Офигеть удобство. Одну маленькую звёздочку лень поставить. Битва за синтаксический оверхед, что ли?
да. К>Заодно потащил всюду, где нужно и не нужно, умные указатели...
У меня был один проект, где вообще все объекты создались исключительно по new и хранились исключительно в smart указателях.
К>Заодно намекнул, что операция прекрасно определена и над нулевым указателем. (Что, правда, что ли?! В духе ObjC?)
Не в данном случае, но я видел smart pointer, который создавал объект внутри operator->()
К>Как это можно сделать по-нормальному: К>
К>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, Вы писали:
BFE>>Плохой код, это когда количество связей между объектами неоправданно высоко или когда существуют негласные соглашения о динамической модели состояния объектов.
E>Ну вот у тебя, например E>1) Есть лишняя связь между списком и указателем, через функцию инициализации
Ничего подобного. Код списка и указателя можно менять независимо. Это внешняя операция по отношению к указанным объектам.
E>2) Есть негласное соглашение о том, что в несозданный список можно выводить элементы
Ровно наоборот. У меня нет негласного соглашения, что в не созданный список нельзя выводить элементы.
Впрочем, я не верно сформулировал критерий динамической модели. Я хотел сказать, что плохой код позволяет легальным использованием разрушить динамическую модель. Надо будет подумать над красивой формулировкой.
E>Ничего не смущает?
нет
Здравствуйте, B0FEE664, Вы писали:
BFE>Если у /*тут ещ public интерфейс*/ не добавлено ничего нового по сравнению с MyListBody, то скажут, что я напрасно потратил время на набивание методов, которые ничего не делают. К тому же возникнут вопросы, как быть с наследниками MyListBody... и т.д. и т.п.
Какие ещё наследники? Кто-то сам говорил, что наследников нет, и поэтому можно не заморачиваться.
Здравствуйте, B0FEE664, Вы писали:
BFE>С тем, что это простая проблема, я согласиться не могу ...
Да уж, пожалуй и в самом деле сложная, если для того чтобы прочитать файл в кодировке UTF-16 средствами стандартной библиотеки понадобилось ждать до 2011 года.
Неужели ?
По мне — вполне остроумно.
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) И ни разу не встречал переносимой. Ровно наоборот -- обычно гвоздями приколочена к компилятору. Хорошо если только к мажорной версии
Так шата... Эта, братан, не про ту сторону аргумент-то получился
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
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>
Мне вариант с Add..., который вернёт ссылку на *this тоже больше нравится. Но, это увело бы в сторону от operator <<...
BFE>А ещё лучше, наверное, применить списки инициализации из нового стандарта, но мы пока этого сделать не можем...
Ну можем в стиле
ListBoxInitInfo x[] = { ... };
MyList oList( x );
E>>Кстати, если уж говорить о ясности и понятности, то я бы функцию fillTVStandardsList писал вообще не так. E>>Я бы имел сатический массив пар, который бы циклом згонял в листбокс... BFE> В большинстве случаев так примерно (через BOOST_ENUM_VALUES(..) ) и сделано
Ну так и вернёмся к О(Б)СУЖДАЕМОМУ вопросу использования перегруженных операторов для необычных операций?
Кстати, в С++ opertor << уже устойчиво имеет семантику "запихать чего-то куда-то"
Так что твой пример не совсем про то. Но даже он показывает, что с "просто методами" выходит прямее и лучше.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Я не соглашусь, что в перегрузках подобного рода есть что-то плохое. Перегрузка операторов — обычное дело. BFE>Неужели вот такой код вызовет какие-то проблемы у читающего: 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.
BFE>>Просто я не имею права копипастить код из проекта, так что слегка его переделал... E>1) насмешил E>2) Так откуда оператор сдвига у shared_ptr<MyListBox>?
А в чем сложность добавить, например, такой оператор:
?
E>>>Лично мне тут не очевидно многое. BFE>>в случае такого добавления: E>>> oListBox.AddTVPair(0x6E747363, "NTSC"); E>>> oListBox.AddTVPair(0x6E743233, "NTSC2398 (3:2 pulldown)"); BFE>>это так же не известно. E>Тут, по крайней мере, очевиден порядок, в котором они будут добавлены...
Код:
и порядок добавления тот же. Что смущает?
E>>>3) К какой из строк будет относиться DefaultIndex? К "PAL — default" или к "HD1080p2398"? BFE>>Да, этот пункт не очевиден в общем случае. E>Уже один признанный тобой минус имеем. Угу.
А если DefaultIndex назвать SetPreviousItemAsDefaultIndex минус останется?
BFE>>да. Из-за ошибки это было не очевидно. E>>>Если так, то откуда у неё оператор сдвига?.. BFE>>Ну, наверное следует предположить, что кто-то переопределил этот оператор для данного типа... E>Очень хорошо, это вот "следует предположить" оно, по твоему повышает читабельность что ли?
В данном контексте мне трудно предположить что-то другое, кроме как переопределённого оператора. Вы, кстати, интуитивно правильно поняли исходный код.
E>Я бы вот после указателя ждал бы ->ИмяМетода, а вовсе и не сдвиг...
Think different
В С++ неожиданности встречаются на каждом шагу :
E>Ну так и вернёмся к О(Б)СУЖДАЕМОМУ вопросу использования перегруженных операторов для необычных операций? E>Кстати, в С++ opertor << уже устойчиво имеет семантику "запихать чего-то куда-то"
Вот я и "запихиваю" данные в лист-бокс
E>Так что твой пример не совсем про то. Но даже он показывает, что с "просто методами" выходит прямее и лучше.
По мне это просто дело вкуса
То, что могут быть шаблоны выражений...
BFE>А если DefaultIndex назвать SetPreviousItemAsDefaultIndex минус останется?
Да.
Длинно, неудобно, непонятно, фиг найдёшь.
BFE>В данном контексте мне трудно предположить что-то другое, кроме как переопределённого оператора. Вы, кстати, интуитивно правильно поняли исходный код.
Мы, кстати, поняли его, в основном, из-за имён переменных и текстов внутри строчек
Ну и ща мужем не первый раз как бы
BFE>Think с
Вот это-то и контрпродуктивно. Надо не "different", а "наиболее ожидаемо"...
BFE>В С++ неожиданности встречаются на каждом шагу : BFE>
Ну-ну. Но "думай иначе" призывал тут не я, а ты...
Или ты не приемлешь "принцип наименьшего удивления"?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>UTF-8 был стандартизован после стандарта С++ 2003-го года... BFE>К тому же, если я правильно понимаю, размер байта пришлось расширить до 8 бит....
BFE>>?
E>В том, что узнать о его существовании или несуществовании можно только прочитав "все хедеры в проекте"...
Если его нет — значит проект не компилируется
Если компилируется — значит есть.
BFE>>Think с E>Вот это-то и контрпродуктивно. Надо не "different", а "наиболее ожидаемо"...
Понимаете... я долго (4 года) не использовал на работе templates потому, что некоторые коллеги не понимали как они вообще работают и зачем нужны... я знаю людей которые сознательно пишут на "С++" в стиле структуры + наборы функций и ссылка (референс) для них будет неожиданностью. А ещё, однажды, я в перегруженной виртуальной функции вызвал эту же функцию базового класса. На что, один мой коллега сказал, что это хак и такого рода безобразий следует избегать...
Где граница между тем, что ожидаемо, а что нет?
BFE>>В С++ неожиданности встречаются на каждом шагу : 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 сторонних библиотек. Эти библиотеки были написаны в разное время, разными людьми, в разном стиле и с использованием различных парадигм. Время от времени я наталкиваюсь на ошибки в этих библиотеках. Иногда я их исправляю. А для этого мне приходится "перелопачивать" много исходников. Дак вот, новая библиотека — это новая неожиданность, часто вызывающая удивление "на ровном месте". Так что, "принцип наименьшего удивления" не работает.
Не-не-не, то, что некоторые его не придерживаются, вернее придерживаются не везде, это же затрудняет тебе поддержку из кода?
Казалось бы, это иллюстрирует то, что принцип, как раз, работает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>>>и непереносимо, к тому же... BFE>>куда непереносимо? Это же boost... E>Ну, как бы, один кэп подказывает нам, что слэш разделяет компоненты пути далеко не во всех OS. E>Например, в MAC OS было двоеточие...
вовсе не обязывает добавлять именно прямой слэш
E>Ну и вообще, с путями много чего делать бывает нужно. Например, бывает нужно приделать расширение. И какой оператор будет там?..
Не знаю, что вы называете расширением у пути, но если действительно интересно то вам сюда
BFE>>Написать удобную, быструю, переносимую и гибкую библиотеку ввода-вывода — это, на мой взгляд, не простая задача.
E>Так в случае iostream эта задача не решена. E>1) Все известные мне реализации крайне неудобны. Подумай сам, если бы были удобны, появился бы в MFC класс CFile, например? E>2) Опять же все известные мне реализации очень неторопливы. E>3) И ни разу не встречал переносимой. Ровно наоборот -- обычно гвоздями приколочена к компилятору. Хорошо если только к мажорной версии
E>Так шата... Эта, братан, не про ту сторону аргумент-то получился
Здравствуйте, Erop, Вы писали:
E>Что конкретно сделано -- не ясно. И что ещё МОЖНО делать, тоже не ясно. E>Например, можно ли заменить тип указателя? Можно ли заменить MyList на его наследника и т. д...
Да, но это никогда не ясно без чтения документации или кода. Вне зависимости от того — функция это или переопределённый оператор.
BFE>>Где граница между тем, что ожидаемо, а что нет? E>В чувстве меры граница.
Она у всех разная. E>Но, в любом случае, если команда не готова к каким-то новациям, то от новаций будет хуже, а не лучше...
Зависит от желания обучаться. А в целом — да.
E>>>И где тут неожиданность? BFE>>Как же? Ведь тут shared_ptr использован не для того, чтобы освободить память после использования указателя, а чтобы файл закрыть. Неожиданно! E>AFAIK, это штатное испольование. shared_ptr предназначен чтобы хранить любой тип хэндэла. Указатель на память выеленну по new -- это стратегия по умолчанию... E>В общем, читай документацию и делай прямо и будет тебе счастье
Да, это штатное использование, но без чтения кода или документации такое использование неожиданно. С переопределёнными операторами ровно тоже самое.
BFE>>У нас в проекте используется примерно 15 сторонних библиотек. Эти библиотеки были написаны в разное время, разными людьми, в разном стиле и с использованием различных парадигм. Время от времени я наталкиваюсь на ошибки в этих библиотеках. Иногда я их исправляю. А для этого мне приходится "перелопачивать" много исходников. Дак вот, новая библиотека — это новая неожиданность, часто вызывающая удивление "на ровном месте". Так что, "принцип наименьшего удивления" не работает. E>Не-не-не, то, что некоторые его не придерживаются, вернее придерживаются не везде, это же затрудняет тебе поддержку из кода? E>Казалось бы, это иллюстрирует то, что принцип, как раз, работает
А я и не говорю, что он не работает. Я говорю, что один и тот же код, у разных программистов будет вызывать разную степень раздражения.
Здравствуйте, B0FEE664, Вы писали:
BFE>Поправте если я ошибаюсь, но унылость это нечто противоположное неожиданности.
Не, в данном случае унылость -- это характеристика того говна, имени которого этот код...
Я всё могу понть, но на кой навязывать объяктам MyList быть имуществом shared_ptr я не понимаю ни разу... А вдруг где-то ахочется сделать список полем, например?
В любом случае, то, что operator << можно юзать для чего попало ни емеет непосредственного отношения к тому, что вы перекрыли его у shared_ptr<XXX> вместо того, чтобы перекрыть у самого ХХХ...
Правда, если бы у вас был просто метод, то уродлство было бы сложнее написать.
Но сам по себе ход с operator<< не у того класса -- это тупо ниже плинтуса.
BFE>А иначе и не бывает. Предположения всегда приходится строить.
Бывает, но не в говнокоде.
Ну и ещё вопрос, на почве чего думаем-то? Если нам деже над такой ерундой, как инициализация списка константным перечнем надо думать, то это просто ужос-ужос...
BFE>Видя operator << у указателя я бы предположил, что объект должен создаваться, если он пустой, после чего инициализироваться данными.
Кошмар!
А это для чего? Для маскировки ошибок?
Кроме того, а где берутся остальные параметры? Ну там, родительское окно, положение в нём, стили?..
E>>Опять же, адекватность она бывает только одна, в отличии от неадекватности. BFE>Адекватность как функция приспособления бывает разной.
Вам, пожалуй, стоит отведать осетрины "второй свежести".
BFE>Вполне может быть. Я и такое встречал.
Я вот не пойму. Ты, как я понял, настрадался от уродского "новаторства" в программировании. Зачем ты хочешь продолжать эту традицию? Ты хочешь "отомстить им", что ли?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
BFE>вовсе не обязывает добавлять именно прямой слэш
Он, конечно, не обязывает, но если на платформе двоеточие, а в коде слэш, то это нифига не наглядно вообще и непонятнои загадочно, если честно
BFE>Не знаю, что вы называете расширением у пути, но если действительно интересно то вам сюда
Расширение -- это текст после точечки, если грубо
BFE>Покажите, где (в какой библиотеке) эта "простая" проблема решена простым способом.
Ну, например, в операторах ввода-вывода языка FORTRAN...
В С тоже неплохо...
А вообще-то, когда iostrem делали, то другую проблему решали. Как сделать так, что в printf можно было бы выводить и СВОИ классы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Тут многое зависит от задачи. Иногда задачу следует решать исключительно в частном виде, а не пытаться писать библиотечный код.
Интересно, зачем тут выбрали менее общий вариант? В чём профит-то, по сравнению с ->AddPair()->AddPair()->AddPair()?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Да, но это никогда не ясно без чтения документации или кода. Вне зависимости от того — функция это или переопределённый оператор.
Дык если это будет метод, то всё будет намного прямее...
BFE>Да, это штатное использование, но без чтения кода или документации такое использование неожиданно.
Без чтени документации неожиданнен сам shared_ptr, с чтнием нет.
Это же основная его функциональность вроде? Что неоиданно-то?
BFE>С переопределёнными операторами ровно тоже самое.
Зависит от того, что конкретно делают те операторы.
Сдвиги у указателя для меня крайне неожиданны и нелогичны.
E>>Казалось бы, это иллюстрирует то, что принцип, как раз, работает BFE>А я и не говорю, что он не работает. Я говорю, что один и тот же код, у разных программистов будет вызывать разную степень раздражения.
IMHO, если у тебя код вызывает раздражение, то надо искать другое занятие.
Плохой код не раздражание вызывает, а дорог в поддрежке и развитии...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Он, конечно, не обязывает, но если на платформе двоеточие, а в коде слэш, то это нифига не наглядно вообще и непонятнои загадочно, если честно
boost местами весьма загадочный и ненаглядный
BFE>>Не знаю, что вы называете расширением у пути, но если действительно интересно то вам сюда E>Расширение -- это текст после точечки, если грубо
это у имени файла или каталога...
BFE>>Покажите, где (в какой библиотеке) эта "простая" проблема решена простым способом. E>Ну, например, в операторах ввода-вывода языка FORTRAN...
да уж. простым. я не знаю как в современном фортране, но раньше это был такой ужас-ужас-ужас, что над некоторыми многостроковыми операторами FORMAT можно 4 часа сидеть силясь понять алгоритм вывода...
Мало того, что устройства были занумерованы без имён, дак ещё и FORMAT может находится совсем не там, где WRITE:
READ(5,11) A,B
... где-то в конце файла...
11 FORMAT(F6.2,2X,F8.4)
это просто?
Или это:
С Высветить сообщение "One=1, Two=2, Three=3"
С на экран, не делая это простейшим образом!
WRITE (* ,980)'One= ',1,1+1,'ee= ',+(1+1+1)
980 FORMAT (A,I2,Two= ',1X,I1,Thr',A,I2)
?
Или классический вопрос о том, как напечатать подряд два (или три?) апострофа ?
E>В С тоже неплохо...
да ну? как напечатать двадцать первых символов из строки с помощью printf не заглядывая в help?
а так же, всё это так безопасно...
Здравствуйте, B0FEE664, Вы писали:
BFE> boost местами весьма загадочный и ненаглядный
Ещё какой *ненаглядный*
В общем, ты меня не убедил, что это хороший пример.
Единственный относительно хороший, который я помню -- это % в качестве разделителей. И то есть некоторые вопросы...
E>>Расширение -- это текст после точечки, если грубо BFE>это у имени файла или каталога...
Ну и?
BFE>да уж. простым. я не знаю как в современном фортране, но раньше это был такой ужас-ужас-ужас, что над некоторыми многостроковыми операторами FORMAT можно 4 часа сидеть силясь понять алгоритм вывода...
Что-то мне так кажется, что тут не в операторе FORMAT дело...
BFE>Мало того, что устройства были занумерованы без имён, дак ещё и FORMAT может находится совсем не там, где WRITE:
Ну так это же не оператора вина, а программиста...
А сейчас, так вообще, определение класса никога не тоит рядом с использованием
BFE>это просто?
В С++ вообще нельзя задать формат отедельно от данных. Если это таки надо, то это очень неудобно. Если это таки не надо, то и на FORTRAN можно так не делать...
BFE>
BFE>
BFE> С на экран, не делая это простейшим образом!
BFE>
BFE>?
Ну на любом почти языке можно написать ужос. Ну и что?
Тем не менее, если страдой не страдать, то на FORTRAN получалось егко и просто писать удобный и понятны ввод-вывод, который, к тому же, работал везде одинаково и быстро...
BFE>Или классический вопрос о том, как напечатать подряд два (или три?) апострофа ?
E>>В С тоже неплохо... BFE>да ну? как напечатать двадцать первых символов из строки с помощью printf не заглядывая в help? BFE>а так же, всё это так безопасно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
E>>В С тоже неплохо... BFE>да ну? как напечатать двадцать первых символов из строки с помощью printf не заглядывая в help?
1) А как в плюсах?..
2) %20.20s наверное? BFE>а так же, всё это так безопасно...
Ну на общем уровне безопасности в С...
Но в целом я согласен, что по пути FORTRAN -> C -> C++ вывод только деградировал и деградировал
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
BFE>>Да, но это никогда не ясно без чтения документации или кода. Вне зависимости от того — функция это или переопределённый оператор. E>Дык если это будет метод, то всё будет намного прямее...
В чём "прямость"? Внешний вид не нравится или что?
BFE>>Да, это штатное использование, но без чтения кода или документации такое использование неожиданно. E>Без чтени документации неожиданнен сам shared_ptr, с чтнием нет.
Поведение shared_ptr вполне ожидаемо для человека знакомого с "умными" указателями.
E>Это же основная его функциональность вроде? Что неоиданно-то?
Неожиданно, что shared_ptr можно использовать для освобождения ресурса отличного от памяти.
BFE>>С переопределёнными операторами ровно тоже самое. E>Зависит от того, что конкретно делают те операторы. E>Сдвиги у указателя для меня крайне неожиданны и нелогичны.
Операция конкатенации для строк определённая через '+' тоже может быть неожиданна:
std::string two("2");
std::string three("3");
std::string five = two + three;//oops
E>>>Казалось бы, это иллюстрирует то, что принцип, как раз, работает BFE>>А я и не говорю, что он не работает. Я говорю, что один и тот же код, у разных программистов будет вызывать разную степень раздражения. E>IMHO, если у тебя код вызывает раздражение, то надо искать другое занятие. E>Плохой код не раздражание вызывает, а дорог в поддрежке и развитии...
Нормальная реакция человека на неправильную работу или на изменение привычного "хода вещей" — раздражение.
Здравствуйте, Erop, Вы писали:
BFE>>Поправте если я ошибаюсь, но унылость это нечто противоположное неожиданности. E>Не, в данном случае унылость -- это характеристика того говна, имени которого этот код... E>Я всё могу понть, но на кой навязывать объяктам MyList быть имуществом shared_ptr я не понимаю ни разу... А вдруг где-то ахочется сделать список полем, например?
И в чём проблема?
E>В любом случае, то, что operator << можно юзать для чего попало ни емеет непосредственного отношения к тому, что вы перекрыли его у shared_ptr<XXX> вместо того, чтобы перекрыть у самого ХХХ... E>Правда, если бы у вас был просто метод, то уродлство было бы сложнее написать.
Почему сложно и почему уродство ?:
CreateAndAddPairToListBox(oListBox, 0x6E747363, "NTSC");
CreateAndAddPairToListBox(oListBox, 0x6E743233, "NTSC2398 (3:2 pulldown)");
void CreateAndAddPairToListBox(shared_ptr<MyListBox> oListBox, unsigned int n, const char* str)
{
if ( !oListBox ) {
assert(false && "If you think that you can fill the empty object - think again!");
return;
}
Pair oPair(n, str);
AndAddPairToListBox(*oListBox, oPair);
}
E>Но сам по себе ход с operator<< не у того класса -- это тупо ниже плинтуса.
std::string тоже где-то внутри может хранить аналог shared_ptr<>, однако operator<< для string оторопь наверно не вызывает?
BFE>>А иначе и не бывает. Предположения всегда приходится строить. E>Бывает, но не в говнокоде.
Как не напиши, всё равно найдётся человек, который скажет, что это тупо или глупо.
E>Ну и ещё вопрос, на почве чего думаем-то? Если нам деже над такой ерундой, как инициализация списка константным перечнем надо думать, то это просто ужос-ужос...
В программировании не бывает мелочей.
BFE>>Видя operator << у указателя я бы предположил, что объект должен создаваться, если он пустой, после чего инициализироваться данными. E>Кошмар! E>А это для чего? Для маскировки ошибок?
В некоторых случаях это удобно и позволяет писать без ошибок. Пример, опять же std::string
E>Кроме того, а где берутся остальные параметры? Ну там, родительское окно, положение в нём, стили?..
Какие ещё родительские окна? Это вообще к окнам имеет отношение весьма опосредованное. Вы опять что-то предполагаете без всяких оснований.
BFE>>Вполне может быть. Я и такое встречал. E>Я вот не пойму. Ты, как я понял, настрадался от уродского "новаторства" в программировании. Зачем ты хочешь продолжать эту традицию? Ты хочешь "отомстить им", что ли?
Как не напиши, всё равно найдётся человек, который скажет, что это тупо или глупо. Значит и писать следует так, как нравится.
Здравствуйте, Erop, Вы писали:
BFE>> boost местами весьма загадочный и ненаглядный E>Ещё какой *ненаглядный* E>В общем, ты меня не убедил, что это хороший пример.
А я и не пытался убедить, что это "хороший" пример. Я просто показал, что в одной широко известной библиотеке так делают. Мне данный способ кажется остроумным.
E>>>Расширение -- это текст после точечки, если грубо BFE>>это у имени файла или каталога... E>Ну и?
это объекты другого типа
BFE>>Мало того, что устройства были занумерованы без имён, дак ещё и FORMAT может находится совсем не там, где WRITE: E>Ну так это же не оператора вина, а программиста...
Скорее создателя языка.
E>А сейчас, так вообще, определение класса никога не тоит рядом с использованием
это другое
BFE>>это просто? E>В С++ вообще нельзя задать формат отедельно от данных. Если это таки надо, то это очень неудобно. Если это таки не надо, то и на FORTRAN можно так не делать...
можно. более того, я вполне допускаю, что где то существуют библиотеки реализующие фортраный способ вывода на С++.
E>Ну на любом почти языке можно написать ужос. Ну и что? E>Тем не менее, если страдой не страдать, то на FORTRAN получалось егко и просто писать удобный и понятны ввод-вывод, который, к тому же, работал везде одинаково и быстро...
данные и формат их вывода в фортране разнесён — это первый минус. Второй — для правильного написания формата нужно изучить, по сути, ещё один маленький язык (если мне не изменяет память там даже циклы внутри оператора FORMAT есть). Критерий простоты в Фортране не выдержан.
Здравствуйте, Erop, Вы писали:
E>>>В С тоже неплохо... BFE>>да ну? как напечатать двадцать первых символов из строки с помощью printf не заглядывая в help? E>1) А как в плюсах?..
std::cout << str.substr(0, 20); E>2) %20.20s наверное? BFE>>а так же, всё это так безопасно... E>Ну на общем уровне безопасности в С...
E>Но в целом я согласен, что по пути FORTRAN -> C -> C++ вывод только деградировал и деградировал
Не согласен. По функциональным возможностям разницы нет, а по простоте использования есть улучшения.
Жаль, что так и не удалось увидеть "простой" проблемы простого решения.
Здравствуйте, B0FEE664, Вы писали:
E>>Я всё могу понть, но на кой навязывать объяктам MyList быть имуществом shared_ptr я не понимаю ни разу... А вдруг где-то ахочется сделать список полем, например? BFE>И в чём проблема?
А как его инициализировать тогда? Ведь для инициализации нужен shared_ptr?
Или предлагается сделать shared_ptr с пуситой функцией освобождения хэндэла?
BFE>Почему сложно и почему уродство ?:
Ну метод имущества "перевисть" на указатель сложнее...
На мой вкус тут есть некоторая шероховатость -- использование << немного расширительно и конркетное уродство -- переопределение оператора не у списка, а у указателя на него.
BFE>std::string тоже где-то внутри может хранить аналог shared_ptr<>, однако operator<< для string оторопь наверно не вызывает?
Дык basic_string -- это же пользовательсктй класс и для него переопределять операторы вполне естественно.
А shared_ptr -- класс библиотечный, и указатель, к тому же...
BFE>Если написать так: BFE>Если написать так: BFE>то одно мнение мы уже видили...
Так вполне нормально, но это не имеет никакого отношения к теме.
BFE>Как не напиши, всё равно найдётся человек, который скажет, что это тупо или глупо.
Мы вроде как сошлись с тобой, что ПРАВИЛЬНО это писать, через массив инициализаторв...
BFE>В программировании не бывает мелочей.
Угу, но хорший кодер пишет так, что и в сложном коде просто разобраться, а плохой так, что и над ерундой рпиходится думать...
BFE>В некоторых случаях это удобно и позволяет писать без ошибок. Пример, опять же std::string
у std::string нет семантики указателя! Нет!
По семнтике это просто последовательность char
Соответственно пустая строка -- это естественное значение по умолчанию.
У списка уже всё хуже. У него есть атрибуты, которые всё равно надо задать, чтобы его использовать.
Кроме того, у УКАЗАТЕЛЯ на список ещё более иная семантика...
BFE>Какие ещё родительские окна? Это вообще к окнам имеет отношение весьма опосредованное. Вы опять что-то предполагаете без всяких оснований.
Так в том-то и проблема что в вашем коде нихрена из кода не понятно...
BFE>Как не напиши, всё равно найдётся человек, который скажет, что это тупо или глупо. Значит и писать следует так, как нравится.
Писать надо так, чтобы потом легко было править. При чём не тебе, а тому умеренно квалифицированному парню, которого посадят потом на поддержку этого кода...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
E>>Дык если это будет метод, то всё будет намного прямее... BFE>В чём "прямость"? Внешний вид не нравится или что?
Ну там с налсдениками, другими классами, другими владельцами и т. д. вопросы автоматически решатся стандартным общеизвестным и ожидаемым способом...
BFE>Поведение shared_ptr вполне ожидаемо для человека знакомого с "умными" указателями.
Ну и тот код, который ты привёл, тогда тоже ожидаем...
BFE>Неожиданно, что shared_ptr можно использовать для освобождения ресурса отличного от памяти.
Почему неожиданно? Ты никогда с каким-нибудь COMPtr не сталкивался, что ли?
E>>Сдвиги у указателя для меня крайне неожиданны и нелогичны. BFE>Операция конкатенации для строк определённая через '+' тоже может быть неожиданна:
Да, и это тоже уродство.
Но есть несколько общепринятых альтернативных трактовок перегруженных операторов.
1) << >> для того куда можно что-то вывести и для того, откуда можно что-то достать
2) + -- конкатинация последовательностей букв.
Всё вроде как...
BFE>Нормальная реакция человека на неправильную работу или на изменение привычного "хода вещей" — раздражение.
Почему это? Почему раздражение, а не интерес, например?
Но это не важно всё. Говонокод не такое уж и чудо, чтобы удивляться. Беда тут в том, что обычно говокод трудно поддерживать и развивать. Собственно потому он и "говно-"...
Бывают языки и задачи, где код write only. Но это таки особое направление программирования.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>данные и формат их вывода в фортране разнесён — это первый минус.
Это не минус, а возможность. Типичная история, что один и тот же формат используют для ввода и вывода. Или для вывода из нескольких мест...
Просто есть возможность переиспользования кода. В С, кстати, она тоже есть, а в С++ уже нет...
BFE>Второй — для правильного написания формата нужно изучить, по сути, ещё один маленький язык (если мне не изменяет память там даже циклы внутри оператора FORMAT есть). Критерий простоты в Фортране не выдержан.
Это тоже возможность, а не проблема. Если тебе надо описать структуру таблицы, то циклы удобны. Ну и вообще, в С++ это толкьо хуже, нет форматов, но есть манипуляторы, которые более громоздкие и совсем непонятные...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
E>>1) А как в плюсах?.. BFE>std::cout << str.substr(0, 20);
Так в любом языке можно сделать. Ты не формат вывода изменил, а выводимые данные.
В FORTRAN и в С можно это сделать толкьо меняя формат...
E>>Но в целом я согласен, что по пути FORTRAN -> C -> C++ вывод только деградировал и деградировал BFE>Не согласен. По функциональным возможностям разницы нет, а по простоте использования есть улучшения.
1) Описать формат в отдеьном месте, и, например, импортировать его во все утилиты пакета. Попробуй это сделать в С++
BFE>Жаль, что так и не удалось увидеть "простой" проблемы простого решения.
Это я не понял.
Вывод FORTRAN, по твоим же криетериям лучше.
1) Он абсолютно переносим
2) Он очень быстрый
3) Он понятный.
или какие у тебя там были?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
BFE>>данные и формат их вывода в фортране разнесён — это первый минус. E>Это не минус, а возможность. Типичная история, что один и тот же формат используют для ввода и вывода. Или для вывода из нескольких мест... E>Просто есть возможность переиспользования кода. В С, кстати, она тоже есть, а в С++ уже нет...
Потенциально она всё же есть. Соданим класс FORMAT... , впрочем это вряд ли кому-то нужно.
BFE>>Второй — для правильного написания формата нужно изучить, по сути, ещё один маленький язык (если мне не изменяет память там даже циклы внутри оператора FORMAT есть). Критерий простоты в Фортране не выдержан. E>Это тоже возможность, а не проблема. Если тебе надо описать структуру таблицы, то циклы удобны.
Я не помню, что будет при несоответствии переданных данных формату в Фортране.
И я не говорю, что в Фортране есть проблема. Я говорю, что решение задачи ввода-вывода не может быть сделано просто. И в Фортане оно (решение) не простое.
E> Ну и вообще, в С++ это толкьо хуже, нет форматов, но есть манипуляторы, которые более громоздкие и совсем непонятные...
Ну я бы так не сказал. Что удобнее:
— написать два формата, один из которых, будучи применён к данным, дает вывод в виде таблицы, а другой в виде XML;
— написать две функции, одна из которых, будучи применёна к данным, дает вывод в виде таблицы, а другая в виде XML;
при усливии, что формат не может быть вынесен из программы и расматриваться как данные?
По мне — разницы нет.
Здравствуйте, Erop, Вы писали:
E>>>1) А как в плюсах?.. BFE>>std::cout << str.substr(0, 20); E>Так в любом языке можно сделать. Ты не формат вывода изменил, а выводимые данные. E>В FORTRAN и в С можно это сделать толкьо меняя формат...
Какая разница кто меняет данные: формат или функция?
E>>>Но в целом я согласен, что по пути FORTRAN -> C -> C++ вывод только деградировал и деградировал BFE>>Не согласен. По функциональным возможностям разницы нет, а по простоте использования есть улучшения. E>1) Описать формат в отдеьном месте, и, например, импортировать его во все утилиты пакета. Попробуй это сделать в С++
Я такими специфичными задачами не занимался, но подозреваю, что существует не одна библиотека в С++, которая решает данную задачу даже без перекомпиляции кода. На мой взгляд встраивать подобные средства в С++ было бы некоторым безумием.
E>Вывод FORTRAN, по твоим же криетериям лучше. E>1) Он абсолютно переносим E>2) Он очень быстрый E>3) Он понятный. E>или какие у тебя там были?
Здравствуйте, Erop, Вы писали:
E>>>Дык если это будет метод, то всё будет намного прямее... BFE>>В чём "прямость"? Внешний вид не нравится или что? E>Ну там с налсдениками, другими классами, другими владельцами и т. д. вопросы автоматически решатся стандартным общеизвестным и ожидаемым способом...
Это же не всеобъемлющий код, который раз и навсегда, в единой манере, оптимальным образом, для любых нынешних и будущих потомков....
Нет никаких других наследников и потомков то же нет. Для других классов — другой код. Что же касается стандартных, общеизвестных и ожидаемых способов, то нет критерия , что к ним относить, а что — нет.
BFE>>Поведение shared_ptr вполне ожидаемо для человека знакомого с "умными" указателями. E>Ну и тот код, который ты привёл, тогда тоже ожидаем...
Нет. Умный указатель не обязан иметь функцию освобождения ресурсов. Более того, один умный указатель может внутри содержать другой умный указатель...
BFE>>Неожиданно, что shared_ptr можно использовать для освобождения ресурса отличного от памяти. E>Почему неожиданно? Ты никогда с каким-нибудь COMPtr не сталкивался, что ли?
с каким-нибудь сталкивался, но ведь функция освобождения ресурса там не является параметром...
E>>>Сдвиги у указателя для меня крайне неожиданны и нелогичны. BFE>>Операция конкатенации для строк определённая через '+' тоже может быть неожиданна: E>Да, и это тоже уродство.
ну понятно...
BFE>>Нормальная реакция человека на неправильную работу или на изменение привычного "хода вещей" — раздражение.
E>Почему это?
Я слышал об экспериментах, которые специально ставили, чтобы прояснить этот вопрос. Оказалось, что так.
E>Почему раздражение, а не интерес, например?
Полагаю, что это является одним из основополагающих принципов когнитивных процессов. В общем виде, всякое отклонение от обычного процесса должно вызывать скорее настороженность, чем любопытство, так как такое изменение может быть опасно. Интерес же "должен" появляться от скуки, однако долгое отсутствие всяких внешних раздражителей тоже является раздражителем, так как само по себе отсутствие неожиданностей является неожиданностью.
E>Но это не важно всё. Говонокод не такое уж и чудо, чтобы удивляться. Беда тут в том, что обычно говокод трудно поддерживать и развивать. Собственно потому он и "говно-"...
Трудно поддерживать тот код, который написан с использованием концепций и стилей, которые неизвестны читателю. Это не значит, что код плохой. Плохой код, это когда количество связей между объектами неоправданно высоко или когда существуют негласные соглашения о динамической модели состояния объектов. Всё остальное — это дело стиля, не более.
Здравствуйте, B0FEE664, Вы писали:
BFE>Потенциально она всё же есть. Соданим класс FORMAT... , впрочем это вряд ли кому-то нужно.
Я имею в виду стандартный С++ ввод/вывод. То, что я знаю просто кучу альтернативных библиотек для этого дела, как бы намекает нам, что стандартный слегка УГ...
BFE>- написать два формата, один из которых, будучи применён к данным, дает вывод в виде таблицы, а другой в виде XML; BFE>- написать две функции, одна из которых, будучи применёна к данным, дает вывод в виде таблицы, а другая в виде XML; BFE>при усливии, что формат не может быть вынесен из программы и расматриваться как данные? BFE>По мне — разницы нет.
В фортране всё несколько иначе. Он не может быть вынесен из программы, но там ничего не может быть вынесено, зато он может быть переиспользован...
Примерно как библиотека в С
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Полагаю, что это является одним из основополагающих принципов когнитивных процессов. В общем виде, всякое отклонение от обычного процесса должно вызывать скорее настороженность, чем любопытство, так как такое изменение может быть опасно. Интерес же "должен" появляться от скуки, однако долгое отсутствие всяких внешних раздражителей тоже является раздражителем, так как само по себе отсутствие неожиданностей является неожиданностью.
Я думаю, что это от человека как бы зависит
Кого-тораздражает, а кому-то интересно...
BFE>Трудно поддерживать тот код, который написан с использованием концепций и стилей, которые неизвестны читателю. Это не значит, что код плохой. Плохой код, это когда количество связей между объектами неоправданно высоко или когда существуют негласные соглашения о динамической модели состояния объектов. Всё остальное — это дело стиля, не более.
Нет, всё-таки одни стили сильно проигрывают другим...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>Плохой код, это когда количество связей между объектами неоправданно высоко или когда существуют негласные соглашения о динамической модели состояния объектов.
Ну вот у тебя, например
1) Есть лишняя связь между списком и указателем, через функцию инициализации
2) Есть негласное соглашение о том, что в несозданный список можно выводить элементы
Ничего не смущает?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
E>>Ну вот у тебя, например E>>1) Есть лишняя связь между списком и указателем, через функцию инициализации BFE>Ничего подобного. Код списка и указателя можно менять независимо. Это внешняя операция по отношению к указанным объектам.
Ага-ага. А как мне заиметь таки список-поле?
E>>2) Есть негласное соглашение о том, что в несозданный список можно выводить элементы BFE>Ровно наоборот. У меня нет негласного соглашения, что в не созданный список нельзя выводить элементы.
Ну-ну. Обычно для указателей оно таки есть.
E>>Ничего не смущает? BFE>нет
Бывает В целом это хорошо, наверное
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, igna, Вы писали:
I>Да уж, пожалуй и в самом деле сложная, если для того чтобы прочитать файл в кодировке UTF-16 средствами стандартной библиотеки понадобилось ждать до 2011 года.
Все-таки C++ — это не Java, которую вы упоминаете ниже, а более низкоуровневый язык. Вместо поддержки каких-то конкретных кодировок на уровне языка были заданы два типа:
1) char — который использовался для хранения символов в, возможно, мультибайтной кодировке. Кодировка и размер были платформозависимы, а кодировка еще и локалезависимой;
2) wchar_t — который использовался для хранения символов в "широкой" кодировке и должен был вмещать любой символ из набора доступного на платформе в одну wchar'ину. Размер и кодировка тоже были платфомозависимы.
Ситуация здесь абсолютно такая же как с размерами short, int, long, которые, в отличии от той же Java'ы тоже могут меняться в зависимости от платформы.
Соответственно, если в Windows набор был ограничен UCS-2, wchar_t был 16-битным и вмещал любой доступный в системе символ. Все в общем-то было логично, до тех пор пока не появился UCS-4.
Здравствуйте, Erop, Вы писали:
BFE>>Потенциально она всё же есть. Соданим класс FORMAT... , впрочем это вряд ли кому-то нужно. E>Я имею в виду стандартный С++ ввод/вывод. То, что я знаю просто кучу альтернативных библиотек для этого дела, как бы намекает нам, что стандартный слегка УГ...
Именно библиотек или специфичных для системы API ? Да, и назовите хоть одну хорошую.
E>В фортране всё несколько иначе. Он не может быть вынесен из программы, но там ничего не может быть вынесено, зато он может быть переиспользован... E>Примерно как библиотека в С
Ну хорошо. Я так понимаю, что без формата вам библиотека не мила. Однако я так и не понял, чем формат лучше стиля с использованием переопределённого оператора << ?
Здравствуйте, Erop, Вы писали:
E>>>Ну вот у тебя, например E>>>1) Есть лишняя связь между списком и указателем, через функцию инициализации BFE>>Ничего подобного. Код списка и указателя можно менять независимо. Это внешняя операция по отношению к указанным объектам. E>Ага-ага. А как мне заиметь таки список-поле?
Если деструктор не защищён — обычным образом, а если защищён, то от указателя никуда не уйдешь
E>>>2) Есть негласное соглашение о том, что в несозданный список можно выводить элементы BFE>>Ровно наоборот. У меня нет негласного соглашения, что в не созданный список нельзя выводить элементы. E>Ну-ну. Обычно для указателей оно таки есть.
Это полностью зависит от стиля. Если в проекте принят ленивый стиль, то указатели никогда не создаются до момента их использования.
Здравствуйте, Erop, Вы писали:
E>>>Я всё могу понть, но на кой навязывать объяктам MyList быть имуществом shared_ptr я не понимаю ни разу... А вдруг где-то ахочется сделать список полем, например? BFE>>И в чём проблема? E>А как его инициализировать тогда? Ведь для инициализации нужен shared_ptr? E>Или предлагается сделать shared_ptr с пуситой функцией освобождения хэндэла?
Да ничего подобного! Можно использовать и обычные методы
BFE>>Почему сложно и почему уродство ?: E>Ну метод имущества "перевисть" на указатель сложнее... E>На мой вкус тут есть некоторая шероховатость -- использование << немного расширительно и конркетное уродство -- переопределение оператора не у списка, а у указателя на него.
А на мой взгляд тут есть непонимание того, что умный указатель, это уже не указатель, хотя и сильно на него похож.
BFE>>Как не напиши, всё равно найдётся человек, который скажет, что это тупо или глупо. E>Мы вроде как сошлись с тобой, что ПРАВИЛЬНО это писать, через массив инициализаторв...
Для инициализации — да. Но ведь перегрузка << может быть использована хитрее:
При этом ReadAndCreateArrayOfPairs может быть объектом, или функцией...
BFE>>В программировании не бывает мелочей. E>Угу, но хорший кодер пишет так, что и в сложном коде просто разобраться, а плохой так, что и над ерундой рпиходится думать...
Нет, это не аргумент. Если бы это было так, то к использованию shared_ptr никто бы не перешёл. Все бы так и использовали обычные указатели, что бы не думать над такой ерундой и переусложнением, как template'ная надстройка над указателем.
BFE>>В некоторых случаях это удобно и позволяет писать без ошибок. Пример, опять же std::string E>у std::string нет семантики указателя! Нет! E>По семнтике это просто последовательность char
вида char* E>Соответственно пустая строка -- это естественное значение по умолчанию. E>У списка уже всё хуже. У него есть атрибуты, которые всё равно надо задать, чтобы его использовать.
Я даже боюсь предположить, что вы скажите, если увидите такое:
E>Кроме того, у УКАЗАТЕЛЯ на список ещё более иная семантика...
Хмм. А это интересная мысль! operator ++ от shared_ptr<List> должен возвращать... (на этом мысль останавливается)
BFE>>Какие ещё родительские окна? Это вообще к окнам имеет отношение весьма опосредованное. Вы опять что-то предполагаете без всяких оснований. E>Так в том-то и проблема что в вашем коде нихрена из кода не понятно...
У коллег указанный код вопросов вообще не вызвал.
BFE>>Как не напиши, всё равно найдётся человек, который скажет, что это тупо или глупо. Значит и писать следует так, как нравится. E>Писать надо так, чтобы потом легко было править. При чём не тебе, а тому умеренно квалифицированному парню, которого посадят потом на поддержку этого кода...
Да ладно. Код-то простой. Это ведь не нечто, вроде:
Здравствуйте, B0FEE664, Вы писали:
E>>Я имею в виду стандартный С++ ввод/вывод. То, что я знаю просто кучу альтернативных библиотек для этого дела, как бы намекает нам, что стандартный слегка УГ...
BFE>Именно библиотек или специфичных для системы API ?
Библиотек или частей библиотек.
BFE>Да, и назовите хоть одну хорошую.
"хорошую" -- это провокация на мегафлейм.
Я назову пару популярных.
CFile
QFile
BFE>Ну хорошо. Я так понимаю, что без формата вам библиотека не мила. Однако я так и не понял, чем формат лучше стиля с использованием переопределённого оператора << ?
BFE>Ну и что мешает написать чего-нибудь вроде этого:
Кое-что мешает, но в целом есть библиотеки форматированного вывода, которые как-то так примерно и умеют...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
BFE>А на мой взгляд тут есть непонимание того, что умный указатель, это уже не указатель, хотя и сильно на него похож.
так в том и косяк!
Вот посмотри на string, например. Оно может внутри себя иметь COW указатель на тело, но, тем не менее, она на указатель никак не похожа. Указатель -- это подробность реализаии и наружу не торчит.
Был бы у тебя MyListBody и MyList { shared_ptr<MyListBody> body; /*тут ещ public интерфейс*/ };
Ни у кого бы и вопроса никакого не возникло...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
BFE>>Да, и назовите хоть одну хорошую. E>"хорошую" -- это провокация на мегафлейм.
Ну тогда в какой библиотеке ввод вывод решается просто?
E>Я назову пару популярных. E>CFile
Это примитивная обёртка над файлом. Будет ли CFile работать с терминальным вводом выводом — это ещё вопрос...
E>QFile
Это опять же файл, а не нечто универсальное. К тому же в документации предлагается и такой метод:
QFile file("file.dat");
file.open(QIODevice::WriteOnly);
QDataStream out(&file); // we will serialize the data into the file
out << QString("the answer is"); // serialize a string
out << (qint32)42; // serialize an integer
Что же касается реализации всего этого, то она не тривиальна.
К тому же из за того, что Qt не использует теплэйты можно кричать ужас-ужас на эту строчку:
Здравствуйте, B0FEE664, Вы писали:
BFE>Это примитивная обёртка над файлом. Будет ли CFile работать с терминальным вводом выводом — это ещё вопрос...
E>>QFile BFE>Это опять же файл, а не нечто универсальное. К тому же в документации предлагается и такой метод:
Я как бы напоминаю тебе, мой довод состоит в том, что был бы стандатны ввод/вывод удобным -- эти классы бы не появились...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
BFE>>А на мой взгляд тут есть непонимание того, что умный указатель, это уже не указатель, хотя и сильно на него похож. E>так в том и косяк!
И всё же. вот: const shared_ptr<T> и const T* это не одно и то же
E>Вот посмотри на string, например. Оно может внутри себя иметь COW указатель на тело, но, тем не менее, она на указатель никак не похожа. Указатель -- это подробность реализаии и наружу не торчит.
За исключением c_str()
В shared_ptr указатель тоже наружу не торчит.
E>Был бы у тебя MyListBody и MyList { shared_ptr<MyListBody> body; /*тут ещ public интерфейс*/ }; E>Ни у кого бы и вопроса никакого не возникло...
Если у /*тут ещ public интерфейс*/ не добавлено ничего нового по сравнению с MyListBody, то скажут, что я напрасно потратил время на набивание методов, которые ничего не делают. К тому же возникнут вопросы, как быть с наследниками MyListBody... и т.д. и т.п.
Здравствуйте, B0FEE664, Вы писали:
BFE>За исключением c_str()
Не обязан возвращать указатель на тело строки. Тело строки не обязано ежать подряд и т. д...
BFE>Если у /*тут ещ public интерфейс*/ не добавлено ничего нового по сравнению с MyListBody, то скажут, что я напрасно потратил время на набивание методов, которые ничего не делают. К тому же возникнут вопросы, как быть с наследниками MyListBody... и т.д. и т.п.
слушай, посмотри, как строка реализована, и не морочь мне голову. Там никто ничего не дублирует, и всё у них хорошо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Я как бы напоминаю тебе, мой довод состоит в том, что был бы стандатны ввод/вывод удобным -- эти классы бы не появились...
Здравствуйте, B0FEE664, Вы писали:
E>>Я как бы напоминаю тебе, мой довод состоит в том, что был бы стандатны ввод/вывод удобным -- эти классы бы не появились...
BFE>А я разве с этим спорил?
Я не очень понимаю, с чем ты споришь. Но окей, так и запишем. Ты призна, что потоки неудобные. Так?
Кстати в С и FORTRAN альтернативных бибиотек ввода-вывода что-то не припомню
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>>>Я как бы напоминаю тебе, мой довод состоит в том, что был бы стандатны ввод/вывод удобным -- эти классы бы не появились... BFE>>А я разве с этим спорил? E>Я не очень понимаю, с чем ты споришь. Но окей, так и запишем. Ты призна, что потоки неудобные. Так?
1) Перегрузка оператора '<<' для вывода — это хорошая идея;
2) Задача ввода-вывода это не простая проблема.
Спорить же о том хороша или нет стандартная библиотека ввода-вывода у меня желания нет. Возможно и вероятно она могла бы быть реализована лучше и удобнее. Что же касается традиционного способа ввода-вывода с помощью форматов, то такой подход ещё хуже, чем стандартная библиотека. Главные минусы форматированного вывода я вижу такие: (1) язык описания формата имеет, как правило, труднозапоминаемый и неудобный синтаксис, (2) обработка ошибок при несоответствии данных формату труднореализуема, если вообще возможна, (3) разбор строки формата в реалтайме (ака printf) в принципе плохая идея. Я понимаю, что третья причина в Fortran'е отсутствует, однако первые две остаются.
E>Кстати в С и FORTRAN альтернативных бибиотек ввода-вывода что-то не припомню
Я вообще с трудом припомнил способ организации ввода-вывода в Фортране. Уже более 15 лет прошло с тех пор, как я его использовал последний раз.
Здравствуйте, Кодт, Вы писали:
BFE>>Если у /*тут ещ public интерфейс*/ не добавлено ничего нового по сравнению с MyListBody, то скажут, что я напрасно потратил время на набивание методов, которые ничего не делают. К тому же возникнут вопросы, как быть с наследниками MyListBody... и т.д. и т.п. К>Какие ещё наследники? Кто-то сам говорил, что наследников нет, и поэтому можно не заморачиваться.
В данном, конкретном случае это так. В общем случае — нет.
Перекуём баги на фичи!
operator ++ от shared_ptr<List> должен возвращать... (на этом мысль останавливается) 