[CLN-list] New version of MAYBE_INLINE patch

[Alexei Sheplyakov]

Dear Richard,

New version of the patch is available at

http://theor.jinr.ru/~varg/0001-CL_INLINE-co-ISO-C-compliant-macros-for-selecti.patch.bz2

It gets rid of MAYBE_INLINE completely. I don't post the patch here,
since it's large enough (99k uncompressed). Sorry for that, but replacing
MAYBE_INLINE in a gradual manner turned out to be surprisngly difficult,
i.e. more difficult than rewriting them all.

> >These attributes make the compiler inline functions more aggressively,
> >so no out of line copies (which cause link failure) produced.
> 
> *That* should be explained in source code comments.

Done. But I think gcc manual explains that even better.

> >I found out my patch was incomplete.
> 
> Which makes me wonder: what's the definition of 'complete', here?

It's explained right in the next sentence:

> > In some places non-inline versions of functions was used intstead of inline ones.

> Does it work or not?

Yes.

> Does it depend on compiler flags like -finline-limit?

Yes, because quite a number of MAYBE_INLINE stuff left unchanged
(in the previous version). The new version of the patch replaces them
all, so the dependence on the compiler flags is not that severe.

> >Why equal_hashcode(const cl_RA&) is not inlined, but other type-specific 
> >equal_hashcode functions are?

The inline version of equal_hashcode(const cl_RA&) is used now.

> >Why sign is cl_I? It looks like bool would be enough.
> 
> Why not cl_I? Remember that small integers are immediate.

Although it doesn't consume more memory, tests on it (i.e. minusp) are
more expensive and involve a function call (since the inlined versions
are not used). If we care about performance (which is a good idea) using
plain bool would be better.

> I've also been pondering the removal of that own string class and 
> replacing it with std::string. But it has never been a priority and the 
> change would be somewhat intrusive. That will have to wait until some 
> time after 1.2.0 now.

OK.

> As to why it is necessary to inline cl_make_heap_string? I can't imagine 
> it is critical.

So I didn't bother to inline it.

Best regards,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/cln-list/attachments/20080115/e8293056/attachment.pgp