Относительно iostream - собственно пока не могу себе представление о "потоке" построить...
взять и пробовать и будет представление:
Цитата:
Если вы хотите использовать STL из популярной IDE Arduino, все, что вам нужно сделать, это скопировать все файлы из каталога avr-stl / include в подкаталог hardware / tools / avr / avr / include установки Arduino. Например, в моей системе я бы скопировал все файлы заголовков сюда: C: Program Files (x86)\arduino-1.0.1\hardware\tools\avr\avr\include.
Так там пример реального железа есть, правда LCD, но и семисегментник так же можно. Только зачем, если есть ардуиновая семисегментная библиотека. LiquidCrystal поток Это позволяет вам писать на ЖК-дисплей символьный, используя потоки.
У адуринки все последовательные протоколы сведены к потокам... "Stream Stream is the base class for character and binary based streams. It is not called directly, but invoked whenever you use a function that relies on it. Stream defines the reading functions in Arduino. When using any core functionality that uses a read() or similar method, you can safely assume it calls on the Stream class. For functions like print(), Stream inherits from the Print class. Some of the libraries that rely on Stream include :
Serial Wire Ethernet Client Ethernet Server SD ..."
собственно для единства наименования применяемых методов... Только вот... суть - буферизация массива последовательно принимаемых/отсылаемых данных?.. Или чего иного?... Чего собственно "ПОТОК"? (или что подразумевает термин ПОТОК по отношению к более понятным методам ассемблера/Си)...
За варианты print(), println() и соответствующего форматированного вывода особо ничего нового... Вопрос каким боком это к ПОТОКУ соотносится - обработкой данных буфера или пакетом пересылки? Куда там чего "течет"... А за расшифровку понимания содержимого термина "ПОТОК" .... НИЧЕГО... жаль... снова придется самому разбираться... Это как в прошлый раз - термин ПАРСИНГ - оказался всего-то анализом и сортировкой входных данных по мере их поступления - я когда прожку загрузки КОТУИНКО делал даже и не подозревал, что можно анализ символов строк *.hex файла тем мудреным термином назвать! (а может еще и обматюкать как "парсинг потока данных файла формата intel hex8 для бутлоадера"). Да и насчет "чего встроено" в ардуинке... - там за последнее время много чего понапихали - для той версии, что под 7-10ку расчитана (1.8.13 к примеру со всеми "обновлениями платформ"). Только те обновления (и в части компиляторов) сидят в "скрытом каталоге", а не в основном каталоге в program files. Я в те дебри не лезу - анализ IDE и ее компиляторов - это уже задача КОТОВ ПОМАТЕРЕЕ (а оные все еще ДРЕМЛЮТЬ).
Цель создания С++ была в том, чтобы пользователь мог определить новые типы данных, работа с которыми была бы столь же удобна и эффективна как и со встроенными типами. Таким образом, кажется разумным потребовать, чтобы средства ввода-вывода для С++ программировались с использованием возможностей С++, доступных каждому. Представленные здесь потоковые средства ввода-вывода появились в результате попытки удовлетворить этим требованиям. Основная задача потоковых средств ввода-вывода - это процесс преобразования объектов определенного типа в последовательность символов и наоборот.
Да я то уже много раз перечитывал (и не только того автора)... СУТЬ самого понятия в приближении к более примитивному виду - обмен данными из буфер массива или какая еще .... А там только поток ввода и поток вывода. Но ввод/вывод производятся таки не непрерывно, а по соответствуюшщим заросам... Или поток принимается как еще один вид данных всего лишь как абстрактное обобщение... ВОТЬ... Вобщем... пока то отложимс... до прояснения в той части, которая моим представлением требуется. Я ж не СИшник по "начальной базе знаний".
Вобщем похоже таки на "разновидность типа/класса данных" - ибо "базовый класс Stream" относится практически ко всем последовательным коммуникационным протоколам...
СУТЬ самого понятия в приближении к более примитивному виду - обмен данными из буфер массива или какая еще ....
Суть в буферизации, которой может и не быть. Выводишь строку через Uart, если там наследование от класса Stream, то должен быть виртуальный метод добавляющий в буфер по одному символу. Если в буфер влезла вся строка, значит можно заниматься чем-то другим, а Uart будет отправлять данные по прерываниям. Если речь о дисплее, то буфера наверно нет и будет блокирующий вывод по одному символу сразу на экран.
Загрузчик КОТУИНКО обрабатывает "поток данных" побайтово "на лету"... Плюс буфер размером в одну строку *.hex файла для последующего прикладного размещения в ОЗУ ВПД/ВПП. Т.е. один реальный входной поток по RS232 на скорости 9600 совмещенный с анализом и преобразованием для последующего размещения в оперативном буфере и второй - сброс данных в соответстви с указанными для них адресами в ВПП/ВПД... Неуж-то и "поток" и "парсинг" уже в дальнем прошлом изучен...?... Правда под ассемблером... Чтой-то не особо в то верится... Гдей-то ПОДВОХ...
Это у вас такая фантазия буйная? Потоки, парсинги, подвохи... Как не вспомнить старинный анекдот: "Пэрэбудова, прискорэння, гластнисть... - Бидна пташина, опъять москалив найилась!"
Это не фантазия, а типичная в С++ терминология, суть которой пока не во всем понятна... Однако по причине применения в ардуино IDE (там таки С++) требует хотя-бы ознакомительного восприятия. А насчет "анекдотов с намяком"- пожалте в соответствующий раздел: https://www.radiokot.ru/forum/viewtopic ... 7&t=101261 Разбор технических вопросов с примесью предвзятого отношения к оппоненту, не относящегося к теме обсуждения, часто приводит к ошибочным результатам.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
