Как быстро работать с .cpp и .hpp?

Question

[Vitaliy]

Есть ли какие-то дополнения для синхронизации таких файлов ? Например если в .hpp добавляю метод, то он должен сгенерироваться в .срр, чтобы не писать за каждым разом Class::method(){}.
Находил отдельный инструмент Lazy C++, но пока не ясно на сколько он адекватен

Comments

[devalone]

.hpp обычно используют для шаблонов, т.е. без .cpp

[Vitaliy]

devalone, а реализация не нужна? Или в hpp пишется?

[devalone]

Виталий Столяров, для шаблонов пишется в .hpp, т.к. для них другого способа просто нет, если не шаблонные методы, то конечно описание в .h, а реализация в .cpp. Но это не прям строгое правило, а просто часто встречающаяся практика.

[Vitaliy]

devalone, реализация всего в hpp? Да ладно!?!? А это не тот ли .h, только под плюсы? Поэтому ничего не мешает делать реализацию не шаблонных в .срр

[devalone]

Виталий Столяров, а как ты себе представляешь иначе? Компилятор должен знать реализацию шаблонной функции для того, чтобы сгенерировать нужный вариант. Т.е. если у нас есть такой код:

#include <iostream>

template <typename T>
T getSumOfArguments(const T& arg1, const T& arg2)
{
	return arg1 + arg2;
}
int main() {
	std::string str1 = "Hello, ";
	std::string str2 = "World";
	int num1 = 1;
	int num2 = 2;
	
	std::cout << (getSumOfArguments(str1, str2)) << std::endl;
	std::cout << (getSumOfArguments(num1, num2)) << std::endl;
	
	return 0;
}

то сгенерируются 2 варианта функции getSumOfArguments, а если она будут в отдельном .cpp, то при создании объектного файла у нас недостаточно информации, чтоб сгенерировать нужное количество функций.

Можно разве что сделать так:
helper.h/helper.hpp file:

#pragma once 

template <typename T>
T getSumOfArguments(const T& arg1, const T& arg2);

#include <helper.cpp>

helper.cpp file:

template <typename T>
T getSumOfArguments(const T& arg1, const T& arg2)
{
	return arg1 + arg2;
}

[Vitaliy]

devalone, как это отменяет тот факт, что .hpp остаются теми же заголовочными файлами для С++ ? Или если один шаблонный метод попался, то можно уже не писать реализации других в .срр ?

[devalone]

Виталий Столяров, я не писал, что надо не писать реализацию методов в .cpp, когда это возможно, писать их там стоит, но для шаблонов невозможно(хак с инклудом в .h не в счёт)

Answer 1

[Vitaly]

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

Comments

[Vitaliy]

Не хочу привязываться к какой-либо IDE, к тому же не находил хорошую под Linux и бесплатную. А что именно делается по хоткеям?

[devalone]

Виталий Столяров,

Не хочу привязываться к какой-либо IDE, к тому же не находил хорошую под Linux и бесплатную

Да ладно? Вы не пробовали QtCreator? Или у нас разные понятия хорошей IDE?

[Vitaly]

Виталий Столяров, Если хотите стать профессиональным разработчиком, то вам придётся освоить IDE, это даже обсуждать не стоит, т.к. очевидно. Vim/Emacs ребята входят в отдельную категорию, их я трогать не хочу лишний раз.
По хоткеям в IDE делается практически всё. Например, надо вам определение метода по сигнатуре сгенерировать, вы ставите курсор на имя метода и нажимаете определённое сочетание клавиш, после чего получаете менюшку с вариантами действий (где, как и что генерировать). + любые другие рефакторинги/фиксапы и т.п.

Под Linux есть куча отличных и бесплатных IDE, QtCreator например.

[SEOD]

devalone, QtCreator крайне бестолковый относительно работы с cmake, что может потребоваться под линуксом.

[Антон Жилин]

Виталий Столяров, просто оставлю это здесь: https://www.jetbrains.com/student

[devalone]

SEOVirus, ну не знаю, я собирал cmake'ом из QtCreator'а и вполне удобно.

[Vitaliy]

Vitaly, IDE во многом ограничивает, и часто не дает сделать что-то изнутри самого процесса сборки. Конечно, если разрабатывать на Qt или WPF, то под них в IDE уже все продумано под конкретную технологию.

[Vitaliy]

devalone, Qt creator пробовал когда-то, и что я в итоге получал, так это некоторую возню с настройкой той же Cmake сборки, которая через одни bash'ы очевиднее и проще

[devalone]

Виталий Столяров, ну, можно продолжать собирать ручками, а писать код в IDE

[Vitaly]

Виталий Столяров, больше конкретики, плз. Если система сборки сильно кастомная, то она вполне вероятно что-то генерит, проекты VS, мэйк-файлы и т.п. Кто мешает вызывать сборочные скрипты отдельно (или как в QtCreator отдельным шагом процесса сборки) и потом комфортно работать в IDE? Можно настроить IDE, чтобы она вызывала кастомный скрипт на сборку или команду...

[Vitaliy]

Vitaly,

профессиональным разработчиком, то вам придётся освоить IDE

откуда такая информация? От тех, кто ассоциирует редакторы для программирования с Nodepad++ ?@vt4a2h,

[Vitaliy]

Vitaly, тогда получится тот же редактор, только прожорливый

[Vitaly]

Вы и правда не понимаете разницы между IDE и редактором? Окей, второе - часть первого. Подробнее, на вики.

Это ответ на оба коммента выше.

[Vitaliy]

Vitaly, понимаю, я вам что-то обратное говорил? Вот цитаты:

IDE во многом ограничивает

получал, так это некоторую возню с настройкой

тогда получится тот же редактор, только прожорливый

То есть вывод такой, если IDE не подходит под процесс сборки, и к тому же прожорливая, то какой в ней смысл, если она будет выполнять ту же роль, что и редактор? Только редактор еще можно настроить под себя и нужные языки

П.С. VS Code отлично себя чувствует как под JS, так и под С++, только бывают проблемы с поиском нужных дополнений (но и никто не ограничивает написать свои, конечно если нет уже реализованных)

[Vitaly]

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

VS Code -- жуткая поделка в Electron контейнере (вы же знаете, что это?). Я не уверен, что оно потянет серьезный проект с кучей зависимостей и сможет быстро осуществлять хотя бы навигацию по именам/методам класса, рефакторинги и отладку. А ресурсов гарантировано выжрет кучу, т.к. Chrome сам по себе прожорлив. Я бы ещё понял, рекламируй вы какой-нибудь нативный редактор, тот же Vim, то использовать что-то в электрон контейнере и говорить о прожорливости...

[Vitaliy]

Vitaly,

Если для вас IDE -- это не более чем рекдатор,

IDE это IDE, вот только если на ней не выполнять сборку (как предлагали выше), то все, что от нее остается - редактор и отладчик

как анализ кода на лету, расширенные рефак..

все это (ну почти) есть в VS Code, и основное что дополнительные возможности активно дополняются со стороны сообщества

VS Code -- жуткая поделка в Electron контейнере

Чем жуткая?

быстро осуществлять хотя бы навигацию по именам/методам класса

в один клик и долю секунды - это достаточно быстро?

А ресурсов гарантировано выжрет кучу,

Все процессы VS Code (вместе с дополнениями), жрут 680 мб, в это же время IntelliJ IDEA - 790 мб. И это еще стоит упомянуть, что VS Code быстрее запускается



Сейчас бы говорить о прожорливости Chromium в 2017