Вы добавляете информацию к вершине каждого .hpp/.cpp файла? [закрытый]
Это слишком большой комментарий, поэтому это псевдо-ответ.
Вот приближение к MCVE - со значительной проблемой, что, когда я компилирую его, я не вижу ошибку, которую вы видите.
arm31.cpp
#include <cstdint>
typedef struct
{
uint32_t interval;
uint16_t duration;
uint8_t max_adv_evts;
uint8_t secondary_phy;
} ble_gap_adv_params_t;
typedef struct
{
ble_gap_adv_params_t adv_params;
uint16_t adv_program;
} ble_gap_adv_data_t;
#define ADV_1M_LEGACY_CONNECTABLE (ble_gap_adv_params_t) { \
.interval = 29, \
.duration = 31, \
.max_adv_evts = 0, \
.secondary_phy = 0, \
}
static uint8_t advertising_init_common(ble_gap_adv_data_t *ble_gap_adv_data,
ble_gap_adv_params_t adv_params)
{
uint8_t advHandle = 19;
ble_gap_adv_data->adv_params = adv_params;
ble_gap_adv_data->adv_program = 31963;
return advHandle;
}
#include <iostream>
int main()
{
ble_gap_adv_data_t m_adv_data;
uint8_t m_adv_handle = advertising_init_common(&m_adv_data,
ADV_1M_LEGACY_CONNECTABLE);
std::cout
<< "handle: " << m_adv_handle << ", "
<< "program: " << m_adv_data.adv_program << ", "
<< "interval: " << m_adv_data.adv_params.interval << ", "
<< "duration: " << m_adv_data.adv_params.duration << ", "
<< "maxadvev: " << m_adv_data.adv_params.max_adv_evts << ", "
<< "secondph: " << m_adv_data.adv_params.secondary_phy << "\n";
}
Компиляция
$ g++ -O3 -g -std=c++11 -Wall -Wextra -Werror -c arm31.cpp
$
, которая не выдает предупреждений (на Mac с MacOS 10.14.2 Mojave, используя home- встроенный G ++ 8.2.0). Чтобы получать предупреждения, мне также нужно использовать -pedantic:
$ g++ -O3 -g -std=c++11 -Wall -Wextra -Werror -pedantic -c arm31.cpp
arm31.cpp: In function ‘int main()’:
arm31.cpp:18:9: error: C++ designated initializers only available with -std=c++2a or -std=gnu++2a [-Werror=pedantic]
.interval = 29, \
^
arm31.cpp:39:52: note: in expansion of macro ‘ADV_1M_LEGACY_CONNECTABLE’
ADV_1M_LEGACY_CONNECTABLE);
^~~~~~~~~~~~~~~~~~~~~~~~~
arm31.cpp:19:9: error: C++ designated initializers only available with -std=c++2a or -std=gnu++2a [-Werror=pedantic]
.duration = 31, \
^
arm31.cpp:39:52: note: in expansion of macro ‘ADV_1M_LEGACY_CONNECTABLE’
ADV_1M_LEGACY_CONNECTABLE);
^~~~~~~~~~~~~~~~~~~~~~~~~
arm31.cpp:20:9: error: C++ designated initializers only available with -std=c++2a or -std=gnu++2a [-Werror=pedantic]
.max_adv_evts = 0, \
^
arm31.cpp:39:52: note: in expansion of macro ‘ADV_1M_LEGACY_CONNECTABLE’
ADV_1M_LEGACY_CONNECTABLE);
^~~~~~~~~~~~~~~~~~~~~~~~~
arm31.cpp:21:9: error: C++ designated initializers only available with -std=c++2a or -std=gnu++2a [-Werror=pedantic]
.secondary_phy = 0, \
^
arm31.cpp:39:52: note: in expansion of macro ‘ADV_1M_LEGACY_CONNECTABLE’
ADV_1M_LEGACY_CONNECTABLE);
^~~~~~~~~~~~~~~~~~~~~~~~~
arm31.cpp:22:1: error: ISO C++ forbids compound-literals [-Werror=pedantic]
}
^
arm31.cpp:39:52: note: in expansion of macro ‘ADV_1M_LEGACY_CONNECTABLE’
ADV_1M_LEGACY_CONNECTABLE);
^~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
Следующие шаги
Пожалуйста, возьмите этот исходный код и скомпилируйте его в своей системе. Затем повозитесь с ним, пока он не воспроизведет ошибку, которую вы видите. Затем опубликуйте этот исправленный код для редактирования вопроса.
16 ответов
Информация о том, кто создал файл и когда и кто отредактировал ее и когда все в управлении исходным кодом. Если у Вашей команды будут хорошие методы вокруг комментариев регистрации, то Вы будете знать причины каждого изменения также. Никакая потребность в комментариях для того материала.
Я думаю, что это на 100% законно - мудрый, даже - для помещения блока комментария, пока необходимо, объясняя цель класса/модуля. Когда следующий человек пойдет для изменения его, у них будет лучшая идея полного видения и является ли этот файл соответствующим местом для их изменения.
Некоторые магазины помещают уведомления об авторском праве и другую легальную безделушку в комментариях исходного файла. Это кажется мне просто глупый - если Ваш (неOSS) исходный код сделал его на чужие серверы без Вашего ведома или разрешения, уведомление об авторском праве, вероятно, не собирается удерживать их от выполнения чего-либо с ним. IANAL, YMMV.
Я использую Подверсию. Вот то, что мне нравится помещать близко к вершине.
$Id$
$HeadURL$
Это заменяет пересмотром, последним редактором и затем местоположением файла в репозитории. Хотя я всегда работаю из рабочих копий, это позволяет мне печатать/посылать файл по электронной почте и посмотреть на него позже для знания точно, куда он прибыл из. $HeadURL$ особенно хорошо, потому что это говорит, в каком проекте и ответвлении файл находится и как стать к нему (любезным с большими вложенными подпакетами и т.п.).
Согласованный бесполезность больших ручных блоков комментария — хотя docstrings/Javadocs рекомендуются — и при автоматическом добавлении журнала фиксации.
Это кажется, что некоторые из Вас используют ужасный VCSes, если Вы получаете diffs или конфликты слияния, сгенерированные самими ключевыми словами. Подверсия обрабатывает его хорошо.
Мы используем MSVC & VSS и имеем плагин, который добавляет любой комментарий Вы specifiy при регистрации в файл, в этом регистрируются как комментарий. Очень удобно посмотреть наверху файла CPP для обнаружения номера билета отслеживания ошибок, для которого было внесено изменение.
Все говорят, что Ваше управление исходным кодом будет иметь дату и информацию о программисте, но это не всегда верно. Я работал в магазине, который использовал Безопасный Источник, и он был прекрасен, пока кто-то не решил переместить файл в другое местоположение. В той точке это по существу стало новым файлом согласно SS, и никакая предыдущая история не существовала.
Возможно, из-за этого имя программиста и дата были автоматически добавлены к разделу комментария наверху файла. Когда там добрался, чтобы быть больше, чем приблизительно 10 записей, мы разделим все средние, покидая только исходную дату и автора и текущую информацию.
Я обычно включаю описание цели кода, найденного в том файле. Все остальное, кажется, обрабатывается в другом месте: даты и комментарии в управлении исходным кодом, и т.д.
я обычно только добавляю любую "информацию о комментарии", когда... я не буду думать, что буду помнить или не очевидный, что что-то делает или когда я выпускаю исходный код, и я на самом деле хочу, чтобы другие смогли использовать/изучать от него.
Если Вы используете CVS, проверяете, это - замены ключевого слова. Они помогут автоматизировать встраивание та информация.
Лично я засовываю это во главе всех моих исходных файлов:
// $Id$
Другие информативные комментарии, которые я встраиваю, чтобы быть проанализированным с doxygen, если они касаются чего-то определенного (файл, класс, тип, и т.д.).
Это - то, что я обычно поместил наверху файлов:
///////////// Copyright © 2008 DesuraNET. All rights reserved. /////////////
//
// Project : [project name]
// File : [file name]
// Description :
// [TODO: Write the purpose of ... ]
//
// Created On: 11/12/2008 2:24:07 PM
// Created By: [name] <mailto:[email]>
////////////////////////////////////////////////////////////////////////////
и я настроил макрос в vis, чтобы сделать, включают его и заполняют информацию по умолчанию, когда я делаю новый файл
Я не встраиваю дату, потому что это избыточно. Если кто-то хочет знать дату, файл был создан, не доверяют автору, доверяют Вашей системе управления исходным кодом. Это должен быть категорический ответ для даты создания.
Я определенно не против встраивания регистрации сообщений все же. Это довольно полезно.
Мы используем наш RCS для автоматической штамповки следования файла:
Авторское право,
Имя файла RCS,
Измененная дата,
Автор последнего изменения,
Число пересмотра RCS
Я думаю, что это очень удобно. Я действительно как наличие имени файла, автоматически заполненного в каждом файле, потому что это делает поиск решения для файлов очень быстрым.
Первоначально отвеченный здесь, но, так как удалено: 134249
Я только поместил бы две вещи:
- лицензирование/авторское право информации
- комментарии, требуемые генерирующими документацию инструментами (т.е. комментарии должны быть в заголовке для работы - иначе, они должны войти в файлы определения),
Что-либо еще - ненужный пух, который не будет сохраняться и в конечном счете станет хуже, чем ничто вообще.
В то время, когда я работал на крупную оборонную компанию, и у нас были драконовские стандарты кодирования. Если бы Вы следовали за ними к букве (и большинство людей не делает), то большинство Ваших заголовков было бы составлено главным образом того бессмысленного пуха. Вдвойне хуже то, что тот же самый пух требуется, чтобы быть помещенным в исходные файлы также, что означает, что две копии пуха становятся устаревшими и становятся вводящими в заблуждение.
Я раньше любил помещать ключевые слова управления версиями в заголовок файла. Но восстановленный с того несчастья.:) По двум причинам:
- Никто не поместил комментарии в это, имеют любое применение. Вы всегда волнуете рассмотрение diffs, о котором сообщает система управления версиями.
- Это создает кошмар в попытке к различному большому filesets, потому что ключевые слова создают различия, которые являются единственной разницей в файле.
Я включаю имя файла, краткое описание цели файла и тег $Id$ в целях Подверсии или CVS. Создатель файла и дата создания могут быть найдены путем проверки репозитория, таким образом, это не нужно.
Имя файла включено, потому что в зависимости от того, что Вы используете для редактирования файла, который не мог бы быть совершенно очевидным, когда Вы редактируете его. Описание может использоваться, чтобы определить, принадлежит ли немного кода файла, или если это должно быть перемещено к другому. И конечно, $Id$ дает Вам прошлый раз изменения и последнего редактора.
Встраивание сообщений регистрации только полезно, когда сообщение полезно, и только если файл обновляется однажды и некоторое время. Включая каждое сообщение просто чрезмерно увеличит размер файла до такой степени, когда существует больше комментариев, описывающих изменения, чем существует фактический код. Лучше всего оставить это репозиторию также; часто это - только короткая командная строка для получения журнала регистрации файла.
Если Вы застреваете с системой управления версиями, которая не может сохранить историю для перемещений и копии, в этом случае просто сослаться на исходный файл и его номер версии. Конечно, если Вы используете систему, которая была создана когда-то в этом веке а не последнее, которое не должно быть проблемой.
Мы требуемся поместить информацию об авторском праве наверху каждого файла. Я думаю даты, авторы, и название файла является пустой тратой времени.
У нас также есть наша система управления исходным кодом, добавляют комментарии регистрации у основания каждого файла. Я первоначально ненавидел журнал изменений, но со временем я учился любить его. Это действительно помогает при слиянии изменений.
Не делать. Большая часть материала может быть получена от системы управления версиями при необходимости, таким образом, это избыточно для добавления. Это оставило бы Вас с описанием содержания файла, но это - часть документации класса большую часть времени (или по крайней мере документации определенного типа).
Я не делаю ни одного из тех, но с другой стороны, мне не нравится хлам.