2016-06-10 1 views
0

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

Теперь я смотрел, как использовать отдельные единицы перевода, но, честно говоря, я даже не знаю, с чего начать. Если бы у меня был только файл main.cpp в данный момент, и я хотел разбить его на, например, 3 части, где был бы один «variables1.cpp», один «variables2.cpp» и один main.cpp, где он расчеты и т. д., как бы я это сделал, используя визуальную студию?

+0

https://en.wikipedia.org/wiki/Object-oriented_programming – Tyler

+0

Вы также можете попробовать скомпилировать каждый исходный файл в файл объекта отдельно, а затем связать их вместе. Возможно, это может уменьшить использование памяти. – ForceBru

+4

@ Тайлер ссылка не имеет отношения к вопросу. Вы можете иметь несколько классов в одной единицы перевода, а также несколько единиц перевода без ООП. – user463035818

ответ

0

Это одна из основных задач программиста, как структурировать код таким образом, что логика кода становится понятной этим «разделением». Некоторые будут использовать один класс/один файл.

Я думаю, что этот вопрос требует очень подробного ответа. Может быть, вы должны прочитать эту статью: Organizing Code Files in C and C++

Нарезка любого разумного размера проекта до покупает вам некоторые преимущества, наиболее важными из которых являются следующие:

ускорения компиляции - большинство компиляторов работа над файлом за раз. Поэтому, если все ваши 10000 строк кода находятся в одном файле, и вы меняете одну строку, тогда вам нужно перекомпилировать 10000 строк кода. С другой стороны, если ваши 10000 строк кода распределяются равномерно по 10 файлам, то при изменении одной строки потребуется только 1000 строк кода для перекомпиляции. 9000 строк в другие 9 файлов не нуждаются в перекомпиляции. (Связывание времени является незатронутыми.)

Увеличение организацией - Расщепление код по логическим линиям будет сделать его проще для вас (и любых других программистов по проекту) в найти функции, переменных, объявление структур/классов , и так далее. Даже с возможностью прямого перехода к заданному идентификатору, который является , представленным во многих редакторах и средах разработки (например, Microsoft Visual C++), всегда будет время, когда вам нужно сканировать код вручную, чтобы что-то искать. Так же, как разбиение кода уменьшает объем кода, который необходимо перекомпилировать, он также уменьшает количество кода, которое нужно прочитать, чтобы найти что-то. Представьте, что вам нужно найти исправление, которое вы внесли в код несколько недель назад. Если у вас есть один большой файл с именем GAME.C, это потенциально много поиска. Если у вас есть несколько небольших файлов с именем GRAPHICS.C, MAINLOOP.C, SOUND.C и INPUT.C, вы знаете, где искать, сократить время просмотра на 3/4.

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

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

Split кодирование обязанностей среди программистов - Для очень больших проектов, это, пожалуй, главная причина для разделения кода в нескольких файлов. Практически не более одного человека может быть , внося изменения в один файл в любой момент времени. Поэтому вам нужно было бы использовать несколько файлов, чтобы каждый программист мог работать над отдельной частью кода, не затрагивая файл, который редактируют другие редакторы . Конечно, еще нужно проверить, что 2 программиста не пытаются изменить один и тот же файл; конфигурация системы управления и системы контроля версий, такие как CVS или MS SourceSafe поможет вам здесь.

+0

Хотя это теоретически может ответить на вопрос, [было бы предпочтительнее] (// meta. stackoverflow.com/q/8259), чтобы включить основные части ответа здесь и предоставить ссылку для справки. – NathanOliver

+0

Я, как правило, даю короткий ответ как можно быстрее (человек, который задает вопрос, нуждается в ответе), а затем редактирует его, чтобы улучшить его. – Heto

+2

Боюсь, что быстрого ответа на этот вопрос нет. OP не предоставляет никаких подробностей, но похоже, что у них есть одна функция «main» на 100 000 строк с 60 000 переменных. – melpomene

Смежные вопросы