>[The following falls under the category "micro-optimisation" but may IMO
>still be worth an investigation]
>After working on various parts of OpenSolaris I found that is common to
>use the following sequence to concatenate strings:
>-- snip --
>...
>char *s;
>...
>strcat(s, "foo");
>strcat(s, "/");
>strcat(s, "bar");
>-- snip --
>(note: The example is simplified, normally { "foo", ",", "bar" } are
>normal strings and no static string literals)
>while this code is simple and easy to understand it is quite inefficient
>- |strcat()| will always walk |s| each time. If |s| already contains a
>large path this will be horrible time-consuming.
>
>Back in the 1990 timeframe there was the "DICE C" compiler for AmigaOS
>(AFAIK SAS C/C++ had something similar - but I am not sure) which solved
>this issue quite cleanly via having a special version of |strcat()|
>which returned the end of the string instead of the beginning (like
>ANSI-C |strcat()| does) ... I don't remember the functions's name in
>"DICE C" anymore - lets call it |strFOOcat()| for now...
>
>... the idea would be to introduce the same functionality to Solaris's
>libc+kernel to make such cases much faster (and carry the idea to the
>standard bodies (ISO-C and whoever maintains the widechar interfaces)
>for inclusion).
>
>Proposed functions would be (with "FOO" replaced with a better name):
>|strFOOcat()| - like |strcat()| but returns the pointer to '\0'
>|wcsFOOcat()| - like |wcscat()| but returns the pointer to '\0'
>|wsFOOcat()| - like |wscat()| but returns the pointer to '\0'
>
>Comments/suggestions/ideas welcome...
Why not a varargs: strMANYcat():
strMANYcat(s, "foo", "/", "bar", NULL);
(In most cases, the function call overhead dominates the "finding the
end of string" because pushing stack frames modifies memory and
finding the end of a string likely to be in the L1 cache is *really*
cheap)
Casper
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
