Существует ли стандарт #include конвенция для C++?
Как и ответ на дубликат вопроса , который я изложил в комментариях. Вы можете использовать это для удовлетворения своих потребностей. Например:
HTML
Hi
JS-код
angular.module('MyModule', [])
.controller('MyController', function ($scope) {
$scope.myfunction = function (data) {
alert("---" + data);
// Do something more...
};
});
// I changed the code here so when element with ID "YourElementId"
// gets clicked, it executes the anonymous function that calls "myFunction"
// in the controller "MyController"
window.onload = function () {
angular.element(document.getElementById('YourElementId')).on('click', function (event) {
angular.element(event.target).scope().myfunction('test');
});
}
8 ответов
Я всегда использую принцип наименьшего количества связи. Я только включаю файл, если текущему файлу на самом деле нужен он; если мне может сойти с рук предописание вместо полного определения, я буду использовать это вместо этого. Мои .cpp файлы всегда имеют груду #includes наверху.
Bar.h:
class Foo;
class Bar
{
Foo * m_foo;
};
Bar.cpp:
#include "Foo.h"
#include "Bar.h"
Проверьте Крупномасштабную Разработку программного обеспечения C++ John Lakos. Вот то, за чем я следую (записанный как пример):
Интерфейс
// foo.h
// 1) standard include guards. DO NOT prefix with underscores.
#ifndef PROJECT_FOO_H
#define PROJECT_FOO_H
// 2) include all dependencies necessary for compilation
#include <vector>
// 3) prefer forward declaration to #include
class Bar;
class Baz;
#include <iosfwd> // this STL way to forward-declare istream, ostream
class Foo { ... };
#endif
Реализация
// foo.cxx
// 1) precompiled header, if your build environment supports it
#include "stdafx.h"
// 2) always include your own header file first
#include "foo.h"
// 3) include other project-local dependencies
#include "bar.h"
#include "baz.h"
// 4) include third-party dependencies
#include <mysql.h>
#include <dlfcn.h>
#include <boost/lexical_cast.hpp>
#include <iostream>
Предварительно скомпилированный заголовок
// stdafx.h
// 1) make this easy to disable, for testing
#ifdef USE_PCH
// 2) include all third-party dendencies. Do not reference any project-local headers.
#include <mysql.h>
#include <dlfcn.h>
#include <boost/lexical_cast.hpp>
#include <iosfwd>
#include <iostream>
#include <vector>
#endif
Некоторые лучшие практики:
- Каждый .cpp или.C файл включают все заголовки, в которых он нуждается и не полагается на заголовки включая другие связанные заголовки
- Каждый .hpp или.h файл включают все свои зависимости и не полагаются на включенные заголовки включая другие связанные заголовки
Каждый заголовок перенесен с:
#ifndef HEADER_XXX_INCLUDED #define HEADER_XXX_INCLUDED ... #endif /* HEADER_XXX_INCLUDED */Заголовки не включают каждого другие в циклы
- Часто: существует единственный "заголовочный файл всего проекта" как "config.h" или ".h", который всегда включается сначала любым .cpp или.C файлом. Обычно это имеет связанные с платформой данные конфигурации, константы всего проекта и макросы и т.д.
Это не обязательно "лучшая практика", но правила, за которыми я обычно следую также:
- Определенные для проекта заголовки включены как
#include "..."и перед заголовками в масштабе всей системы, которые включены как#include <...> - Определенные для проекта заголовки включены в алфавитном порядке как способ гарантировать, что нет никакого случайного, скрытого требования, в который порядок они включены. Поскольку каждый заголовок должен включать своих зависимых, и заголовки должны быть защищены от нескольких включение, необходимо смочь включать их в любой порядок, которого Вы желаете.
Используйте только минимальное количество, включает необходимый. Бесполезный включая замедляет компиляцию.
Кроме того, Вы не должны включать заголовок, если Вам просто нужно к указателю на класс. В этом случае можно просто использовать предописание как:
class BogoFactory;
править: Только прояснить. Когда я сказал, что минимальное количество, не означал создавать, включают цепочки как:
a.h
#include "b.h"
b.h
#include "c.h"
Если a.h нужен c.h, он должен быть включен в a.h, конечно, для предотвращения проблем обслуживания.
Построение, что сказанный antti.huima:
Скажем, у Вас есть классы A, B, и C. Зависеть от (включает) B, и и A и B зависят от C. Однажды Вы обнаруживаете, что больше не должны включать C в A, потому что B делает это для Вас, и таким образом, Вы удаляете это #include оператор.
Теперь, что происходит, если в какой-то момент в будущем Вы обновляете B, чтобы больше не использовать C? Внезапно A не повреждается ни на каком серьезном основании.
В A.cpp всегда включайте A.h сначала, чтобы гарантировать, что A.h не имеет никаких дополнительных зависимостей. Включайте всех локальных (тот же модуль) файлы перед всеми файлами проекта перед всеми системными файлами, снова чтобы гарантировать, что ничто не зависит от предварительно включенных системных файлов. Используйте предописания как можно больше. Используйте #indef/#define/#endif шаблон, Если заголовок включен в A.h, Вы не должны включать его в A.cpp. Любые другие заголовки, в которых нуждается A.cpp, должны быть явно включены, даже если им, оказывается, предоставляют другие.h файлы.
Существует несколько проблем с #include моделью, используемой в C/C++, при этом основной - это, это не выражает фактического графа зависимостей. Вместо этого это просто связывает набор определений в определенном порядке, часто приводящем к определениям, существующим другого порядка в каждом исходном файле.
В целом включать файловая иерархия Вашего программного обеспечения - что-то, что необходимо знать таким же образом, как Вы знаете свой datastructures; необходимо знать, какие файлы включены от где. Считайте свой исходный код, знайте, какие файлы высоки в иерархии, таким образом, можно постараться не случайно добавлять включение так, чтобы это было включено "отовсюду". Думайте трудно, когда Вы добавляете, что новое включает: я должен действительно включать это здесь? Что другие файлы будут оттянуты в том, когда я сделаю это?
Две конвенции (кроме уже упомянутых), который может выручить:
- Один класс == один исходный файл + один заголовочный файл, последовательно называемый. Класс A входит в A.cpp и A.h. Шаблоны кода и отрывки хороши здесь для сокращения объема необходимого ввода для объявления каждого класса в отдельном файле.
- Используйте Impl-шаблон, чтобы не подвергать внутренних участников в заголовочном файле. impl шаблон означает помещать всех внутренних участников в структуру, определенную в .cpp файле, и просто имейте частный указатель с предописанием в классе. Это означает, что заголовочный файл должен будет только включать те headerfiles, необходимые для его открытого интерфейса, и любые определения, необходимые для его внутренних участников, будут не допущены в headerfile.