Вот как я это получил.
Я добавил перенаправление портов в vagrant, а затем запускаю синхронизацию браузера из vm. Все работает сейчас на http://example.dev:3000
и http://example.dev:3001
.
Вот что я добавил в свой Vagrantfile:
config.vm.network :forwarded_port, guest: 3000, host: 3000, auto_correct: true
config.vm.network :forwarded_port, guest: 3001, host: 3001, auto_correct: true
Вообще говоря, то, что вы хотите, чтобы компилятор встроил в код или шаблонный код. В любом случае код должен быть доступен компилятору везде, где он используется, поэтому у вас нет выбора.
Однако обратите внимание, что чем больше кода вы вставляете в файл заголовка, тем больше времени потребуется для компиляции - и тем больше часто приходится касаться файлов заголовков, вызывая цепную реакцию медленных сборок :)
Одной из причин минимизировать количество кода в заголовках является минимизация количества кода, который нужно перекомпилировать при изменении реализации. Если вас это не волнует, вы можете иметь любое количество кода в заголовках.
Иногда код только в заголовках делается намеренно, чтобы раскрыть код - ATL делает это для eaxmple.
При разработке большого проекта на C ++ вы должны проявлять бдительность, чтобы каждый файл .CPP сочетался с минимально возможным количеством файлов заголовков.
Итак, у меня есть простое правило «рисования» строка ":
Если, встраивая реализацию, ваш файл заголовка теперь должен включать дополнительный файл заголовка, вы должны переместить реализацию из заголовка в файл .CPP.
Конечно, это не так. это не единственная причина не вставлять строки, но это конкретный пример линии, которую нельзя пересекать.
Но когда заголовок увеличивается в размерах, для компиляции требуется все больше и больше времени, поэтому полезно использовать предварительно скомпилированные заголовки.
Когда у вас есть код в файле заголовка для простого метода получения / установки методы, это более или менее нормально, потому что вы либо хотите сэкономить некоторое рабочее время из-за обслуживания кода (вводя один и тот же метод в заголовке и файле реализации), либо потому, что вы действительно хотите, чтобы метод был встроенным из-за накладных расходов на вызов функции во время критичных мест.
Вы не только будете подвергаться более медленным сборкам, но и время компоновки может быть огромным , если у вас есть много классов, видимых более или менее повсюду.
Еще одна обратная сторона - смешивание кода между ними. заголовочные файлы и файлы реализации удобны для чтения. Если вы последовательно объявляете в файле заголовка и последовательно сохраняете код в файле реализации, он проще сохранить одинаковый порядок между методами. Если вы понимаете, что я имею в виду, у вас нет пропусков.
Ура!
Я бы использовал код в файлах .c и .cpp, а заголовки - в файлах .h, .hpp. Причина в том, что когда я загружаю .tar.gz или zip с исходным кодом, я всегда ищу файлы .h для заголовка и файлы .cpp для источника. Многие люди к этому привыкли, поэтому я думаю, вам следует придерживаться этого стиля.
Также обратите внимание, что вы можете столкнуться с некоторыми странными побочными эффектами, если поместите код в файл заголовка и не будете осторожны со своим Makefile. Однажды у меня была ошибка из-за кода, который я изменил в заголовке, который был перекомпилирован в некоторые файлы, но не в другие, потому что зависимости не были правильными в Makefile. Это не имеет большого значения, если вы создаете свой Makefile автоматически.
Вам понадобится код в заголовке, если вы хотите "встроить" код. В противном случае есть больше преимуществ в том, чтобы наклеить реализацию в корпус.
Выбор за вами. Boost помещает почти весь свой код в заголовок ... и это уважаемая библиотека.