Речь идёт о высоте в положении сидя. В среднем для взрослого человека она составляет примерно чуть больше половины от высоты стоя, так что не думаю что это ошибка.
Мне лично пока нравится подход, при котором краткое описание (\brief, \param, \return и т.д.) указывается перед объявлением метода, а подробное описание (\detail) перед его определением. Такой подход, в частности, используется в µOS++.
Я так понял, \code и \endcode требуют скопировать всю функцию в комментарий, что дико неудобно.
Это не так, воспринимайте эти команды как способ оформления текста. Вы можете разместить там абсолютно произвольный код, причём даже не имеющий отношения к вашей функции, и в любом объёме.
И, да, я убеждаюсь в том, что Doxygen не совсем подходящее решение для вас. Судя по сказанному, вам просто требуется преобразовать исходники в удобный для чтения формат, снабженный иллюстрациями, а не автоматически генерировать документацию для своего кода.
Эта штука для javascript? Просто мне для c++
Нет, не только. Вот результат её работы для .cpp файла:
Код примера
// В данном файле определена функция, которая возвращает n-е число Фибоначчи.
// Данная задача решается с помощью быстрого возведения матрицы в степень, что позволяет обеспечить быстрое вычисление искомого значения
int fib(int n)
{
int a = 1, ta,
b = 1, tb,
c = 1, rc = 0, tc,
d = 0, rd = 1;
while (n)
{
// Если степень нечетная, то умножаем вектор R на матрицу A
if (n & 1)
{
tc = rc;
rc = rc*a + rd*c;
rd = tc*b + rd*d;
}
// Затем умножаем матрицу A на саму себя
ta = a; tb = b; tc = c;
a = a*a + b*c;
b = ta*b + b*d;
c = c*ta + d*c;
d = tc*tb+ d*d;
n >>= 1;
}
return rc;
}
Насколько я понимаю, вам необходимо добавить в документацию к тем или иным документируемым элементам (например, функции) пояснение относительно того, как работает код внутри них?
Вполне возможно, вашу задачу можно решить путём использования команд \code и \endcode (о них я писал в статье), но вы уверены, что Doxygen подходящий инструмент для решения вашей задачи? Ведь основной его задачей является документация API, соответственно, функции и методы представляются по большей части как чёрные ящики. Можете убедиться в этом изучив примеры существующих документаций и того, что и как документируется в них.
Мне кажется, к тому, что вы ищите ближе тот же Docco.
r44083, я пошёл самым простым путём: поставил подсветку синтаксиса для языка, в котором символ для начала комментариев такой же, какой использует и Doxygen (да, это был старый-добрый Python).
Вообще, есть специальные пакеты для подсветки его синтаксиса (например, этот), но мне не приходилось ими пользоваться.
Да, ещё есть команда \example, которая позволяет добавить ссылку на пример в документируемый элемент (а также в отдельный список примеров, если он у вас создаётся).
Но в этом случае будет добавлена именно ссылка, а не вставлен код. Пример ниже:
Эту команду удобно использовать, когда код примера у вас большой. В случае, если же пример небольшой, на мой взгляд, предпочтительнее использовать непосредственную вставку кода (три способа для этого я описал в статье). Вообще, посмотреть в живую на пример использования этой команды можно здесь.
Выше в разделе «Код внутри документации» я писал про команду \snippet. Мне кажется, что это именно то, что вам нужно.
Приведу сразу пример из документации. Пусть в файле snippets/example.cpp у вас есть некоторый код, в нём вы выделяете пример при помощи документирующих блоков с указанием имени фрагмента.
QImage image(64, 64, QImage::Format_RGB32);
image.fill(qRgb(255, 160, 128));
//! [Adding a resource]
document->addResource(QTextDocument::ImageResource,
QUrl("mydata://image.png"), QVariant(image));
//! [Adding a resource]
...
Затем уже в документирующем блоке, в котором вы описываете вашу функцию, вы добавляете следующую команду:
\snippet snippets/example.cpp Adding a resource
В результате в документацию будет включен следующий код:
Поэтому вопрос скорее я бы поставил так (поправьте, если я не прав): в чём разница между штатными средствами PGFPlot и GNUPlot? Разработчики PGFPlot отвечают следующее:
– Штатные средства не требуют установки внешних приложений и не требуют указания каких-либо дополнительных опций в командной строке;
– Штатные средства не создают огромное число временных файлов;
– GNUPlot использует радианы для тригонометрических функций, тогда как штатные средства используют по умолчанию градусы (это можно изменить, если поставить trig format=rad);
– GNUPlot быстрее;
– GNUPlot имеет большую математическую библиотеку;
– GNUPlot точнее (однако начиная с версии 1.2 это больше не является серьёзной проблемой).
Хотя на мой взгляд особых кардинальных различий между этими средствами нет, которые бы проявлялись в повседневной работе.
Для этого используется свойство major tick length для основных засечек (по умолчанию 0.15 см) и minor tick length для дополнительных (по умолчанию 0.1 см).
Если интересно, о других настройках засечек можно прочитать в документации (стр.276) или спросить здесь (это будет очень полезно для будущих читателей).
В связи с этим предлагаю ознакомиться со следующей дискуссией.
Мне лично пока нравится подход, при котором краткое описание (
\brief,\param,\returnи т.д.) указывается перед объявлением метода, а подробное описание (\detail) перед его определением. Такой подход, в частности, используется в µOS++.И, да, я убеждаюсь в том, что Doxygen не совсем подходящее решение для вас. Судя по сказанному, вам просто требуется преобразовать исходники в удобный для чтения формат, снабженный иллюстрациями, а не автоматически генерировать документацию для своего кода.
Нет, не только. Вот результат её работы для .cpp файла:
Пример кода позаимствован отсюда
Вполне возможно, вашу задачу можно решить путём использования команд \code и \endcode (о них я писал в статье), но вы уверены, что Doxygen подходящий инструмент для решения вашей задачи? Ведь основной его задачей является документация API, соответственно, функции и методы представляются по большей части как чёрные ящики. Можете убедиться в этом изучив примеры существующих документаций и того, что и как документируется в них.
Мне кажется, к тому, что вы ищите ближе тот же Docco.
Вообще, есть специальные пакеты для подсветки его синтаксиса (например, этот), но мне не приходилось ими пользоваться.
Но в этом случае будет добавлена именно ссылка, а не вставлен код. Пример ниже:
Эту команду удобно использовать, когда код примера у вас большой. В случае, если же пример небольшой, на мой взгляд, предпочтительнее использовать непосредственную вставку кода (три способа для этого я описал в статье). Вообще, посмотреть в живую на пример использования этой команды можно здесь.
Приведу сразу пример из документации. Пусть в файле snippets/example.cpp у вас есть некоторый код, в нём вы выделяете пример при помощи документирующих блоков с указанием имени фрагмента.
Затем уже в документирующем блоке, в котором вы описываете вашу функцию, вы добавляете следующую команду:
В результате в документацию будет включен следующий код:
Если желаете, могу добавить пример в статью.
Результат таков.
Поэтому вопрос скорее я бы поставил так (поправьте, если я не прав): в чём разница между штатными средствами PGFPlot и GNUPlot? Разработчики PGFPlot отвечают следующее:
Хотя на мой взгляд особых кардинальных различий между этими средствами нет, которые бы проявлялись в повседневной работе.
Если интересно, о других настройках засечек можно прочитать в документации (стр.276) или спросить здесь (это будет очень полезно для будущих читателей).
P.S. Спасибо за внимательность, исправил.