Здравствуйте, Marty, Вы писали:
M>Здравствуйте, T4r4sB, Вы писали:
F>>>Открой для себя ассист.
TB>>А теперь попробуй с помощью отсосиста найти ошибку компиляции в гугл-тесте, образанном многоэтажными рекурсивными макросами.
M>А зачем использовать такие макросы?
Потому что в плюсах нет рефлексии.
А потому что любое решение не угодит всем.
Макросы — плохо, шаблоны — плохо, внешняя кодогенерация — плохо.
Как хорошо зато никто не знает.
Здравствуйте, B0FEE664, Вы писали:
N>>Как он будет выглядеть? Вы хотите полный GUI? Графические примитивы на фреймбуфере? Что-то иное? N>>Как будете реализовывать общение с человеком? N>>Проблема практически именно в том, что никто не может предложить этот новый стандарт, чтобы он был хоть как-то универсальным. "15 competing standards", ага...
BFE>Я могу описать свои хотелки и — да, я хочу полный GUI и несколько окон для ввода-вывода для одного приложения. BFE>Есть международные институты стандартизации, сотрудникам которых неплохо платят. Было бы не плохо, если бы они всем этим занялись...
Ну то есть никакой прикидки нет, даже приблизительно, но есть пожелания. Всё-таки обычно вначале хоть какие-то кривые образцы рисуют, достаточные для старта.
Мне вот ничего в голову, кроме действительно простой тайловой нарезки с текстом в каждой, в голову не приходит. Потому что картинку рисовать в разы сложнее.
Или не тайлами, а лентой, как в Jupyter. Но зачем их разделять?
N>>Зато текст, даже в ASCII, тут туп и надёжен. BFE>Вот — нет. Как только текст на языке отличном от английского, так читать очень сложно.
Для технических работ достаточно латиницы в ASCII. Дальше — юникод в пределах — без лигатур и приклеивания модификаторов, с одним направлением слева направо. И уже на это можно получать следующий круг фидбэка.
N>>Но чтобы все такими были — нет. В embedded куча зверей с прошитыми фонтами. За их пределами и не в x86, да, не видел (в x86, может оказаться, текстовые режимы делает процессор видяхи). Но всё равно вопрос в лёгкости управления. BFE>В embedded обычно можно подключится вторым терминалом с нормальным экраном и там всё сделать удобно и красиво, а встроенные терминалы можно делать как обычно.
Учитывая их специфику, 99.999% твою идею "второго терминала" похерят нафиг.
Зачем, если для задачи "показать стадию загрузки" достаточно семисегментника, а для чего-то посерьёзнее — поля 6x9 с кодировкой вроде ASCII с добавленной псевдографикой?
А если GUI, то это уже сразу категория повыше.
BFE>>> Реализация в 1-10 килобайт — кому она нужна? Я вообще не помню, чтобы последние десять лет я держал в руках что-то современное, что в себе содержало менее 32 мегабайт памяти. Не понимаю я причём тут размер. N>>Ну вы не держали, верю. Я держал, хоть и недолго. Полмега на всё и крутись как хочешь. И просто зачем тут что-то лишнее? Сколько уйдёт на полноценный гуй или что там вы предлагаете? BFE>Так ведь гуй не обязательно запускать внутри
А если снаружи, то это отдельный зверь, который со внутренним общается по самопальному двоичному протоколу
BFE>Выживание не всегда связано с пользой. Возьмём, к примеру ICQ — это не первый и не последний chat, в своё время очень популярный, номер 1, но можно считать, что не выжил. А почему? Моё мнение — исключительно потому, что менеджеры не придумали как на нём делать деньги и как развивать. Тоже самое могло произойти и с IBM 3270, хотя про их терминал ничего сказать не могу.
Деньги? Загляни в билетную кассу на вокзале, наверняка увидишь АЦ терминалы. Это оно и есть. Весь exUSSR продолжает работать на них.
Очень вероятно, что будет не отдельный железный зверь, а писюк с tn3270, в последнее время это будет Linux, и транспорт поверх IP. Но в душе им же и осталось.
Протокол терминала проще всего описать так: пока не нажмёшь Enter, он молчит (каждая клавиша не передаётся), а по нажатию передаётся пакет из всех полей ввода (или только изменённых). Где поля ввода — устанавливается командами вывода. Ну и всё, что компьютер хочет вывести, выводит командами с явным позиционированием.
Есть даже слухи, что IBM начала вкладываться в Linux в 2000 именно для того, чтобы иметь надёжный 3270 на любом железе, которое захочет применить (x86, M68k, MIPS, Itanium — пофиг).
Но именно такой пакетный режим туда-обратно и несовместимость с ленточным режимом а-ля пишущая машинка привели к тому, что уже в S/360 был слой эмуляции консольного режима поверх АЦ дисплеев (предшественников линии 3270).
BFE>Очевидные трудности: BFE>- вывод в одно окно всего и вся, предполагаемое решение — несколько окон/закладок (для одного приложения);
TUI через curses, slang, аналоги это лечит влёгкую.
Разбирательства со всеми ANSI-последовательностями и тому подобным оно берёт на себя.
BFE>- ввод и вывод из одного окна, предполагаемое решение — выделенная область ввода;
То же самое.
BFE>- поддержка естественных языков, предполагаемое решение — UTF-8;
Давно сделано.
BFE>- не удобная работа с историей, предполагаемое решение — отдельное окно вызываемое по Ctrl-R с возможностью навигации, поиска, фильтрования, редактирования и историей редактирования;
Требует доработки, да — но относительно простой.
BFE>- не удобное скролирование больших объёмов выведенного текста, предполагаемое решение — свёртка результатов для каждого отдельного запуска/вывода, "умный" (двойной) скролбар, автоматическое сворачивание однотипных блоков...
Тоже делается в TUI.
BFE>Каждое окно должно быть с поиском, с фильтром, изменяемых размеров и возможностями кастомизации.
Делается. Только отдельные контролы в тексте будут выглядеть не очень. Но подъёмно.
N>>Сейчас вопрос именно в этом. BFE>Разве? Мне так кажется, что сейчас "никому ничего не нужно", так как все привыкли и могут обойтись тем, что есть.
Потому что есть методы постепенного развития. Нужна база того, что ты описал? Curses, slang и вперёд (API slang совместимо на 90% с curses, так что, считаем, это то же самое). А вот когда нужно что-то посерьёзнее, обычно и объёмы ресурсов такие, что можно переходить к полному GUI.
N>>Я согласен и на корявые зюки в Paint, лишь бы идею понять. BFE>А чего тут понимать? Начать надо с того, что взять окно для редактирования текста (любое, как вот это, в котором я сейчас ввожу текст) и пришить к нему снизу вывод текста из терминала — одно это решит половину проблем.
"Два прыжка — и я в окопе", как говорила наша учительница руслит.
BFE>>>Так об этом я и пишу, что форматирование данных и их вывод — это разные операции. N>>Да, разные. Но на каком-то уровне они сходятся, как протокол передачи в диск. BFE>Не надо так низко опускаться — удобнее работать на высоком уровне.
Ну вот и не опускаемся. Всё сделано за нас.
BFE>Не-не-не. Это не правильный путь вникуда. Ввод-вывод должен остаться потоковым, а вот работа с потоками должна быть улучшена на уровне стандарта.
Curses — стандарт X/Open.
BFE>>>Это принципиальный вопрос качества: если входные данные портят поведение программы, то это баг программы, а не данных. N>>А если она просто говорит "тут фигня пришла"? BFE>Диагностировать ошибку, а не втихую следовать за ошибочными данными.
Речь про то, что кто-то может последнюю строку просто проигнорировать?
N>>Заметим, вопрос остался без ответа. BFE>JACM не читаю.
Зря. Там (вместе с CACM) неплохое отражение будущих направлений.
BFE>>> Собственно, появление таких языков, как Java, C# и вот, Rust — это попытка ограничить языковыми средствами непонимание простыми программистами принципов безопасной разработки многопоточных программ. N>>Или то, что эти принципы невозможно точно полностью соблюсти на огромных проектах, и лучше, когда рантайм позаботится. Ибо to err is human. BFE>Тут не согласен: чем больше проект, тем лучше соблюдаются принципы разработки, так как в противном случае проект перестаёт существовать.
Это уже сверху. А вот снизу количество ошибок, если не управляемо, не уменьшается.
N>>И вот этот вариант я считаю основным как причиной появления всех названных. BFE>Ошибки людей могут быть компенсированы организацией кода и Rust, видимо, тому пример.
Да, в заметной мере.
BFE>>>А вот стандартной очереди для безопасной передачи данных из одной нитки в другую как не было, так и не будет. N>>А как бы выглядела такая стандартная очередь? BFE>Как потокобезопасная очередь (ограниченного размера), с методом push на стороне отправителя и методами pop и pop_all на стороне принимающего. BFE>+ BFE>отдельный объект синхронизации
Тогда надо выяснить, почему стандарт C++ это не даёт. А Go, например, или Erlang — дают.
Возможно, решили, что слишком просто и разнообразно в деталях, чтобы это стандартизовать.
BFE>>>Не знаю я, что с Event'ом не то. Уже который год в каждом новом проекте (и не только новом) я пишу обёртку вокруг CV, чтобы превратить его в Event, чтобы было можно хоть как-то унифицировано работать с объектами синхронизации. N>>Под Unix? BFE>В основном — да, Debian, но код мультиплатформенный, работает везде.
N>>Каким образом завлекаете его, например, в poll (epoll, etc.)? BFE>Обычно никаким, так как не выхожу за пределы стандарта. В случае сопряжения с другими библиотеками запускаю отдельную нитку для сопряжения синхронизации одного объекта с другим.
Ну так неинтересно, ничего нового. Тогда и Event стиля Windows не нужен, кроме привычки.
Здравствуйте, CreatorCray, Вы писали:
N>>И это работает только потому, что количество элементов вектора гарантированно влезает в знаковый ssize_t. CC>Это твой код будет работать только с размерами контейнера влазящими в ssize_t.
Покажи мне такие, что не влазят, на какой-нибудь реальной платформе.
Может, ты найдёшь какой-то супермелкий и кривой embedded, я поверю. Но в большинстве жёсткое ограничение сверху SSIZE_MAX, вызванное банальной арифметикой и проблемами размера ptrdiff_t.
N>>Переполнение в "i--" на последней операции, которое проходит только потому, что формализована семантика неотрицательных вычетов по модулю. CC>Внезапно (tm) так и работают беззнаковые. Это кольцо.
Только в условиях C/C++.
N>> По сути — грязный хак, хоть и по стандарту. CC>Ты определись, таки хак или таки по стандарту?
По стандарту — пока мы не выходим за пределы C/C++ текущих версий.
Хак — когда выходим. Данная тема им не ограничена.
N>>Там вообще-то была ссылка, которую тебе лучше бы прочитать. CC>Ну прочитал я её, и что? Меня давно перестало интересовать мнение теоретиков, практика сильно вносит коррективы в "стройную теорию", так что я уж лучше и дальше практическим опытом буду руководствоваться.
И какой же практический опыт тебе сказал про возможность контейнера толще SSIZE_MAX?
Здравствуйте, _NN_, Вы писали:
TB>>>А теперь попробуй с помощью отсосиста найти ошибку компиляции в гугл-тесте, образанном многоэтажными рекурсивными макросами.
M>>А зачем использовать такие макросы?
_NN>Потому что в плюсах нет рефлексии.
_NN>А потому что любое решение не угодит всем. _NN>Макросы — плохо, шаблоны — плохо, внешняя кодогенерация — плохо.
Макры такие, как в C/C++ — плохо.
Такие, как, например, в Common LISP — хорошо. Как в Rust — приближается к этому (может, и догонит).
Шаблоны — плохо, пока через хаки через enable_if пытаются решить проблемы отсутствия нормальных макр, и хорошо, когда это не нужно и можно сделать честно и напрямую.
Внешняя кодогенерация — плохо, когда средства узколокальные или извращённые, как m4 (функциональный язык, по сравнению с которым плюсовые шаблоны в тьюринг-полном применении немного понятнее). Хорошо, когда средство стандартное, понятное, лёгкое в написании и сопровождении.
_NN>Как хорошо зато никто не знает.
Знает. Но кто-то знает по-своему, а кому-то просто не хватает сил сделать функционально, качественно и удобно.
Здравствуйте, netch80, Вы писали:
N>Макры такие, как в C/C++ — плохо. N>Такие, как, например, в Common LISP — хорошо. Как в Rust — приближается к этому (может, и догонит).
N>Шаблоны — плохо, пока через хаки через enable_if пытаются решить проблемы отсутствия нормальных макр, и хорошо, когда это не нужно и можно сделать честно и напрямую.
N>Так и живём.
Мы же вроде про C++.
За неимением лучшего выбираем то, что решает задачу.
Уверяю, что там, где можно обойтись макросами и шаблонами, пишут без них.
Здравствуйте, netch80, Вы писали: BFE>>В embedded обычно можно подключится вторым терминалом с нормальным экраном и там всё сделать удобно и красиво, а встроенные терминалы можно делать как обычно. N>Учитывая их специфику, 99.999% твою идею "второго терминала" похерят нафиг.
Чью специфику? embedded — он очень разный. N>Зачем, если для задачи "показать стадию загрузки" достаточно семисегментника, а для чего-то посерьёзнее — поля 6x9 с кодировкой вроде ASCII с добавленной псевдографикой?
Вы не понимаете, я пишу совсем не про это. BFE>>Так ведь гуй не обязательно запускать внутри N>А если снаружи, то это отдельный зверь, который со внутренним общается по самопальному двоичному протоколу
Вы, опять же не понимаете, о чём я пишу. BFE>>Очевидные трудности: BFE>>- вывод в одно окно всего и вся, предполагаемое решение — несколько окон/закладок (для одного приложения); N>TUI через curses, slang, аналоги это лечит влёгкую.
Что — это?
Вот у меня две нитки в программе — я хочу, чтобы ввод/вывод в/из каждую из них шёл два разных окна-терминала. Как мне это сделать стандартным (не зависимым от операционной системы способом)? BFE>>- ввод и вывод из одного окна, предполагаемое решение — выделенная область ввода; N>То же самое.
Одна программа может иметь два ввода в двух разных окнах? И для этого есть стандартные средства? BFE>>- поддержка естественных языков, предполагаемое решение — UTF-8; N>Давно сделано.
Нигде не видел. BFE>>- не удобное скролирование больших объёмов выведенного текста, предполагаемое решение — свёртка результатов для каждого отдельного запуска/вывода, "умный" (двойной) скролбар, автоматическое сворачивание однотипных блоков... N>Тоже делается в TUI.
Если вы про вот это:
то вы совершенно не понимаете, о чём я пишу. N>Потому что есть методы постепенного развития. Нужна база того, что ты описал? Curses, slang и вперёд (API slang совместимо на 90% с curses, так что, считаем, это то же самое). А вот когда нужно что-то посерьёзнее, обычно и объёмы ресурсов такие, что можно переходить к полному GUI.
Причём тут TUI? Причём тут Curses, slang и какие-то ещё API? Я разве где-то писал о выводе графики и эмуляции окон? Нет, я о совершенно другом — о стандартизации работы с потоками ввода вывода текста. N>>>Я согласен и на корявые зюки в Paint, лишь бы идею понять. BFE>>А чего тут понимать? Начать надо с того, что взять окно для редактирования текста (любое, как вот это, в котором я сейчас ввожу текст) и пришить к нему снизу вывод текста из терминала — одно это решит половину проблем. N>"Два прыжка — и я в окопе", как говорила наша учительница руслит.
Нет, это совершенно не то, что нужно. Это какие-то окна. Если я куда-то захожу терминалом, то что, по вашему та программа, которая имеет стандартный ввод/вывод занимается созданием окна? Нет, не занимается. Созданием окна занимается система, с которой я куда-то захожу терминалом. Сама программа ничего не делает ни с какими окнами — это вообще не её работа. Так и должно остаться. А вот что нужно, так это несколько стандартных каналов, если хотите, ввода-вывода. Сейчас, иногда, это решают (но только для вывода) через промежуточный файл или перенаправленным выводом ошибок, скажем, в файл. Этого мало и это не удобно. Нет разделения по исполняемым ниткам, например. BFE>>>>Так об этом я и пишу, что форматирование данных и их вывод — это разные операции. N>>>Да, разные. Но на каком-то уровне они сходятся, как протокол передачи в диск. BFE>>Не надо так низко опускаться — удобнее работать на высоком уровне. N>Ну вот и не опускаемся. Всё сделано за нас.
Опять какие-то окна. BFE>>Не-не-не. Это не правильный путь вникуда. Ввод-вывод должен остаться потоковым, а вот работа с потоками должна быть улучшена на уровне стандарта. N>Curses — стандарт X/Open.
Curses не нужны. BFE>>>>Это принципиальный вопрос качества: если входные данные портят поведение программы, то это баг программы, а не данных. N>>>А если она просто говорит "тут фигня пришла"? BFE>>Диагностировать ошибку, а не втихую следовать за ошибочными данными. N>Речь про то, что кто-то может последнюю строку просто проигнорировать?
Речь про то, что ошибочный вывод программы не должен портить внешний вид терминала. N>Тогда надо выяснить, почему стандарт C++ это не даёт. А Go, например, или Erlang — дают. N>Возможно, решили, что слишком просто и разнообразно в деталях, чтобы это стандартизовать.
Не, всё это потому, что те, кто пишет стандарт находятся под влиянием разработчиков компиляторов, а они, в свою очередь, не пишут прикладных программ и не знают, что нужно программистам. N>Ну так неинтересно, ничего нового.
Так я пишу про работу, а не про научные исследования. N>Тогда и Event стиля Windows не нужен, кроме привычки.
Не согласен. Event — это легко масштабируемый объект синхронизации: добавление нового эвента не оказывает особого влияния на работу всей остальной программы. Можно завести 10000 эвентов и всё будет работать как часы. Чего не скажешь про condition_variable — я не представляю себе программы, в которой было бы хотя бы с десятоком condition_variable работающих отдельно, без унифицированного подхода. Точно так же и с другими примитивами, с мьютексами. Если мьютексы начинают использовать не для защиты данных, а для защиты от параллельного исполнения части кода, то начиная с некоторого момента никто, кроме авторов, не может ничего понять.
Здравствуйте, B0FEE664, Вы писали:
BFE>Не согласен. Event — это легко масштабируемый объект синхронизации: добавление нового эвента не оказывает особого влияния на работу всей остальной программы. Можно завести 10000 эвентов и всё будет работать как часы.
У тех, кто придумывает такую фигню что-то работает? Да еще и как часы?
Здравствуйте, netch80, Вы писали:
N>И какой же практический опыт тебе сказал про возможность контейнера толще SSIZE_MAX?
Практический опыт говорит что не надо использовать знаковые типы для логически беззнаковых данных.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>И какой же практический опыт тебе сказал про возможность контейнера толще SSIZE_MAX? CC>Практический опыт говорит что не надо использовать знаковые типы для логически беззнаковых данных.
Если бы это был практический опыт с языком, где целые числа честно представляются диапазонами, я бы даже поверил.
Russinovich> Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust
Я понимаю, что "руссинович" известен своими sysinternals — СУГУБО СИСТЕМНЫМИ УТИЛИТАМИ, но давайте не слушать людей чисто за их узкоспецифичную работу! Вот когда он напишет все виды приложений на Расте, желательно прикладных, тогда и можно послушать этого "Лозу от ИТ". Тем более, что невозможно доказать, что он — не проплаченная ш..... амбассадорина этого Раста (который уже НЕСКОЛЬКО ЛЕТ суют программистам во все места, а они, "сволочи", всё равно не хотят на нём писать! ).
Russinovich> for those scenarios where a non-GC language is required
эээ... и много таких мест??!! (не говоря о том, что есть язык Ди, который появился задолго до ржы)
Russinovich> For the sake of security and reliability. the industry should declare those languages as deprecated.
Проблема не столько в языках, сколько в МИЛЛИОНАХ дилетантов, наводнивших ИТ! Каждый, кто прочёл две страницы по похапэхе, уже мнит себя хрен знает кем! Хуже того — таких ещё берут на работу! Так что защита и устойчивость пробиваются сугубо человеческим фактором.
vsb> Прислушайтесь!
Сам его слушай! Для меня уже просто лакмусовая бумажка этот хайп: как только чел ляпает про Rust, можно разворачиваться и вызывать санитаров.
ещё подкину дровишек https://www.youtube.com/watch?v=QzK2maO89uw
Человек понятное дело — растоман, мнение будет субьективно.
Мой вольный перевод:
Автор выдвигает 5 причин для компании, чтобы переходить на Rust:
Быстродействие + безопасность памяти. Опыть же приводит в довод исследование Microsoft, что 70% -это ошибки работы с памятью
Средства разработки. С++ не имеет единого компилятора и менеджера пакетов.
Сообщество. Очень спорное утверждение как по мне. Приводит классические доводы startup: мы быстрорастущие, молодые, талантливые.
Взаимодействие с С++. Тут уже обсуждали. В общем проблем использовать legacy на C++ быть не должно
И последнее довольно интересное. Кривая изучения Rust лучше чем у С++. Понятное дело хуже чем у JavaScript и Python, но лучше обычной истории С++ разработчика.
Здравствуйте, sergii.p, Вы писали: SP>И последнее довольно интересное. Кривая изучения Rust лучше чем у С++. Понятное дело хуже чем у JavaScript и Python, но лучше обычной истории С++ разработчика.
Есть нюансы. Кривая обучения раста может оборваться почти на самом начале на таких вещах, как владение, заимствование и время жизни. Без понимания этих вещей писать на расте будет очень сложно.
Я понимаю, что "руссинович" известен своими sysinternals — СУГУБО СИСТЕМНЫМИ УТИЛИТАМИ, но давайте не слушать людей чисто за их узкоспецифичную работу! Вот когда он напишет все виды приложений на Расте, желательно прикладных, тогда и можно послушать этого "Лозу от ИТ". Тем более, что невозможно доказать, что он — не проплаченная ш..... амбассадорина этого Раста (который уже НЕСКОЛЬКО ЛЕТ суют программистам во все места, а они, "сволочи", всё равно не хотят на нём писать! ).
Для меня уже просто лакмусовая бумажка этот хайп: как только чел ляпает про Rust, можно разворачиваться и вызывать санитаров. 
