Ну смотрите, задача Буду признателен если вы скажете как ее можно решить без единого каста )
Есть функция передачи некоего буфера чаров по каналу связи. И по этому каналу могут передаваться 10 разных типов структур скажем...
Или вот еще - есть проект с весьма ограниченными ресурсами по ОЗУ. Поэтому создан глобальный буфер скажем buftmp. В некоторой функции мне надо создать локальную переменную типа ololo_type размером скажем 100 байт.
что я делаю?
В Pascal'е есть конструкция, аналогичная union в языке C, - запись с вариантами. Она позволяет отобразить несколько разных структур на одну область памяти.
Это позволит решить обе задачи - и с передачей разных структур по каналу, и с повторным использованием глобального буфера для разных нужд. И при этом синтаксис останется достаточно выразительным.
P.S. Кстати, работа с указателями там тоже имеется. В самом языке отсутствуют некоторые вольности в обращении с ними вроде адресной арифметики, но в конкретных реализациях обычно есть расширения, позволяющие делать и это (хотя это вряд ли идет на пользу программе, но принципиальная возможность есть).
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
Ну я не говорю что в паскале этого нет - мой пост был адресован тов. Satyr, который утверждал что использовать касты и указатели моветон
Однако union в данном случае не очень подходит. Ибо мне надо в функции создать динамически структуру в глобальном буфере, которая сдохнет вместе в функцией, а не содержать огроменный union со всеми возможными структурами. Помимо этого часто нужно использовать буфер со смещением, скажем чтоб разместить в нем две структуры.
Опять же для подобных хаков есть лазейки в конкретных реализациях. Например, в TurboPascal это операция поименования @ (аналогичная & в C), аналогичная псевдофункция Addr(), нетипизированный ссылочный тип Pointer (аналог void *) и пр. В диалектах языка для PDP-11, VAX-11, Z80 и др. были свои аналогичные средства с другим синтаксисом. Буду очень удивлен, если их не окажется в диалекте для AVR.
Конечно, эти не описанные в стандарте Вирта дополнения языка не унифицированы и уникальны в каждой реализации, поэтому ни о какой переносимости такого кода речи быть не может (хотя далеко не всем это реально нужно). Но если задаться целью как следует побезобразничать в коде, то на Pascal'е это получится с тем же успехом, что и на C, - есть все необходимое.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
Я понятия не имею, что делает эта конструкция на Си
Берем указатель (&x) на float (Real в Паскале), после чего преобразуем его к указателю на int (int*), после чего обращаемся к нему как к массиву ( [] ), беря первый элемент ( [0] ), т.е., вынимаем первые два байта представления float.
У раздолбаев такое распространено не только в эмбеддиде
Даже мне как заядлому сишнику страшно на это смотреть ))
Говорите что хотите, а меня от таких конструкций просто прет. Хотя пихать их куда попало, конечно, не надо.
дааааа )))) жуть ))))
указатели на функции стараюсь не использовать без надобности ибо это ад для неподготовленного мозга, стараюсь делать читаемо, хотя иногда приходится бесспорно. Например без этого достаточно трудно обойтись при реализации многопоточности, а может и вообще невозможно
Указатель на функцию в принципе ничем не опаснее любого другого, да и вряд ли сложнее в понимании и использовании. Зато без указателей на функцию невозможно реализовать полиморфное поведение объекта, а следовательно, мы не сможем применить в своих программах ни один из реально полезных паттернов проектирования, даже если не связываемся с многопоточностью.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
Да знаю я тот синтаксис. Просто редко использую (указатели на функции), потому для уверенности и лезу в справку. Но за книжку спасибо, лишней не будет.
Ну а с обычными указателями, ессно, и так проблем никаких.
UPD: Ух ё, сколько там вообще интересных книг по той ссылке! Спасибо еще раз!
Если понравилось, заглядывайте время от времени, я регулярно добавляю туда новые экспонаты по мере прочтения. Ну и наиболее понравившиеся статьи тоже в отдельный блог кладу. А то потом сам не найду, если понадобится перечитать или процитировать.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
Действительно дофига замечательных книг на англе. Может сделаем инициативную группу волонтеров и переведем их на русский?) Может потом и издательство какое заинтересуем )
Я могу и на английском читать. На русском приятнее, и меньше устаю, но это все ерунда. А русский народ ленивый и что он насчет научиться это вряд ли )))))))
Спасибо, жаль только, линков на скачивание нету. Я понимаю, копирастия и все такое, только я уже проверил - две трети трудов хрен скачаешь с первого тычка. Вот мучаю гугл, ищу... Все-таки тема специфичная, и потому эти книги на каждом шагу не валяются.
Может сделаем инициативную группу волонтеров и переведем их на русский?)
Ну нафиг, только ошибки плодить. Да и всего не перевести. Тогда уж более здравой выглядит идея написать хороший учебник по техническому английскому.
Разница между теорией и практикой на практике гораздо больше, чем в теории.
YS писал(а):хороший учебник по техническому английскому
Тоже вариант, но сложно ) Да и в итоге получится словарь )
Можно выбрать хороший труд и перевести, думаю многим будет полезно ) Ну в принципе если не интересна идея - то нафих ее )
Видел я переводы хороших трудов... Чаще всего это грустное зрелище.
Пример - Bob Pease, Troubleshooting analog circuits. Переводную книжку закрыл после фразы, в которой осциллографические щупы (oscilloscope probes) назвали пробниками. При наличии таких ляпов я банально перестаю верить переведенному тексту.
Разница между теорией и практикой на практике гораздо больше, чем в теории.
YS писал(а):Спасибо, жаль только, линков на скачивание нету.
Я специально линки там не привожу во избежания наездов по поводу пиратства. Тем более что наши соотечественники в последнее время тоже грешат копирастией, а пара-тройка отечественных авторов там тоже затесались (хотя и не жемчужины коллекции). Казалось бы, книга доброго слова не стоит, сплошь плагиат или пустословие, а шуму-то...
Если что-то из перечисленного захотелось почитать, а найти не смогли - обращайтесь в личку, поделюсь. Почти все хранятся у меня в закромах. Не дам только James W. Grenning, Test Driven Development for Embedded C и Mark VanderVoord, Embedded Testing with Unity and CMock. Их электронные версии мне прислали авторы, и не хотелось бы, чтобы именно моя именная копия расползлась по Сети. Впрочем, видел их сканы на торрентах. Остальные - без проблем.
YS писал(а):Тогда уж более здравой выглядит идея написать хороший учебник по техническому английскому.
Лучше взять просто хороший учебник английского и энциклопедический словарь по теме, например, этот. Лучшие технические книги пишутся живым литературным языком, обычно еще и с юмором. Протокольный технический язык хорош только для даташитов.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle