Лучшие практики для допускающего повторное использование встроили C?
Ну, как первая точка вызова, я сказал бы относительно общих метрик, HSV (Оттенок, Насыщенность и Значение) или HSL являются лучшим представителем того, как люди чувствуют цвет, чем говорят RGB или CYMK. См. HSL, HSV на Википедию .
я предполагаю наивно, что я вывел бы точки на печать в пространстве HSL для двух цветов и вычислил бы величину вектора различия. Однако это означало бы, что яркий желтый и яркий зеленый будут считать столь же отличающимся как зеленым к темно-зеленому. Но тогда многие рассматривают красные и розовые два различных цвета.
, Кроме того, векторы различия в том же направлении в этом пространстве параметров не равны. Например, человеческий глаз берет зеленый намного лучше, чем другие цвета. Сдвиг в оттенке от зеленого той же суммой как сдвиг от красного может казаться больше. Также сдвиг в насыщенности от небольшого количества для обнуления является различием между серым и розовым цветом, в другом месте сдвиг был бы различием между двумя оттенками красного цвета.
С точки зрения программистов, необходимо было бы вывести векторы различия на печать, но измененный матрицей пропорциональности, которая скорректирует длины соответственно в различных регионах пространства HSL - это было бы довольно произвольно и будет основано на различных цветных идеях теории, но будет настроено справедливо произвольно в зависимости от того, к чему Вы хотели применить это.
Еще лучше, Вы видели, сделал ли кто-либо уже такую вещь онлайн...
4 ответа
Очень хороший вопрос, и ответ на него непростой. Следует учесть несколько моментов. Вот несколько мнений из моего опыта.
Общий код против локального копирования проекта
Одним из важных решений является использование «общего» библиотечного кода, который обновляется автоматически из центрального местоположения (библиотека повторного использования вашей компании "), или сохранить локальную копию проекта.
Это подробно обсуждается в этом вопросе SO .
Преимущество центральной библиотеки в том, что однажды выполненная работа может принести пользу многим проектам . Сложность с локальной копией проекта заключается в том, что любые исправления ошибок и улучшения не возвращаются в центральную библиотеку, и любые исправления ошибок в центральной библиотеке могут не быть внесены в ваш проект.
Но потенциальная трудность с использованием центральной библиотеки заключается в том, что люди на их конкретном компьютере неконтролируемым образом изменяют ее в соответствии со своим проектом, и это непреднамеренно нарушает работу других проектов. Я лично видел это в «обычном» коде, который наполнился #ifdef и регулярно нарушал работу других проектов.
Чтобы получить хорошую отдачу от общего кода, известного как центральная библиотека повторного использования:
Библиотека:
- должна иметь четко определенные требования, API и модульные тесты
- должны избегать кода, специфичного для проекта; он должен быть универсальным
- должен иметь механизм для чистой настройки параметров конкретного проекта (фактически это можно рассматривать как часть API)
- должен иметь формальный процесс выпуска, с номерами версий и исправлениями, проблемами необходимо отслеживать.
Индивидуальные проекты:
- не должны автоматически и слепо получать " и развертывать в других проектах, если / когда эти проекты сочтут нужными.
Если в компании нет такого процесса, тогда проект должен просто сделать локальную копию фрагмента кода (скажем, скопированного из предыдущего project) и с этого момента возьмет на себя всю ответственность за проект. Вы по-прежнему получаете некоторую выгоду от повторного использования в этой ситуации, потому что вы не переписываете его с нуля.
Конфигурация для конкретного проекта
Если для кода требуется конфигурация для конкретного проекта, в идеале она должна быть минимальной часть кода по возможности - не разбросанная по куче исходных файлов. В идеале - один заголовочный файл. Но вполне возможно, что это и файл .C (скажем, если вам нужно определить некоторые таблицы поиска). Библиотека должна предоставлять шаблон с хорошо прокомментированными параметрами.
Хороший пример того, как это можно сделать,
Это не нарушает различие, которое почти полностью определяется платформой тем не мение. Единственное определенное поведение состоит в том, что если включение, использующее "" , не может найти файл, оно выполняет поиск снова, как если бы вы сказали <> .
Я думаю, что вы " ты делаешь правильные вещи. По моему опыту, нормальный способ обработки заголовка, зависящего от платформы, заключается в том, что вы даете ему имя, которое, насколько это возможно, никогда не столкнетесь ни с чем другим, и #include его с помощью "" . Затем вы говорите портеру платформы сделать все, что необходимо для конкретного компилятора, чтобы гарантировать, что он будет найден. Обычно это просто означает указание некоторого аргумента компилятора, например -I, для того места, где он хочет сохранить файл. Так что да, один из каталогов его проекта. Но если ничего не помогает, он всегда может скопировать свой файл в какое-нибудь место, откуда его компилятор будет искать. Он мог бы даже скопировать его в свою локальную копию исходного кода вашей библиотеки, если его компилятор неоправданно затрудняет все это.
Другой способ - иметь файл в библиотеке selectplatform.h, который будет выглядеть примерно так:
// obviously WIN32 isn't an embedded platform, and GCC is too broad
// to be supported by a single header file. Replace with whatever platforms
// it is you do support out of the box.
#if _WIN32
#include "platforms/msvc32.h"
#elif __GNUC__
#include "platforms/gcc.h"
#else
#error "You must add a new clause to selectplatform.h for your platform"
#endif
Это избавляет от необходимости конфигурировать компилятор, но имеет обратную сторону: каждый новый порт платформы должен изменять файл. Если вы единственный, кто занимается портированием, это определенно не проблема. В противном случае этот файл будет разветвлен третьими сторонами. Затем, возможно, они добавят новый файл в платформы / в вашей библиотеке или, возможно, они поместят свой файл в другое место. Так что с третьими сторонами это только , вероятно, не проблема. Они могут внести свои изменения (возможно, включая заголовок своей платформы) обратно вверх по течению, если они и вы оба захотите.
No.
Normally you define a path to your lib's includes directory using a command flag in your compiler (usually, it is -I flag).
Say, if you are using GCC compiler, and your library's header files are in the
/usr/local/include/mylibheaders
then you must call compiler with following option:
-I/usr/local/include/mylibheader/mycurrentplatform
where mycurrentplatform directory is different for each project and contains project-specific libraryConfig.h
Thus, you can use #include in every project.
На самом деле это скорее вопрос управления конфигурацией, чем вопрос C. По моему опыту, наиболее полезно использование хорошей программы контроля версий. Найдите тот, который позволяет вам определять «проект», извлекая исходный код из нескольких разных мест. Поймите, что определение «проекта» в вашей программе управления версиями станет важным элементом при построении проекта.
Также важно иметь возможность вносить изменения в код вашей библиотеки для ветки проекта и несколько раз проверять их в системе управления версиями без необходимости проверять изменения в главном местоположении библиотеки, пока изменения не будут подтверждены, поскольку они может повлиять на множество различных проектов.
Ваши библиотечные модули также могут закончиться файлом, который определяет параметры библиотеки для каждого конкретного проекта.