Здравствуйте, netch80, Вы писали:
BFE>>Так я о том и пишу, что пора бы уже отказаться от старья и перейти на новый стандарт для терминалов. N>Как он будет выглядеть? Вы хотите полный GUI? Графические примитивы на фреймбуфере? Что-то иное? N>Как будете реализовывать общение с человеком? N>Проблема практически именно в том, что никто не может предложить этот новый стандарт, чтобы он был хоть как-то универсальным. "15 competing standards", ага...
Я могу описать свои хотелки и — да, я хочу полный GUI и несколько окон для ввода-вывода для одного приложения.
Есть международные институты стандартизации, сотрудникам которых неплохо платят. Было бы не плохо, если бы они всем этим занялись...
N>Зато текст, даже в ASCII, тут туп и надёжен.
Вот — нет. Как только текст на языке отличном от английского, так читать очень сложно.
BFE>>Покажите мне что-то в современном мире, что ещё работает в алфавитно-цифровом режиме. Такого оборудования на практике больше не встречается: все терминалы сейчас — это графическая эмуляция, в которой есть и скроллы и шрифты. N>Насчёт шрифтов я бы ой не был уверен. Да, много решений, где тебе дали пиксельный фреймбуфер, и дёргайся как хочешь. Шрифты уже в софте. Скролл тоже там. И чем это так уж лучше? Кто-то будет рамочки рисовать? N>Но чтобы все такими были — нет. В embedded куча зверей с прошитыми фонтами. За их пределами и не в x86, да, не видел (в x86, может оказаться, текстовые режимы делает процессор видяхи). Но всё равно вопрос в лёгкости управления.
В embedded обычно можно подключится вторым терминалом с нормальным экраном и там всё сделать удобно и красиво, а встроенные терминалы можно делать как обычно.
BFE>> Реализация в 1-10 килобайт — кому она нужна? Я вообще не помню, чтобы последние десять лет я держал в руках что-то современное, что в себе содержало менее 32 мегабайт памяти. Не понимаю я причём тут размер. N>Ну вы не держали, верю. Я держал, хоть и недолго. Полмега на всё и крутись как хочешь. И просто зачем тут что-то лишнее? Сколько уйдёт на полноценный гуй или что там вы предлагаете?
Так ведь гуй не обязательно запускать внутри
N>>>Заметим, стиль IBM для того же — где не выжили 3270 с компанией, ушёл в музей. А мест, где выжили — очень мало. BFE>>И что? N>Именно то, что это оказалось в среднем самым полезным стилем. N>И сравнение со стилем 3270, который тоже текстовый, но другой, тут показательно.
Выживание не всегда связано с пользой. Возьмём, к примеру ICQ — это не первый и не последний chat, в своё время очень популярный, номер 1, но можно считать, что не выжил. А почему? Моё мнение — исключительно потому, что менеджеры не придумали как на нём делать деньги и как развивать. Тоже самое могло произойти и с IBM 3270, хотя про их терминал ничего сказать не могу.
BFE>>Вы не поняли, я не против терминального ввода вывода, я против его старой убогой реализации. N>Покажете новую? Как именно она будет выглядеть?
Показать не могу — не видел ничего достойного. Могу рассказать как надо делать: надо смотреть с какими трудностями сталкиваются пользователи и как сделать удобно.
Очевидные трудности:
— вывод в одно окно всего и вся, предполагаемое решение — несколько окон/закладок (для одного приложения);
— ввод и вывод из одного окна, предполагаемое решение — выделенная область ввода;
— поддержка естественных языков, предполагаемое решение — UTF-8;
— не удобная работа с историей, предполагаемое решение — отдельное окно вызываемое по Ctrl-R с возможностью навигации, поиска, фильтрования, редактирования и историей редактирования;
— не удобное скролирование больших объёмов выведенного текста, предполагаемое решение — свёртка результатов для каждого отдельного запуска/вывода, "умный" (двойной) скролбар, автоматическое сворачивание однотипных блоков...
Каждое окно должно быть с поиском, с фильтром, изменяемых размеров и возможностями кастомизации.
N>Сейчас вопрос именно в этом.
Разве? Мне так кажется, что сейчас "никому ничего не нужно", так как все привыкли и могут обойтись тем, что есть.
N>>>На порядки проще GUI со всей его спецификой — поля разных типов, лейауты, реакции виджетов,, фонты, цвета, ресайзинг, и ещё 100500 мелочей... BFE>>Мне не нужны простые, мне нужны удобные и эффективные инструменты. N>Так всё-таки, будет пример?
Нет, нету примеров. Но могу точно сказать, тащить разметку и веба в терминал не следует.
N>Я согласен и на корявые зюки в Paint, лишь бы идею понять.
А чего тут понимать? Начать надо с того, что взять окно для редактирования текста (любое, как вот это, в котором я сейчас ввожу текст) и пришить к нему снизу вывод текста из терминала — одно это решит половину проблем.
BFE>>Так об этом я и пишу, что форматирование данных и их вывод — это разные операции. N>Да, разные. Но на каком-то уровне они сходятся, как протокол передачи в диск.
Не надо так низко опускаться — удобнее работать на высоком уровне.
N>А дальше — вставляются. Там фрейминг и всё такое. N>Просто вы почему-то решили, что это единственный путь. Библиотеку curses видели? N>Там это разделено. И для TUI она — первая рекомендация на всё. N>То, что кто-то отказался от этого в генерации PS1, не значит, что его решение было лучшим.
Не-не-не. Это не правильный путь вникуда. Ввод-вывод должен остаться потоковым, а вот работа с потоками должна быть улучшена на уровне стандарта.
BFE>>Это принципиальный вопрос качества: если входные данные портят поведение программы, то это баг программы, а не данных. N>А если она просто говорит "тут фигня пришла"?
Диагностировать ошибку, а не втихую следовать за ошибочными данными.
N>Заметим, вопрос остался без ответа.
JACM не читаю.
BFE>> Собственно, появление таких языков, как Java, C# и вот, Rust — это попытка ограничить языковыми средствами непонимание простыми программистами принципов безопасной разработки многопоточных программ. N>Или то, что эти принципы невозможно точно полностью соблюсти на огромных проектах, и лучше, когда рантайм позаботится. Ибо to err is human.
Тут не согласен: чем больше проект, тем лучше соблюдаются принципы разработки, так как в противном случае проект перестаёт существовать.
N>И вот этот вариант я считаю основным как причиной появления всех названных.
Ошибки людей могут быть компенсированы организацией кода и Rust, видимо, тому пример.
BFE>>А вот стандартной очереди для безопасной передачи данных из одной нитки в другую как не было, так и не будет. N>А как бы выглядела такая стандартная очередь?
Как потокобезопасная очередь (ограниченного размера), с методом push на стороне отправителя и методами pop и pop_all на стороне принимающего.
+
отдельный объект синхронизации
BFE>>Не знаю я, что с Event'ом не то. Уже который год в каждом новом проекте (и не только новом) я пишу обёртку вокруг CV, чтобы превратить его в Event, чтобы было можно хоть как-то унифицировано работать с объектами синхронизации. N>Под Unix?
В основном — да, Debian, но код мультиплатформенный, работает везде.
N>Каким образом завлекаете его, например, в poll (epoll, etc.)?
Обычно никаким, так как не выхожу за пределы стандарта. В случае сопряжения с другими библиотеками запускаю отдельную нитку для сопряжения синхронизации одного объекта с другим.
Здравствуйте, B0FEE664, Вы писали:
CC>>>Hint: в бизнес логике не должно быть raw pointers S>>А что должно быть? Исключительно unique_ptr/shared_ptr?
BFE>Да + intrusive_ptr, если хотите скорости.
unique/shared/intrusive_ptr -- это все для владеющих указателей.
Невладеющие указатели/ссылки вы предлагаете пустить в топку?
Здравствуйте, so5team, Вы писали: S>>>Невладеющие указатели/ссылки вы предлагаете пустить в топку? BFE>>Кто-то отменил std::weak_ptr ? S>Вы вообще в курсе чем отличаются владеющие указатели от невладеющих?
Да.
Здравствуйте, B0FEE664, Вы писали:
S>>>>Невладеющие указатели/ссылки вы предлагаете пустить в топку? BFE>>>Кто-то отменил std::weak_ptr ? S>>Вы вообще в курсе чем отличаются владеющие указатели от невладеющих? BFE>Да.
Тогда зачем вы упоминаете weak_ptr?
S>>здесь нужно возвращать std::weak_ptr, я правильно вас понял? BFE>Нет. Зачем здесь std::weak_ptr?
Здравствуйте, so5team, Вы писали:
S>>>>>Невладеющие указатели/ссылки вы предлагаете пустить в топку? BFE>>>>Кто-то отменил std::weak_ptr ? S>>>Вы вообще в курсе чем отличаются владеющие указатели от невладеющих? BFE>>Да. S>Тогда зачем вы упоминаете weak_ptr?
weak_ptr — пример невладеющего указателя.
S>>>здесь нужно возвращать std::weak_ptr, я правильно вас понял? BFE>>Нет. Зачем здесь std::weak_ptr? S>Вы точно понимаете о чем идет разговор?
Если вы хотите отслеживать жизнь объекта, то вы всегда можете завернуть указатель/ссылку на этот объект в такой смарт указатель, который можно проверять на валидность перед использованием. Накладные расходы будут сравнимы с накладными расходами встроенными в другие языки. Разве речь не об этом?
Здравствуйте, B0FEE664, Вы писали:
S>>>>>>Невладеющие указатели/ссылки вы предлагаете пустить в топку? BFE>>>>>Кто-то отменил std::weak_ptr ? S>>>>Вы вообще в курсе чем отличаются владеющие указатели от невладеющих? BFE>>>Да. S>>Тогда зачем вы упоминаете weak_ptr? BFE>weak_ptr — пример невладеющего указателя.
А говорите, что различаете...
S>>>>здесь нужно возвращать std::weak_ptr, я правильно вас понял? BFE>>>Нет. Зачем здесь std::weak_ptr? S>>Вы точно понимаете о чем идет разговор? BFE>Если вы хотите отслеживать жизнь объекта, то вы всегда можете завернуть указатель/ссылку на этот объект в такой смарт указатель, который можно проверять на валидность перед использованием. Накладные расходы будут сравнимы с накладными расходами встроенными в другие языки. Разве речь не об этом?
Я вам пример привел и спросил нужен ли там weak_ptr. Вы сказали, что не нужен. Так как мне контролировать время жизни этой ссылки?
Здравствуйте, so5team, Вы писали:
S>А говорите, что различаете...
Различаю.
S>Я вам пример привел и спросил нужен ли там weak_ptr. Вы сказали, что не нужен. Так как мне контролировать время жизни этой ссылки?
Похоже, что под контролем вы понимаете что-то своё. Что конкретно вы хотите получить?
Здравствуйте, B0FEE664, Вы писали:
S>>А говорите, что различаете... BFE>Различаю.
Пока что этого не видно.
S>>Я вам пример привел и спросил нужен ли там weak_ptr. Вы сказали, что не нужен. Так как мне контролировать время жизни этой ссылки? BFE>Похоже, что под контролем вы понимаете что-то своё. Что конкретно вы хотите получить?
Я хочу понять как в C++ получить контроль за валидностью ссылок и указателей.
В случае с владеющими указателями (unique_ptr/shared_ptr/intrusive_ptr/...) ситуация понятна. Кстати, weak_ptr -- это часть механизма владеющих указателей.
Как быть с невладеющими указателями, коих в программах (в тех, с которыми я имею дело) гораздо больше?
Здравствуйте, B0FEE664, Вы писали:
BFE>·>внезапно ломается, иногда, т.к. getConfig() вдруг возвращает config_t по значению. BFE>Тут закономерно ничего не ломается: path будет скопирован до разрушения копии config_t;
А ну да. Впрочем это означает, что в случае use(const string&) ненужная копия будет.
А в случае const auto & path будет ломаться, как so5team написал.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, flаt, Вы писали:
F>Базовой и азбучной список стал на заре компьютеров, как только появилась возможность работать с указателями. Это для ассемблера и Си (ака высокоуровневый ассемблер) связанный список — базовая структура.
Rust пропихивают как системный язык, так что будьте бобры.
F> Ты в Питоне тоже списки используешь? Сомневаюсь (хоть язык и позволяет написать). А в Haskell?
Я не использую ни питон ни хаскель.
F>Неделю спрашивать на форуме проще, чем самому прочитать "Rust vs C++"?
Таки да. Проще спросить у тех, кто уже знает, ибо мне не для практики а для ознакомления. Было б надо для практики — не спрашивал бы вообще а давно уже разобрался сам.
CC>>В С++ таки можно операторы конвертации написать где надо чтоб одно в другое автоматом умело конвертироваться, а тут как сделать легальное исключение? F>Под капотом паник — исключения. И первые можно перехватывать. Но в целом, исключений в языке нет, ибо ФП.
Под исключением имелось в виду не exception а workaround, т.е. исключение из общих правил.
Здравствуйте, so5team, Вы писали:
S>А что должно быть? Исключительно unique_ptr/shared_ptr?
Не обязательно именно такая имплементация но да, только завёрнутое.
CC>>Не, там дело в std который позволяет делать поток из лямбды. Это конечно бывает удобно, но вызывающий должен понимать что он делает. S>Опечатки случаются даже у тех, кто понимает.
Там сама идея error prone.
S>Собственно, это и есть главный selling point для Rust
Для меня это скорее повод на него не смотреть совсем. Ибо выглядит как "овчинка выделки не стоит".
S>Тогда как на Rust не получится писать как угодно, но зато Rust будет проверять на наличие целого класса ошибок и будет их предотвращать, а полученный код будет работать так же быстро, как и C++ный.
Дык не будет же. Чудес в природе не бывает. Потому что придётся бороться с языком чтоб написать нужную бизнес логику, делая ошибки уже в логике, пытаясь её вывихнуть под заморочки языка. Ну или хреначить unsafe и тогда какая уж нафиг разница С++ или rust?
CC>>Свою реализацию таки можно заставить принимать только конкретные обёртки, которые будут заниматься вопросами владения. CC>>Не идеально но всё же получше. S>И как это будет выглядеть?
Лень сюда код писать, звиняй.
