Здравствуйте, vdimas, Вы писали:
V>Если я доверяю кусок кода непрофессионалу-бухгалтеру, то плохо, ес-но, т.к. он может банально всё уронить.
Не может, если хост языка ему не позволяет.
V>Сорри, за ликбез, но является обширной частью спецификации. В стандарте прямо упоминается внешнее и внутреннее связывание. Упоминается термин "единица компиляции".
V>Про платформенно зависимые pragma даже говорить неохота. Но справедливости ради pragma упоминается именно в исходном коде программы, а не аргументах командной строки линкера.
Это вы С с С++ путаете.
S>>Вы правильно помните. Итак, стал ли Лого GPPL после добавления возможности импорта библиотек на том же Лого? V>Т.е. если расширить спецификацию языка до вызова произвольных внешних ф-ий? На нем станет возможным писать код общего назначения, т.е. не только той направленности, под которую разработали язык.
Откуда взялись произвольные внешние функции?
V>Ну так хост не дается кем-то сверху, это именно ты хостишь JS, и ты можешь дать только то, что считаешь нужным. Я потому и использую для JS для своих инструментов в кач-ве DSL, что в нем изкаробки нет ничего, кроме голого синтаксиса, т.е. весь нужный функционал подается извне. Именно поэтому он БЕЗОПАСЕН для браузеров. Вернее, ровно наоборот — он был разработан таким, чтобы быть безопасным, поэтому такие ограничения. S>>В С роль хоста играет линкер.
V>Опять сорри за ликбез, но нет. CRT является частью языка и стандарта, позволяя писать практически что угодно без линкера.
Я боюсь, что у вас ничего не получится без линкера.
V>Насчет твоих inp/outp. Если интересовался, то в защищенном режиме x86 порты отображены на карту виртуальной памяти. Во многих embedded-архитектрах, например PIC — точно так же без всякого защищенного режима — порты ввода-вывода лежат по специальным адресам. Но это фигня, дело-то не в порта, так? А в выполнении произвольной инструкции процессора, правильно? С/С++ чуть ли не единственные языки, где можно записать данные в некоторую область памяти (в сегмент данных, например) и передать туда управление. Так работают всякие нейтивные вирусы, писанные на С.
И это не имеет никакого отношения к импорту библиотек.
V>В каком месте мы в этом убедились? На примере С/С++ никак не убедились, т.к. совокупность всех возможностей языка позволяет ему ставить раком произвольную аппаратную платформу.
Мне нравится ваша способность начисто игнорировать весь ход обсуждения. Что мы имеем? Пример С показывает, что для постановки раком платформы библиотеки ему не нужны, да и нет в языке ничего специального про библиотеки. Пример "улучшенного Лого" показывает, что добавление библиотек никак не помогает поставить раком платформу. Но вас это не смущает.
V>Да и взять сами термины: на мой взгляд specific area отличается от general area границами и более ничем. Поэтому для меня императивный DSL — это в первую очередь ограничение области приложения, а затем уже хелперы и прочие плюшки. Например, с точностью до тонкостей синтаксиса можно этот HTML-DOM обрабатывать из какого-нить C# или С++ при подключенной соответствующей библиотеке.
Совершенно верно. Поэтому изо всех языков, работающих с DOM, DSL-ями являются только CSS и XSLT. JS, как и С и C++, это типичный GPPL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, koodeer, Вы писали:
K>Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.
Видимо, ты давно последний раз видел C++.
Если размерность значения определена в его типе, то достаточно легко получить и контроль во время компиляции (причём оно может, например, разрешить присвоить скорости произведение ускорения на время и в то же время запретить присвоение ей массы), и в то же время единственным данным внутри класса будет значение величины — например, типа double — и после оптимизации всё это выродится в простейшие операции со скаляром с плавающей точкой.
Попробуй сам (только на современных компиляторах, а не образца 95-го года) и удивись.
K>А в DSL и масса и температура по-прежнему останутся после компиляции простым типом. Никакого оверхеда в рантайме!
Для статически типизированного — да. Для динамически — нет.
Зависит именно от типизации.
Но можешь ли ты в DSL простым образом объявить новую размерность величины?
Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?
Здравствуйте, netch80, Вы писали:
N>Для статически типизированного — да. Для динамически — нет. N>Зависит именно от типизации. N>Но можешь ли ты в DSL простым образом объявить новую размерность величины? N>Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?
Детский сад. Если уж С++ с этим справляется то ДСЛ с системой типов заточенной на это справится вообще не напрягаясь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, netch80, Вы писали:
N>>Для статически типизированного — да. Для динамически — нет. N>>Зависит именно от типизации. N>>Но можешь ли ты в DSL простым образом объявить новую размерность величины? N>>Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь? WH>Детский сад. Если уж С++ с этим справляется то ДСЛ с системой типов заточенной на это справится вообще не напрягаясь.
Я не тебя спрашивал. Меня интересует именно подход koodeer'а с *его* организацией DSL'ей.
Здравствуйте, AndrewVK, Вы писали:
_>>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке. AVK>Генерировать то может и проще, а вот десериализовать его потом ...
В том редакторе, что мы сейчас используем, данные хранятся в неком внутреннем файле проекта, со всеми настройками и т.п. А код генерируется (кстати на разных языках) по нажатию кнопки. Так что десереализация не нужна при таком подходе.
AVK>Есть и такое. Например, WPF/XAML. Отработка на самого себя и другие контролы, а так же несложная анимация задаются декларативно прямо внутри XAML.
Ага, какие то элементы есть. Так же как и скажем в delphi и т.п. Но это всё только обрезки решения, захватывающие небольшую часть логики. Полноценного же решения, которор позволило бы полностью отделить интерфейс от "движка", на рынке не видно. А хотелось бы. И кстати кроме удобстваразработки такой подход мог бы принести как бонус реальную кроссплатформенность. на уровне своего интерфейса под каждую платформу (особенно актуально для софта работающего и на десктопе и на мобильных устройства).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб. PD>>Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.
AVK>Может я чего не понял в твоей задаче, но лобовое решение без всяких SSE и CUDA, типа такого: AVK>
AVK>for (var y = 0; y < _height; y++)
AVK>{
AVK> var line = data[y];
AVK> for (var x = 0; x < _width; x++)
AVK> line[x] = line[x] < 128 ? (byte) 0 : (byte) 1;
AVK>}
AVK>
Здравствуйте, WolfHound, Вы писали:
AVK>>А вроде бы не тебе отвечал. И нигде не утверждал, что задачу анализировать не нужно. WH>Ох. Ты сам-то веришь, что задачу по этому куску можно проанализировать?
Я не прошу анализа задачи или создания архитектуры. Я прошу показать, как гипотетически можно было бы упростить такой кусок. Любые фантазии допустимы.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, alex_public, Вы писали:
_>>>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке. AVK>>Генерировать то может и проще, а вот десериализовать его потом ...
_>В том редакторе, что мы сейчас используем, данные хранятся в неком внутреннем файле проекта, со всеми настройками и т.п.
Тогда это и есть тот самый отдельный язык.
_>Ага, какие то элементы есть. Так же как и скажем в delphi и т.п.
В Дельфи даже близко не. В Дельфи самый примитивизм допустим, просто подписка. А в WPF можно довольно объемную логику в XAML упихать.
_> Но это всё только обрезки решения, захватывающие небольшую часть логики.
Ты сперва попробуй.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Я не прошу анализа задачи или создания архитектуры. Я прошу показать, как гипотетически можно было бы упростить такой кусок. Любые фантазии допустимы.
Для того чтобы его упростить нужно понять что там происходит.
А по этому куску понять это нельзя.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
WH>>А по этому куску понять это нельзя. AVK>Ну, я понял.
А сколько еще кода в этом проекте ты прочитал/написал/спроектировал?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>В этом? 0. Я вообще прикладным кодом не занимаюсь.
Те ты написал и спроектировал весь системный код?
Я правильно понял?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Думаю, надо писать на ассемблере. Потому как "модели" тут у предметной области нет никакой. Выполнять побайтное сравнение с константой — это ровно одна операция. Задача не в том, как эту операцию представить в более читаемом виде, а как поаккуратнее запихать данные в SSE.
SSE тут, конечно, присутствует, (а еще присутствует распараллеливание) но вот насчет модели предметной области — не мешало бы определить, что она (в этом контексте) такое и почему ее в этой задаче нет.
Алгоритм там намного сложнее сравнения с константой. Тот, что ты имеешь в виду (полагаю, это то же, что озвучил AndrewVK) — никуда не годится. Черный будет пиксел или белый в target — определяется не только им, но еще и квадратным окном вокруг него. Так что размерность задачи (если не продумывать эту самую модель предметной области) — N*M*K^2, где K — размер окна.
Здравствуйте, AndrewVK, Вы писали:
_>> Но это всё только обрезки решения, захватывающие небольшую часть логики. AVK>Ты сперва попробуй.
Ну и как мне сделать на xaml что бы по нажатию пунка меню About открывалось окно About (тоже заданное на xaml рядом)? Или что бы какой-то пункт контекстного меню был активен только если в дереве (допустим это у нас основной контрол в окне) выделен элемент?
Здравствуйте, Vain, Вы писали: V>Как я сказал уже это от базы данных зависит. Как вы к примеру собираетесь через SQL управлять реестром винды? Или файловой системой? А это ведь тоже база данных.
Хорошо, раз вам неочевидно, я разжую ещё подробнее: через SQL проще управлять реляционными базами данных. S>>Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях. V>Попу с пальцем сранивать бесполезно.
Ну, если вы хотите на таком уровне сравнивать, то я не понимаю смысла вообще дальше общение продолжать.
А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
AVK>>В этом? 0. Я вообще прикладным кодом не занимаюсь. WH>Те ты написал и спроектировал весь системный код? WH>Я правильно понял?
В приведенном куске нет практически никакого системного кода, он весь аккуратно спрятан. А вызовы типа DeleteObjects очевидны и недвусмысленны.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, alex_public, Вы писали:
_>Ну и как мне сделать на xaml что бы по нажатию пунка меню About открывалось окно About
Подписаться на метод вызова About
_> (тоже заданное на xaml рядом)?
Что значит рядом? Это уже другое окно, и смысла в xaml увязывать межоконную логику немного. Ыпрочем, при желании можно примитивный компонентик написать, который это делает.
_> Или что бы какой-то пункт контекстного меню был активен только если в дереве (допустим это у нас основной контрол в окне) выделен элемент?
Это без проблем.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
