 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A little remark after looking at the (nice) isosurface code :
Vector_IsoSurface_Function, Float_IsoSurface_Function, Evaluate_Function are
declared as inline functions but only defined at the end of isosurf.cpp. It
seems gcc(g++) will not inline the function if the call is before the
definition. If you want gcc to actually inline those functions they should
be moved at the top of the file (with Evaluate_Function first)
A quick test with scene isosurfaces.pov on a x86 linux (and gcc3.2) gives
114s vs 116s only by moving the functions
(another small thing : the parameter 'in_shadow_test' is not used in
recursive function IsoSurface_Function_Find_Root_R)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e778de3@news.povray.org> , "Mael" <mae### [at] hotmail com> wrote:
> A little remark after looking at the (nice) isosurface code :
> Vector_IsoSurface_Function, Float_IsoSurface_Function, Evaluate_Function are
> declared as inline functions but only defined at the end of isosurf.cpp. It
> seems gcc(g++) will not inline the function if the call is before the
> definition. If you want gcc to actually inline those functions they should
> be moved at the top of the file (with Evaluate_Function first)
> A quick test with scene isosurfaces.pov on a x86 linux (and gcc3.2) gives
> 114s vs 116s only by moving the functions
Indeed, some compilers cannot inline such functions for odd reasons. Apart
from a workaround, I would suggest to send a feature request to the compiler
maker because in the end "inline" is just a guide and not a requirement for
the compiler to make the function inline.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Also compilers will (when using optimizations) inline functions whenever
possible anyways, whether or not they are defined as 'inline'. In some
sense the 'inline' keyword is obsolete for this purpose.
(Note that it's not obsolete completely; it has one important role which
is a bit different than this. I can explain if someone really wants... :) )
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Mar 2003 18:18:27 -0500, Warp <war### [at] tagpovrayorg> wrote:
> (Note that it's not obsolete completely; it has one important role which
> is a bit different than this. I can explain if someone really wants... :) )
http://new-brunswick.net/workshop/c++/faq/inline-functions.html#[9.5] ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e77a943@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> (Note that it's not obsolete completely; it has one important role which
> is a bit different than this. I can explain if someone really wants... :) )
I think most people here know... ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX <abx### [at] abxartpl> wrote:
> http://new-brunswick.net/workshop/c++/faq/inline-functions.html#[9.5] ?
No, that's not it.
"If you put the inline function's definition into a .cpp file, and if
it is called from some other .cpp file, you'll get an "unresolved
external" error from the linker."
That's wrong. It should say "you may get", not "you'll get".
A compiler can (and in these cases should, AFAIK) create a regular
instance of the function which is used as a regular function call when
it's not possible to inline it (eg. because the code is not available
in the current cpp file). This way there's no linkage problem.
I don't remember if gcc does this automatically, but at least you
can instruct it to do it with a compiler option.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
>> (Note that it's not obsolete completely; it has one important role which
>> is a bit different than this. I can explain if someone really wants... :) )
> I think most people here know... ;-)
Really? Perhaps you are thinking of something else than me.
The keyword 'inline' has mostly lost its meaning as an instruction for
the compiler to try to inline the function (the compiler will try to do
it anyways, regardless of the keyword). It's very similar to what happened
to the 'register' keyword, which has become completely obsolete.
However, 'inline' is not an obsolete keyword. It has an important role
which is related to linking.
Suppose that you have a function implemented in a header file, for
example like this:
double square(double d) { return d*d; }
Now you use this header file in several cpp files. This means that this
function will be used in several object files (which are what the linker
uses to create the final binary).
As long as the compiler is able to inline that function there's no
problem. However, if for some reason the compiler is unable to inline
that function, it will create an actual instance of it in the object file,
which means that you will have the same function implementation in
several object files.
This will cause a collision in the linking stage: The linker will see
two (or more) instances of the same function and will not know which one
of them to use for generating the function calls.
One solution to this problem which is sometimes seen in actual code
is to declare the function static:
static double square(double d) { return d*d; }
This means that each object file using this function (still supposing
that the compiler can't inline it) will have a unique ID for this function.
The function calls of an object file will be directed to the unique instance
of the function in that object file.
This, however, has several problems. The most obvious one is that the
same function will be linked to the final binary several times, needlessly
increasing its size. However, there's a more important problem with this
'trick', and it happens when the function has for example static variables,
eg. like this:
static int increaseCounter()
{
static int counter = 0;
return ++counter;
}
You might have a function like this which is supposed to keep some
information about the execution of the program or whatever.
However, what happens if this function is used in several object files?
Oops! Each object file uses a distinct instance of this function, each one
with its own 'counter' variable. The purpose of the whole thing got broken.
When/if the coder doing this discovers the reason he will probably move
the function from the header file to a single cpp file to avoid the problem,
losing the advantage of possibly having it inlined by the compiler. However,
there's a better solution for this:
Now, here kicks in the real power of the 'inline' declaration. If instead
of making the function static you make it inline, like this:
inline int increaseCounter()
{
static int counter = 0;
return ++counter;
}
it will work exactly as it should, even if the compiler is unable to inline
it for some reason.
This is because the standard requires that if the same 'inline' function
implementation appears in several object files, the compiler must instruct
the linker to merge them into one when linking the final binary. This way
there will be only one instance of the function in the final binary and
all function calls will call this single instance.
(Btw, the exact same principle applies to template functions. It could
be said that template functions are implicitly 'inline', whether or not
the keyword has been defined for them.)
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e784485@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>>> (Note that it's not obsolete completely; it has one important role which
>>> is a bit different than this. I can explain if someone really wants... :) )
>
>> I think most people here know... ;-)
>
> Really? Perhaps you are thinking of something else than me.
No, I didn't, but I tried to avoid having to read a page-long message ;-)
> As long as the compiler is able to inline that function there's no
> problem. However, if for some reason the compiler is unable to inline
> that function, it will create an actual instance of it in the object file,
> which means that you will have the same function implementation in
> several object files.
In fact this depends on the object file format being used. The standard
does not require not to put code for an inline function into an object file,
and in fact for certain global code optimisation strategies it can be
beneficial to have all functions' code available (also optimisations that
aggressive are rarely used or even implemented).
> This means that each object file using this function (still supposing
> that the compiler can't inline it) will have a unique ID for this function.
> The function calls of an object file will be directed to the unique instance
> of the function in that object file.
Actually the mangled name (what you call id) will be exactly the same for
all of them, but the linker will recognize the static as part of the mangled
name and for this reason not complain or compilers may decide not not make
static names visible in the object file at all (more common). This behavior
is required because it is not possible to guarantee a unique name be given
unless the compilers would know about all other instances of the function
(which would require communication).
> When/if the coder doing this discovers the reason he will probably move
> the function from the header file to a single cpp file to avoid the problem,
> losing the advantage of possibly having it inlined by the compiler.
<snip>
> This is because the standard requires that if the same 'inline' function
> implementation appears in several object files, the compiler must instruct
> the linker to merge them into one when linking the final binary. This way
> there will be only one instance of the function in the final binary and
> all function calls will call this single instance.
This is not the whole story. It is very legal to specify inline functions
with external linkage (7.1.2 paragraph 4 of the standard). This implies
that a linker (!!!) may inline function code. And in fact some do...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e783eed@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>> http://new-brunswick.net/workshop/c++/faq/inline-functions.html#[9.5] ?
>
> No, that's not it.
>
> "If you put the inline function's definition into a .cpp file, and if
> it is called from some other .cpp file, you'll get an "unresolved
> external" error from the linker."
Indeed, that is incorrect for standard-compliant compilers. Of course,
certain mainstream compilers don't care about standards. It is for everyone
to guess which company sells such a compiler...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Indeed, some compilers cannot inline such functions for odd reasons.
> Apart from a workaround, I would suggest to send a feature request to the
> compiler maker because in the end "inline" is just a guide and not a
> requirement for the compiler to make the function inline.
>
WAIT. Because it seems you [Mael] are using an outdated version of gcc.
Try using gcc-3.2:
g++ -V3.2.2 ...blahblah... -W -Wall -Winline -c -o isosurf.o isosurf.cpp
isosurf.cpp: In function `int All_IsoSurface_Intersections(OBJECT*, RAY*,
ISTACK*)':
isosurf.cpp:147: warning: unused variable `int i'
isosurf.cpp:149: warning: unused variable `int begin'
isosurf.cpp:149: warning: unused variable `int end'
/usr/include/c++/3.2.2/bits/stl_algobase.h: At top level:
config.h:235: warning: `uid_t euid' defined but not used
For any function which cannot be inlined, you get a warning when
you use -Winline. With gcc-2.95, I get tons of warnings. But with
gcc-3.2 I've never seen one (in a whole lot of code from me).
So, please upgrade. gcc-3.2 produces faster POVRay-code anyways.
(Or, complain about my ignorance in case I am wrong at this issue.)
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
