Для этого есть функция IBM: (строка) IBM Knowledge Center[^], (chars) IBM Knowledge Center[^] Но они потребуют нестандартных библиотек IBM,к которым у вас, вероятно, не будет доступа. Что вполне логично, поскольку почти единственными людьми, которые когда-либо использовали EBCDIC, были IBM ... :смеяться:
Честно говоря, это довольно тривиальное преобразование: два массива по 255 символов, один из которых организован индексом ASCII, а другой-EBCDIC, сделают это очень просто: IBM Knowledge Center[^]
Но мне очень интересно узнать, какое чертово оборудование все еще работает, которое все равно использует EBCDIC? :D
Наш хост работает на мэйнфрейме IBM, которому нужны данные в том же формате :P
Боже мой. Он все еще принимает перфокарты? :смеяться:
Виртуальные машины IBM имеют устройства чтения виртуальных карт. И удары. Я знаю одну большую компанию, которая существует уже много лет. Они просто продолжают "копировать" материал каждый раз, когда создается новое подразделение (по крайней мере, один раз в год).
Это будет для кода Кобола, от которого они не могут уйти? :смеяться:
Цитата:Есть ли какая-либо встроенная функция в c для преобразования значения ascii в ebcidic?
Цитата:или нам нужно написать функцию самостоятельно?
Стратегия для вас - альтернатива функции - может быть, просто для размышления - но, возможно, то, что вам нужно.
Создайте 256 - байтовый массив. Предположим, что индекс массива является значением ASCII исходного символа. Установите для каждого значения значение EBCDIC. Теперь вместо вызова функции вы можете транскрибировать массив, прокручивая входные данные в виде значений ASCII и записывая значение, присвоенное этому индексу, в новую строку.
В конечном счете, как бы вы это ни делали, каждый символ должен быть адресован - это пропускает накладные расходы на вызов функции, а вместо этого использует список поиска, который обычно очень быстр.
Почему функция, которая переводит строку, так плоха? И извините, имейте в виду сухо. Ни одного голоса с моей стороны, даже если бы это принесло что-то между 1 и 3!
Ни то, ни другое не плохо - но если бы это было сделано много, каждый вызов функции имел бы накладные расходы, такие как нажатие и выскакивание значений стека. Теперь, если это скомпилировано, функция может быть встроена и сделать это в любом случае.
Это просто экономит накладные расходы, но требует, чтобы вы кодировали цикл вместо вызова функции с входным и возвращаемым значением.
Внутренне, так или иначе, вы будете использовать концепцию таблицы поиска в функции.
"Внутренне, так или иначе, вы будете использовать концепцию таблицы поиска в функции": Я согласен. Ок а 4 :(
Спасибо. Я довольно старомоден и привык делать различные приложения для численного моделирования. Часто" звонок" происходил десятки миллионов раз. Это действительно складывается с функциями против встроенных. Вспомните также, насколько медленнее были процессоры. Так что - привычка вроде прилипает - не причиняет никакого вреда, если это одноразовое событие.
Подумайте о порядке клевания эффективности:
Прямое встроенное преобразование
Функция-преобразование через входные строки
Функция-преобразование, символ за раз.
Последнее, очевидно крайнее, подчеркивает суть - хотя я совершенно уверен, что вы уже поняли ее. Когда-нибудь, возможно, он вам даже понадобится.
"Я довольно старомоден": то же самое и здесь :)