OSDev

для всех
Текущее время: 15 ноя 2018, 22:59

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 285 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 29  След.
Автор Сообщение
СообщениеДобавлено: 10 дек 2014, 18:34 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 946
Откуда: Дагоба
эмбрион писал(а):
По сути вы заявляете о ненужности конкретно для вас предложенного для обсуждения языка. То есть прекрасно понимаете, что языка не будет и вы без него легко обойдётесь. Но перефразируя вас - наблюдается заведомо пораженческая тактика.

Нет, почему же? Это надо понимать скорей так: Zealint понимает, что он не будет самостоятельно заниматься разработкой языка (и тем более написанием компилятора), т.к. не обладает соответствующими навыками и необходимым временем, но из этого не следует, что никто другой не создаст новый язык. Я прав, Zealint?

эмбрион писал(а):
Только начинающие программисты ещё не понимают систему, с которой им приходится работать. Ну а когда поймут - опять попадают в замкнутый круг, где их удерживает привычка к хорошо изученному инструменту, отказаться от которого они могут только под давлением ну очень веских аргументов.

Ну почему же? Инструмент очень легко меняется под давлением проблем, которые он вызывает. Но люди не любят заменять одни проблемы другими, поэтому смена С++ на вашу любимую Джаву - не вариант :D.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 дек 2014, 20:15 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Zealint писал(а):
Это очень грустная для математика формула. Гораздо веселей она будет выглядеть как-нибудь так:

Изображение

Если речь идет про язык общего назначения, такие штуки в нем должны решаться DSL. В языке должна быть возможность подключения DSL как плагинов к компилятору.

Yoda писал(а):
Freeman писал(а):
Все эти зубодробильные конструкции со звездочками и плюсами стали возможны именно из-за полной и честной реализации императивной парадигмы.

[...] Прежде всего из-за убогости старых терминалов, в которых иногда даже фигурных или квадратных скобок не было, поэтому приходилось вешать кучу смысла на один символ и вводить такую дикость, как триграфы.

Ха-ха! Про старые терминалы я не подумал, хотя обычно не упускаю этот момент. Что же, надо было написать неправильный ответ, чтобы получить правильный. :lol:

Yoda писал(а):
Многие "функциональные приблуды" не имеют прямого отношения к идее ФП и могут быть реализованы в рамках императивного программирования (что и демонстрируют лямбды в С++).

Согласен, но лишь отчасти. Обилие языковых средств, позволяющих сделать почти одно и тоже, будет лишь вызывать путаницу и недоумение. Скажем, зачем нужны функции-процедуры, если есть функции-лямбды? Или, если говорить про ООП, зачем нужны структуры с методами, если есть классы? Добавление нового должно подразумевать исключение или пересмотр старого, -- именно это и называют прогрессом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 дек 2014, 21:31 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Yoda писал(а):
Проблем с написанием функций целиком на ассемблере я не вижу, главное - соблюдать соглашения о вызовах и писать соответствующие прототипы функций в заголовочных файлах.

Проблема, о которой я говорил, так это несовместимость объектных файлов, получаемых каким-то компилятором с тем, что даёт выдаёт ассемблер. Например, я потратил какое-то время на то, чтобы объединить VS и ассемблер. В результате, объединить студию удалось только с vsyasm. Не буду утверждать, что приложил все усилия, но сам факт наличия проблемы, разрешающейся неочевидным для рядового программиста образом, огорчает. Хотя мне лично тоже больше нравится отдельные функции целиком писать на ASM. В VS уже давно запретили Inline-assembler.

Yoda писал(а):
Int72 - не вижу проблем. Умножения отбрасывают лишние разряды, сложения/вычитания добавляют перенос после операции с 64 битами к 8 битным операндам.

Я имею в виду, как Вы заставите компилятор применить adc в нужном месте? Допустим, мы определяем класс class int72 { int32 l, h; int8 hh; }; Мы не хотим плодить кучу функций умножения и сложения с разным размером операндов и результатом int72, поэтому решили написать один оператор, который на входе и на выходе имеет дело с int72 (т. е. компилятор не получит подсказки в виде разных размерностей операндов и результата). Как может выглядеть реализация такого оператора на Вашем языке, чтобы компилятор сообразил, что нужен adc? Я вижу лишь один подходящий вариант: определить в языке оператор, скажем #, который для базовых типов (int32, int64) гарантированно превращается в adc, при этом не вносит между серией add / adc никаких других команд, сбрасывающих флаг переноса. Например (псевдокод):
Код:
int72 operator + ( int72 a, int72 b ) {
  Result . l = a . l + b . l;
  Result . h = a . h # b . h;
  Result . hh = a . hh # b . hh;
}


Компилятор, увидев это, гарантирует, что менять порядок не будет и разбавлять чем-нибудь тоже.
Как же тогда обозначить аналог SBB? : )

Yoda писал(а):
Я всегда выступал с резкой критикой функциональных языков.

Да и мне они кажутся слишком неестественными. Зато там есть идеи, которые заслуживают внимания. Те же лямбды, и вообще определение функции как объекта. Бывает удобным в C++.
Yoda писал(а):
Собс-но, я не к тому, что это пара пустяков, но не стоит преувеличивать сложность создания рабочего компилятора даже по самым продвинутым стандартам. Основная сложность заключается в разработке оптимизации. Это - да, может отнять много человеко-лет.

Ну, я это и имел в виду, оптимизирующий компилятор. Как-то неоптимизирующий и в голову мне не приходил.

Yoda писал(а):
Да, мне тоже сложно себе представить набор программ в таком виде. По крайней мере, про текстовые редакторы придётся забыть.

Да, я думаю, что придётся. Ведь раньше были перфокарты и не совсем просто было представить, что можно сделать текстовый редактор. Теперь текстовый редактор для целей программирования не очень-то многими используется, хотя я на протяжении многих лет писал все программы на всех языках в обычном редакторе Far, а кто-то для тех же целей использует vim. Я в нём вообще всё писал, даже письма, книги, диссертацию и т. д. Но, должен сказать, что был бы нормальный редактор кода для того же TeX, я бы им пользовался. Сейчас многие редакторы уже выглядят пристойно для набора программ в привычном смысле и вот, кто-то уже и не мыслит, что можно написать код в обычном MS-блокноте. А в ряде учреждений не знают ничего кроме MS-Word, и когда делаешь работу в TeX, принося им PDF, они не знают, что с ним делать. Тенденция такова, что обычный текстовый редактор постепенно заменяется необычным, а затем и вовсе уйдёт в прошлое, как перфокарты.

Может показаться, что всё плохо, ведь программу нельзя отредактировать другим редактором:
Yoda писал(а):
В вашем случае потребуется визуальный редактор и программу невозможно будет редактировать в любом другом стандартном текстовом редакторе.

Но давайте посмотрим на вещи иначе. Если нет компилятора, то нельзя скомпилировать программу. Так отчего же мы будем сокрушаться, что у нас нет визуального редактора, чтобы её написать? В моём представлении компилятор и среда программирования должны идти вместе, хотя никто не будет запрещать создавать другие визуальные редакторы, подобно тому, как для одного и того же языка существуют различные IDE. Не совсем понятно, почему следует держаться за редакторы обычного plain-текста так сильно. Только потому что большинству это кажется удобным в силу привычки? У большинства вообще редко привычки бывают разумными. Это сложно, но вполне возможно изменить любые привычки любого человека. Главное, чтобы идея оказалась на самом деле лучше, а для этого нужно очень хорошо её продумать. Есть вещи, которые нужно перестать тащить за собой как мусор. Обычные текстовые редакторы и текстовые графические режимы вполне могут оказаться таким мусором, как и древние кодировки. Это я весьма категорично высказался, я понимаю, но раз высказался, значит есть личные причины.
Yoda писал(а):
Сначала кажется, что использование UTF-8 облегчает эту задачу. Однако, если покопать, открывается куча подводных камней. ОС Windows заточена под использование кодировки Win-1251, поэтому переносимость сразу теряется. А разновидности виндовс - это подавляющий процент рынка, забить на него нельзя.

Не совсем ясно, почему теряется переносимость. Винвовс поддерживает utf-8. Кроме того, бывают случаи, когда общество вынуждает пересмотреть ошибки прошлого.

Yoda писал(а):
Далее, символы в юникоде разные, есть, например, пробел, разные тире. Как отличать, что относится к идентификаторам?

Это непростой вопрос, но я над ним думал уже. Решение вижу в подсветке синтаксиса. Графические редакторы позволяют самым разным способом раскрасить и выделить разные языковые конструкции (кому не нравятся разные цвета, то можно настроить оттенки серого).

Yoda писал(а):
Современные стандарты С/С++ разрешают использование символов UTF-8 в именах идентификаторов, однако при этом используется куча дополнительных регламентирующих таблиц.

По поводу идентификаторов можно придумать разные варианты. Например, запретить использовать в них какие-то нелатинские буквы. Меня однажды напрягла одна тупая ошибка, обнаружив которую я очень удивился, так как в те далекие времена почти никогда не ошибался при написании программ. Там в названии функции была русская буква «с» вместо латинской «c». Компилятор при этом выдавал что-то невнятное.
Yoda писал(а):
В общем, это тот самый случай, когда за 30-40 лет накопился ком проблем, который пока не очень понятно, с какого конца раскручивать. Лично я пока что для себя решил так: национальные символы запрещены. Собс-но, это не означает, что они запрещены навсегда. Разрешить их использование потом - не проблема. А вот менять что-то в уже использующихся кодах - может превратиться в очередную головную боль и до ужаса кривые стандарты. Лучше перетерпеть лет 10 и не гнаться за прогрессом вместе с толпой, эта толпа может завести не туда.

Вы имеете в виду, не гнаться за utf-8? Подождать другую кодировку? Или подождать, пока эта устоится?

Yoda писал(а):
Нет уж, инструмент должен быть достаточно удобен, чтобы им без проблем мог начать пользоваться новичок.

Сейчас дети в два-три года пользуются телефоном лучше, чем я, опытный пользователь ПК : ) Не думаю, что они будут испытывать какие-то сложности с графическим редактором, а скорее будут криво смотреть на текстовой как на пережиток прошлого, о котором они даже ничего толком не знают. Так я смотрю на перфокарты, например, на БЭСМ-6 тоже так смотрю. Даже на своих преподавателей, которые всего-то лет на 5-10 меня старше я вынужден смотреть как на людей, безнадёжно отставших от методологии разработки высокопроизводительных программ, я очень рад, что мне удалось без большой крови работать в своём стиле, а не в их. Хотя «подраться» пришлось.

Yoda писал(а):
Нет, почему же? Это надо понимать скорей так: Zealint понимает, что он не будет самостоятельно заниматься разработкой языка (и тем более написанием компилятора), т.к. не обладает соответствующими навыками и необходимым временем, но из этого не следует, что никто другой не создаст новый язык. Я прав, Zealint?

Скорее правы, чем нет. Я могу быть частью команды, которая разрабатывает язык. Думаю, что многим дам фору в вопросах тестирования продукта и реализации сложных алгоритмов для его библиотек. Могу также поделиться опытом размышлений такого плана, которым делюсь вот в этой теме. А сам компилятор вряд ли напишу правильно, никогда этого не делал и теорию знаю лишь на уровне общих университетских курсов. Книгу дракона даже не полностью ещё изучил, хотя пока ничего нового там для себя не обнаружил. Язык невозможно создать без правильной идеи, мне будет достаточно, если в этой объемлющей идее будут и мои мысли.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 дек 2014, 22:19 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
Clang - 6 лет писался до того как стал проходить все тесты на стандарт 11 года.
"Редкая профессия разработка компилятора" - год на запуск но тесты тоже смогли пройти только через 5-7 лет работы.
Если судить по истории GCC, то даже в нем новый фишки стандартов появляются через год-два.

Так что идеально правильный компилятор это вам не хухры мухры.
Но простой вариант даже с ООП написать не сложно можно в течение нескольких месяцев если под напрячься. Что касается оптимизации, то можно LLVM использовать. А можно и свой вариант сделать.

А можно взять готовое и начать переделывать.
По поводу книги дракона. Как по мне она устарела.
И есть огромное желание её переписать.
Почти не уделяется вопрос структурам, данных. Мало уделяется вопросам разбора выражений.
И другие вопросы тоже не сильно. А вот ненужной болтологии много.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 14:02 

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
Zealint писал(а):
Код:
f[n]=1.0/pow(2.0,n)/sqrt(5)*(pow(1+sqrt(5),n)-pow(1-sqrt(5),n))

Это очень грустная для математика формула. Гораздо веселей она будет выглядеть как-нибудь так:

Изображение

Подобное пожелание по дополнению возможностей языка можно реализовать достаточно быстро в приложении к любому существующему ЯВУ. Нужна готовая IDE, а к ней пишется плагин или дорабатывается сама среда разработки. Но в результате не получится новый язык, ведь способ визуализации формул вполне независим от любого языка. То есть опять предлагается разделять потребность на составляющие - выделить в предпочитаемом вами языке лишь часть, ответственную за визуализацию формул. Далее, возможно, захочется по другому визуализировать циклы, условия, структуры данных и т.д. Но это всё опять не меняет общего подхода, принятого в языке, как например в С по прежнему останутся указатели, функции и всё те же циклы, но с двумя вариантами визуализации - в текстовом виде для фанатов Блокнота и в графическом для продвинутых пользователей.

При этом важно понять, что же тогда остаётся от языка, если мы позволяем средствам визуализации изменять привычный текстовый вид. А останется от языка его логика, то есть не важно, каким значком обозначен оператор сложения, но важно, что независимо от значка мы в результате получим именно сумму.

Отсюда вывод - новый язык должен давать нам новую логику. А всяческие украшения в виде лямбд и графических визуализаторов ничего нового не дают. Хотя введение удобств можно назвать новизной. И даже после накопления некой критической массы введённые удобства могут дать новое качество разработки.

В целом пожелание по переходу на более удобные средства разработки с поддержкой визуализации некими графическими средствами я поддерживаю. Ну а кому не нравятся визуализаторы - для них всегда останется доступным средство под названием "Блокнот". Значит введение визуализаторов ни кому плохого не сделает, но вот пользу принесёт многим.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 15:55 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 946
Откуда: Дагоба
Zealint писал(а):
Проблема, о которой я говорил, так это несовместимость объектных файлов, получаемых каким-то компилятором с тем, что даёт выдаёт ассемблер. Например, я потратил какое-то время на то, чтобы объединить VS и ассемблер.

Да, действительно, такая проблема есть. Я вижу выход в поддержке ассемблера тем же компилятором, т.е. один и тот же компилятор работает как с ЯВУ, так и с ассемблером. Либо по максимуму поддерживать форматы объектных файлов.

Zealint писал(а):
Я имею в виду, как Вы заставите компилятор применить adc в нужном месте? Допустим, мы определяем класс class int72 { int64 l, h; int8 hh; };...

Заставить нельзя. Но можно помочь ему разобраться. Всякий раз, когда результат превышает размером исходные данные и используются старшие разряды, нужно брать перенос. Например, так:
Код:
int72 operator + ( int72 a, int72 b ) {
  int128 t = a.l + b.l;
  Result.l = t;
  Result.h = t>>64;
}

Использование дополнительных операторов типа # специально для переносов только запутает программиста и усложнит код.

Zealint писал(а):
Как же тогда обозначить аналог SBB? : )

Вычитание ничем не отличается от сложения, если рассматривать его в моём контексте. А вот у вас, да, придётся вводить новую операцию :).

Zealint писал(а):
Yoda писал(а):
В вашем случае потребуется визуальный редактор и программу невозможно будет редактировать в любом другом стандартном текстовом редакторе.

Но давайте посмотрим на вещи иначе. Если нет компилятора, то нельзя скомпилировать программу. Так отчего же мы будем сокрушаться, что у нас нет визуального редактора, чтобы её написать?

Есть стандарт на язык программирования, поэтому я могу использовать любой компилятор, который худо-бедно ему соответствует. Например, я часто пишу программы, которые одинаково компилируются и работают в VS, GCC, CLang, а если без плюсов, то и TCC. Поэтому вопрос стоит рассматривать не как "если нет компилятора, то нельзя скомпилировать программу", а как "один компилятор можно заменить другим". Точно так же, обычный текст можно редактировать любым plain-text редактором. А визуальную среду имеет смысл рассматривать только в том случае, если будет существовать некий стандарт, в рамках которого я смогу выбирать разные продукты. Стандарт на визуальное программирование мне представить сложно, хотя я и не отрицаю его возможность.

Zealint писал(а):
Не совсем понятно, почему следует держаться за редакторы обычного plain-текста так сильно. Только потому что большинству это кажется удобным в силу привычки?

Нет, дело не в привычке, а в высшей степени переносимости.

Zealint писал(а):
Обычные текстовые редакторы и текстовые графические режимы вполне могут оказаться таким мусором, как и древние кодировки.

Могут, но не сейчас, а только в отдалённом будущем.

Zealint писал(а):
Не совсем ясно, почему теряется переносимость. Винвовс поддерживает utf-8. Кроме того, бывают случаи, когда общество вынуждает пересмотреть ошибки прошлого.

Виндовс не поддерживает UTF-8. Оно поддерживает UTF-16, а это совсем не то же самое. Да, верно, ошибки прошлого, и виндовс со своей UCS, трансформировавшейся в UTF-16 и есть такая ошибка, но очень прочно застрявшая на рынке.

Zealint писал(а):
По поводу идентификаторов можно придумать разные варианты. Например, запретить использовать в них какие-то нелатинские буквы.

"Какие-то" - это и есть применение таблиц, ограничивающих использование разных символов. До жути кривое решение.

Zealint писал(а):
Меня однажды напрягла одна тупая ошибка, обнаружив которую я очень удивился, так как в те далекие времена почти никогда не ошибался при написании программ. Там в названии функции была русская буква «с» вместо латинской «c». Компилятор при этом выдавал что-то невнятное.

Вот именно, - это одна из типичных граблей при использовании национальных символов.

Zealint писал(а):
Вы имеете в виду, не гнаться за utf-8? Подождать другую кодировку? Или подождать, пока эта устоится?

Вряд ли возможна кодировка лучшая чем UTF-8. Я думаю, как минимум надо подождать, пока эта устаканится, но что-то мне подсказывает, что этого не произойдёт никогда. Поэтому, вероятно, потребуется какое-то другое волевое решение, но его нужно принимать только по принципу осторожного разрешения ранее запрещённых вещей и только после очень тщательного анализа.

Zealint писал(а):
Yoda писал(а):
Нет уж, инструмент должен быть достаточно удобен, чтобы им без проблем мог начать пользоваться новичок.

Сейчас дети в два-три года пользуются телефоном лучше, чем я, опытный пользователь ПК : ) Не думаю, что они будут испытывать какие-то сложности с графическим редактором, а скорее будут криво смотреть на текстовой как на пережиток прошлого, о котором они даже ничего толком не знают.

В данном случае я рассматриваю именно редактор VIM. Не проблема выучить что-то новое, но только при условии, что это "новое" имеет интуитивно понятный интерфейс. 20-30 лет тому назад ничего не было кроме редакторов EMACS и VIM и компилятора cc, поэтому можно было потратить месяц на освоение. Но сейчас продуктов - море, и новый продукт типа VIM просто не приживётся даже в среде детей возрастом два-три года :), потому что есть гораздо более дружелюбные редакторы.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 15:56 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 946
Откуда: Дагоба
pavia писал(а):
Clang - 6 лет писался до того как стал проходить все тесты на стандарт 11 года.
"Редкая профессия разработка компилятора" - год на запуск но тесты тоже смогли пройти только через 5-7 лет работы.
Если судить по истории GCC, то даже в нем новый фишки стандартов появляются через год-два.

Так что идеально правильный компилятор это вам не хухры мухры.

Здесь дело не в сложности адаптации компилятора под стандарты, а в целеполагании. Я, например, точно знаю, что на сегодняшний день ни студия, ни GCC, ни Clang не соответствует полностью стандартам, сам писал тесты и проверял их реакцию. Просто им это и не нужно.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 20:37 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1070
Откуда: Балаково
Zealint писал(а):
Проблема, о которой я говорил, так это несовместимость объектных файлов, получаемых каким-то компилятором с тем, что даёт выдаёт ассемблер. Например, я потратил какое-то время на то, чтобы объединить VS и ассемблер. В результате, объединить студию удалось только с vsyasm. Не буду утверждать, что приложил все усилия, но сам факт наличия проблемы, разрешающейся неочевидным для рядового программиста образом, огорчает. Хотя мне лично тоже больше нравится отдельные функции целиком писать на ASM. В VS уже давно запретили Inline-assembler.

Плохо искали :) Всё что вам нужно лежит в C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64
ml64.exe - Ассемблер
cl.exe - Компилятор С++
link.exe - Сборщик

Конечно GCC C++ с его ассемблерными вставками будет лучше, нет издержек на внешние вызовы.
Я поэкспериментировал ещё с той программой Cycles.12.cpp, так в Linux с GCC 4.9.2 она выполняется всего за 2 секунды (Cycles.14b.cpp за 3сек).
Использовал дистрибутив http://cdimage.ubuntu.com/daily-live/current
Ещё меня порадовало то, что вычисления в виртуалке VmWare 10 идут с такой же скоростью, как на реальной аппаратуре.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 21:30 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
эмбрион писал(а):
Подобное пожелание по дополнению возможностей языка можно реализовать достаточно быстро в приложении к любому существующему ЯВУ. Нужна готовая IDE, а к ней пишется плагин или дорабатывается сама среда разработки.

Вы правильно говорите, что визуальное отображение кода можно делать отдельным плагином и, в принципе, надстроить визуализацию над уже готовым языком. Но, во-первых, это не достаточно быстро делается, а, во-вторых, Вы снова предлагаете некое решение, тогда как решать пока нечего. Будет ли это надстройка над редактором кода или что-то другие сейчас сказать невозможно.

эмбрион писал(а):
Но в результате не получится новый язык, ведь способ визуализации формул вполне независим от любого языка. То есть опять предлагается разделять потребность на составляющие - выделить в предпочитаемом вами языке лишь часть, ответственную за визуализацию формул. Далее, возможно, захочется по другому визуализировать циклы, условия, структуры данных и т.д. Но это всё опять не меняет общего подхода, принятого в языке, как например в С по прежнему останутся указатели, функции и всё те же циклы, но с двумя вариантами визуализации - в текстовом виде для фанатов Блокнота и в графическом для продвинутых пользователей.

Вот здесь Вы взяли за основу свою идею и пытаетесь сразу придумать что получится в результате. А на самом деле совершенно не обязательно, что останутся указатели, функции и те же циклы. Нужно абстрагироваться от привычных вещей, а для этого нужно перестать искать решение не поставленной задачи без наличия хоть какой-нибудь концепции.

эмбрион писал(а):
Ну а кому не нравятся визуализаторы - для них всегда останется доступным средство под названием "Блокнот". Значит введение визуализаторов ни кому плохого не сделает, но вот пользу принесёт многим.

Я смотрю на такие вещи иначе. Блокнот - это тот же визуализатор ноликов и единичек.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 11 дек 2014, 21:55 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Yoda писал(а):
Заставить нельзя. Но можно помочь ему разобраться. Всякий раз, когда результат превышает размером исходные данные и используются старшие разряды, нужно брать перенос. Например, так:
Код:
int72 operator + ( int72 a, int72 b ) {
  int128 t = a.l + b.l;
  Result.l = t;
  Result.h = t>>64;
}


Честно говоря, не понял, как это должно работать. Потерялся 1 байт ещё. Как компилятор сообразит, что тут adc? – он сделает то, что тут написано, усложнив процедуру сложения.
Yoda писал(а):
А визуальную среду имеет смысл рассматривать только в том случае, если будет существовать некий стандарт, в рамках которого я смогу выбирать разные продукты. Стандарт на визуальное программирование мне представить сложно, хотя я и не отрицаю его возможность.

Ну тут я вижу два варианта: подождать, когда кто-нибудь разработает такой стандарт или сделать самому. Например, в каком-то смысле TeX оказался де-факто стандартом набора математических формул, по крайней мере, из мне известных престижных журналов из моей области никто в Word математику не набирает, как это делают почти все российские журналы. Если ждать, то кто-нибудь может протолкнуть глупость вместо стандарта, как это часто бывает, если делать самому, то делать самому : )
Yoda писал(а):
"Какие-то" - это и есть применение таблиц, ограничивающих использование разных символов. До жути кривое решение.

В Вашем решении предлагается избавиться от национальных символов. Это не то же самое? Можно ли выделить в UTF-8 символы, которые уже точно будут стоять на своих местах?
Yoda писал(а):
потому что есть гораздо более дружелюбные редакторы.

Значит нужно придумать достаточно дружелюбный редактор (и стандарт). Не может же быть, чтобы plain-text остался в программировании навсегда.

Как вариант, который был предложен тов. эмбрион’ом, можно совместить текст и визуальное оформление, оставив выбор за пользователем.

Исходные причины, по которым я задумался над визуальным редактором, состоят в том, что запись в одну строку сразу отнимает возможность использовать верхние и нижние индексы (что удобно), а ещё заставляет изворачиваться весьма ограниченным набором символов для записи различных операций. Согласитесь, не все операторы C++ выглядят так, как могли бы, будь у нас больше разных символов.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 285 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 29  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB