LINUX.ORG.RU

А куда, если не в веб?

 , ,


3

4

Хай, Лор. Давно сюда не писал, многое поменялось, многое перепробовал.

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

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

Подскажите, есть ли истории успеха? Что-то алгоритмическое/техническое? Буду рад всем отписавшимся по вопросу.

Ответ на: комментарий от Alve

Знаем мы, около десятка знаем товарищей, живущих по рабочей визе на съёмных полупустых квартирах в Германии

Учитывая, что все немцы много пердят – полупустая квартира скорее плюс. Больше воздуха разбавить вонь.

anonymous
()
Ответ на: комментарий от seiken

Нафиг Лазарь сдался практикующему плюсисту - не понятно.

Плюсы говно ширпотребное. А Дельфа и Лазарь – тема промышленная. Мамкиному хелловордщиу или веб-макаке проще будет на плюсах, это да.

anonymous
()
Ответ на: комментарий от alysnix

легким движением си компилятор можно переделать на вашу нотацию правкой в паре строк кода, не затронув более ничего. и тогда ЭТОТ язык по вашему стразу станет достойным для освоения программирования?

Станет. Но не стал же. Дывыйта я просто буду зыманять букве в такста, которай пишу. Удобан ли будат тыкой такст для обучания?

Конечно нет, ублюдочная нотация ставит крест на языке для начинающего, как надпись XYZ на портрете Мона Лизы ставит с ног на голову всё восприятие картины, даже несмотря на то, что большая часть картины не изменилась. Это потом, когда обучающийся освоится с алфивитом, он сможет проникнуться в структуры данных, во взаимодействие управляющих структур, и там тоже можно поговорить про вещи, подходящие и не подходящие для обучения.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

для начинающего, если он хочет потом продолжать, нужен сишарп. он и простой и модули в нем есть и нормальное ооп, и мусор соберет. и освоив его, можно как минимум на нем что-то строить.

даже облагороженный ‘:=’ си непригоден для старта. верней пригоден, как соскок с ассемблера, или для тех, что хочет позаниматься микроконтроллерами и железом, а не базами и вебом.

скриптовые языки непригодны, они не дают реального понимания того, что происходит «внизу».

функциональные - это для ценителей.

православный паскаль с ‘:=’ искаропки, пригоден только для совсем старта, потому что его придется потом бросать и переучиваться на сишный синтаксис с неправославным присваиванием и фигурными скобками.

alysnix ★★★
()
Ответ на: комментарий от alysnix

для начинающего, если он хочет потом продолжать, нужен сишарп. он и простой и модули в нем есть и нормальное ооп, и мусор соберет. и освоив его, можно как минимум на нем что-то строить

Как ты думаешь, почему MS создает столько новых альтернативных языков под CLR, да и сам C# постоянно дорабатывает, если он «и простой, и модули в нем есть, и нормальное ООП, и мусор соберет»?

даже облагороженный ‘:=’ си непригоден для старта. верней пригоден, как соскок с ассемблера, или для тех, что хочет позаниматься микроконтроллерами и железом, а не базами и вебом.

Если в рамках облагораживания присваивания вынести из языка еще и вот это «a = b = c == d()», то получится вполне терпимый язык для фортраноподобных алгоритмов, то есть, без динамической памяти и без строк.

скриптовые языки непригодны, они не дают реального понимания того, что происходит «внизу»

У вас его тоже нет, и что? Авось не всю жизнь скрипты писали.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

У вас его тоже нет, и что? Авось не всю жизнь скрипты писали.

я меня есть. даже не сомневайтесь :)

alysnix ★★★
()
Ответ на: комментарий от gedisdone

И много ли на бэке фриланса?

Да.

девопс

Это так сейчас админы зовутся?

Нет.

Gentooshnik ★★★★★
()
Ответ на: комментарий от seiken

Нафиг Лазарь сдался практикующему плюсисту - не понятно.

Ну строго говоря, не Лазарь, а fpc, Лазарь - всего лишь IDE над ним. Итак:

  1. Модули (см. выше). Когда C++20 доберётся до ширнармасс в полном объёме, вероятно, будет неактуально.

  2. Стандартизованный файл проекта. Исходники на фрипаскале/дельфи самодостаточны. У них есть чётко выделенный главный модуль, он же файл проекта, им во многих случаях не нужна «левая» система сборки. Это развитие вопроса с модулями, возможно, к следующему стандарту Комитет дозреет, а пока практикующие плюсисты давятся императивными костылями типа cmake. Уже много лет давятся.

  3. Локальные функции. Начиная с C++11, появились лямбды, в т.ч. повторно используемые, и похоже, что они таки заменяют этот механизм, но выглядит это куда более вырвиглазно, чем в паскале.

К «чистому» C++ с STL есть и ещё ряд претензий, но Qt позволяет их обходить (как в ряде случаев и вопрос с системой сборки, лол).

А так-то да, если практикующий плюсист приучился всё перечисленное терпеть и обходить, ему не нужен ни паскаль, ни раст, ни вообще какой-либо другой ЯП (ну, кроме, может быть, кусочков ассемблера в крайне редких случаях).

На C++ можно написать всё! Насколько удобно — другой вопрос.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 3)
Ответ на: комментарий от hobbit

На C++ можно написать всё!

Нет, это на С можно написать всē. А на крестах - чуть поменьше. Вообще же, вся эта крестовая муть в реале нужна в полутора приложениях. И если GUI'ней не страдать, то можно даже длинной палкой С++ не касаться никогда!

anonymous
()
Ответ на: комментарий от evgeny_aa

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

Знаком с двумя людьми, которые сидя в одной конторке имели оклад, про который никогда не слышали абсолютно все, кто сидит здесь. Я бы сказал, что нынче просто есть возможность прыгать по конторам и не попадать в отстойник, которые популярны в какой-нибудь японии, где приходя на новое место работы тебе дают вилку и отправляют говно чистить «пар лет будешь на испытании, а там посмотрим, можно ли тебе ответственную работу давать» — таким образом прыгая по конторам ты будешь получать худшую и низкооплачиваемую работу. Естественно, СНГ - не Япония.

byko3y ★★★★
()
Ответ на: комментарий от hobbit

На C++ можно написать всё! Насколько удобно — другой вопрос.

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

alysnix ★★★
()
Ответ на: комментарий от hobbit

только там нет ни одного арма, и архитектуры староваты. такое впечатление что писалось это где-то не позже конца 90х - начала 2000х.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Так-то редкие архитектуры/платформы это одно из главных преимуществ Паскаля, это тебе не LLVM где делают лишь то, что нужно бизнесу, попутно выпиливая всё что ненужно, типа PPC Mac Os X…

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Так-то редкие архитектуры/платформы это одно из главных преимуществ Паскаля, это тебе не LLVM где делают лишь то, что нужно бизнесу, попутно выпиливая всё что ненужно, типа PPC Mac Os X…

эти платформы поумирали давно, кроме неувядающего интела. может и были на слуху, как редкие, лет 20 назад. а сегодня они уже скорее мертвые.
все эти платформы и gcc поддерживает. как память о далеком прошлом

alysnix ★★★
()
Ответ на: комментарий от alysnix

только там нет ни одного арма

В README упоминаются. Правда, сборок отдельных я действительно не увидел.

А вот для FPC 3.0.2 сборки есть, кстати.

И вот ещё инструкция для малинок из оф-вики.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Ну вот я в свое время ушел с Pascal на C++ потому, что C++ позволял мне делать то, чего не хватало в языке/библиотеке, а Pascal – нет. И, подозреваю, за прошедшие почти 30 лет ничего в лучшую для Pascal сторону и не изменилось.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

За 30 лет в языке многое таки изменилось. Начать с того, что есть свободные реализации того, что было только в виде проприетарщины у Борланда. И сам язык развивался.

C++ позволял мне делать то, чего не хватало в языке/библиотеке, а Pascal – нет.

А можно пример того, что не позволял Pascal?

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

А можно пример того, что не позволял Pascal?

встречный вопрос - а UML в паскаль умеет? и пара утверждений. либ на с++ больше, чем позволяет охватить человеческий разум, а вопрос кроссразработки на паскале вполне себе открытый. на плюсах это поддерживается огромным сообществом, а на паскале - группой энтузиастов, причем выданные ими тулзы и сборки явно мало кто тестировал. Брать это для кроссразработки - самоубийство, даже если платформа объявлена поддерживаемой.
Там внутри могут быть такие баги, что угробят проект на стадии, когда уже пройдена точка невозврата.

alysnix ★★★
()
Ответ на: комментарий от hobbit

А можно пример того, что не позволял Pascal?

Из того что осталось в памяти со времен 1990-1991гг: не было возможности определить свою функцию с переменным количеством аргументов, не было возможности переопределять операторы. Поэтому, скажем, в C++ я мог написать собственные классы Set и Matrix, а в Pascal-е – нет. Ну и обобщенного программирования в Pascal-е долго не было.

eao197 ★★★★★
()
Ответ на: комментарий от alysnix

Нет. Не все. gcc также удаляет старые платформы, например скоро удалит Itanium: https://www.phoronix.com/scan.php?page=news_item&px=Intel-IA-64-GCC-Deprecation

Например, для dos 16 bit, есть только gcc-6, https://github.com/tkchia/gcc-ia16 (для dos 32bit, есть порт djgpp gcc 9.2)

для Win16 я вообще не знаю есть ли такой gcc, но точно Win16 поддерживает digital mars, но это достаточно старый и мёртвый компилятор.

Для Commodore 64, я не знаю насколько актуальный компилятор C/C++ существует…

Плюс, даже если для этих древних платформ находится компилятор, то нужно ещё и находить библиотеки. А стандартная библиотека в pascal чуть побольше, чем у С или С++(особенно древних версий С++).

Так что для just for fun ретро проектов free pascal хорош.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

just for fun я бы писал роботов на stm32 или армах. чтобы бегали и прыгали…
а комодор - это какой-то особенный винтаж для бабушек :)

alysnix ★★★
()
Ответ на: комментарий от alysnix

только там нет ни одного арма

Поддержка ARM есть в предудущем стабильном: https://sourceforge.net/projects/freepascal/files/Linux/3.0.2/

и архитектуры староваты. такое впечатление что писалось это где-то не позже конца 90х - начала 2000х

Каких архитектур не хватает?

byko3y ★★★★
()
Ответ на: комментарий от eao197

Из того что осталось в памяти со времен 1990-1991гг…

в 2020 кое-что появилось:

функция с переменным количеством аргументов: http://rosettacode.org/wiki/Variadic_function#Free_Pascal

переопределение операторов(free pascal это тоже может, просто у embarcadero пример лучше написан): http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Operator_Overloading_%28Delphi%29

какой-то поддержки в языке для метапрограммирования нет, хотя возможно это я не знаю…

generics: https://wiki.freepascal.org/Generics

сериализация: https://wiki.lazarus.freepascal.org/Streaming_components

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Каких архитектур не хватает?

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

alysnix ★★★
()
Ответ на: комментарий от eao197

Во фрипаскале сейчас даже перегрузку операций сделали, оказывается. Хотя по совести говоря, это синтаксический сахар.

hobbit ★★★★★
()
Ответ на: комментарий от alysnix

а UML в паскаль умеет?

В какую сторону? Реверсить из паскалевского кода в диаграммы умеет ESS-Model. Про кодогенерацию не знаю.

и пара утверждений

И никакой конкретики, аргументация на уровне «у паскаля сообщество меньше, значит брать его — самоубийство». Другими словами - Так Здесь Принято.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

И никакой конкретики, аргументация на уровне «у паскаля сообщество меньше, значит брать его — самоубийство».

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

alysnix ★★★
()
Ответ на: комментарий от fsb4000

какой-то поддержки в языке для метапрограммирования нет, хотя возможно это я не знаю

Обобщения - это и есть метапрограммирование. В FPC 2.2.0 уже было, 2007 год.

byko3y ★★★★
()
Ответ на: комментарий от alysnix

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

Контроллеры точно пишут на FPC, отсюда и поддержка всяких MIPS/Raspberry.

byko3y ★★★★
()
Ответ на: комментарий от alysnix

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

Тут недавно был тред про strict aliasing и volatile с моим участием, я показывал на конкретных примерах, как эти фичи превращают работу с железом в ад (а именно - некорректные оптимизации), и почему в FPC такой проблемы не существует в принципе. А дело в том, что паскаль писался человеком, который корову съел на создании компиляторов, потому писать компилятор под паскаль очень удобно и нет необходимости совершать некорректные оптимизации над глобальными данными, потому что они обычно явно объявлены локальными.

такие случаи были в личной практике даже с gcc

Мне было бы интересно узнать, какие конкретно проблемы были с GCC.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

а вы лично сколько написали компиляторов?

alysnix ★★★
()
Ответ на: комментарий от byko3y

Мне было бы интересно узнать, какие конкретно проблемы были с GCC.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

а вы лично сколько написали компиляторов?

Ноль. Максимум, что у меня было в этой сфере - это рекурсивный парсер и интерпретатор простых выражений с трансляцией в постфиксную форму.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ноль. Максимум, что у меня было в этой сфере - это рекурсивный парсер и интерпретатор простых выражений с трансляцией в постфиксную форму.

Вот. А я 2 с половиной примерно. поэтому вот эта ваша фраза неверна.

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

a volatile(или его аналог) в системном языке необходим, поскольку ЯВНО указывает компилятору, что переменная может поменяться внезапно, нарушив инварианты графа потока исполнения. вот нет ни одной команды, что могла бы ее поменять, а она может поменяться. например если это отображение на порт ввода-вывода, или переменную меняют из прерывания или паралельного треда. и тут никакой язык не причем. это проблема оптимизации. опять же,тут неважно локальная это переменная или нет. локальную переменную тоже можно сделать доступной для паралельных активностей, передав ее адрес. достаточно часто volatile объявляются поля класса, если к ним возможен паралельный доступ.

alysnix ★★★
()
Ответ на: комментарий от alysnix

a volatile(или его аналог) в системном языке необходим, поскольку ЯВНО указывает компилятору, что переменная может поменяться внезапно

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

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

Этой проблемы не существует в паскале, где компилятор может сам из исходного кода выяснить, когда переменная может измениться внезапно, а когда - не может:
https://forum.lazarus.freepascal.org/index.php/topic,38961.msg266921.html#msg...
Ссылка уже была в прошлом обсуждении: О божественном C и введение в него через ed (комментарий)

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

Могут меняться ссылки на непонятно что в однопотоке (например, через callback-и). А в многопоточном приложении абсолютно все экспортируемые глобальные переменные могут меняться «внезапно». Твоя программа не работает с нашим компилятором? Ну скомпилируешь с другим.

и тут никакой язык не причем. это проблема оптимизации

Нет, это как раз проблема конкретного отсутствия поддержки оптимизации в конкретном языке Си.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

никакая «модель модулей» не может ничего сокрыть, если экспортируется функция типа (это типа псевдопаскаль)

func ff(): ^int { return address(HiddenIntVar); }

адрес любой скрытой переменной можно выдать наружу, и компилятор это не поймет.

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

alysnix ★★★
()
Ответ на: комментарий от byko3y

так. повнимательно почитал дискуссию по интераптам в паскале… ну знаете… там явно указан обработчик прерывания в этом же модуле. компилятор просто все использованые в обработчике переменные модуля считает волатильными и все. это простейший случай.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

никакая «модель модулей» не может ничего сокрыть, если экспортируется функция типа (это типа псевдопаскаль)
func ff(): ^int { return address(HiddenIntVar); }

Ты правильно заметил — это не паскаль.

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

Который в данном случае для паскаля будет читаться/писаться по семантике, аналогичной «volatile» ANSI C. Автоматически и без вмешательства программиста. Ручное описание доступа в данном случае — это приглашение к написанию ошибок.

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

Откуда асм возьмет адрес переменной? Если кто-то где-то его взял — это семантика, аналогичная «volatile». Если нет, то и адреса у переменной никакого нет — ее можно хранить в регистре.

byko3y ★★★★
()
Ответ на: комментарий от alysnix

вот пусть они заведут глобальную переменную в одном модуле, в другом напишут использующую ее функцию

Это будет семантика «volatile» уже здесь. Пример по ссылке был с кодом в единственном главном модуле программы, но экспорт переменной через интерфейс вторичного модуля автоматом как бы ставит «volatile» для этой переменной.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Это будет семантика «volatile» уже здесь. Пример по ссылке был с кодом в единственном главном модуле программы, но экспорт переменной через интерфейс вторичного модуля автоматом как бы ставит «volatile» для этой переменной.

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

короче пусть вводят волатильность и не парятся. смогут оптимизировать код лучше, чем сейчас.

alysnix ★★★
()
Ответ на: комментарий от byko3y

ихнюю систему «защиты» можно сломать так. внутри модуля есть глобальная неэкспортированная переменная Var. и экспортируется функция Func() что ее меняет. а внутри модуля другие функции эту Var используют.

… так вот. если в каком-то еще модуле я вызову эту Func() внутри обработчика, то Var должна быть волатильной, а если вызову в обычной функции - то не должна. и как компилятор поймет что Var волатильна? не забываем, что Func() может Var менять неявно, через несколько вызовов еще каких-то внутренних функций. ничего компилятор не поймет, и все радостно рухнет. то есть такая модель наивна и не работает.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

«Обычное десктопное приложение» на Windows всегда многопоточно, для справки.

Что может дать гарантию, что переменная, экспортированная без volatile, никогда не будет использована, например, другим потоком? А ее нет пока переменная экспортирована, и программист должен выяснять факт использования сам вручную, и повторять это заново при появлении нового кода в проекте. Как я уже писал, volatile — это приглашение к написанию ошибок. Ровно как и strict aliasing.

Вы, сишники, решительно забываете, что смысл volatile на самом деле находится там, где его нет, а не там, где он есть. То есть, в агрессивной оптимизации. И по этой причине не объясняете, почему такая оптимизация вообще имеет право быть в 2020 году. Я в том треде давал сам ответ на этот вопрос:
О божественном C и введение в него через ed (комментарий) а именно — не имеет право существовать, потому что ее влияние на производительность ничтожно. Там же я писал, volatile приводит к бессмысленным деоптимизациям переменных, которые гарантировано никогда и нигде больше не будут прочитаны, что есть вторая сторона сторона войны оптимизаторов с программистами.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

О божественном C и введение в него через ed (комментарий) а именно — не имеет право существовать, потому что ее влияние на производительность ничтожно.

тут вы ничего нового не открыли. волатильные переменные всегда располагаются в памяти, и не отображаются на регистры. почему? потому, что только в памяти они будут доступны для паралельной активности. а необходимость этого обьявлена через volatile. просто не надо неволатильную переменную объявлять волатильной. аналогично не надо в паскале обьявлять обычную функцию обработчиком прерываний, в с++ невиртуальный деструктор виртуальным, и все такое…

alysnix ★★★
()
Ответ на: комментарий от alysnix

ихнюю систему «защиты» можно сломать так. внутри модуля есть глобальная неэкспортированная переменная Var. и экспортируется функция Func() что ее меняет. а внутри модуля другие функции эту Var используют

Нет, нельзя взломать так. В частности, как минимум в Delphi есть такое мерзопакостное явление, что достаточно сделать «uses Classes;» — и твое приложение раздувается на 500 КБ за счет того, что у него в экспорте есть классы с неубираемым Run-Time Type Information, которое по цепочке вытягивает все функции и переменные. Нужно понимать, что это не наспех состряпанный костыль аки Си, а тщательно продуманный наследник языка Модула. Так что как только шквара экспорта достигает переменную — она становится «volatile».

И вернуть адрес неэкспортированной переменной из экспортированной функции не получится, потому что взятие адреса сделает ее «volatile». И даже передача обычной функцие аргумента по ссылке (не сам указатель) сделает значение volatile внутри функции с этим аргументом — только в inline функциях получится целиком избавиться от этого статуса.

byko3y ★★★★
()
Ответ на: комментарий от alysnix

волатильные переменные всегда располагаются в памяти, и не отображаются на регистры. почему? потому, что только в памяти они будут доступны для паралельной активности. а необходимость этого обьявлена через volatile

Я писал о том, что влияние volatile на производительность ничтожно, а не о том, где ее нужно и где не нужно писать. Какая разница где нужно писать то, что не имеет значения?

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.