On Sat, 29 Sep 2001, Stas Bekman wrote: > I've implemented c) as it seems the most logical to me. Why? If you > *Set* some key/val in a subsection, you don't expect to inherit some > values for the same key from the parent section/dir. You do *Set*.
i see, that makes sense. should double check what 1.x and make sure it won't break anybody. but c) sounds correct in any case, we should probably make 1.x do that if it doesn't already. > I think apr_table needs a third constant for apr_table_overlap, since > that's where it belongs, IMHO. sounds good to me. > ok, so what's the rule of thumb of when some code should be a macro and > when a function and when an MP_INLINEd function? > > From what I remember from C++ (or was it C?), you use inline when some > code is really short, and used only a few times so you won't end up > duplicating the same machine code a few times. that's true. in this case, modperl_table_get_set should probably not be inline-d, it is only called once per function that uses it. we don't need the macro form anymore since it won't be referencing ST(x) and items. i've been using MP_INLINE for functions that are either: - only ever called once (the "wrappers" that are called by .xs), no matter what the size of code is. - short bodies of code called in "hot" code (like modperl_env_hv_store, which is called many times inside of a loop), where it is cleaner to see the code in function form rather than macro with lots of \'s --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
