tugo

Как-то так:

#include <iostream>
#include <type_traits>
#include <typeinfo>

template <typename T>
class GenericQueueBase
{
	//Общий интерфейс очереди (для рантайм полиморфизма)
};

template <typename T>
class Queue_pass : public GenericQueueBase<T>
{
    static_assert(sizeof(T) <= 4, "types up to 4 bytes are allowed");
    //Реализация очереди
};

template <typename T>
class Pool_pass : public GenericQueueBase<T>
{
    //Реализация пула
};


template<typename T>
using GenericQueue = typename std::conditional<sizeof(T) <= 4, Queue_pass<T>, Pool_pass<T>>::type;

int main()
{
	std::cout << typeid(GenericQueue<int>).name() << '\n' << typeid(GenericQueue<double>).name();
}

VisualParadigm

Самое большое сообщество электронщиков профессионалов в рунете - electronix.ru. Думаю ваш вопрос лучше задать там.

1. Нет. Культовая K&R C -- 260 страниц
   
2. Да. libGTK
   

Язык С весь можно уложить в голову за неделю. Потом учиться программировать

Мне кажется что необходимо разделить этапы. Отдельно собрать, а потом уже писать софт. Выставите проект с более или менее детальным описанием на форум . Для обсуждения с понимающими людьми. Иначе вы сильно усложняете себе задачу. Я сам собрал с десяток проектов на Arduino и могу сказать что двигаться нужно постепенно. Все и сразу не получится.

Напишите письмо в Google и попросите вас разбанить :)
aterlux.ru/index.php?page=article&art=ntcresistor

Рекомендую Bitbucket!
Можно создать приватный репозитарий, создать в нем свое wiki.
Можно создать свою команду и в ней создавать хранилища для разных проектов.
Есть встроенная интеграция с HipChat. Создаешь комнату для своей команды и туда будут прилетать все коммиты которые вы делаете. И чат довольно удобный. Сохраняет ссылки и файлы в истории.

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

Ну раз нет, так нет. Незачем тогда напрягаться. А для себя найтите что пополезнее.

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

JIRA, Slack, GitHub, Google Hangouts.
У нас команда разбита на основную в офисе и удаленщики.
Все проекты ведутся в Jira, она интегрирована с GitHub & Slack. Как только задача меняет статус, это видно в слаке. Коммиты и пулреквесты содержат метки задач, поэтому видно, какая задача была закрыта каким кодом.
GitHub также интегрирован со Slack. Сразу видны code review, pull requests.
При управлении кодом используем слегка адаптированную модель отсюда
nvie.com/posts/a-successful-git-branching-model
Код из master всегда в деплое, разработка путем пулл реквестов в development. Под каждую задачу (группу совместных задач) отдельная ветка.
Пулл реквесты облегчают рассмотрение кода. Внутри имеем правило - пул реквест обязательно должен быть прочитан кем-то еще, кроме автора. Автор мерджит после одобрения.

Делается программный таймер, аппаратный таймер и аппаратные внешние прерывания только под кнопку отдавать это мягко говоря нерационально.
В одном аппаратном таймере обновляются все программные таймеры, которые могут быть использованы для чего угодно.
Значит заводим программный таймер для опроса кнопки, например с тиком каждые 100мс и переменную-счетчик. Далее проверяем в нем если кнопка нажата и если счетчик меньше 30 то инкрементируем его, иначе ставим флаг об удержании и выполняем функцию которая должна выполнятся при удержании ее. Если кнопка не нажата - сбрасываем счетчик и флаг удержания.
Псевдокод:

u08 buttonCounter=0;
  u08 buttonHold=0;

  u16 Timers[1]={0};//массив счетчиков программных таймеров

  interupt HardwareTimer1(){//прерывание аппаратного таймера каждые 25мс
        if(Timers[0]++==4){//  100мс/25мс=4 раза
            Timers[0]=0;
            onProgTimer1();
        }
  }
 
  void onProgTimer1(){//этот программный таймер тикает каждые 100ms
      if(button1==PRESSED){
             onButton1Press();//функционал когда кнопку нажали

            if(buttonCounter<30){//ждем пока счетчик досчитает до 30 - 100мс*30 раз=3000мс=3 сек
                buttonCounter++;
            }else{
                if(buttonHold==0){
                    buttonHold=1;//Ставим флаг удержания кнопки
                    onButton1Hold();//выполняем функционал при удержании
                }
            }
      }else{
            buttonCounter=0;//сбрасываем таймер-счетчик
            onButton1Release(buttonHold);//функционал когда кнопку отпустили
            buttonHold=0;//сбрасываем флаг удержания кнопки
      }
  }

Берете и разбирайтесь с QThread. Для остановки/запуска используете сигналы/слоты (смысл QThread в том, что он умеет запускать свой eventLoop, и ловить QueuedConnection-сигналы из других потоков)

ИМХО к сожалению, состояние нашей промышленности не способствует созданию таких рабочих мест, где широко нужны программисты "железячники". Если сравнивать с прикладными+веб, то их можно считать что и нету. Увы.
Сам я тоже должен быть железячником по образованию, все с паяльниками сидел, но еще после школы понял что скорее всего это останется занятием для души бумажки о ВО, а основным, как и все, упорно заняться прикладным, через пару лет дошло что лучше веб. Просто не в том месте или не в то время я родился=) Писать даже индуский код на том же php для "забугра" в разы выгоднее.
Вообщем себе рисовал картину так - минусы железячника:
- производство стоит, отсталое
- маленькое количество рабочих мест
- относительно низкая ЗП, в несколько раз меньше по сравнению с другими
- работа на внутренний рынок
- сложное освоение, большие затраты на покупку демо-железяк
- привязанность к конкретному месту производства
- устроится сложно, работа часто "по блату"
- сам один ты в поле не воин, ты не напишешь крутую прошивку, скажем умного дома, под устройство которого нет, сам не запустишь производство, сам не продашь... как бы этого не хотелось... разве что kickstarter=) и то команда нужна серьезная чтоб создать свое маленькое дело
- там где есть хоть какое то производство -ужасная экология, жить в индустриальном районе не хочется, ну это так - придирки
- мало шансов свалить в "загнивающийзапад" по рабочей визе

Конечно, есть яркие исключения, но в основной массе оно примерно так...

Может получиться как у меня - отучился на железячника, а все ровно параллельно сам учил прикладное и веб- круть, теперь я web dev с никому ненужными навыками программиста мк, системотехника и архитектора сетей=))
Вообщем хорошенько еще подумайте=)
Если бы у меня была машина времени- я бы вообще вернулся на 10 лет назад и сказал бы себе - "харе кодить, забей - сиди на лавке пей пиво, через 10 лет будешь ручным тестированием заниматься - там за месяц буш готов, мозг береги"=)))

Может быть я как-то не так мыслю?

Конечно, не так.
Важной чертой мышления программиста является умение искать информацию и пользоваться поиском.
Если таких навыков нет, то всё печально.
https://toster.ru/search?q=%D0%BC%D1%8B%D1%88%D0%B...

У вас проблема в терминологии - при статической линковке вы на выходе должны получить ровно один файл, который зависит только от стандартных библиотек Windows. При этом вы можете так собрать статические библиотеки Qt, что в них не будет "лишнего" (функционала Qt, который в вашей программе не задействован).

Здесь у вас будут три проблемы:

• под форточками собирать qt - удовольствие ниже среднего (вы не сможете слету открыть терминал и вбить туда make)
  
• параметры сборки под ваше приложение придется долго подбирать, а если у вас нет кластера для сборки, вы можете собирать каждую новую версию qt по полдня
  
• если у вас коммерческий продукт, изучите внимательно, как LGPL относится к статической компоновке
  

После этого, на полученный файл можно будет натравить упаковщик типа UPX, что позволит выиграть еще процентов 30.

sparkle-project.org
winsparkle.org
qt installer framework

Oh, not this shit again...

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

Вы уверены, что люди которые поставлены отвечать вам на вопросы это компетентные люди?!

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

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

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