[jcxz 184]

17 минут назад, Forger сказал:

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

Странно... у меня IAR вообще ни для каких методов в стек не кладёт this. И при этом как-то всё работает. Что-ж Вам так дался этот стек???  

И static- и friend-методы могут спокойно обращаться к членам класса если им явно передать this. Никаких проблем нет.

[Forger 17]

2 minutes ago, jcxz said:

Откуда такие странные голословные утверждения???

Да знаю я, что this кладется в R0, автоматом компилятором, в ARM-ах по крайней мере.

Таково предписание самой конторы ARM для проектировщиков компиляторов. Там и про другие регистры есть предписания. В частности R1- регистр возвращаемого значения, если не ошибаюсь.

Но сути это не меняет - для статических методов класса и обычных c-функций никакой this не доступен. И с этим ничего не поделать.

 

[jcxz 184]

2 минуты назад, Forger сказал:

В частности R1- регистр возвращаемого значения, если не ошибаюсь.

R1 используется только когда возвращаемое значение не влезает в R0 (в 32 бита). Тогда используется пара R0:R1. Использую это свойство регулярно.

[Forger 17]

1 minute ago, jcxz said:

Странно... у меня IAR вообще ни для каких методов в стек не кладёт this. И при этом как-то всё работает. Что-ж Вам так дался этот стек???  

И static- и friend-методы могут спокойно обращаться к членам класса если им явно передать this. Никаких проблем нет.

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

По сути придется сделать его глобально видимым, хотя бы даже в пределах одного файла (с припиской static). Для меня это - пройденный этап. Скверный костыль.

А friend вообще не имеет отношения к этому. Это совсем другое - он позволяет посторонним влезать в protected/private секции. А это - очень скверная штука, и пользоваться ей нужно с осторожностью. 

[jcxz 184]

4 минуты назад, Forger сказал:

Но сути это не меняет - для статических методов класса и обычных c-функций никакой this не доступен. И с этим ничего не поделать.

Он легко передаётся явно. И тода статическая функция по доступу ничем не отличается от нестатической. Только явным использованием указателя.

2 минуты назад, Forger сказал:

Для меня это - пройденный этап. Скверный костыль.

Ну что-ж: кто-то некошерную пищу не ест. Другим религия ещё чего-то не позволяет. Каждый сходит с ума по-своему....

[Forger 17]

25 minutes ago, jcxz said:

R1 используется только когда возвращаемое значение не влезает в R0 (в 32 бита). Тогда используется пара R0:R1. Использую это свойство регулярно.

Спорить не буду, не вникал в эти дебри :)

Все равно это - это не суть.  На одном компиляторе так, на другом так.  А привязка к платформе - это всегда некая заплатка/костыль.

Хороший код - код без подобных костылей, но хороший код - редкость ;)

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

 

 

24 minutes ago, jcxz said:

Он легко передаётся явно. 

Покажите пример. Пример должен компилироваться без ошибок.

Задача: добраться до конкретного экземпляра класса из static метода класса или обычной C-функции.

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

 

[AlexandrY 3]

2 hours ago, k155la3 said:

C++ позволяет "умственную" абстракцию формализировать, как минимум. При этом появляются шансы, что абстракция будет видна не только автору. С минимальными затратами времени-сил на чтение кода. 

Эт миф. 
Напишите функции C-и с хорошим форматированием и комментированием и они абстракцию представят лучше любого C++
С++ как раз наоборот затрудняют чтение кода, причем значительно. Почитайте посты даже тут, разобраться в классах mbed некоторым крайне сложно. 
А ведь это один из лучших образцов.  

Слово "абстракция" в учебниках по C++ затаскали и извратили. Мало кто понимает теперь что оно означало, большинство путает его с обобщением. 
А обобщение раньше детализации - пустая трата времени.
Т.е. плюсы не избавляют от множественных реализаций, а только добавляют синтаксического мусора.  

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

 

[Forger 17]

31 minutes ago, AlexandrY said:

Напишите функции C-и с хорошим форматированием и комментированием и они абстракцию представят лучше любого C++

Хорошо спроектированный код на С++ обычно не требует комментариев. А писать без комментариев на "С"  - откровенный садомазахизм. 

Комментарий - костыль для плохо читаемого кода. Нормальный код не требует комментариев, кроме "шапки" файла.

Сужу по своему опыту. Мне лично подобный код одинаково быстро понятен и завтра и через 5 лет.

 

Quote

С++ как раз наоборот затрудняют чтение кода, причем значительно.

Вот это как раз миф, он очень популярен среди закоренелых "пенсионеров" asm и C :)

 

 

Quote

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

По мне - mbed как раз отличный пример одного из самых трудночитаемых способов применения C++.  Без поллитра не разберешься.

 

Quote

А ведь это один из лучших образцов.  

Это кто так считает?

 

Quote

Слово "абстракция" в учебниках по C++ затаскали и извратили.

С++ надо не по учебниках изучать, а проекты делать. Тогда и потребность в языках высокого уровня придет сама собой, а не наоборот, как многие думают.

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

 

[k155la3 26]

53 minutes ago, AlexandrY said:

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

А какая "порча экологии", за исключением незначительного увеличения расхода памяти ? 

Не так давно и для С-компиляторов embedded был мелким. Есть конечно разные назначения этого embed. Если реалтайм - то, наверное да.

ps

По "абстракциям" - отсюда 

"Объектно-ориентированное программирование с использованием C++" Автор: Айра (Ирэ) Пол ДиаСофт Лтд 1995

Если у кого есть файл или ссылка - поделитесь пож-ста. Тк книгу у меня "увели" в незапамятные времена.

[AHTOXA 14]

1 час назад, ViKo сказал:

А куда заносить обработчик прерывания, который пишет или читает Packet?

А вы не думайте об обработчике прерывания, как о чём-то особенном. Это обычная функция, которая вызывается системой при возникновении определённых условий.

Соответственно, например, обработчик прерывания UART будет дёргать функцию Uart::interruptHandler();

и уже там принятые данные будут складываться в пакет. После того, как пакет будет собран, он может быть помещён в очередь принятых пакетов. Либо сразу обработан.

Или же UART не будет собирать/разбирать пакеты (это правильнее с точки зрения разделения ответственности), а будет просто предоставлять буферы приёма/передачи. А пакетами будет заниматься какой-нибудь CommunicationProtocol.

В общем, если есть интерес, то советую просто начать применять плюсы. Сделайте для начала какой-нибудь небольшой проект. Почитайте имеющиеся проекты, посмотрите, как там сделано. Я думаю, что вам понравится.

[ViKo 1]

8 минут назад, AHTOXA сказал:

Соответственно, например, обработчик прерывания UART будет дёргать функцию Uart::interruptHandler();

То есть, обработчик, что в стартап-файле описан, будет вызывать другой (функцию из класса Packet)?

Пока что я вижу "overhead" от применения ООП. 

[AHTOXA 14]

1 минуту назад, ViKo сказал:

То есть, обработчик, что в стартап-файле описан, будет вызывать другой (функцию из класса Packet)?

Да, так. Вас смущают затраты на вызов ещё одной функции?
Это не беда - если сделать всё правильно, то вызов будет заинлайнен, и затрат не будет.

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

[ViKo 1]

1 минуту назад, AHTOXA сказал:

если сделать всё правильно, то вызов будет заинлайнен, и затрат не будет

О! А как ... правильно?

[AHTOXA 14]

1 минуту назад, ViKo сказал:

О! А как ... правильно?

Объявить функцию inline, определить в заголовочном файле.

[Forger 17]

6 minutes ago, AHTOXA said:

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

Вы по сути описали delegate, но только сделанный "на коленке в гараже" :)

Оверхед такой же, но в остальном - проигрывает готовым решениям.