[ViKo 1]

Только что, AHTOXA сказал:

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

У меня обычно обработчики прерываний в отдельном файле. Видимо, его надо в тот же файл, что и класс Packet перенести. Ну, или тот самый --multifile задать.

[AHTOXA 14]

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

У меня обычно обработчики прерываний в отдельном файле. Видимо, его надо в тот же файл, что и класс Packet перенести. Ну, или тот самый --multifile задать.

Я не очень понял, при чём тут класс Packet. Но суть простая. Если мы размещаем тело функции прямо в объявлении класса, вот так:
 

class Packet
{
publuc:
	Packet() {};
	void putByte(unsigned char byte)
	{
		buffer[count++] = byte;
	}
}

, то если потом вы вызываете Packet.putByte(), то вызова не будет, функция будет заинлайнена.

 

[ViKo 1]

Я про вызов обработчика putByte из прерывания USART. 

[AHTOXA 14]

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

Я про вызов обработчика putByte из прерывания USART. 

Ну всё будет точно также, у вас будет файл Uart.h:

#include "Packet.h"

class Uart
{
public:
	void interruptHandler()
	{
		rxByte = USARTx->DE;
		rxPacket.putByte(rxByte);
	}
private:
	Packet rxPacket;
}

А в c++ -файле обработчиков прерываний будет так:
 

#include "Uart.h"

Uart uart;
  
extern "C" void USART1_IRQHandler()
{
	uart.interruptHandler();
}

И всё заинлайнится - и Uart::interruptHandler(), и  Packet::putByte().

[esaulenka 5]

On 2/8/2019 at 6:09 PM, Forger said:

https://habr.com/ru/post/78299/

Не очень пристально вчитывался, но у Вас получилось выкинуть оттуда dynamic_cast ?

пользу RTTI до сих пор не осознал, а флеша оно достаточно много хочет...

 

Сама идея замечательная, Qt'шного connect'а очень не хватает.

[Forger 17]

14 minutes ago, esaulenka said:

Не очень пристально вчитывался, но у Вас получилось выкинуть оттуда dynamic_cast ?

Я брал другую реализацию,  где-то на просторах гитхаба стырил. Их там немного, но выбор есть.

Выпилил MulticastDelegate, мне он ни к чему.

Безусловно никаких dynamic_cast

А втой статье полезно только описание в начале для чего это зачем, остальное - лучше не читать ))

 

 

Quote

пользу RTTI до сих пор не осознал, а флеша оно достаточно много хочет...

RTTI не использую

 

Quote

Сама идея замечательная, Qt'шного connect'а очень не хватает.

слоты/сигналы можно сделать своими руками, тут нет ничего сложного,

у меня получилось немного колхозно, но зато мне понятно и главное - отлично работает.

Начал с того, что просто в xmind прорисовал все взаимосвязи на примере некого простого проекта. Сразу все стало понятно и наглядно.

[AlexandrY 3]

8 hours ago, Forger said:

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

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

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

Чувствуется травматический опыт программирования под PC в каком-нибудь билдере. 
Да, там не комментировали ничего. Во первых потому что делали огромный контекстный хелп, а во вторых чтобы никто не слямзил их объектную модель. 
Потому что всякие борланды отлично знали - исходники без комментариев никому не нужны.
 

Гляньте в сорсы ThreadX. (лежит в известном всем месте)
Там каждая! строчка прокоментирована. Ну так эта ось потому в 6 миллиардах устройств и стоит.
Эт к вопросу о том "кто так сказал" 
 

[Forger 17]

34 minutes ago, AlexandrY said:

Чувствуется травматический опыт программирования под PC в каком-нибудь билдере. 

Ваш "стиль" легко узнаваем: "Cтавлю диагнозы по фото без смс и регистрации"  

Продолжайте дальше, вы ни чуть не мешаете 

 

 

[Forger 17]

42 minutes ago, AlexandrY said:

сорсы ThreadX. 

Там каждая! строчка прокоментирована.

Да закройте уже свой любимый "журнал с мисс Апрель" и переходите как и все - на живой здоровый высокоуровневый код :D

 

 

[AlexandrY 3]

54 minutes ago, Forger said:

Ваш "стиль" легко узнаваем: "Cтавлю диагнозы по фото без смс и регистрации"  

Продолжайте дальше, вы ни чуть не мешаете 

Чай не с луны свалились. Читаете те же книжки, что и все. Да и мифы пересказываете характерные. 
Ваша беда в том, что пытаетесь практики программирования под PC перенести на микроконтроллеры. 

Но те книжки не учли современные тренды в автогенерации кода  и фреймворках.
Плюсовые проекты типа eCOS или .NET micro framework умерли, mbed жив, но уже готовится уйти на линукс.  
Все что вы написали на плюсах не составит и доли процента от того что сейчас помещается и нужно поместить в какой-нить  S7G2 или i.MX RT
Но этот плюсовой багаж который вы уже накодили, придется выбросить, поскольку он не совместим с кодогенераторами и HAL-ами от слова абсолютно.
Либо так и будете писать до пенсии свои классы GPIO да UART 
Современным должен быть не язык, а технология.
Вон JavaScript как поднялся, а все было его уже забыли. Библиотеки из любого языка конфетку сделают.  

    

[Forger 17]

41 minutes ago, AlexandrY said:

Ваша беда в том, что пытаетесь практики программирования под PC перенести на микроконтроллеры. 

Я не программист под PC (не моё), а самый простой "железячник".

У вас что не пост, то "демонстрация причиндал/медалек" или "пук в лужу". В данном случае по ходу есть и то и другое 

 

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

Но что-то со стороны это выглядит уж очень грустно 

 

[jcxz 184]

13 часов назад, Forger сказал:

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

Что за бред? Какая "привязка"??? Что значит "привязка" к способу передачи аргументов для языка си? О чём Вы вообще говорите?

А если для вызова функции из ассемблера, то как можно обойтись без этой "привязки"? Приведите ка пример, теоретик Вы наш.

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

 

13 часов назад, Forger сказал:

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

Используйте оператор взятия адреса &.

[jcxz 184]

13 часов назад, Forger сказал:

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

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

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

И от языка тут ничего не зависит.

[Forger 17]

7 hours ago, jcxz said:

Что за бред? 

Вы прекрасно поняли о чем я. См. подробности ниже

 

Quote

Какая "привязка"??? Что значит "привязка" к способу передачи аргументов для языка си?

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

Я имею ввиду именно такой термин "стек", БЕЗ привязки к конкретно взятой платформе или компилятору. 

Теперь понятно выражаюсь?

 

Quote

А если для вызова функции из ассемблера, то как можно обойтись без этой "привязки"? Приведите ка пример, теоретик Вы наш.

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

А в ваших практических навыках использовать особенности компилятора никто не сомневается, тема не об этом :)

 

 

Quote

Используйте оператор взятия адреса &.

Повторюсь: покажите пример как из статического метода (функции) класса обратится к его другим НЕстатическим методам или полям (данным). Об это речь, если вы не поняли :)

 

[Forger 17]

7 hours ago, jcxz said:

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

Мой код сначала проектируется (самое сложное - т.н. naming), а уже потом кодируется. В таком порядке комментарии в коде практически не требуются.

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

 

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

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

В таком случае ваши же слова будут вполне уместны: Можно только посочувствовать вашим коллегам

 

 

 

Quote

И от языка тут ничего не зависит.

Безусловно не зависит. А кто утверждал обратное?