[Numpy-discussion] Core math library in numpy

[Matthieu Brucher]

The inline keyword is never an obligation to inline, it's only a
proposal. And the compiler in fact doesn't care about it. When using
an optimization mode, the compiler will inline the function if it is
simple enough. It's its call. It will even be easier to do so if the
static keyword is used, as it knows that it must not supply an
external copy.

Matthieu

2009/2/24 Neal Becker <ndbecker2 at gmail.com>:
> Matthieu Brucher wrote:
>
>> In fact, the __inline is not helpful. It's the static keyword that
>> enables the compiler to inline the function if the function is small
>> enough. As the static indicates that the function will not be seen
>> from the outside, it can do this.
>>
>
> Depends what is meant by 'helpful'.  My understanding is that gcc will both
> inline the function within the current module and supply an external copy if
> __inline__ is used.
>
>> Matthieu
>>
>> 2009/2/24 David Cournapeau <cournape at gmail.com>:
>>> On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris
>>> <charlesr.harris at gmail.com> wrote:
>>>>
>>>> In order to inline, the function definition would need to be in the
>>>> header and a library version would still be required for passing
>>>> functions by address or in case the compiler decided *not* to inline.
>>>
>>> I looked more into this while solving some nasty mingw FPU handling
>>> bugs on windows 64. I learnt one thing I did not know about C: you can
>>> define inline static functions in headers, and that's the approach
>>> follows for very short functions. For example, FPU status flag code in
>>> BSD is defined as follows:
>>>
>>> fenv.h:
>>>
>>> static __inline int feraiseexcept(int __excepts);
>>> ...
>>>
>>> fenv.c:
>>> int fereaiseexcept(int excepts);
>>>
>>> we could follow this, maybe - once we solve the inline problem (many
>>> compilers do not support it for C). Having optional, non inline is
>>> important IMHO, for future SSE or other dynamically loaded
>>> implementations (where inline is not an option).
>>>
>>> David
>>> _______________________________________________
>>> Numpy-discussion mailing list
>>> Numpy-discussion at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>>
>
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher