0

I don't want to use cupsAddOption(), because it has quadratic behaviour (only ever adds one entry to the allocated memory block), and because it strdups every name and value string, while in my case, they are all string literals. So in a call to cupsPrintFile(), I want to pass a C array of cups_option_ts.

But as a C++ programmer, I cannot assign a C string literal (having type const char[]) to the cups_option_t fields, because they are char*.

Is that just lazy API design, or does CUPS actually manipulate those strings in-place?

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
Marc Mutz - mmutz
  • 24,485
  • 12
  • 80
  • 90

1 Answers1

0

As they are meant to point to malloced and strcpyed memory, they apparently cannot be const.

What performance penalties do you actually expect? How often do you use that function actually? Prematue optimization is often a bad habbit and results in hard to maintain code.

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
  • So what you're saying is that `static const cups_option_t options[] = { { "opt1", "value1" }, ..., { "optN", "valueN" } };` is premature optimisation and harder to maintain than `cups_option_t *options = 0; unsigned int noptions = 0; noptions = cupsAddOption("opt1", "value1", noptions, &options); ... noptions = cupsAddOption("optN", "valueN", noptions, &options);`. Riiiiiight.... – Marc Mutz - mmutz Jul 04 '15 at 22:55
  • I wonder what happens if the struct changes for some reason. And, yes, it is an optimization - apparently - why again did you not want to use the functions? I might be wrong about maintainability, though. That depends if filling the struct is really all the function does. Sure the array is not sorted or hashed? – too honest for this site Jul 04 '15 at 23:15
  • The struct won't change, because it's public, documented (well, somewhat) API. Yes I'm sure the array is not sorted or hashed: http://www.opensource.apple.com/source/cups/cups-30/cups/options.c?txt As for why not use the functions: As Alexandrescu likes to put it: No work is less work than some work. In this case, it's more correct to say that no work is less work than *a huge amount* of work (quadratic behaviour, use of dynamic memory, ...). And you're mistaking "optimisation" for "avoiding premature pessimisation". – Marc Mutz - mmutz Jul 05 '15 at 08:07