Просто бывает интересно именно восстанавливать вещи, не собирая новое в старом корпусе. У меня не такой большой опыт, вот и прикидываю, как надо делать сопряжение. Если у 176 серии слабые выходы, то по транзисторному каскаду на каждый выход?
Да не, по большому счету я согласен, что Фортран не так удобен для работы с аппаратурой — не тот инструмент просто.
Но все то же сделать можно, пусть и непривычным путем, кмк.
То что С для работы с бинарными данными и для побитовых операций вне конкуренции, сомнений не вызывает.
Тот же Delphi имеет такой же функционал по этой части.
Мне нужно было с аудиокарты данные получать, делать преобразование Фурье, совершать какие-то манипуляции с составляющими, делать обратное преобразование и выдавать обратно на аудиокарту — и все это с минимальной задержкой
Эквалайзер?
В Фортране, если я правильно помню, есть быстрые библиотечные реализации дискретных FFT (Intel FC).
и сделал все на Дельфи
Так если на Дельфи написано, то все равно через Win интерфейс идет работа. Не напрямую же с аппаратурой.
а то и на готовые семисегментные сборки. Да только вот же незадача — это выглядит уже совсем не так… осовремененно и оттого попсово выглядит, я бы сказал.
Вы странные вещи говорите.
Если отложить в сторону «какой кому синтаксис нравится». Чем тот же Си лучше Фортрана при работе с периферией?
Я имею в виду — все равно все через библиотеки внешние идет. И нет никакой разницы — подключить библиотеку к Си или к Фортрану.
Нужно вам, например, с драйвером пообщаться в Win32. Вы вызываете DeviceIoControl из kernel32.dll. Какая разница, lib со stub'ами к Си прилинковать или к Фортрану?
«верифицировать исправление ошибки» (== доказать ее исправление),
«верифицировать» != «доказать» в данном контексте. Доказать могу я, разработчик. Мол, смотри, раньше делали так и так и получали AV, теперь — все чисто, а в коде это выглядит вот так и так. Таки мобразом, я доказал исправление ошибки. (да и слово «исправление» можетозначать незаврешенный процес — в таком случае я докажу, что я исправлял ошибку, т.е. доказал исправление, т.к. «исправление» имеет 2 смысла) А тестировщик может verify, т.е. подтвердить, что это действительно так, что процесс завершен.
«verify» имеет коннотацию «провести собственное исследование-тестирование и подтвердить, что ошибка исправлена», а «подтвердить исправление» — нет. По крайне мере, мое чувство языка мне так подсказывает.
А тут соглашусь. «Ошибка» — гораздо более узкое и конкретное понятие.
Мне, напротив, кажется, что «ошибка» — более широкое понятие. Например, опечатка в сообщении — ошибка, а отказ в обслуживании — результат bug'а. (он же — логическая ошибка, например).
Слово «Верификация» в русском языке есть уж минимум полсотни лет (а скорее всего и больше) и корни у него латинские, а не англоязычные.
Так lexx2real именно о «верифаить» сказал.
Язык свой надо лучше знать, тогда вместо калькирования всех незнакомых слов внезапно окажется, что у половины из них есть вполне благозвучные и подходящие аналоги.
У половины. Именно.
А «верифаить», на мой взгляд — это исключительно от безграмотности, а не от того, что много ИТ-терминов кальки, с чем я и не спорю…
Не обязательно от безграмотности. Тут вопрос привычки тоже играет большую роль. Как я указывал выше, основной язык в IT сфере — английский, множество статей, документации, обсуждения на форумах ведутся на английском. Поневоле какие-то слова «впечатываются». Кто-то, как я, например, работает к тому же в англоязычном коллективе, это еще сильнее усугубляет проблему.
Плюс, что еще важнее — у некоторых слов есть _коннотация_. И это очень, очень важно. Например, то же «верифаить», являясь по сути безграмотной калькой, тянет за собой незримый абзац смысла — о процессе тестирования, о том, как кооперируются разработчики и тестировщики и пр. А слово «подтвердить», являясь точным аналогом, тем не менее коннотации не имеет. Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный. Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).
Отсутствие затрат на копирование должно покрывать такой overhead.
Но все то же сделать можно, пусть и непривычным путем, кмк.
Тот же Delphi имеет такой же функционал по этой части.
Эквалайзер?
В Фортране, если я правильно помню, есть быстрые библиотечные реализации дискретных FFT (Intel FC).
Так если на Дельфи написано, то все равно через Win интерфейс идет работа. Не напрямую же с аппаратурой.
Можно заменить другим.
100 лет назад, когда писал на фортране, связка ассемблер+фортран+линкер вполне работала.
Речь же не о написании драйверов.
Какой именно части? Что вам кажется неудобным?
Естественно. Win — не rtos.
Отнюдь.
Я имею в виду не средства, встроенные в язык, а способ записи;
Верно.
Если отложить в сторону «какой кому синтаксис нравится». Чем тот же Си лучше Фортрана при работе с периферией?
Я имею в виду — все равно все через библиотеки внешние идет. И нет никакой разницы — подключить библиотеку к Си или к Фортрану.
Нужно вам, например, с драйвером пообщаться в Win32. Вы вызываете DeviceIoControl из kernel32.dll. Какая разница, lib со stub'ами к Си прилинковать или к Фортрану?
Вполне сродни приведению через нетипизированный указатель в других языках.
Это понятно. Всему свое место.
Надо. Это по-своему хорошее средство, если не злоупотреблять.
Например?
«верифицировать» != «доказать» в данном контексте. Доказать могу я, разработчик. Мол, смотри, раньше делали так и так и получали AV, теперь — все чисто, а в коде это выглядит вот так и так. Таки мобразом, я доказал исправление ошибки. (да и слово «исправление» можетозначать незаврешенный процес — в таком случае я докажу, что я исправлял ошибку, т.е. доказал исправление, т.к. «исправление» имеет 2 смысла) А тестировщик может verify, т.е. подтвердить, что это действительно так, что процесс завершен.
«verify» имеет коннотацию «провести собственное исследование-тестирование и подтвердить, что ошибка исправлена», а «подтвердить исправление» — нет. По крайне мере, мое чувство языка мне так подсказывает.
Мне, напротив, кажется, что «ошибка» — более широкое понятие. Например, опечатка в сообщении — ошибка, а отказ в обслуживании — результат bug'а. (он же — логическая ошибка, например).
Так lexx2real именно о «верифаить» сказал.
У половины. Именно.
Не обязательно от безграмотности. Тут вопрос привычки тоже играет большую роль. Как я указывал выше, основной язык в IT сфере — английский, множество статей, документации, обсуждения на форумах ведутся на английском. Поневоле какие-то слова «впечатываются». Кто-то, как я, например, работает к тому же в англоязычном коллективе, это еще сильнее усугубляет проблему.
Плюс, что еще важнее — у некоторых слов есть _коннотация_. И это очень, очень важно. Например, то же «верифаить», являясь по сути безграмотной калькой, тянет за собой незримый абзац смысла — о процессе тестирования, о том, как кооперируются разработчики и тестировщики и пр. А слово «подтвердить», являясь точным аналогом, тем не менее коннотации не имеет. Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный. Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).