powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
184 сообщений из 184, показаны все 8 страниц
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574009
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Насколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).

Делал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?

Есть ли какая- то книжка, статья, блог, канал youtube... где о подобном скрещивании можно почитать подробненько?

Благодарю за обмен опытом!
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574016
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых
языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).

Ты уверен, что не наоборот?..

Если хочешь - вбей в гугль "1С" и хоть зачитайся. Там, правда, не питон, но тоже
скриптовый язык.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574039
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov, на 1с программировал примерно 13 лет... Но я не про многопользовательские СУБД, где скорость работы отдельного пользователя не важна (поэтому, кстати, в 1с нет и никогда не будет многопоточности). Да, в таких случаях и прикладную часть реализуют на скриптовом языке.

Если же скорость работы приложения важна, то основной расчет реализуют на языках низкого уровня. Например, в том же python библиотеки написаны на языке С, чтобы шевелилось побыстрее. На вскидку могу предположить, что подобный подход позволяет быстро создать прототип приложения, который потом можно будет оптимизировать с помощью низкоуровневого языка в нужных местах.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574042
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLНапример, в том же python библиотеки написаны на языке С, чтобы шевелилось побыстрее. На
вскидку могу предположить, что подобный подход позволяет быстро создать прототип
приложения, который потом можно будет оптимизировать с помощью низкоуровневого языка в
нужных местах.

Так работает любой скриптовый язык - от PHP до LUA. И да, библиотеки для питона пишутся на
С не от хорошей жизни и даже не чтобы шевелилось быстрее, а потому что иначе никак. Не
могут скриптовые языки ни с чем взаимодействовать без нативной прокладки.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574044
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLЕсли же скорость работы приложения важна, то основной расчет реализуют на языках низкого уровня. Например, в том же python библиотеки написаны на языке С, чтобы шевелилось побыстрее. На вскидку могу предположить, что подобный подход позволяет быстро создать прототип приложения, который потом можно будет оптимизировать с помощью низкоуровневого языка в нужных местах.
Проблема в том, что любое приложение должно иметь ядро, которое, в том числе, будет порождать процессы (нити) и управлять ими. И это ядро так же является высоконагруженной частью приложения, и, желательно, его сразу иметь на компилируемом языке.
Отсюда и возникает конструкция вроде 1С или Axapta. Есть скомпилированное ядро, если скриптовый язык, который может использовать как скомпилированные компоненты ядра, так и внешние компоненты, в том числе и скомпилированные.
Иными словами, интерпретатору отдается средний слой, тогда как верхний и нижний остается прерогативой компиляторов.
Такой подход как раз и позволяет легко оптимизировать что угодно, вынося это на нижний слой, без ущерба верхнему слою, который сразу компилируемый.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574070
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ptr128Проблема в том, что любое приложение должно иметь ядро, которое, в том числе, будет порождать процессы (нити) и управлять ими. И это ядро так же является высоконагруженной частью приложения, и, желательно, его сразу иметь на компилируемом языке.
Отсюда и возникает конструкция вроде 1С или Axapta. Есть скомпилированное ядро, если скриптовый язык, который может использовать как скомпилированные компоненты ядра, так и внешние компоненты, в том числе и скомпилированные.
Иными словами, интерпретатору отдается средний слой, тогда как верхний и нижний остается прерогативой компиляторов.
Такой подход как раз и позволяет легко оптимизировать что угодно, вынося это на нижний слой, без ущерба верхнему слою, который сразу компилируемый.

Одно непонятно: зачем вы верхний слой отдаете компилируемым языкам? Недостатки вижу (нельзя выполнять код, введенный пользователем), а преимущества- нет.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574091
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).
Вы опоздали лет на 15. В играх для описания квестов и сценариев давно используется Python или Lua.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574096
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLДелал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?
Фраза построена непонятно. Предпочтительнее .. чем?

И не зависимо от ответа оба варианта будут никуда негодны. Микс С++/C# можно рассматривать
как миграцию легаси. Или допиливание дот-нета до поддержки специфичного железа.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574107
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonAlekseySQLДелал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?
Фраза построена непонятно. Предпочтительнее .. чем?

И не зависимо от ответа оба варианта будут никуда негодны. Микс С++/C# можно рассматривать
как миграцию легаси. Или допиливание дот-нета до поддержки специфичного железа.

Я подразумевал такой смысл: если в проекте также используется язык сценариев, который берет на себя "редковыполняемую" часть проекта, то для "долговыполняемой" части нужно использовать более быстрый язык программирования. Поэтому связка python & C++ более разумна, чем связка python & С#.

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

p.s. Умею я холивары устраивать :)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574113
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLp.s. Умею я холивары устраивать :)
бред.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574126
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLptr128Проблема в том, что любое приложение должно иметь ядро, которое, в том числе, будет порождать процессы (нити) и управлять ими. И это ядро так же является высоконагруженной частью приложения, и, желательно, его сразу иметь на компилируемом языке.
Одно непонятно: зачем вы верхний слой отдаете компилируемым языкам? Недостатки вижу (нельзя выполнять код, введенный пользователем), а преимущества- нет.
Потому что ядро, порождающее процессы и управляющее ими должно быть максимально быстрым. Делать его на интерпретаторе сродни тому, что делать ядро операционной системы на интерпретаторе. Ведь именно ядро будет обеспечивать для среднего слоя весь многопользовательский и мультизадачный сервис.

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

Так что преимущество именно в том и заключается, что ядро не торомозит все приложение (так как быстрое) и обеспечивает изолированность и синхронизацию запущенных им процессов с интерпретатором (или даже разных интерпретаторами разных языков).

Собственно говоря, ядро будет выступать в качестве сервера приложений для толстого клиента или для веб-сервера. Но с расширенными возможностями, имея возможность самому порождать процессы по различным событиям или по расписанию.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574155
Фотография CEMb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТы уверен, что не наоборот?..+1
maytonВы опоздали лет на 15. В играх для описания квестов и сценариев давно используется Python или Lua.+1, выносить как-то всю игровую логику на флагах или чем-то ещё в ядерную игровую механику - это мозгоубийство. А вот скриптовые языки поверх движка с этим справляются легко.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574210
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Единственное, что интегрируется абсолютно со всем - это С.

Из С++ можно наружу отдать С-интерфейсы, а из Сшарп - нет.

Потому Сшарп здесь совсем не в тему. Интероперабельность только через ОЛЕ-прослойку, а она не везде "лезет".

Делать пользовательскую логику на скриптовых языках придумали очень давно.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574235
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ptr128Потому что ядро, порождающее процессы и управляющее ими должно быть максимально быстрым.

Почему вы считаете, что процессы должны порождаться и управляться в самом верху программного стека? Я думаю процессы должны создаваться и управляться по мере необходимости, т.е. в низовом коде. Иначе поломается инкапсуляция, и программа превратится в код- лапшу.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574245
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЕдинственное, что интегрируется абсолютно со всем - это С.

Из С++ можно наружу отдать С-интерфейсы, а из Сшарп - нет.

Потому Сшарп здесь совсем не в тему. Интероперабельность только через ОЛЕ-прослойку, а она не везде "лезет".

Делать пользовательскую логику на скриптовых языках придумали очень давно.
Отдать c-интерфейсы наружу можно и из c# - готовить нужно уметь
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574274
у связки ".NET/С# + скриптовый язык" есть такое преимущество перед связкой "С++ + скриптовый язык":
скриптовый язык может быть скомпилирован в тот же CIL и далее JIT-ирован рантаймом дотнета в машинный код, то есть в итого скорость его исполнения будет такой же, как и у C#.

есть куча готовых реализаций таких скриптовых языков - IronPython, IronRuby и т.д.

если захочется "поскриптовать" на самом C# (или F#, C++/CLI, VB.NET, JScript.NET) - нет проблем: компиляторы - часть фреймворка, и можно встроить редактор скриптов (можно в простом текстбоксе) в свою программу - будет работать без всякой студии (вопрос отладки, конечно, отдельный), при этом интеграция скриптов с кодом на C# будет полной и беспрокладочной в обе стороны

при большом желании можно соорудить транслятор со своего уникального языка в один из поддерживаемых дотнетом (+ конвертер позиции в коде (строка, колонка) из дотнетовского сообщения об ошибке компиляции для правильной подсветки ошибочного места уже в коде вашего языка)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574332
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLptr128Потому что ядро, порождающее процессы и управляющее ими должно быть максимально быстрым.

Почему вы считаете, что процессы должны порождаться и управляться в самом верху программного стека? Я думаю процессы должны создаваться и управляться по мере необходимости, т.е. в низовом коде. Иначе поломается инкапсуляция, и программа превратится в код- лапшу.
С чего Вы взяли, что верх программного стека - это ядро системы? Стек растет снизу вверх, по крайней мере на Intel архитектуре, начиная с 8008. А структуру приложения я рисую сверху вниз, по порядку вызова. Потому что привык читать сверху вниз и справа налево, а не наоборот )
То есть, верхним уровнем я называю ядро, вызываемое из ОС, а нижним - библиотеки.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574350
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128верхним уровнем я называю ядро
не удивляйтесь, что вас не понимают
ptr128Стек растет снизу вверх, по крайней мере на Intel архитектуре, начиная с 8008.
и здесь всё наоборот (push - декрементирует регистр указателя стека)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574393
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилptr128верхним уровнем я называю ядро
не удивляйтесь, что вас не понимают
Буду тогда избегать понятия верх и низ )

ptr128Стек растет снизу вверх, по крайней мере на Intel архитектуре, начиная с 8008.
и здесь всё наоборот (push - декрементирует регистр указателя стека)[/quot]
Декрементирует - это да. А вот снизу вверх или сверху вниз? )))
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574423
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128А вот снизу вверх или сверху вниз? )))
– А не пролечу ли я всю землю насквозь? Вот будет смешно! Вылезаю – а люди вниз головой! Как их там зовут?.. Антипатии, кажется… (с)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574526
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).

Делал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?

Есть ли какая- то книжка, статья, блог, канал youtube... где о подобном скрещивании можно почитать подробненько?

Благодарю за обмен опытом!
Не понял к чему тут слово "сейчас", если это давно. Впрочем, не важно. Вполне себе традиционная схема - если есть большой хост - процесс и куча dll, с функциями которые могут быть вызваны из хоста напрямую, из меню или еще как. И есть каталог скриптов, которые хост может запускать. Скрипты обращаются к функциям реализованным в этих dll и к объектам предоставляемым хостом. Собственно в самих dll лежат ресурсоемкие операции к примеру компрессия или перекодирование или что-то с длинными вычислениями над большими объектами. Те же ГИС к примеру. Как отработать функцию - реализовано в dll, а что и в каком порядке и к каким файлам или объектам в хост - процессе применять - это пользователи самим себе в скриптах рисуют. Программа апгрейдится без изменения этих пользовательских каталогов и показывает к примеру менюшку со списком функций из этих скриптов или просто сами их имена или еще как. Ну и получается что пользователи наращивают свою кастомную логику под свои задачи ну или им под заказ разово делают такие скрипты.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574529
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLDimitry Sibiryakov, на 1с программировал примерно 13 лет... Но я не про многопользовательские СУБД, где скорость работы отдельного пользователя не важна (поэтому, кстати, в 1с нет и никогда не будет многопоточности).
Из учебных курсов 1С про многопоточность и фоновые задания:
http://курсы-по-1с.рф/articles/как-ускорить-1с-многопоточность/
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574595
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ну яИз учебных курсов 1С про многопоточность и фоновые задания:
http://курсы-по-1с.рф/articles/как-ускорить-1с-многопоточность/

Так можно и через COM из управляющей 1с запустить несколько подчиненных сеансов 1с и разделить между ними задачу. Но будет ли это многопоточностью? Тут происходит тоже самое.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574602
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).
С++ не является языком низкого уровня. Это обычный себе прикладной язык.
Низкий уровень - это C и/или ассемблер.

AlekseySQLДелал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?
При чем тут C# предпочтительнее C++? И то и то компилируемые языки.

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

Современная игрушка просто на старт иногда требует несколько минут, не говоря уже на перелинковку, без быстрого изменения кода в runtime там вообще никак.

AlekseySQLЕсть ли какая- то книжка, статья, блог, канал youtube... где о подобном скрещивании можно почитать подробненько?

Благодарю за обмен опытом!
да нет никакого сакрального знания там.

единственно что стоит почитать - это про то, что писать на чистом LUA скрипты это несколько моветон.
статья была на хабре, лень читать

тру чуваки скрипты пишут на диалектах C/C++, чтоб после того, как все понаписали и отладили - можно было слинковаться нативно,
т.е. скрипты преобразовать непосредстваенно в машинный код.


есть и интерпретируемые субдиалекты С или C++, или и вовсе - техника нативной компиляции в runtime с динамической выгрузкой/подгрузкой .dll/.so
т.е. цель достичь секундной реакции на изменение в коде можно достичь не только интерпретатором, а и традиционными средствами.
преимущества - отладка в родной IDE, нет необходимости отправлять открытый (нетранслированный) код в релиз, и т.п.

хотя так обычно мало кто парится, да и геймдевдизайнеры предпочитают ламповый LUA или подобное этим вашим звездочкам и & закорюкам.


но опять же - это все нужно лишь там, где от F5 до запуска приложения проходит более 30 секунд. иначе - проще писать сразу в одном языке и не париться
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574644
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchС++ не является языком низкого уровня. Это обычный себе прикладной язык.

Несмотря на то, что потребление памяти у C++ больше, чем у C, а производительность несколько ниже, его вполне успешно используют в качестве языка низкого уровня. Например, на том же Arduino, вообще без операционной системы.
Так что не все так однозначно.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574705
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128А вот снизу вверх или сверху вниз? )))
Вниз - это туда, где уменьшаются адреса, а не вниз картинки с этими адресами
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574722
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128dbpatchС++ не является языком низкого уровня. Это обычный себе прикладной язык.

Несмотря на то, что потребление памяти у C++ больше, чем у C, а производительность несколько ниже, его вполне успешно используют в качестве языка низкого уровня. Например, на том же Arduino, вообще без операционной системы.
Так что не все так однозначно.
ну ты нам эту лапшу не вешай. в ардуине не современный C++, а эдакий сильно урезанный C with objects.

под С++ сейчас подразумевается эта ваша шаблонизированная STL/Boost копипаста, возведенная в абсолют, и общий крен в сторону всяких этих C# и прочих лямбда типо фичей, без которых низкоуровневое системное ПО (и не только) отлично себя чувствует.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574761
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилSiemarglЕдинственное, что интегрируется абсолютно со всем - это С.

Из С++ можно наружу отдать С-интерфейсы, а из Сшарп - нет.

Потому Сшарп здесь совсем не в тему. Интероперабельность только через ОЛЕ-прослойку, а она не везде "лезет".

Делать пользовательскую логику на скриптовых языках придумали очень давно.
Отдать c-интерфейсы наружу можно и из c# - готовить нужно уметь
ну так кидай ссылку, каким это местом делается не через ОЛЕ
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574763
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchptr128пропущено...

Несмотря на то, что потребление памяти у C++ больше, чем у C, а производительность несколько ниже, его вполне успешно используют в качестве языка низкого уровня. Например, на том же Arduino, вообще без операционной системы.
Так что не все так однозначно.
ну ты нам эту лапшу не вешай. в ардуине не современный C++, а эдакий сильно урезанный C with objects.

под С++ сейчас подразумевается
Про лапшу будете рассказывать своим внукам. Для Arduino используется полноценный С++ от GCC, вполне себе соответствующего стандартам . В том числе и последнему принятому ISO/IEC 14882:2003. А что там возникло в Вашем воображении, кроме ISO стандартов языка - исключительно Ваши проблемы )

У Вас такое искаженное представление возникло по той причине, что на Arduino нет операционной системы. Как следствие, например, не реализованы new и delete. Но из языка их никто не убирал. Они просто не реализованы и Вы получите ошибку компоновки, если сами не напишете свою реализацию. По той же причине не реализовано множество стандартных классов, связанных с вводом-выводом. Но опять таки, язык не ограничен и Вы вправе реализовать любой класс самостоятельно. Если, конечно, уложитесь в пару килобайт доступной RAM )
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574764
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128dbpatchпропущено...

ну ты нам эту лапшу не вешай. в ардуине не современный C++, а эдакий сильно урезанный C with objects.

под С++ сейчас подразумевается
Про лапшу будете рассказывать своим внукам. Для Arduino используется полноценный С++ от GCC, вполне себе соответствующего стандартам . В том числе и последнему принятому ISO/IEC 14882:2003. А что там возникло в Вашем воображении, кроме ISO стандартов языка - исключительно Ваши проблемы )

У Вас такое искаженное представление возникло по той причине, что на Arduino нет операционной системы. Как следствие, например, не реализованы new и delete. Но из языка их никто не убирал. Они просто не реализованы и Вы получите ошибку компоновки, если сами не напишете свою реализацию. По той же причине не реализовано множество стандартных классов, связанных с вводом-выводом. Но опять таки, язык не ограничен и Вы вправе реализовать любой класс самостоятельно. Если, конечно, уложитесь в пару килобайт доступной RAM )

все что ты рассказал, это и есть C with objects. С++ без STL бесcмысленен, как и без операторов new, delete, сколько не маши для имитации солидноcти каким-то там стандартом
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574771
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglИзопропилпропущено...

Отдать c-интерфейсы наружу можно и из c# - готовить нужно уметь
ну так кидай ссылку, каким это местом делается не через ОЛЕ
Какие аспекты интересуют?

Создание управляемой dll с точками входа winapi (C)
Или передача управляемого callback в нативный код?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574772
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargl,

Кстати насчёт COM

COM интерфейсы не обязаны использовать зловещую инфраструктуру,
Это всего лишь соглашение о вызовах

C++ не обязателен, Direct3D - тому пример
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574778
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В топике мы уже подошли к bash/PowerShell.

Неожиданно...
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574779
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchвсе что ты рассказал, это и есть C with objects. С++ без STL бесcмысленен, как и без операторов new, delete, сколько не маши для имитации солидноcти каким-то там стандартом

При чем тут STL? Если Ваше личное мнение отличается от мнения ISO/IEC то это проблемы Ваши или ISO? )))
А голый C без подавляющего количества базовых функций (read/write/getc/putc/printf/scanf) тоже "бессмысленен"? А их реализации и быть не может на микроконтроллере!

Если язык позволяет реализовать любой код, поддерживаемый архитектурой, значит он язык низкого уровня. Кроме ассемблера, это можно сделать только ассемблерными вставками. А их как раз поддерживает как C, так и C++.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574782
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchС++ без STL бесcмысленен
Если уж Вы не можете представить себе C++ без STL, то замените Arduino в моем посте на STM32. Так как он ARM архитектуры, то STL там полноценно поддерживается. Пока, кончено, оперативки хвататет )
И при этом все равно C++ остается на STM32 языком низкого уровня.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574792
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128dbpatchС++ без STL бесcмысленен
Если уж Вы не можете представить себе C++ без STL, то замените Arduino в моем посте на STM32. Так как он ARM архитектуры, то STL там полноценно поддерживается. Пока, кончено, оперативки хвататет )
И при этом все равно C++ остается на STM32 языком низкого уровня.

я то тут причем? вопрос библиотек описан в стандарте
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf

если библиотеки не реализованы (или даже - просто не используются) - то это не С++, а C with Objects или С with Classes

даже на Delphi можно писать в стиле Turbo Pascal
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574793
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchесли библиотеки не реализованы (или даже - просто не используются) - то это не С++, а C with Objects или С with Classes
По этой же логике, если какая-то библиотека реализована с ошибкой, то тогда это тоже не С++
А такси без шашечек не такси
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574799
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилC++ не обязателен, Direct3D - тому пример

Забавно, что как раз с Direct3D не могут (без дополнительной прокладки на С) работать ни
Delphi, ни FPC по причине одинакового бага с возвратом интерфейса из функции.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574804
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилSiemarglпропущено...

ну так кидай ссылку, каким это местом делается не через ОЛЕ
Какие аспекты интересуют?

Создание управляемой dll с точками входа winapi (C)
Или передача управляемого callback в нативный код?
Оба, но первый интереснее (с точками входа stdcall).

В целях повышения образованности (с)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574805
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилSiemargl,

Кстати насчёт COM

COM интерфейсы не обязаны использовать зловещую инфраструктуру,
Это всего лишь соглашение о вызовах

C++ не обязателен, Direct3D - тому пример
VBA тому пример.

Но это не только соглашение, но и поддержка функционала со стороны ОС.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574823
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglНо это не только соглашение, но и поддержка функционала со стороны ОС.
Direct3D никакой поддержки COM со стороны ОС не требует
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574825
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилDirect3D никакой поддержки COM со стороны ОС не требует

И никакой СОМ поддержки ОСи не требует. Фабрика классов СОМ+ это, внезапно, не часть ядра
Windows, а просто одна из надстроек.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574826
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglИзопропилпропущено...

Какие аспекты интересуют?

Создание управляемой dll с точками входа winapi (C)
Или передача управляемого callback в нативный код?
Оба, но первый интереснее (с точками входа stdcall).

В целях повышения образованности (с)
http://www.xinterop.com/index.php/tag/c-dll-export/

весь секрет в нескольких MSIL инструкциях
.export
.vtentry

c# и компания эти инструкции генерить не умеют, потому приходится или писать на MSIL,
или дизассемблировать код, вставлять инструкции и собирать заново (процесс нынче автоматизирован)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574827
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovИзопропилDirect3D никакой поддержки COM со стороны ОС не требует

И никакой СОМ поддержки ОСи не требует. Фабрика классов СОМ+ это, внезапно, не часть ядра
Windows, а просто одна из надстроек.
я имел ввиду, что для Direct3D эта надстройка не требуется(вызов CoInitialize в частности)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574831
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchptr128пропущено...

Если уж Вы не можете представить себе C++ без STL, то замените Arduino в моем посте на STM32. Так как он ARM архитектуры, то STL там полноценно поддерживается. Пока, кончено, оперативки хвататет )
И при этом все равно C++ остается на STM32 языком низкого уровня.
вопрос библиотек описан в стандарте
если библиотеки не реализованы

Во-первых, для ARM они реализованы, и на STM32 можете STL воспользоваться.
Во-вторых, как называется по Вашему язык C, в котором не реализованы большинство базовых функций, описанных еще K&R (все, вызывающие ОС - getc,putc,read,write,printf,scanf и т.п.), и тоже описанные в стандарте?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574835
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchя то тут причем? вопрос библиотек описан в стандарте http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf
если библиотеки не реализованы (или даже - просто не используются) - то это не С++, а C with Objects или С with Classes
цитата из упомянутого документаTwo kinds of implementations are defined: a hosted implementation and a freestanding implementation.
For a hosted implementation, this International Standard defines the set of available libraries.
A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (20.5.1.3).
certain language-support libraries (20.5.1.3)A freestanding implementation has an implementation-defined set of headers. This set shall include at least the headers shown in Table 19.
The supplied version of the header <cstdlib> shall declare at least the functions abort, atexit, at_quick_exit, exit, and quick_exit (21.5).
The other headers listed in this table shall meet the same requirements as for a hosted implementation.
Table 19Subclause Header(s)<ciso646>21.2Types <cstddef>21.3Implementation properties <cfloat> <limits> <climits>21.4Integer types <cstdint>21.5Start and termination <cstdlib>21.6Dynamic memory management <new>21.7Type identification <typeinfo>21.8Exception handling <exception>21.9Initializer lists <initializer_list>21.10Other runtime support <cstdarg>23.15Type traits <type_traits>32Atomics <atomic>D.4.2, D.4.3Deprecated headers <cstdalign> <cstdbool>
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574886
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128dbpatchпропущено...

вопрос библиотек описан в стандарте
если библиотеки не реализованы

Во-первых, для ARM они реализованы, и на STM32 можете STL воспользоваться.
Во-вторых, как называется по Вашему язык C, в котором не реализованы большинство базовых функций, описанных еще K&R (все, вызывающие ОС - getc,putc,read,write,printf,scanf и т.п.), и тоже описанные в стандарте?

С подобный язык, или - подмножество языка C. Примером такого языка является OpenCL C-like
https://en.wikipedia.org/wiki/OpenCL#Overview

как говорится - создан по мотивам известного произведения.

не пойму, из за чего такая трагедия. стандарты вроде довольно четко описывают, что там должно быть, чтоб это называлось The C Language, The C++ Language
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574887
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorovdbpatchя то тут причем? вопрос библиотек описан в стандарте http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf
если библиотеки не реализованы (или даже - просто не используются) - то это не С++, а C with Objects или С with Classes
цитата из упомянутого документаTwo kinds of implementations are defined: a hosted implementation and a freestanding implementation.
For a hosted implementation, this International Standard defines the set of available libraries.
A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (20.5.1.3).
certain language-support libraries (20.5.1.3)A freestanding implementation has an implementation-defined set of headers. This set shall include at least the headers shown in Table 19.
The supplied version of the header <cstdlib> shall declare at least the functions abort, atexit, at_quick_exit, exit, and quick_exit (21.5).
The other headers listed in this table shall meet the same requirements as for a hosted implementation.
Table 19Subclause Header(s)<ciso646>21.2Types <cstddef>21.3Implementation properties <cfloat> <limits> <climits>21.4Integer types <cstdint>21.5Start and termination <cstdlib>21.6Dynamic memory management <new>21.7Type identification <typeinfo>21.8Exception handling <exception>21.9Initializer lists <initializer_list>21.10Other runtime support <cstdarg>23.15Type traits <type_traits>32Atomics <atomic>D.4.2, D.4.3Deprecated headers <cstdalign> <cstdbool>


ну и? давай, рви уже покровы!

кстати, в Arduino нет оператора new (уупс), т.е. 21.6 как минимум уже не соблюдается.
аналогично в там нет exceptions (уупс)

чо? вы все еще утверждаете, что там C++?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574889
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchчо? вы все еще утверждаете, что там C++?Я про "там" не утверждаю ничего.
Просто напоминаю, что стандартных реализаций языка - более одной. С существенно разным набором библиотек.

P.S. new, всегда возвращающий нул - это "стандарт" или "баба-яга против"?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574890
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchчо? вы все еще утверждаете, что там C++?
а что там, С ?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574897
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchptr128 Во-вторых, как называется по Вашему язык C, в котором не реализованы большинство базовых функций, описанных еще K&R (все, вызывающие ОС - getc,putc,read,write,printf,scanf и т.п.), и тоже описанные в стандарте?

С подобный язык, или - подмножество языка C.


А как же стандарт? Или он Вам уже не указ? Что хотим принимаем, а что хотим - отвергаем?
5.1.2.1 Freestanding environment

In a freestanding environment (in which C program execution may take place without any
benefit of an operating system), the name and type of the function called at program
startup are implementation-defined. Any library facilities available to a freestanding
program, other than the minimal set required by clause 4, are implementation-defined.


Clause 4
A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>,<iso646.h>,<limits.h>,<stdarg.h>,<stdbool.h>,<stddef.h>, and <stdint.h>.

Если честно, сильно повеселили тем, что для микроконтроллеров, в автомобилях, бытовых приборах, промышленной автоматике и т.п. пишут вовсе не на C, а на каком-то безымянном C-подобном языке )))

А теперь вернемся к нашим баранам:
ptr128для ARM они [STL] реализованы, и на STM32 можете STL воспользоваться.

Итак, STL на STM32 Вам уже ничто не мешает воспользоваться. Так по каким причинам C++ тогда не является языком низкого уровня, если только на нем можно написать код для STM32?
И вообще, что Вы понимаете под понятием "язык низкого уровня"?
Я так искренне считаю, что если бы C и C++ не поддерживали ассемблерных вставок, то они бы языками низкого уровня не являлись.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574899
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatch21.6|Dynamic memory management <new>
21.8|Exception handling <exception>

кстати, в Arduino нет оператора new (уупс), т.е. 21.6 как минимум уже не соблюдается.
аналогично в там нет exceptions (уупс)

А это что? new.h
А это? exceptions.h

То, что для чайников из IDE они по-умолчанию выключены, не говорит ни о чем, кроме того, что надо десять раз подумать, прежде, чем их использовать на микроконтролере.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574900
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Так по каким причинам C++ тогда не является языком низкого уровня, если только на нем можно написать код для STM32?
Извини, у тебя какая-то яичница в голове, в виде умозаключений. То про adruino говорим, то про ARM, теперь на STM32 перепрыгнули.
При чем тут это все?

ptr128И вообще, что Вы понимаете под понятием "язык низкого уровня"?
С++ - это прикладной язык, и именно поэтому на нем не пишут операционные системы, ну разве какие совсем экзотические (так экзотику и на C# писали). Разве это не очевидно?


ptr128Я так искренне считаю, что если бы C и C++ не поддерживали ассемблерных вставок, то они бы языками низкого уровня не являлись.
Ассемблерные вставки есть даже в Delphi/Object Pascal, но никто не назовет Delphu языком низкого уровня, так что вообще мимо.

вообще о чем терзания и сомнения? хочется попасть в какую-то иную лигу, не прикладников?
ну так это нереально, для этого нужно принять волевое решение и выбросить ++ из сознания, а это для начинающих кодеров слишком нереально
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574902
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchptr128Так по каким причинам C++ тогда не является языком низкого уровня, если только на нем можно написать код для STM32?
То про adruino говорим, то про ARM, теперь на STM32 перепрыгнули.
При чем тут это все?

Модератор: Редактировано
Вы писали?
dbpatchС++ не является языком низкого уровня. Это обычный себе прикладной язык.
Низкий уровень - это C и/или ассемблер.

Вот это мы и обсуждаем. И раз AVR (Arduino) Вас не устроил отсутствием поддержки STL, то я и перешел к STM32 , который является одной из реализаций ARM, а точнее ARM Cortex M.

dbpatchС++ - это прикладной язык, и именно поэтому на нем не пишут операционные системы, ну разве какие совсем экзотические (так экзотику и на C# писали). Разве это не очевидно?

Слово "очевидно" является аргументов только в устах демагога
Дайте определение того, что Вы считаете языком низкого уровня, пожалуйста.

dbpatchptr128Я так искренне считаю, что если бы C и C++ не поддерживали ассемблерных вставок, то они бы языками низкого уровня не являлись.
Ассемблерные вставки есть даже в Delphi/Object Pascal, но никто не назовет Delphu языком низкого уровня, так что вообще мимо.

Потому что помогают они там, как мертвому припарка. Из-за отсутствия развитого механизма указателей, толком ничего коду в этой ассемблерной вставке не передать и результат выполнения этой ассемблерной вставки не получить.
Но при чем тут Delphi/Object Pascal, если мы тут обсуждаем истинность Вашего утверждения?
dbpatchС++ не является языком низкого уровня.


dbpatchхочется попасть в какую-то иную лигу, не прикладников?

Модератор: РедактированоЯ с 1982 года успел попрограммировать для I8048, I8051, Z80, AVR, AVR32, ESP8266, STM8 и STM32.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574905
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Из-за отсутствия развитого механизма указателейМожно вопрос. Развитый - это какой? Какие у него преимущества перед неразвитым, типа дельфового?

ptr128толком ничего коду в этой ассемблерной вставке не передать и результат выполнения этой ассемблерной вставки не получитьУдивляюсь даже теперь, как работает половина функций rtl Delphi, если им ничего передать нельзя.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574906
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128Из-за отсутствия развитого механизма указателейМожно вопрос. Развитый - это какой? Какие у него преимущества перед неразвитым, типа дельфового?
Не типизированные указатели (void *), возможность присвоения указателю константного физического адреса, различные виды указателей для различных адресных пространств памяти (RAM, ROM, EPROM, внешняя RAM и т.п.) и свободное преобразование типов указателей.
Да просто попробуйте только на Pascal, без использования функций, написанных на других языках программирования, создать программу, работающую без операционной системы. Вообще без ОС. Так как пишут для микроконтроллеров. Сами все поймете )

YuRockptr128толком ничего коду в этой ассемблерной вставке не передать и результат выполнения этой ассемблерной вставки не получитьУдивляюсь даже теперь, как работает половина функций rtl Delphi, если им ничего передать нельзя.
Вы вообще понимаете разницу между ассемблерной вставкой и функцией?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574907
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Не типизированные указатели (void *), возможность присвоения указателю константного физического адреса, различные виды указателей для различных адресных пространств памяти (RAM, ROM, EPROM, внешняя RAM и т.п.) и свободное преобразование типов указателей.Это всё про стандартный паскалевский Pointer.
ptr128Вы вообще понимаете разницу между ассемблерной вставкой и функцией?
Да, в асм. вставках в делфи можно использовать объявленные локальные переменные. Они могут быть указателями. Не понимаю проблемы.

ptr128Да просто попробуйте только на Pascal
Да нет, знаний мне для этого не хватит - никогда таким не занимался. А начинать уже смысла нет.
Хотя что-то вроде слышал про операционку на паскале, но мне это не интересно - смысла нет опять же.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574909
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128Не типизированные указатели (void *), возможность присвоения указателю константного физического адреса, различные виды указателей для различных адресных пространств памяти (RAM, ROM, EPROM, внешняя RAM и т.п.) и свободное преобразование типов указателей.Это всё про стандартный паскалевский Pointer.

Приведите, пожалуйста, ссылки и цитаты из стандарта по каждому из перечисленных мной пунктов. Я все же не религиозен, да и Вы не теолог )))

YuRockУдивляюсь даже теперь, как работает половина функций rtl Delphi, если им ничего передать нельзя.
ptr128Вы вообще понимаете разницу между ассемблерной вставкой и функцией?
Да, в асм. вставках в делфи можно использовать объявленные локальные переменные.

Это как раз значения не имеет. Тот же GCC спокойно обходится без этого.
Вы на вопрос ответьте. Какая связь между "половина функций rtl Delphi" и ассемблерными вставками?

YuRockptr128Да просто попробуйте только на Pascal
Хотя что-то вроде слышал про операционку на паскале, но мне это не интересно - смысла нет опять же.
Самое смешное, что не то что операционку, а даже сам Pascal только на Pascal написать невозможно. Большинство стандартных функций Pascal написаны на чем угодно (C, C++, ассемблер и т.п.), но только не на самом Pascal. В отличии от C/C++.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574910
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Самое смешное, что не то что операционку, а даже сам Pascal только на Pascal написать невозможно.Ну это реально смешно. Даже делфи написан на делфи.
Не говоря об fpc, который поставляется с исходниками (на паскале) и без проблем пересобирает сам себя.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574911
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Приведите, пожалуйста, ссылки и цитаты из стандарта по каждому из перечисленных мной пунктов.
Может я неправильно выразился.
Я начал пользоваться паскалем к концу 90-х, и тогда в нем уже был Pointer - нетипизированный указатель, аналог void*. Скажем так, это стандарт "для меня", т.к. я другого не видел.
Да, и нетипизированные указатели (которым можно присвоить что угодно, хоть константу) в паскале существуют наряду с типизированными, и преобразовать можно из любого в любой. Всё это тоже с прошлого тысячелетия, для меня это стандарт.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574912
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Это как раз значения не имеет. Тот же GCC спокойно обходится без этого.Так оказывается можно всё-таки передать/получить из вставки (не функции) или нет? Вот, что имеет значение.

ptr128Вы на вопрос ответьте. Какая связь между "половина функций rtl Delphi" и ассемблерными вставками?
Не думал, что Вам так важна эта разница. И там, и там язык одинаковый используется, например. Но если Вы не признаёте функции - ок, ограничимся переменными в "классических" вставках.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574914
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128Это как раз значения не имеет. Тот же GCC спокойно обходится без этого.Так оказывается можно всё-таки передать/получить из вставки (не функции) или нет? Вот, что имеет значение.

Конечно можно. Через регистры CPU. Если есть возможность располагать в нужный момент нужные переменные в нужных регистрах. Потому что, когда, как на ATtiny13, оперативной памяти 64 байта, а регистров - 32 байта, десять раз подумаешь, прежде чем переменную в памяти размещать. А к локальным переменным легко обратиться через указатель стека.
Вы какие-то странные вопросы задаете. У Вас вообще есть опыт программирования на ассемблере? Вы в курсе, что на подавляющем большинстве архитектур нет машинных команд напрямую адресующих память-память?

YuRockptr128Вы на вопрос ответьте. Какая связь между "половина функций rtl Delphi" и ассемблерными вставками?
Не думал, что Вам так важна эта разница. И там, и там язык одинаковый используется, например.
Ассемблерная вставка - синтаксический элемент языка. А функция, написанная на ассемблере, однозначно написана не на Pascal.

Не уходите от вопросов:
Приведите, пожалуйста, ссылки и цитаты из стандарта по каждому из перечисленных мной пунктов.
YuRockЭто всё про стандартный паскалевский Pointer.

Я про указатели в стандартном Pascal (ISO 7185:1983 ANSI/IEEE 770X3.97:1983) вообще впервые от Вас услышал.

YuRockНу это реально смешно. Даже делфи написан на делфи.

Докажите. Я слышал противополжное. А именно, что большая часть RTL в Delphi, написана на C++Builder.

YuRockНе говоря об fpc, который поставляется с исходниками (на паскале) и без проблем пересобирает сам себя.

Мы говорим о Pascal, а не Free Pascal. Это разные языки. Второй вообще не стандартизирован.

YuRockСкажем так, это стандарт "для меня"

Что Вы понимаете тогда под словом "стандарт"? Как вообще стандарт может быть "для меня"? Я всегда был уверен, что стандарт языка программирования может быть зафиксирован только нормативным документом, принятым ANSI/IEEE - ISO/IEC. Я просто не знаю ничего про какие-то иные организации, уполномоченные принимать такие стандарты.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574915
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock,

И давайте так. Больше здесь на тему Pascal я отвечать не буду. Здесь форум по C++. Переползайте в тематический форум, а там уже продолжим дискуссию.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574932
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Я так искренне считаю, что если бы C и C++ не поддерживали ассемблерных вставок, то они бы языками низкого уровня не являлись.
где и в каком стандарте описаны ассемблерные вставки?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574935
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилptr128Я так искренне считаю, что если бы C и C++ не поддерживали ассемблерных вставок, то они бы языками низкого уровня не являлись.
где и в каком стандарте описаны ассемблерные вставки?
ISO/IEC 9899
Annex J.5.10
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574936
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
jmp_originalptr128, пожалуйста, не неси бред про Delphi. Это выглядит и смешно и грустно.
Модератор: Удалено
ptr128я слышал [...], что большая часть RTL в Delphi, написана на C++Builder.

А больше я про Delphi вообще ни слова не утверждал.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574939
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128ISO/IEC 9899
MSVC для платформы x64 ассемблерные вставки не поддерживает.
пропала планета
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574944
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилptr128ISO/IEC 9899
MSVC для платформы x64 ассемблерные вставки не поддерживает.
пропала планета
Стандарт это позволяет: "J.5 Common extensions. The following extensions are widely used in many systems, but are not portable to all
implementations."
При этом MSVC, однако, в качестве собственного расширения, через intrinsics , команды ассемблера x64 благополучно поддерживает. Планета снова в безопасности )))
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574945
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRock,

И давайте так. Больше здесь на тему Pascal я отвечать не буду. Здесь форум по C++. Переползайте в тематический форум, а там уже продолжим дискуссию.
Я думаю что отсылки к Pascal/Delphi уместны когда мы обсуждаем calling convention.

Кроме того, учитывая специфику вопроса (мы уже обсуждали Python/C#/Lua) топик
давно вышел за рамки С++ тематики.

Поздно запрещать. Или пора переносить в Программирование.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574948
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Что Вы понимаете тогда под словом "стандарт"?Всё, я пропадаю.
Я во всём был неправ, Вы во всём правы. Я срасу и не понял, о чём Вы.
Конечно же, на [условно] ABC Паскале не написать ABC Паскаль. Не говоря о ОС.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574956
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockКонечно же, на [условно] ABC Паскале не написать ABC Паскаль. Не говоря о ОС.
Вот теперь я вижу профессионала.
Естественно, к любому, компилируемому в машинные коды/ассемблер, языку в конкретной реализации можно добавить такие расширения, что это позволит использовать его в качестве языка низкого уровня. И это позволит создавать программы на нем в freestanding environment (без операционной системы на голом железе). Вопрос только в том "стоит ли овчинка выделки?"
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574962
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Вопрос только в том "стоит ли овчинка выделки?"
По моему, вопрос изначально стоял, какие языки можно называть языками низкого уровня, а какие - высокого.

А ответ на него таков: чем ближе конструкции, средства языка приближены к железу, тем он более низкого уровня. Всё.
Если сравнивать Ассемблер и Си, то Си - язык высокого уровня.
А если сравнивать Паскаль и C#, то Паскаль - язык низкого уровня.

А вот сравнение Си и Паскаля может вызывать вопросы. В Си, например, нет безусловных циклов. А в Паскале есть. FOR не проверяет условие перед каждой новой итерацией, в отличие от Си в котором for=while, только писать по разному.
И какой из этих for ближе к ассемблеру?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574965
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я думаю что если рассматривать количество трансформаций которые исходный код/AST преодолевает
на пути к машинному коду то окажется что Паскаль ближе всех.

Ну.. по крайней мере бенчмарки компилляторов всегда давали пальму первенства Pascal/Modula - подобным
языкам как наиболее "прямым" с точки зрения процесса компилляции.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574971
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЯ думаю что если рассматривать количество трансформаций которые исходный код/AST преодолевает
на пути к машинному коду то окажется что Паскаль ближе всех.
Ну я пример привёл, где кол-во трансформаций не важно.
В паскале for - это обычный loop.
А цикл с условием трансформируй/не трансформируй - loop не получится. Получится проверка условия и goto.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574972
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockmaytonЯ думаю что если рассматривать количество трансформаций которые исходный код/AST преодолевает
на пути к машинному коду то окажется что Паскаль ближе всех.
Ну я пример привёл, где кол-во трансформаций не важно.
В паскале for - это обычный loop.
А цикл с условием трансформируй/не трансформируй - loop не получится. Получится проверка условия и goto.
В Паскале есть пре-процессор?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574975
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВ Паскале есть пре-процессор?Ну, константы вычисляются до комеиляции. В таком виде есть)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574982
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockmaytonВ Паскале есть пре-процессор?Ну, константы вычисляются до комеиляции. В таком виде есть)А может, сначала в школу?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574983
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargl,

Препроцессор должен сначала в школу заходить, а потом код для компилятора готовить?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574984
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRockпропущено...

Хотя что-то вроде слышал про операционку на паскале, но мне это не интересно - смысла нет опять же.
Самое смешное, что не то что операционку, а даже сам Pascal только на Pascal написать невозможно. Большинство стандартных функций Pascal написаны на чем угодно (C, C++, ассемблер и т.п.), но только не на самом Pascal. В отличии от C/C++.
Тут ты неправ. Погугли про оберон системс.

crt0 тоже написан не на С.

Принципиальной разницы тут нет.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574985
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockSiemargl,

Препроцессор должен сначала в школу заходить, а потом код для компилятора готовить?
Да. Сначала в школу, потом в топик по С++.
Иначе путает препроцессор с оптимизатором.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574986
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglYuRockSiemargl,

Препроцессор должен сначала в школу заходить, а потом код для компилятора готовить?
Да. Сначала в школу, потом в топик по С++.
Иначе путает препроцессор с оптимизатором.
О, великий!
Не знаю, как ты, а я когда-то ради интереса прогонял препроцессором c++ код и знаешь, что в нем видел?
А ничего, кроме посчитанных констант и развернутых макросов.
А так как макросов в паскале нет, остаются только константы.
При чем тут оптимизатор - только боги, такие как ты, видимо, знают.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574991
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockПо моему, вопрос изначально стоял, какие языки можно называть языками низкого уровня, а какие - высокого.
А ответ на него таков: чем ближе конструкции, средства языка приближены к железу, тем он более низкого уровня. Всё.

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

Поясняю, на примере:
1. Размещаем переменную counter в регистре r3 CPU
Код: plaintext
1.
register unsigned char counter asm("r3");


2. Размещаем массив переменных в программной памяти, которая имеет совсем другое адресное пространство, чем оперативная память (Гарвардская архитектура):
Код: plaintext
1.
const int var[2] PROGMEM = { 1, 2 };


3. Указываем, что переменная porta расположена по конкретному адресу в пространстве ввода-вывода (i8080, Z80 и т.п.)
Код: plaintext
1.
volatile int porta __attribute__((io (0x22)));


Для каких языков, кроме C и PL/M вы можете привести аналогичные примеры?

YuRockВ Си, например, нет безусловных циклов.

В ассемблере их тоже нет. Безусловные циклы в машинных командах реализуются через команду безусловного перехода. Аналог goto в C. Другое дело, что в C проще и понятней написать for(;;) {}, чем использовать goto. Вы, наверное, очень увидитесь, если посмотрите ассемблерный код, получающийся в этих двух случаях: он окажется идентичным )

YuRockИ какой из этих for ближе к ассемблеру?
Получается C, раз имеет оператор прямо соответствующий команде безусловного перехода )
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574992
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Получается C, раз имеет оператор прямо соответствующий команде безусловного переходаСмешно называть безусловным циклом цикл, в котором перед (после) каждой итерацией проверяется изначальное условие цикла (которое может быть любым и трехэтажным) а затем, в зависимости от результата, делается "безусловный переход" туда или туда.


ptr128В ассемблере их тоже нет. Безусловные циклы в машинных командах реализуются через команду безусловного перехода
Это бред, извините. Безусловные циклы - это такие, в итерациях которых не проверяется условие для выхода из цикла, а просто работают по счетчику, заданному перед началом цикла.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574993
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В топике на мой взгляд прозвучало сравнения ЯВУ и языков низкого уровня.

Но у меня возникли следующие вопросы.
1) Эта шкала абсолютная? Можем ли мы сравнивая (Assembler/C или С/C#) придти к неоднозначности позиции С в этом сравнении?
2) Всегда-ли имеет смысл выбирать метрику близости к машинным командам? Возможно
совокупность других метрик сможет склонить чашу весов в другую сторону.
Количество слоёв трансформации (7 - в С++ и 2 в C#/.Net). Как влияет на нашу метрику?

А где здесь находится JavaScrip? А где Lisp? Как их между собой сравнивать? То бишь
как к ним приложить линейку?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574995
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglПогугли про оберон системс.
"ОС Оберон написана на разработанном в рамках этого проекта одноимённом языке." К чему это и что это доказывает, кроме того, что я уже написал выше?
ptr128к любому, компилируемому в машинные коды/ассемблер, языку в конкретной реализации можно добавить такие расширения, что это позволит использовать его в качестве языка низкого уровня.

Siemarglcrt0 тоже написан не на С.
А это что? Да, сказано, что "This sequence might also be done in the UTILS/STARTUP/GCC/crt0.S". Но реализация на C вполне себе присутствует.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574996
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Такое определение вообще не позволяет назвать любой язык "языком низкого уровня". Оно позволяет только сравнивать языки.
Поэтому я уже не раз указывал, что языком низкого уровня следует считать тот язык, который позволяет получить любой код поддерживаемый целевой архитектурой
Вот не поленился и заглянул в википедию:

Низкоуровневый язык программирования (язык программирования низкого уровня) — язык программирования, близкий к программированию непосредственно в машинных кодах.

Значит я правильно вспомнил смысл этого определения из школы (интернета еще не было тогда).

Впрочем, я не хочу спорить на эту тему. Т.к. считаю, что под "целевую платформу" нужно писать на том языке, на котором быстрее и проще всего можно получить приемлемый результат. Низкого или высокого этот язык уровня будет при этом, не имеет никакого значения.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574997
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128Получается C, раз имеет оператор прямо соответствующий команде безусловного переходаСмешно называть безусловным циклом цикл, в котором перед (после) каждой итерацией проверяется изначальное условие цикла.
Вам не кажется, что в безусловном цикле по определению не может быть условия цикла? А если в цикле есть условие, то он все же условный?

YuRock в итерациях которых не проверяется условие для выхода из цикла, а просто работают по счетчику, заданному перед началом цикла.
Приведите код такого цикла на ассемблере для любой архитектуры. Просто, чтобы до Вас дошло, что в таком цикле значение счетчика прийдется:
1. Инициализироать
2. Декрементировать
3. Проверять на равенство нулю (или еще чему-то)
4. В зависимости от результата проверки в п.3 выполнять команду условного перехода.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574998
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128языком низкого уровня следует считать тот язык, который позволяет получить любой код поддерживаемый целевой архитектурой
Низкоуровневый язык программирования (язык программирования низкого уровня) — язык программирования, близкий к программированию непосредственно в машинных кодах.

И что? Вот и конкретизируйте, что Вы понимаете под "близкий". Я это сделал.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575001
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonязыков низкого уровня.
1) Эта шкала абсолютная? Можем ли мы сравнивая (Assembler/C или С/C#) придти к неоднозначности позиции С в этом сравнении?

Стандартизированного определения "языка низкого уровня" я не знаю. Общепринятое - я уже озвучил:
ptr128языком низкого уровня следует считать тот язык, который позволяет получить любой код поддерживаемый целевой архитектурой


maytonВсегда-ли имеет смысл выбирать метрику близости к машинным командам?
Ну раз на самом нижнем уровне у нас всегда машинные команды, так как процессор способен выполнять только их, то какие еще можно предложить варианты?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575004
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Вам не кажется, что в безусловном цикле по определению не может быть условия цикла? А если в цикле есть условие, то он все же условный?Вот-вот.

ptr128Приведите код такого цикла на ассемблере для любой архитектурыНе знаю, на счет любой, и знать не хочу - мне не интересно, но в x86 есть loop.


ptr128в таком цикле значение счетчика прийдется:
1. Инициализироать

Нет, в цикле это не делается, это делается 1 раз перед началом цикла.
2. Декрементировать
3. Проверять на равенство нулю (или еще чему-то)
Это всё делается неявно, процессором. И это очень мало, по сравнению с вычислением в каждой итерации трехэтажного условия.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575005
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128SiemarglПогугли про оберон системс.
"ОС Оберон написана на разработанном в рамках этого проекта одноимённом языке." К чему это и что это доказывает, кроме того, что я уже написал выше?
ptr128к любому, компилируемому в машинные коды/ассемблер, языку в конкретной реализации можно добавить такие расширения, что это позволит использовать его в качестве языка низкого уровня.

Siemarglcrt0 тоже написан не на С.
А это что? Да, сказано, что "This sequence might also be done in the UTILS/STARTUP/GCC/crt0.S". Но реализация на C вполне себе присутствует.
С расширениями или без них Паскаль, С, Оберон одинаковы - только с расширениями (или внешними объектниками) на них можно написать ОС.

Ты совсем неправ в пассаже про паскаль
ptr128Самое смешное, что не то что операционку, а даже сам Pascal только на Pascal написать невозможно. Большинство стандартных функций Pascal написаны на чем угодно (C, C++, ассемблер и т.п.), но только не на самом Pascal. В отличии от C/C++.
Впрочем, я присоединяюсь к тому, что с расширениями или без, с библиотекой или без - язык остается оригинальным.
Хотя может и не соответствовать какому либо стандарту в полной мере.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575006
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128языком низкого уровня следует считать тот язык, который позволяет получить любой код поддерживаемый целевой архитектурой
Как с помощью средств языка Си можно получить цикл loop? Никак? Значит, Си - не является языком низкого уровня?

Хорошее "общепринятое" "определение".
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575010
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128maytonВсегда-ли имеет смысл выбирать метрику близости к машинным командам?
Ну раз на самом нижнем уровне у нас всегда машинные команды, так как процессор способен выполнять только их, то какие еще можно предложить варианты?
Я понял вас. Но за последние лет 20 сами по себе машинные команды претерпели много изменений. В них стали выделять микро-код как условно еще один слой логики.

Давайте (условно) выделим следующие слои. Просто для того чтобы форум
и участники осознали всю шЫрость и гЛыбость ситуации.
0. Собственно железо.
1. Микро-код.
2. Код
3. Машиинный код
4. Ассемблер/LLVM
4.5. Собственно классический компилируемый ЯП. Двух-проходный.
5. Байткод(Java(JVM)/Basic/Python/DotNet.CLR
6. Кодогенераторы и порождающие код машины (ANTLR, Byacc/Bizon). ORM-прослойки. Формс-приложения. RAD-средства. SOAP/Rest/JMS адаптеры. Все что описывается не
на ЯП а на языке сетевого протокола.
7. Интерпретаторы и скриптовые ЯП.
8. Сложные и гибридные ЯП в которых невозможно четко выделить принадлежность (Common-Lisp) к слоям.
9. UI. Конфигурации.

И при этом мы еще не рассматривали виртуальные машины, Xen/Kvm/Vmware, и эмуляторы
экзотических процессоров.

Где в них будет лежать язых - бох его знает. Непонятно куда отнести
программирование на ПЛИС, Verilog, VHDL и прочее.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575012
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128языком низкого уровня следует считать тот язык, который позволяет получить любой код поддерживаемый целевой архитектурой
Как с помощью средств языка Си можно получить цикл loop? Никак? Значит, Си - не является языком низкого уровня?

Хорошее "общепринятое" "определение".
Вы включили неверный риторический приём. Вы можете взять справочник машинных команд ASM/TASM/FASM
для x86 и перебирая по одной спрашивать у ptr123 тот-же самый вопрос относительно каждой из них.

И к чему мы придём?

Прошу вас воздержаться от упёртости и тезисов которые заводят нас всех в тупик.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575017
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Язык низкого уровня - тот который позволяет реализовать все функции ОС на заданной платформе.

Поэтому С, С++, и даже паскаль - это все языки низкого уровня.

Точно так же язык высокого уровня - тот который позволяет писать прикладную логику не вдаваясь в детали платформы.
Поэтому паскаль, С++, и даже С - это все языки высокого уровня.

Поэтому спор ни о чем )))
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575019
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,
Fortran IV - какого уровня ?

Или для вас единственный критерий возижность писать без ОС?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575037
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128Приведите код такого цикла на ассемблере для любой архитектурыНе знаю, на счет любой, и знать не хочу - мне не интересно, но в x86 есть loop.

И где он? Мы все с нетерпение ждем!
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575040
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128языком низкого уровня следует считать тот язык, который позволяет получить любой код поддерживаемый целевой архитектурой
Как с помощью средств языка Си можно получить цикл loop?

Я вообще не знаю ничего об целевой архитектуре, про которую Вы ведете речь, и какими машинными командами там реализован совершенно неизвестный мне "loop".
Приведите код на ассемблере и я покажу Вам, как его получить на С.
И Вы так до сих пор и не привели примеры кода, хотя ранее утверждали, что все эти возможности в Pascal есть:
1. Размещаем переменную counter в регистре r3 CPU
Код: plaintext
1.
register unsigned char counter asm("r3");


2. Размещаем массив переменных в программной памяти, которая имеет совсем другое адресное пространство, чем оперативная память (Гарвардская архитектура):
Код: plaintext
1.
const int var[2] PROGMEM = { 1, 2 };


3. Указываем, что переменная porta расположена по конкретному адресу в пространстве ввода-вывода (i8080, Z80 и т.п.)
Код: plaintext
1.
volatile int porta __attribute__((io (0x22)));



Демагогические пассажи про микрокоды и эмуляторы я пропускаю, как совершенно не имеющие отношение к тем двум вопросам, которые мы обсуждаем:
1. Что такое язык низкого уровня?
2. Почему, по утверждению dbpatch, C++ не является языком низкого уровня?
3. Почему, по утверждению YuRock, Pascal является языком низкого уровня?

ИзопропилИли для вас единственный критерий возижность писать без ОС?
У меня сугубо практический подход. Когда я пишу программу для микроконтроллера - это ключевой критерий при выборе языка программирования. Когда я пишу программу, которая должна работать под управлением ОС - данный критерий мне безразличен.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575041
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyЯзык низкого уровня - тот который позволяет реализовать все функции ОС на заданной платформе.
Как вы вообще представляете реализацию ОС или каких-то ее функции на том же ATtiny13 с 64 байтами RAM?

Anatoly Moskovskyпаскаль - это [...] языки низкого уровня.

К сожалению, мне никто хочет это показать. То заводят речь о языках для которых нет ISO стандартов. То просто отказываются продемострировать, как размещать в Pascal переменные в регистре, адресном пространстве программ или в адресном пространстве ввода-вывода.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575057
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Приведите код такого цикла на ассемблере для любой архитектуры.Э-э-э ... Отдельная команда x86? Вот прямо начиная с i8088?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575071
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
низкий, высокий ...
лапаша, не лапша ...

не C, не паскаль не являются языком низкого уровня
мочь сделать что-то через определённую опу это не показатель низкого\высокого уровня языка
в паскале - absolute, port и пр. фигня, в С - 21058769

но они оба системные языки, так же как и форт например
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575076
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRockНе знаю, на счет любой, и знать не хочу - мне не интересно, но в x86 есть loop.

И где он? Мы все с нетерпение ждем!
Вместо того, чтобы ждать, можно было в гугле набрать, например, "ассемблер loop" и посмотреть кучу примеров.

ptr128Приведите код на ассемблере и я покажу Вам, как его получить на С.
Офигеть. Ну ладно.

mov cx 5
Label1:
nop
loop Label1

ptr128хотя ранее утверждали, что все эти возможности в Pascal есть:
Давайте поменьше фантазий.
Я лишь задавал вопросы (на которые Вы ответили только вопросами). А утверждал я лишь то, что в Паскале (которым я пользуюсь) есть нетипизированные указатели (чего вы говорили нет) и возможность преобразования указателей.

ptr128утверждению YuRock, Pascal является языком низкого уровня
Ложь и провокация. Я наоборот говорил, что этот термин можно применять только в сравнении языков, да и то это иногда спорно.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575078
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128То просто отказываются продемострировать, как размещать в Pascal переменные в регистреВ паскале - только как аргументы функций с соглашением вызова register (которое по умолчанию), больше никак. Ну, не считая mov в ассемблерной вставке, но это операция а не размещение.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575081
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockбольше никакя не знаю как, во всяком случае. Компилятору зачастую лучше знать, где переменные разместить.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575085
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128К сожалению, мне никто хочет это показать. То заводят речь о языках для которых нет ISO стандартов. То просто отказываются продемострировать, как размещать в Pascal переменные в регистре, адресном пространстве программ или в адресном пространстве ввода-вывода.
Я думаю что есть предметные области разработки где нет покрытия стандартами.
Военные разработки. Спецтехника. И т.п.

Собственно.. стандарт и реализация это как яйцо и курица. Бесконечный философский
спор на тему что было первым.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575120
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockmov cx 5
Label1:
nop
loop Label1


Если проверите, увидите точно такой код, даже с nop )
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
int main(void)
{
  register int i asm ("ecx") = 5;
Label1:
  asm ("nop");
  asm goto ("loop %l0" : : : : Label1);
}



YuRockА утверждал я лишь то, что в Паскале (которым я пользуюсь) есть нетипизированные указатели (чего вы говорили нет) и возможность преобразования указателей.

Ну так дайте ссылку на ISO стандарт и процитируйте его. И вопрос будет исчерпан.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575123
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)не C, не паскаль не являются языком низкого уровня

Вы уже тут N-ый, который оперирует понятием "язык низкого уровня". Но никто пока, кроме меня, не дал определение этому выражению, так, как он его понимает. Было только сравнительное определение, позволяющее говорить "более низкого уровня, чем". Но не абсолютное.
Вы хоть можете дать определение?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575125
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRockmov cx 5
Label1:
nop
loop Label1


Если проверите, увидите точно такой код, даже с nop )
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
int main(void)
{
  register int i asm ("ecx") = 5;
Label1:
  asm ("nop");
  asm goto ("loop %l0" : : : : Label1);
}




YuRockА утверждал я лишь то, что в Паскале (которым я пользуюсь) есть нетипизированные указатели (чего вы говорили нет) и возможность преобразования указателей.

Ну так дайте ссылку на ISO стандарт и процитируйте его. И вопрос будет исчерпан.
1. Я просил на чистом Си. На чистом паскале это будет стандартный, как Вы любите повторять, цикл for. nop там вместо DoAnything.

2. Про стандарты я уже говорил, мне на них наплевать в моей работе, я же не в университете преподаю.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575133
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock1. Я просил на чистом Си.

А я на чем? GCC копилируется. Ассемлерный листинг я проверил. Под рукой, к сожалению, не было библиотек для 16 бит, поэтому пришлось делать под 32.

YuRockПро стандарты я уже говорил, мне на них наплевать в моей работе, я же не в университете преподаю.
А почему Вы считаете, что если Вам на что-то наплевать, то это должно иметь хоть какое-то отношение к мнению остальных?
А в то, что вы "работаете" плюя на стандарты, верится слабо. Потому что если завтра выйдет какая-то новая архитектура, то перенести на нее Ваш код будет реально, только если он будет соответствовать стандарту. Ведь для новой архитектуры компилятор будет создан в соответствии со стандартом, а не с Вашим личным мнением.
Например, для того же ARM Cortex-M, коммюнити Free Pascal 7 лет выпускали компилятор и уже 12 лет библиотек сделать не могут. А вот mikroPascalPRO, соответствующий ISO стандарту, выпустили больше 10 лет назад.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575152
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128А я на чем?
А Вы на ассемблерных вставках.

ptr128Ассемлерный листинг я проверил.Ну еще бы ассемблерная вставка "скомпилировалась" бы как-то иначе)

ptr128Потому что если завтра выйдет какая-то новая архитектура, то перенести на нее Ваш код будет реально, только если он будет соответствовать стандарту
Стандарту транслятора Вирта, в котором нет указателей или чего там нет? Самому не смешно?

Меня гипотетически возможные проблемы не заботят. Если они возникнут - я ими озабочусь, а не возникнут - плевать.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575153
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

Какое отношение к стандартам имеют ваши ассемблерные вставки?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575155
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилptr128,
Какое отношение к стандартам имеют ваши ассемблерные вставки?
Прямое. В стандарте ISO/IEC 9899 они есть.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575156
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockСтандарту транслятора Вирта, в котором нет указателей или чего там нет? Самому не смешно?

Я программирую на C, поэтому, одно время в UseNet, активно участвовал в разработке очередного стандарта.
Вы программируете на Pascal - Вам наплевать стандарт. Может быть именно потому у Pascal такие стандарты?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575185
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Изопропилptr128,
Какое отношение к стандартам имеют ваши ассемблерные вставки?
Прямое. В стандарте ISO/IEC 9899 они есть.
Кроме одинокого ключевого слова ( и то необязательного в реализации) - что нибудь есть?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575194
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128kealon(Ruslan)не C, не паскаль не являются языком низкого уровня

Вы уже тут N-ый, который оперирует понятием "язык низкого уровня". Но никто пока, кроме меня, не дал определение этому выражению, так, как он его понимает. Было только сравнительное определение, позволяющее говорить "более низкого уровня, чем". Но не абсолютное.
Вы хоть можете дать определение?"языком низкого уровня является язык любая из команд которого переводится в единичную инструкцию целевого процессора". Например, макроассемблер уже не является языком низкого уровня.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575196
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128, т.е. язык состоящий из мнемонических команд целевого процессора
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575217
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)"языком низкого уровня является язык любая из команд которого переводится в единичную инструкцию целевого процессора". Например, макроассемблер уже не является языком низкого уровня.
Автокод Эльбрус (от Эльбрус 1,2) - он какого уровня?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575219
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kealon(Ruslan)ptr128пропущено...

Вы уже тут N-ый, который оперирует понятием "язык низкого уровня". Но никто пока, кроме меня, не дал определение этому выражению, так, как он его понимает. Было только сравнительное определение, позволяющее говорить "более низкого уровня, чем". Но не абсолютное.
Вы хоть можете дать определение?"языком низкого уровня является язык любая из команд которого переводится в единичную инструкцию целевого процессора". Например, макроассемблер уже не является языком низкого уровня.
Рискну предположить что при таком определении у нас просто не будет образцов языков низкого уровня.
А держать классификатор ради одного ассемблера как-то неинтересно. Все равно что утконоса занести
в класс утконосов.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575226
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВсе равно что утконоса занести в класс утконосов.а потом с позором изгнать его оттуда, ибо не вполне соответствует))
феерическую чушь вы, ребята, обсуждаете, имхо))
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575228
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorych, эй бро. Легче на поворотах. Если тебе есть что сказать по сабжу - говори.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575231
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

есть ЯВУ, есть ассемблеры.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575240
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропил, ЯВУ и ассемблеры?

Мы плавно подходим к парадоксу "ложной дихотомии" .
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575265
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRockСтандарту транслятора Вирта, в котором нет указателей или чего там нет? Самому не смешно?

Я программирую на C, поэтому, одно время в UseNet, активно участвовал в разработке очередного стандарта.
Вы программируете на Pascal - Вам наплевать стандарт. Может быть именно потому у Pascal такие стандарты?А еще, это именно я виноват в том, что Делфи мертв (с).
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575268
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonkealon(Ruslan)пропущено...
"языком низкого уровня является язык любая из команд которого переводится в единичную инструкцию целевого процессора". Например, макроассемблер уже не является языком низкого уровня.
Рискну предположить что при таком определении у нас просто не будет образцов языков низкого уровня.
А держать классификатор ради одного ассемблера как-то неинтересно. Все равно что утконоса занести
в класс утконосов.ну как сказать, разновидностей ассемблеров тоже полно - так что вопрос такое определение закрывает однозначно

но в теме топика этот сабж лишний

а по теме: технология годная, вполне работает и давно, я вот бейсик любил встраивать ещё лет 10 назад, и не я один
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575314
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилptr128пропущено...

Прямое. В стандарте ISO/IEC 9899 они есть.
Кроме одинокого ключевого слова ( и то необязательного в реализации) - что нибудь есть?
Естественно, в стандарте не описано, как реализуется эта конструкция для различных архитектур. Потому что на x86 она выглядит сильно иначе, чем AVR или на ARM. Но раз стандарт позволяет мне использовать asm, то Вы это мне точно не запретите )
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575344
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Изопропилпропущено...

Кроме одинокого ключевого слова ( и то необязательного в реализации) - что нибудь есть?
Естественно, в стандарте не описано, как реализуется эта конструкция для различных архитектур. Потому что на x86 она выглядит сильно иначе, чем AVR или на ARM. Но раз стандарт позволяет мне использовать asm, то Вы это мне точно не запретите )Угу, очень переносимо между архитектурами. Главное - по стандарту!
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575347
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockУгу, очень переносимо между архитектурами. Главное - по стандарту!
А как может быть переносимым код, в котором изначально ставилась задача использовать команду x86 архитектуры, которой нет ни на AVR, ни на ARM, ни на PIC, ни, тем более в i8051?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575350
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRockУгу, очень переносимо между архитектурами. Главное - по стандарту!
А как может быть переносимым код, в котором изначально ставилась задача использовать команду x86 архитектуры, которой нет ни на AVR, ни на ARM, ни на PIC, ни, тем более в i8051?Если бы была конструкция в языке, ее реализующая (как цикл for в Паскале) - то легко.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575370
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128YuRockУгу, очень переносимо между архитектурами. Главное - по стандарту!
А как может быть переносимым код, в котором изначально ставилась задача использовать команду x86 архитектуры, которой нет ни на AVR, ни на ARM, ни на PIC, ни, тем более в i8051?
а зачем тогда словоблудить про стандарт?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575389
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропила зачем тогда словоблудить про стандарт?Как вы не понимаете?! Это же (закатив очи долу) СТАНДАРТ!
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575477
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockptr128пропущено...

А как может быть переносимым код, в котором изначально ставилась задача использовать команду x86 архитектуры, которой нет ни на AVR, ни на ARM, ни на PIC, ни, тем более в i8051?Если бы была конструкция в языке, ее реализующая (как цикл for в Паскале) - то легко.
Продемонстрируейте, как на ARM ваш Pascal станет использовать команду LOOP )))
Можете, кстати, попробовать даже на x86. В связи с тем, команда LOOP выполняется ровно столько же времени, сколько две команды DEC и JNZ, многие компиляторы ей не пользуются.
И покажите еще, как Вы на Pascal добьетесь команды nop в цикле. Мне это тоже интересно.

И пожалуйста, не занимайтесь демагогией. Поддерживаемые и не поддерживаемые конструкции языка не имеют вооще никакого отношения к теме. Речь только о том, позволяет язык получить на выходе нужный машинный код или нет.
Вот теперь Вы продемонстируйте, как Ваш компилятор позволяет сформировать предложенный Вами же код:
YuRockmov cx 5
Label1:
nop
loop Label1

И тогда, при сравнении реализаций, будет уже предметный разговор.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575485
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилptr128пропущено...

А как может быть переносимым код, в котором изначально ставилась задача использовать команду x86 архитектуры, которой нет ни на AVR, ни на ARM, ни на PIC, ни, тем более в i8051?
а зачем тогда словоблудить про стандарт?
Словоблудите пока что Вы, даже не удосужившись прочитать стандарт. Флудер? Стандарт C изначально предусматривает разную не переносимую реализацю поддержки разных архитектур. Это явно прописано в стандарте. Читайте Annex J.5
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575511
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Поддерживаемые и не поддерживаемые конструкции языка не имеют вооще никакого отношения к теме. Речь только о том, позволяет язык получить на выходе нужный машинный код или нет.Напоминает байку одного из авторов "Каисы": "Друг ответил, что программировать на PL/I легко и приятно, когда представляешь в какие машинные команды транслируются языковые конструкции. Я согласился, хотя вряд ли это можно отнести к достоинствам языка".

P.S. Я, конечно, понимаю, что профессия накладывает отпечаток и всё такое, но можно, наверное, удерживать профессиональную деформацию в разумных рамках?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575513
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128даже не удосужившись прочитать станда
Ясновидящий?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575522
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наличие ключевого слова asm в стандарте никак не поможет, если оно отсутствует в конкретной реализации.

Как и не помешает при отстутствии в стандарте при наличии в конкретной реализации.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575524
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня была дисциплина в универе "Программирование на языке высокого уровня". А язык был Си.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575551
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128команда LOOP выполняется ровно столько же времени, сколько две команды DEC и JNZ
JNZ - это только часть вычисления какого-то условия.
Пусть есть функция func, она выполняется долго - много считает. И возвращает значение в районе миллиона. Так вот, в конструкции
for I := 0 to func - 1 do begin
end;
функция func будет вызвана один раз перед меткой для loop и ее результат будет помещен в ecx.
То же самое - для любого выражения между to и do.

Как это будет реализовано на ARM, и других платформ, где нет loop - догадаться не сложно. Если действительно интересно - посмотрите сами. Мне не интересно, я кроме как для x86 и amd64 ничего не пишу.

Вообще, мне ваши хотелки порядком надоели. Я Вам ничего не должен объяснять.

Вы ведь даже ответы читать не хотите, а я писал, что nop я вставил вместо DoAnything.

Вот как на паскалях, которыми я пользуюсь, выглядит вставка nop:

asm
nop
end;

Полностью тот мой код - это запихнуть эту вставку в for I := 1 to 5

ptr128И тогда, при сравнении реализаций, будет уже предметный разговор.
У нас не было и нет предметного разговора. Я не сдержался, о чем жалею, и отметил откровенный бред про Паскаль, после чего только и делаю, что отвечаю на Ваши ответы на мои вопросы. Мне это надоело, привет, удачи.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575552
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorovпрограммировать легко и приятно, когда представляешь в какие машинные команды
В таком случае я даже хуже. Мне легко и приятно, когда я имею возможность представить все, что происходит, начиная с ЯВУ не до машинных команд, а до физики p-n перехода и полевого эффекта.
До сих пор не могу понять, как можно понять любую программу, не зная, чем RS-триггер отличается от JK и не понимая, как работает транзистор )
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575555
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockПолностью тот мой код - это запихнуть эту вставку в for I := 1 to 5

Приведите полностью текст программы и ее ассеблерный код, пожалуйста.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575557
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128До сих пор не могу понять, как можно понять любую программу, не зная, чем RS-триггер отличается от JK и не понимая, как работает транзистор )Я бы посоветовал отдохнуть, пока не потребовалось лечение.

P.S. Связь между машиной Тьюринга и программированием - могу понять, а вот связь между программой и схемотехникой - это надо сильно ушибиться чем-то тяжёлым. Работой, например.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575583
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorovptr128До сих пор не могу понять, как можно понять любую программу, не зная, чем RS-триггер отличается от JK и не понимая, как работает транзистор )Я бы посоветовал отдохнуть, пока не потребовалось лечение.

P.S. Связь между машиной Тьюринга и программированием - могу понять, а вот связь между программой и схемотехникой - это надо сильно ушибиться чем-то тяжёлым. Работой, например.
Я бы посоветовал расширить свой кругозор, чтобы не позориться. Сказано же было любую ! Вы можете понять, как работает, например, эта функция без знаний схемотехники?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SIGNAL (SIG_OVERFLOW1)
{
  if((i & 1) == 0) {
         TCNT1 = triac_open;
         PORTD &=~(1<<4);
    } else {
         TCNT1 = t10ms + triac_delay;
         PORTD |= (1<<4);
    }
  i++;
  return;
}
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575588
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

А на паскале такое нельзя что ли написать? )))
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575605
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Вы можете понять, как работает, например, эта функция без знаний схемотехники?Знаете что отличает хорошего специалиста от узкопрофильного? Чёткое понимание границ применимости собственных знаний.
Если лично вы заняты схемотехникой, это ещё не означает, что ваша тематика интересна за пределами вашего круга.

P.S. Я ещё застал времена, когда популярное изложение квантовой механики содержалось, наверное, в каждой книжке "про транзисторы". Тогда это было даже интересно.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575608
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что - понятно. Непонятно - зачемptr128
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SIGNAL (SIG_OVERFLOW1)
{
  if((i & 1) == 0) {
         TCNT1 = triac_open;
         PORTD &=~(1<<4);
    } else {
         TCNT1 = t10ms + triac_delay;
         PORTD |= (1<<4);
    }
  i++;
  return;
}

...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575615
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyЯзык низкого уровня - тот который позволяет реализовать все функции ОС на заданной платформе.

Поэтому С, С++, и даже паскаль - это все языки низкого уровня.

Точно так же язык высокого уровня - тот который позволяет писать прикладную логику не вдаваясь в детали платформы.
Поэтому паскаль, С++, и даже С - это все языки высокого уровня.

Поэтому спор ни о чем )))

вообще ЯПНУ и ЯПВУ довольно четко описаны даже в википедии

https://ru.wikipedia.org/wiki/Низкоуровневый_язык_программирования

https://ru.wikipedia.org/wiki/Высокоуровневый_язык_программирования

строго говоря даже C - это все-таки язык высокого уровня, к низкому уровню изначально относятся классы ассемблеров.

другое дело, что это определение устарело, в современном мире понятие ассемблера оно более широкое,
сам C уже называют современным ассемблером, а некоторые ассемблерами называют и MSIL и даже C# и Java, если в последних не используются runtime библиотеки.

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

говоря проще - если можно написать нечто, что может загрузиться прямо из boot loader и не требовать libstc++ - то это определенно не низкоуровневое программирование.

ну а так как как С++ компилятор не может без libstc++ даже банальный
Код: plaintext
1.
int main(void) {return 0; } 


скомпилировать, то он он по определению не может считаться ЯПНУ.

или может? понятное дело, что можно зарядить -nodefaultlibs -fno-rtti -fno-exceptions -lc, но тогда уже new/delete не доступны, это уже не C++ ни разу
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575620
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Я с 1982 года успел попрограммировать для I8048, I8051, Z80, AVR, AVR32, ESP8266, STM8 и STM32.
Почему-то вспомнилось про колчаковские фронты (с).

А так - возраст не является мерилом опыта и знаний. Можно хоть 40 лет писать код, но так и не освоить программную инженерию как таковую.

Умение мастерски класть кирпичи или плитку не делает тебя инженером-строителем или архитектором, если брать за пример реальный сектор.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575674
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchну а так как как С++ компилятор не может без libstc++ даже банальный
Код: plaintext
1.
int main(void) {return 0; } 



скомпилировать, то он он по определению не может считаться ЯПНУ.

или может? понятное дело, что можно зарядить -nodefaultlibs -fno-rtti -fno-exceptions -lc, но тогда уже new/delete не доступны, это уже не C++ ни разу
Чего вдруг компилятор не сможет скомпилировать? Сможет.
А с чем линковать это уже зависит от платформы. На любой платформе можно создать минимальный libstc++ не зависящий от ОС и стоковой libstc++.
И вовсе не нужно исключения выключать для отвязки от libstc++. Не исключения используют libstc++, а наоборот. То же самое про rtti.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575704
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchptr128Я [...] успел попрограммировать для [...] ESP8266
Почему-то вспомнилось про колчаковские фронты (с).

Я не думал, что Вам меньше трех лет )))

И зачем выдирать фразу из контекста, если это был ответ на абсолютно конкретный и прямой наезд, удаленный в последствии модератором?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575705
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovЧто - понятно. Непонятно - зачем
Ну вот и расскажите почему triac (симистором) приходится управлять именно так, не затронув вообще схемотехнику.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575706
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchесли можно написать нечто, что может загрузиться прямо из boot loader и не требовать libstc++
Вообще то я вел речь о freestanding environment, то есть, не загрузиться из boot loader, а быть boot loader.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575725
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Ну вот и расскажите почему triac (симистором) приходится управлять именно так, не затронув вообще схемотехнику.Хм, лично о тиристорах (и симисторах) помню только то, что управляются они "по току" - открыть ключ можно в любой момент, но закроется он тогда, когда ток станет меньше порога. Ничего не путаю?
Даже если я не ошибаюсь, мне всё равно непонятна логика вашей функции. Более того, могу обоснованно предположить, что логика управления будет слабо связана со схемотехникой.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575728
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но написать
Код: plaintext
1.
if((i & 1) == 0)

может только паскалист =)
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575729
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglНо написать
Код: plaintext
1.
if((i & 1) == 0)

может только паскалист =)
минимум 2 ошибки правил программирования на С
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575734
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorovptr128Ну вот и расскажите почему triac (симистором) приходится управлять именно так, не затронув вообще схемотехнику.Хм, лично о тиристорах (и симисторах) помню только то, что управляются они "по току" - открыть ключ можно в любой момент, но закроется он тогда, когда ток станет меньше порога. Ничего не путаю?
Путаете. Есть проблема четвертого квадранта. Даже если симистор четырёхквадрантный, ток его открытия в четвертом квадранте в разы больше, чем в остальных.

Basil A. SidorovДаже если я не ошибаюсь, мне всё равно непонятна логика вашей функции. Более того, могу обоснованно предположить, что логика управления будет слабо связана со схемотехникой.
Как видите, связана на прямую. Я уж не говорю о приеме и обработке сигналов, когда программным образом нужно учитывать линейные и фазовые их искажения, что тоже требует знаний схемотехники. Поэтому в проектах на микроконтроллерах программист, как минимум, принимает активное участие в разработке схемы, если даже не сам ее и разрабатывает.
Как при написании прикладной программы, у Вас периодически возникает выбор - воспользоваться готовым классом или написать свой, так и в проекте на микроконтроллере периодически возникает выбор между программной и аппаратной реализацией какой-то функции.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575737
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglSiemarglНо написать
Код: plaintext
1.
if((i & 1) == 0)

может только паскалист =)
минимум 2 ошибки правил программирования на С
Где ошибка? Четное ИСТИНА, нечетное ЛОЖЬ.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575738
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Siemarglпропущено...

минимум 2 ошибки правил программирования на С
Где ошибка? Четное ИСТИНА, нечетное ЛОЖЬ.
ну это из области, "как разоблачить советского разведчика"
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575740
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglptr128пропущено...

Где ошибка? Четное ИСТИНА, нечетное ЛОЖЬ.
ну это из области, "как разоблачить советского разведчика"
Где ошибка????
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575741
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

ложечку то вытащил, но глаз по привычке прищуривает с false сравнивает
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575744
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чтоб долго не гадал - 2я - это operator precedence

потому
Код: plaintext
1.
if (i & 1) {}
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575747
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglчтоб долго не гадал - 2я - это operator precedence

потому
Код: plaintext
1.
if (i & 1) {}


Это будет с точностью наоборот. Четное - ЛОЖЬ, нечетное - ИСТИНА.
Как вариант, можно было бы написать так:
Код: plaintext
1.
if( !(i & 1) )


Но это уже, скорее, относится к стилю, чем к машинному коду, который будет сгенерирован.

Где две ошибки? Вы скажете или нет?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575757
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

не парьтесь, тру-паскалист напишет
Код: pascal
1.
if not odd(i) then


но это лишь вопрос времени когда проходило обучение, когда-то так писали, потом так, можно эпоху становления отслеживать
а потом всё смешалось ...
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575761
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавилась электротехника.

Ставлю вопрос о переносе в Программирование.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575768
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovskydbpatchну а так как как С++ компилятор не может без libstc++ даже банальный
Код: plaintext
1.
int main(void) {return 0; } 



скомпилировать, то он он по определению не может считаться ЯПНУ.

или может? понятное дело, что можно зарядить -nodefaultlibs -fno-rtti -fno-exceptions -lc, но тогда уже new/delete не доступны, это уже не C++ ни разу
Чего вдруг компилятор не сможет скомпилировать? Сможет.
А с чем линковать это уже зависит от платформы. На любой платформе можно создать минимальный libstc++ не зависящий от ОС и стоковой libstc++.
И вовсе не нужно исключения выключать для отвязки от libstc++. Не исключения используют libstc++, а наоборот. То же самое про rtti.

да можно что угодно, можно и свою операционку с компилятором с нуля написать.
но конкретно в случае с g++ обычные, казалось-бы, языковые конструкции принудительно требуют линковку с внешней .so, как говорится - приплыли.

возможно это просто заговор трулинуксоидов, Торвальдс (с) ведь не просто так говорил про substandard coders.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575769
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Siemarglчтоб долго не гадал - 2я - это operator precedence

потому
Код: plaintext
1.
if (i & 1) {}


Это будет с точностью наоборот. Четное - ЛОЖЬ, нечетное - ИСТИНА.
Как вариант, можно было бы написать так:
Код: plaintext
1.
if( !(i & 1) )


Но это уже, скорее, относится к стилю, чем к машинному коду, который будет сгенерирован.

Где две ошибки? Вы скажете или нет?

у i, надо понимать, тип int, да?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575771
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchу i, надо понимать, тип int, да?
Не совсем. Здесь uint8_t
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575773
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchв случае с g++ обычные, казалось-бы, языковые конструкции принудительно требуют линковку с внешней .so
Тут Вы заблуждаетесь. Разрешения внешней ссылки они требуют, конечно. Но все эти внешние ссылки могут разрешаться даже в том же файле исходного текста. Ну и, само собой, в других файлах исходного текста или в статической библиотеке.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575783
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Путаете. Есть проблема четвертого квадранта. Даже если симистор четырёхквадрантный, ток его открытия в четвертом квадранте в разы больше, чем в остальных.Заметьте, что вы уже начали приписывать мне собственные проблемы. Я сказал, что открыть симистор можно в любой момент и ничего не говорил о необходимой величине тока.
Если таинственный "четвёртый квадрант" - то, о чём я думаю, то никто не открывает токовый ключ на спаде сигнала. Гораздо проще формировать управляющие импульсы по фронту с помощью дифференцирующей цепочки и диода. "По моему - так" (ц) Винни Пух.Как видите, связана на прямую.Так получилось, что в моей библиотеке есть (уже старая) книга о схемотехнике микроконтроллеров. Один из примеров книги - управление мощностью (инерционной) нагрузки. Описание оптимального алгоритма "прореживания" управляющих импульсов - помню. Упоминания проблемы "четвёртого квадранта" - нет.Я уж не говорю о приеме и обработке сигналов, когда программным образом нужно учитывать линейные и фазовые их искажения, что тоже требует знаний схемотехники.В каком месте "ключевание" симистора требует учёта "линейных и фазовых"?

P.S. Я уже упоминал о проблемах профессиональной деформации?
Или вы правда думаете, что проблемы (микро)схемотехники настолько всеобъемлющи, что затрагивают всех ?
Вам не приходило в голову, что проблемы (микро)схемотехники решают так, чтобы в дальнейшем эти проблемы уже никого не волновали?
Или вам тупо обидно: "я тут пластаюсь, а эти дармоеды даже оценить в состоянии"? Тогда успокойтесь - так и должно быть.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575784
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Где ошибка? Четное ИСТИНА, нечетное ЛОЖЬ."!(i & 1)" генерит меньше кода, если оптимизатор недостаточно умный или достаточно педантичный.

P.S. Це использует "полуторозначную логику", поэтому сравнение с нулём - избыточно в любом случае.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575805
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov"!(i & 1)" генерит меньше кода
Неужели так сложно было проверить свое утверждение, чтобы не позориться публично своим невежеством?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
   7:t7.c          ****   if ( (i & 1)==0 ) { i++; }
  19              		.loc 1 7 0
  20 000c 0FB645FC 		movzbl	-4(%ebp), %eax
  21 0010 83E001   		andl	$1, %eax
  22 0013 85C0     		testl	%eax, %eax
  23 0015 750A     		jne	L2
  24              		.loc 1 7 0 is_stmt 0 discriminator 1
  25 0017 0FB645FC 		movzbl	-4(%ebp), %eax
  26 001b 83C001   		addl	$1, %eax
  27 001e 8845FC   		movb	%al, -4(%ebp)
  28              	L2:
   8:t7.c          ****   if ( !(i & 1) ) { i++; }
  29              		.loc 1 8 0 is_stmt 1
  30 0021 0FB645FC 		movzbl	-4(%ebp), %eax
  31 0025 83E001   		andl	$1, %eax
  32 0028 85C0     		testl	%eax, %eax
  33 002a 750A     		jne	L3
  34              		.loc 1 8 0 is_stmt 0 discriminator 1
  35 002c 0FB645FC 		movzbl	-4(%ebp), %eax
  36 0030 83C001   		addl	$1, %eax
  37 0033 8845FC   		movb	%al, -4(%ebp)
...
  59 000c 474E5520 		.ascii "GNU C11 6.3.0 -mtune=generic -march=i586 -g\0"
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575810
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovЕсли таинственный "четвёртый квадрант"
Неужели так сложно открыть хотя бы Википедию , чтобы не нести чушь публично?

Basil A. SidorovИли вы правда думаете, что проблемы (микро)схемотехники настолько всеобъемлющи, что затрагивают всех ?
Я уверен обратном. Все, что я утверждаю, так это то, что в понятие " любая программа" попадают так же и программы на МК, требующие знаний схемотехники.
А вот почему это Вас так раздражает, я уже не знаю. Разве что, действительно у Вас "проблемы профессиональной деформации".
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575834
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так и не понял, в каком форуме можно вести такую дискуссию. Модератор, если что, удаляйте.

Basil A. Sidorovptr128Даже если симистор четырёхквадрантный, ток его открытия в четвертом квадранте в разы больше, чем в остальных.Я сказал, что открыть симистор можно в любой момент и ничего не говорил о необходимой величине тока.
Где Вы сказали, что ведете речь только о четырёхквадрантных симисторах? А произвольный симистор в любой момент открывать недопустимо.

Basil A. Sidorovникто не открывает токовый ключ на спаде сигнала
При чем тут спад сигнала? Вопрос идет исключительно о полярности.

Basil A. Sidorovptr128Я уж не говорю о приеме и обработке сигналов, когда программным образом нужно учитывать линейные и фазовые их искажения, что тоже требует знаний схемотехники.В каком месте "ключевание" симистора требует.
Где Вы тут увидели слово "симистор"?
Хотя даже при управлении симистором необходим детектор нуля, а фазовые искажения на нем неизбежны.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575888
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorovptr128Где ошибка? Четное ИСТИНА, нечетное ЛОЖЬ."!(i & 1)" генерит меньше кода, если оптимизатор недостаточно умный или достаточно педантичный.

P.S. Це использует "полуторозначную логику", поэтому сравнение с нулём - избыточно в любом случае.
кода столько же, проверил даже на самом глупом tcc (даже оригинал короче на 1 инструкцию ))))

и скобочки лишние, и == 0

я потому и сказал, что так пишут паскалисты - им не лень лишние буквы набирать

это и есть ошибка - ошибка в незнании св-в языка, а не в результате
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575892
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglBasil A. Sidorovпропущено...
"!(i & 1)" генерит меньше кода, если оптимизатор недостаточно умный или достаточно педантичный.

P.S. Це использует "полуторозначную логику", поэтому сравнение с нулём - избыточно в любом случае.
кода столько же, проверил даже на самом глупом tcc (даже оригинал короче на 1 инструкцию ))))

и скобочки лишние, и == 0

я потому и сказал, что так пишут паскалисты - им не лень лишние буквы набирать

это и есть ошибка - ошибка в незнании св-в языка, а не в результате
Это не ошибка, это просто не С-шный стиль написания кода
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575904
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglи скобочки лишние, и == 0
MISRA-C
Rule 12.1. In addition to the use of parentheses to override default operator precedence, parentheses should also be used to emphasise it.
Rule 13.2. Tests of a value against zero should be made explicit, unless the operand is effectively Boolean.

Siemarglошибка в незнании св-в языка
Это просто Ваше незнание MISRA-C.

ИзопропилЭто не ошибка, это просто не С-шный стиль написания кода
И Вы, видимо, не знакомы с MISRA-C и не умеете использовать С в критических системах.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575907
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

а давайте еще аду сюда приплетем, и IEC61131-3
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575913
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglptr128,

а давайте еще аду сюда приплетем, и IEC61131-3
Какая связь между адой и правилами написания программ на C, разработанные Motor Industry Software Reliability Association?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575916
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и нумерация правил у вас не соответствует misra-c 2004, Т.е ссылаетесь на устаревшую версию правил
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575918
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglи нумерация правил у вас не соответствует misra-c 2004, Т.е ссылаетесь на устаревшую версию правил
тут я неправ - но оба правила - рекомендательные

связь простая - и то и то предназначено для безопасных программ, ограничивая программиста рамками
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39575921
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglсвязь простая - и то и то предназначено для безопасных программ, ограничивая программиста рамками
А какие у программиста есть еще варианты, если большинство заказчиков явно в контракте прописывают требование о соответствии исходных текстов MISRA-C? Во-первых, MISRA-C, де-факто, ими воспринимается стандартом. Во-вторых, проверки всех правил осуществляются автоматически и не требуют от них никаких усилий.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39576036
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchда можно что угодно, можно и свою операционку с компилятором с нуля написать.
но конкретно в случае с g++ обычные, казалось-бы, языковые конструкции принудительно требуют линковку с внешней .so, как говорится - приплыли.

Ггггг. Да, ни с чем кроме .SO объектники G++ не связываются. Все именно так ))))
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39576091
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128Все, что я утверждаю, так это то, что в понятие " любая программа" попадают так же и программы на МК, требующие знаний схемотехники.Не надо, в общем, делать ложных индукций: процент программистов, которым требуется понимать каждую из "любых" программ - ровно ноль.
В сухом остатке: когда (если) я начну косячить на вашем проекте - можете воспитывать меня материально и унижать морально. А до той поры - идите лесом в пешее эротическое путешествие.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39576195
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorovptr128Все, что я утверждаю, так это то, что в понятие " любая программа" попадают так же и программы на МК, требующие знаний схемотехники.Не надо, в общем, делать ложных индукций: процент программистов, которым требуется понимать каждую из "любых" программ - ровно ноль.
А я разве утверждал где-то иное?


Basil A. SidorovВ сухом остатке: когда (если) я начну косячить на вашем проекте
А не фиг было оскорблять и хамить:
Basil A. SidorovЭто же (закатив очи долу) СТАНДАРТ!
удерживать профессиональную деформацию в разумных рамках
Я бы посоветовал отдохнуть, пока не потребовалось лечение.
это надо сильно ушибиться чем-то тяжёлым.
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39576209
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128А я разве утверждал где-то иное?"Для понимания любой программы требуется знание схемотехники" - ваши слова? Выделено мною.А не фиг было оскорблять и хамить:
Это же (закатив очи долу) СТАНДАРТ!
удерживать профессиональную деформацию в разумных рамках
Я бы посоветовал отдохнуть, пока не потребовалось лечение.
это надо сильно ушибиться чем-то тяжёлым.О как ... Первая строчка была не вам. Но, согласен, вы могли принять её и на свой счёт.
Что касается всего остального ...
Лично меня нисколько не ломает или написать "Был неправ в том-то и том-то" или просто промолчать, если писать лень. Но именно лень - никому не зазорно признать свои ошибки.
Вы же начали, фигурально выражаясь, кидаться какашками из четвёртых квадрантов и задержек - ну и какой ответной реакции вы ожидали? Что я стану шерстить интернет, чтобы устыдиться: "Чувак-то, оказывается нехило так разбирается во всех этих эмпиреях"?
Нафиг мне всё это упало, если я плохо помню, что лежит в основе переключения тиристора - туннельный эффект, лавинный пробой или что ещё?
...
Рейтинг: 0 / 0
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39576212
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Модератор:
Сраца и офффтопик разводить будете в других местах. Предлагаю форум "Просто Трёп".
Адрес надеюсь знаете.
...
Рейтинг: 0 / 0
184 сообщений из 184, показаны все 8 страниц
Форумы / C++ [игнор отключен] [закрыт для гостей] / Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]