В Commodore 64 из коробки обычный построчный Бейсик. Наверное, был сторонний софт с "обычным" редактированием текста - всё-таки у него даже дисковод был - но он же появился после того, как железку задизайнили.
На большинстве 8битных компьютеров основной (забитой в ПЗУ) средой программирования был Бейсик с построчным вводом, такой роскоши как перемещение по коду стрелками просто не было - соответственно, и клавиши кусора воспринимались как что-то впомогательное, так что особо не заморачивались, делали как получится. Это уже потом выжило наиболее эргономичное решение.
И на клонах спектрума у друзей были самопальные джойстики (обычно совместимые с Кемпстон), без него особо не поиграешь.
LaTeX - это скорее язык программирования, который притворяется форматом с логической структурой. Если используется только базовый набор с разбивкой на главы/разделы и т.п., проблем с обработкой нет, но в общем случае с кастомным стилевиком и кучкой вспомогательных пакетов для красивых таблиц, диаграмм и прочего автоматически понять смысл отдельных конструкций нетривиально. Но, конечно, это лучше, чем сам по себе PDF или скан распечатки )
Посмотрел, интересная зверушка - типа урезанный (и не особо совместимый) MSX, с возможностью расширить картриджами (в которых не только ROM, но и RAM) до рабочего состояния.
Проблема из-за того, что в коде два сравнения da и db (на меньше и точное равенство), которые могут вести себя неконсистентно. С одним сравнением проблем не будет.
Правда, задача всё таки хитрее - насколько понял после второго прочтения, полностью совпадающие вершины надо всё-таки объединить, но оставить разные вершины с одинаковым deviation. Так что просто так использовать multiset тоже нельзя...
Если вычислены одними и теми же ассемблерными инструкциями с одинаковыми входными аргументами и тем же значением регистра состояния - будут равны. Но один и тот же сишный код вполне может скомпилироваться по разному в разных местах.
Это примерно как при работе с исполняемыми файлами постоянно декомпилировать их в C (ну или извлекать текст через strings). PDF - исключительно выходной формат для печати на бумаге или отображения на устройстве с достаточно большим размером и разрешающей способностью и для этого он вполне подходит. Для остальных действий по хорошему надо использовать то, из чего этот PDF получен - если оно недоступно, то это уже хакерство, а не документооборот.
Практически этого недостаточно, нужно убрать зависимость при компиляции - так что в реальных больших плюсовых проектах используется либо чисто абстрактный интерфейс, либо pimpl c разными вариациями.
и молиться, чтобы не забыть его при каких-либо изменениях в StringBuffer'е
Можно static_assert'ом проверить - надеюсь, про fastpImpl от Полухина все в курсе ) У него, правда, плюсы, но static_assert и в C11 есть, что то похожее можно сделать.
Я скорее с docbook сравниванию.
В том то и дело, что это скорее код, чем данные )
TeX понимает, как нарисовать результат интепретации исходника на бумаге, семантика ему не нужна.
В Commodore 64 из коробки обычный построчный Бейсик. Наверное, был сторонний софт с "обычным" редактированием текста - всё-таки у него даже дисковод был - но он же появился после того, как железку задизайнили.
На большинстве 8битных компьютеров основной (забитой в ПЗУ) средой программирования был Бейсик с построчным вводом, такой роскоши как перемещение по коду стрелками просто не было - соответственно, и клавиши кусора воспринимались как что-то впомогательное, так что особо не заморачивались, делали как получится. Это уже потом выжило наиболее эргономичное решение.
И на клонах спектрума у друзей были самопальные джойстики (обычно совместимые с Кемпстон), без него особо не поиграешь.
LaTeX - это скорее язык программирования, который притворяется форматом с логической структурой. Если используется только базовый набор с разбивкой на главы/разделы и т.п., проблем с обработкой нет, но в общем случае с кастомным стилевиком и кучкой вспомогательных пакетов для красивых таблиц, диаграмм и прочего автоматически понять смысл отдельных конструкций нетривиально. Но, конечно, это лучше, чем сам по себе PDF или скан распечатки )
Ну так и речь о том, что для осмысленной обработки надо использовать эти исходники в семантически структурированном формате.
Всё это скорее обработка напильником для более качественной печати.
Зачем это "для систем структурирования информации, для семантических сетей, для искусственного интеллекта "?
Тогда уж docbook с mathml. html - тоже скорее для показа, а не структурной обработки.
Посмотрел, интересная зверушка - типа урезанный (и не особо совместимый) MSX, с возможностью расширить картриджами (в которых не только ROM, но и RAM) до рабочего состояния.
Чисто практически - зачем сейчас компилировать счётную фортрановскую программу для x87?
Скажите спасибо, что не надо включать правкой рееестра.
Проблема из-за того, что в коде два сравнения da и db (на меньше и точное равенство), которые могут вести себя неконсистентно. С одним сравнением проблем не будет.
Правда, задача всё таки хитрее - насколько понял после второго прочтения, полностью совпадающие вершины надо всё-таки объединить, но оставить разные вершины с одинаковым deviation. Так что просто так использовать multiset тоже нельзя...
С clang'ом так же, а вот gcc всё ещё цепляется за x87.
Если вычислены одними и теми же ассемблерными инструкциями с одинаковыми входными аргументами и тем же значением регистра состояния - будут равны. Но один и тот же сишный код вполне может скомпилироваться по разному в разных местах.
Вроде как танцы с бубном в функции сравнения как раз для того, чтобы заставить set хранить несколько одинаковых значений.
И почему тогда не используется std::multiset?
Это примерно как при работе с исполняемыми файлами постоянно декомпилировать их в C (ну или извлекать текст через strings). PDF - исключительно выходной формат для печати на бумаге или отображения на устройстве с достаточно большим размером и разрешающей способностью и для этого он вполне подходит. Для остальных действий по хорошему надо использовать то, из чего этот PDF получен - если оно недоступно, то это уже хакерство, а не документооборот.
Практически этого недостаточно, нужно убрать зависимость при компиляции - так что в реальных больших плюсовых проектах используется либо чисто абстрактный интерфейс, либо pimpl c разными вариациями.
Покажите, как проще делается скрытие реализации с возможностью аллокации на стеке. private в C++ эту задачу не решает.
Можно static_assert'ом проверить - надеюсь, про fastpImpl от Полухина все в курсе ) У него, правда, плюсы, но static_assert и в C11 есть, что то похожее можно сделать.