Здравствуйте, SaZ, Вы писали:
SaZ>И сидят такие на Qt4, MFC, WTL и прочих. При этом пытаются доказывать и аргументировать свою позицию фразами типа "для моих задач этого достаточно", а потом начинают бороться с тем, что умные люди уже давно решили в современных фреймворках.
Ну вот я охотно и с удовольствием применяю свежайшие микросхемы, транзисторы, датчики и прочие радиодетали в электронных устройствах, ибо они одновременно меньше по размерам, массе, универсальнее, неприхотливее, надежнее, проще (как правило) в применении и т.п. То есть, от их применения получаешь чистое удовольствие, и [почти] не получаешь неприятных эмоций.
А вот как только я касаюсь даже относительно новых программных решений, так почти всегда оказывается, что они непропорционально велики по размеру, требуют неадекватных своей функциональности ресурсов, достаточно свежих версий ОС, библиотек и компонент, накладывают искусственные ограничения, тормозят в работе и т.п. А те, кто хоть давно, хоть недавно решился с ними связаться, регулярно жалуются на очередные ограничения в использовании, отказ от поддержки не самых старых систем, повышение требований к ресурсам и т.п. Поэтому я каждый раз печально вздыхаю, и делаю все нужное сам.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А вот как только я касаюсь даже относительно новых программных решений, так почти всегда оказывается, что они непропорционально велики по размеру, требуют неадекватных своей функциональности ресурсов, достаточно свежих версий ОС, библиотек и компонент, накладывают искусственные ограничения, тормозят в работе и т.п. А те, кто хоть давно, хоть недавно решился с ними связаться, регулярно жалуются на очередные ограничения в использовании, отказ от поддержки не самых старых систем, повышение требований к ресурсам и т.п. Поэтому я каждый раз печально вздыхаю, и делаю все нужное сам.
Вот у меня с консервированными огурцами такая же фигня. То голова в банку не пролазит, то рука застревает.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Marty, Вы писали:
M>Чего уродливого в std::string или std::vector?
Они хранят данные одним куском. Уже жирный минус. std::string это std::basic_string<char>, но почему никто не использует std::basic_string<unsigned char> знаете? Это ли не уродство?
M>Или в сортировке, например: std::stable_sort(v.begin(), v.end())?
Почему аргументы должны быть одинакового типа?
Здравствуйте, rg45, Вы писали:
R>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector.
std::string — засунуть '\0' в середину и удивляться выводу...
например, так:
char asdf[20];
.... //получение данных в asdf от устройства
std::string str(std::begin(asdf), std::end(asdf));
std::vector — ну, классика — это конструктор с двумя аргументами.
Вот из недавнего:
std::vector<char> factorList{0x20, 0x80};
— компиляция пройдёт или нет, в зависимости от того , какой нынче char у компилятора, но если исправить на
Здравствуйте, B0FEE664, Вы писали:
R>>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector. BFE> BFE>std::string — засунуть '\0' в середину и удивляться выводу... BFE>например, так:
А если бы std::string не был шаблоном, это как-то помогло бы? Так-то ноль можно и в середину строкового литерала засунуть и точно так же удивляться.
Я думал, мы говорим о такких ошибках, которые приводят к ошибкам компиляции:
Мне не нравится, когда при моих непреднамеренных ошибках все это говно вспучивает из-под капота, и мне приходится разглядывать многострочные, но маловразумительные тексты, чтобы догадаться, что же именно пошло не так.
BFE>std::vector — ну, классика — это конструктор с двумя аргументами. BFE>Вот из недавнего: BFE>
Если использование библиотеки предполагает включение заголовка с этими "десятиэтажными шаблонами" в клиентский код, она никак не может быть "максимально проста в использовании". Чисто технически.
У него главная и единственная претензия к стандартной библиотеке — это то, что она шаблонная. Все твои нюансы ему до фонаря.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, B0FEE664, Вы писали:
M>>Чего уродливого в std::string или std::vector? BFE>Они хранят данные одним куском. Уже жирный минус.
И в чем же минус? Более того, это поведение заложено в спеке. Есть куча других контейнеров, которые по разному хранят данные. Это самая универсальная базовая структура, и максимально быстрая структура с произвольным доступом к элементам. Мне было бы очень странно выдеть вектор и строку, реализованные как-то иначе.
BFE>std::string это std::basic_string<char>, но почему никто не использует std::basic_string<unsigned char> знаете? Это ли не уродство?
Во-первых — не знаю, во-вторых я частенько использую. В-третьих таки в чем уродство?
M>>Или в сортировке, например: std::stable_sort(v.begin(), v.end())? BFE>Почему аргументы должны быть одинакового типа?
Самый универсальный способ задания последовательности — начальным и конечным итераторами, полуоткрытый интервал. Любое другое — будет кривизна
Здравствуйте, B0FEE664, Вы писали:
R>>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector. BFE> BFE>std::string — засунуть '\0' в середину и удивляться выводу...
BFE>например, так:
BFE>
BFE>char asdf[20];
BFE>.... //получение данных в asdf от устройства
BFE>std::string str(std::begin(asdf), std::end(asdf));
BFE>
Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают.
А так — я вполне себе при нужде храню в строках нули.
BFE>std::vector — ну, классика — это конструктор с двумя аргументами. BFE>Вот из недавнего: BFE>
Да, с инитиализер лист и универсальной инициализацией не всегда очевидно, появилось много новых способов ининциализации. Но можно таки выбрать менее неоднозначные, ну и да, надо ориентироваться в этих правилах. Для тебя сюрприз, что язык надо знать?
Но это не проблема конкретно вектора. Это дизайн языка. Наверное, можеткак-то и можно было сделать лучше, но чтобы понимать, почему сделали именно так, надо читать PR по всем этим дополнениям, и их обсуждения. Тогда, наверное, будет понятно, почему сделали так, а не иначе.
Здравствуйте, SaZ, Вы писали:
SaZ>Тут ещё есть другая категория похожих людей (не только на рсдн) — это которые упорно долбят старьё и при этом категорически отказываются от новых технологий, думая что старое == хорошее. И сидят такие на Qt4, MFC, WTL и прочих. При этом пытаются доказывать и аргументировать свою позицию фразами типа "для моих задач этого достаточно", а потом начинают бороться с тем, что умные люди уже давно решили в современных фреймворках.
Ну, я не то чтобы упорно долблю старьё, но по плюсам — отстаю обычно на один или два стандарта — не хочу вновь раскладываемым граблям ходить, жду, когда устаканится.
Qt — пока на пятом, ничего нового не делаю, а старые тулзы, которые по мелочам допиливаются, переносить на шестой — а зачем мне этот гемор на ровном месте?
WTL — когда надо что-то легковесное сделать, чисто под винду, обычно это какие-то диалоги — и сейчас использую без проблем.
Здравствуйте, rg45, Вы писали:
R>Я думал, мы говорим о такких ошибках, которые приводят к ошибкам компиляции:
То, что ему чего-то не нравится — это его личные предпочтения. Пока нет конкретики, говорить не о чем.
R>У него главная и единственная претензия к стандартной библиотеке — это то, что она шаблонная.
Нет. Позиция Евгения Музыченко хорошо известна, он её много раз излагал. Суть сводится к тому, что он попытка связать std и C++ в единый и неразрывный монолит — это стратегически плохая идея и что эти две части всегда надо рассматривать отдельно друг от друга. Ещё ему не нравится std из-за стиля, из-за хрупкости шаблонов и скрытых требований к ресурсам. Других разумных аргументов он не излагал.
R>Все твои нюансы ему до фонаря.
Так я не ему отвечал. Не по теме? Как скажите.
Здравствуйте, Marty, Вы писали:
M>Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают. M>А так — я вполне себе при нужде храню в строках нули.
Удивление не в данных, а в том, что с одной стороны std::string всегда хранит завершающий ноль, а с другой может ещё и в середине ноль хранить.
BFE>>std::vector — ну, классика — это конструктор с двумя аргументами. BFE>>Вот из недавнего: BFE>>
BFE>>то можно получить цвет детской неожиданности.
M>Да, с инитиализер лист и универсальной инициализацией не всегда очевидно, появилось много новых способов ининциализации. Но можно таки выбрать менее неоднозначные, ну и да, надо ориентироваться в этих правилах. Для тебя сюрприз, что язык надо знать?
Помнить все 20 способов инициализации, притом, что некоторые зависят от используемого стандарта — это просто и удобно.
Ну и ещё надо всегда держать в памяти, что авторы стандарта пишут не то, что хотят сказать.
M>Но это не проблема конкретно вектора. Это дизайн языка. Наверное, можеткак-то и можно было сделать лучше, но чтобы понимать, почему сделали именно так, надо читать PR по всем этим дополнениям, и их обсуждения. Тогда, наверное, будет понятно, почему сделали так, а не иначе.
Нет, это, конкретно, проблема вектора, причём она существовала с самого начала. Эта проблема легко распознаётся ещё на стадии написания реализации конструктора с двумя (тремя, на самом деле) параметрами, так как его реализация весьма и весьма сложна.
Здравствуйте, B0FEE664, Вы писали:
M>>Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают. M>>А так — я вполне себе при нужде храню в строках нули. BFE>Удивление не в данных, а в том, что с одной стороны std::string всегда хранит завершающий ноль, а с другой может ещё и в середине ноль хранить.
А в чем проблема? Завершающий ноль — для совместимости с сишными АПИ. Не было бы его — ты бы кричал — какая кривая std::string, нельзя сишные АПИ использовать с ней.
Ноль в середине? А что надо делать, если программист сам его по недомыслию кладёт?
M>>Но это не проблема конкретно вектора. Это дизайн языка. Наверное, можеткак-то и можно было сделать лучше, но чтобы понимать, почему сделали именно так, надо читать PR по всем этим дополнениям, и их обсуждения. Тогда, наверное, будет понятно, почему сделали так, а не иначе. BFE>Нет, это, конкретно, проблема вектора, причём она существовала с самого начала. Эта проблема легко распознаётся ещё на стадии написания реализации конструктора с двумя (тремя, на самом деле) параметрами, так как его реализация весьма и весьма сложна.
Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
Здравствуйте, Marty, Вы писали:
M>>>Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают. M>>>А так — я вполне себе при нужде храню в строках нули. BFE>>Удивление не в данных, а в том, что с одной стороны std::string всегда хранит завершающий ноль, а с другой может ещё и в середине ноль хранить. M>А в чем проблема?
Это отход от принципа "не платим за то, что не используем." M>Завершающий ноль — для совместимости с сишными АПИ.
Для совместимости было бы логично завести отдельный класс. M>Не было бы его — ты бы кричал — какая кривая std::string, нельзя сишные АПИ использовать с ней.
И был бы прав: С++ строка, С строка и, скажем, BSTR строка — это три разные вида строк. Для каждой из них следует сделать отдельный класс: в С строке не хранится длина, в C++ нет завершающего нуля и единого куска, а BSTR лежит в памяти в определённом порядке. Они должны свободно конвертироваться одна в другую и поддерживать операции с общими названиями.
M>Ноль в середине? А что надо делать, если программист сам его по недомыслию кладёт?
А что будет в С если '\0' засунуть в середину строки?
M>Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
Да, был не прав, конечно, у других контейнеров std конструкторы с двумя параметрами имеют ту же проблему: по виду x(a, b) который из двух конструкторов вызовется сказать нельзя — надо знать типы a и b. Разрешали и разрешают эту ситуацию с помощью метапрограммирования.
Здравствуйте, B0FEE664, Вы писали:
M>>А в чем проблема? BFE>Это отход от принципа "не платим за то, что не используем."
Так постоянно используется. Да и завершающий 0 — смешная плата
M>>Завершающий ноль — для совместимости с сишными АПИ. BFE>Для совместимости было бы логично завести отдельный класс.
И туда-сюда конвертить?
А такая строка, без завершающего нуля — уже есть. Называется std::vector<char>
M>>Не было бы его — ты бы кричал — какая кривая std::string, нельзя сишные АПИ использовать с ней. BFE>И был бы прав: С++ строка, С строка и, скажем, BSTR строка — это три разные вида строк. Для каждой из них следует сделать отдельный класс: в С строке не хранится длина, в C++ нет завершающего нуля и единого куска, а BSTR лежит в памяти в определённом порядке. Они должны свободно конвертироваться одна в другую и поддерживать операции с общими названиями.
BSTR — это вообще частный случай строк в одной из технологий на одной из платформ. Можешь сделать сам класс для BSTR. Хотя стоп, такие классы вроде уже есть в MFC/ATL. Не помню, правда, есть ли там конвертация в/из std::string. Можешь дописать
А зачем тебе отдельно С++ строка и С строка? Чтобы при вызове сишного АПИ было дополнительное преобразование?
M>>Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
BFE>Да, был не прав, конечно, у других контейнеров std конструкторы с двумя параметрами имеют ту же проблему: по виду x(a, b) который из двух конструкторов вызовется сказать нельзя — надо знать типы a и b. Разрешали и разрешают эту ситуацию с помощью метапрограммирования.
Надо просто запомнить, что первым аргументом идёт count, вторым — значение элемента. Так как у всех контейнеров это сделано единообразно, запомнить не так уж сложно. Также есть метод assign с такой же сигнатурой.
Ни разу не приходилось использовать метапрограммирование для использования таких конструкторов. Зачем? Для чего?
Здравствуйте, Marty, Вы писали:
M>... M>Qt — пока на пятом, ничего нового не делаю, а старые тулзы, которые по мелочам допиливаются, переносить на шестой — а зачем мне этот гемор на ровном месте? M>...
Ну тут вопрос в том, что именно делать. Если нужен современный гуй, рисуемый на gpu, с поддержкой анимаций и т.п., то в qt5 qml безнадёжно устарел. А шестой уже очень хорошо умеет даже в вебассембли. Я вот сча стартапчик начал делать на нём. Бэкэнд: userver, фронт: в основном qml, шаред код: cpp, boost, sqlite_orm. На выходе получается сервер под линух (или мак для отладки), мобильные приложения под iOS/Android (с мобильным сайтом решил не упарываться), а под десктоп/планшеты — wasm через веб, ну или тоже нативное приложение (впрочем, сомневаюсь что оно пригодится).
Вообще меня впечатлила на это дело демка: try.qt.io. Я понимаю, что в qml хватает косяков, я за ним слежу лет 8, но сейчас считаю что технология вполне себе созрела для продакшена. В ембеддед я не умею, там уже давно и много где qml.
Здравствуйте, SaZ, Вы писали:
SaZ>Ну тут вопрос в том, что именно делать. Если нужен современный гуй, рисуемый на gpu, с поддержкой анимаций и т.п., то в qt5 qml безнадёжно устарел. А шестой уже очень хорошо умеет даже в вебассембли. Я вот сча стартапчик начал делать на нём. Бэкэнд: userver, фронт: в основном qml, шаред код: cpp, boost, sqlite_orm. На выходе получается сервер под линух (или мак для отладки), мобильные приложения под iOS/Android (с мобильным сайтом решил не упарываться), а под десктоп/планшеты — wasm через веб, ну или тоже нативное приложение (впрочем, сомневаюсь что оно пригодится).
Здравствуйте, B0FEE664, Вы писали:
BFE>Позиция Евгения Музыченко хорошо известна, он её много раз излагал. Суть сводится к тому, что он попытка связать std и C++ в единый и неразрывный монолит — это стратегически плохая идея и что эти две части всегда надо рассматривать отдельно друг от друга.
Это, по большому счету, меньшее зло. В конце концов, пока в ядре языка практически нет скрытых завязок на std (тот же for по коллекции не заставляет ее импортировать), это не мешает жить на практике, больше добавляет непоняток в обсуждениях.
BFE>Ещё ему не нравится std из-за стиля, из-за хрупкости шаблонов и скрытых требований к ресурсам.
Вот это — основная претензия. "Хрупкость шаблонов" ведь не на пустом месте возникла — это прямое следствие того, что механизм шаблонов до сих пор не имеет адекватных средств управления ими, и все, что выходит за пределы простого обобщения, по-прежнему реализуется исключительно на побочных эффектах (трюках), которые технически невозможно полностью запихать "под капот", чтоб они оттуда никак не вылезали.
Мне это все напоминает электрощит со множеством торчащих из него проводов, которые то коряво скручены, то соединены самодельными переходниками, где соединены провода разного сечения и цвета, одножильные и многожильные, медные и алюминиевые, одни соединения коряво обмотаны изолентой, другие столь же коряво облиты термоклеем, и так далее. Часть защитных автоматов закорочена, еще часть не соответствует по номиналам, и т.п.
Но апологеты всей этой кухни напирают прежде всего на то, что щит снаружи закрыт красивой крышкой, на которой аккуратным шрифтом сделаны пометки. А то, что из-под крышки регулярно идет дым и летят искры, и ее приходится снимать, они предпочитают лишний раз не вспоминать.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>У него главная и единственная претензия к стандартной библиотеке — это то, что она шаблонная.
ЕМ>Это Вы так упрощенно понимаете. Ну, или каждый раз забываете все мои разъяснения по этим вопросам.
Всего лишь слегка утрирую. Художественная пессимизация.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Встречалась ли вам концепция — "C++ как C с классами".
S>Вы скажите — в чем тогда смысл, не лучше ли писать сразу на Java? А смысл чисто практический — по факту С++ наиболее кросс-платформенный и наименее гемморный на сегодня. Дошло до того, что C# компиллят в C++. Здесь не вопрос холивара — просто по факту так оно и есть.
S>Встречали ли вы такую концепция кодирования? Одобряете?
На концептуальный вопрос, концептуальный ответ
Если инструмент не позволяет сделать что-то эффективно,
то следует его заменить или разработать новый..
..Компилятор:
(1) Исходный текст -> (2) сборка модели программы -> (3) компиляция в ядре языка -> (4) целевой код.
1. Исходный текст находится терминах задачи.
Далее он трансформируется в модель программы на языке согласно некоторому стандарту.
Сейчас стандарт навязывается производителями компиляторов.
2. Исходный текст нужен лишь для первичной сборки модели программы в компиляторе.
Сложность модели зависит от стандарта (языка) компилятора.
Но здесь возможна точка сборки локального стандарта проекта
из доступных имеющихся свойств компилятора (языка),
а если нет нужных свойств, то их можно/нужно дописать под проект,
расширив свойства (языка) компилятора.
3. Если мы собрали локальный стандарт проекта,
то и компиляция в целевой код будет согласно уже локальному стандарту проекта.
4. Целевой код тоже может быть разным,
даже текстовым для компиляторов (языков) низшего уровня.
Получается:
Для входа на некоторую платформу,
необходим базовый компилятор с минимальными свойствами платформы.
Минимальные свойства можно стандартизировать,
а расширенные поставлять в виде программных свойств проекта.
Это можно проделать почти на любом языке программирования.
PS: Думаю, что модель компиляторов с закрытыми свойствами весьма ограничена.
Ты обсуждение читаешь вообще?
