0
Я не хочу использовать cupsAddOption(), потому что он имеет квадратичное поведение (только когда-либо добавляет одну запись в выделенный блок памяти), и потому что он strdups каждую строку имени и значения, в то время как в моем случае все они являются строковыми литералами. Поэтому при вызове cupsPrintFile() я хочу передать массив C cups_option_t s.Есть ли причина, по которой `cups_option_t :: name` и` :: value` не являются `const char *`?
Но как программист на C++, я не могу назначить строковый литерал C (имеющий тип const char[]) полям , потому что они char*.
Является ли это просто ленивым API-дизайном, или CUPS фактически управляют этими строками на месте?
Так что вы говорите, что 'static const cups_option_t options [] = {{" opt1 "," value1 "}, ..., {" optN "," valueN "}};' преждевременная оптимизация и сложнее поддерживать, чем 'cups_option_t * options = 0; unsigned int noptions = 0; noptions = cupsAddOption ("opt1", "value1", noptions, & options); ... noptions = cupsAddOption ("optN", "valueN", noptions, & options); '. Riiiiiight .... –
Интересно, что произойдет, если структура по какой-то причине изменится. И, да, это оптимизация - видимо, - почему снова вы не хотели использовать функции? Однако я могу ошибаться в отношении ремонтопригодности. Это зависит от того, заполняет ли структура все функции. Уверен, массив не отсортирован или хеширован? – Olaf
Структура не изменится, потому что это общедоступный, документированный (ну, несколько) API. Да, я уверен, что массив не отсортирован или хеширован: http://www.opensource.apple.com/source/cups/cups-30/cups/options.c?txt Что касается того, почему не использовать функции: Как Alexandrescu нравится говорить: никакой работы не меньше, чем какая-то работа. В этом случае правильнее сказать, что никакая работа - это меньше работы, чем * огромное количество работы (квадратичное поведение, использование динамической памяти, ...). И вы принимаете «оптимизацию» за «предотвращение преждевременной пессимизации». –