On Thu, 19 Apr 2007, Hyrum K. Wright wrote:
> There are several small and frequently called functions in the JavaHL
> C++ classes which could be inlined by the compiler. (One example is the
> Pool::pool() function.) By having the compiler inline such functions,
> overhead is eliminated, and other optimizations possibly performed. C++
> provides the "inline" keyword to allow us to suggest that the compiler
> inline these functions. (Actual inlining is up to the compiler, but
> most compilers worth their salt will inline these types of functions
> regardless of the "inline" keyword.)
>
> The catch here is that the function implementation must be moved to the
> header file, so that it is available to each source file upon
> compilation. The function definition now becomes part of the interface,
> and code compiled against different versions of the function are now no
> longer binarily compatible. Because we make no compatibility guarantees
> within JavaHL itself, I don't see this as a problem.
>
> Thoughts?
We haven't been trying to keep binary compatibility at the C++ level;
it's considered part of the implementation, rather than part of the
public interface (as the Java APIs are). Go for it.
Question: Should you be using APR_INLINE, as we do in core
Subversion's C code?
- application/pgp-signature attachment: stored
Received on Thu Apr 19 20:26:24 2007