inlining or not inlining...

so so at so.so
Fri Feb 11 16:13:34 PST 2011


> All of this is hardly related to the simple feature I initially asked  
> for:
>
> 	string escString (string s) @tellmeifnotinlined {
> 	    s2 = s.replace("\n","\\n");
> 	    s2 = s.replace("\t","\\t");
>              return s2;
>          }
> 	void show (X x) {
> 	    // ... use escString ...
>          }
> ==>
> 	Warning: function 'escString' in module 'foo' (line 123) was not  
> inlined.
> 	(or else it was actually inlined)
>
> Which (I guess) is not that a big deal since the compiler needs to  
> decide anyway. I just wish to be informed of the result of the decision  
> procedure, only in case of 'no'.
>
> Denis

Guys, i don't know what are you trying or why you simply seem to avoid my  
reasoning on this, if you don't need this (and you all seem not use it)  
why are you trying to find solutions for the problems that doesn't affect  
you directly? :)

Unline a few of you said this is not a complex problem and actually it  
hasn't been complex in C++ either for again, practical purposes.

Standard C++ says:
For class/struct methods, compiler inlines things and it is aware of most  
of them wrappers so you don't need "inline" keyword there.
But still it does have this keyword as a hint to use other methods. This  
has never been enough and all major compilers now have forced inlines.  
(always_inline, __forceinline...)
What they do is forcing to compiler inline a function and if compiler  
won't do it it issues an error to state why.

All is needed is just i said in another post:
@inline // inline or issue and error why you won't.

- simple
- serves practical purposes rather than fiction
- it does no harm to anyone
- so easy to implement
- it is sometimes advanced but still something controllable

Now please what is wrong here someone enlighten me.

Thanks.


More information about the Digitalmars-d mailing list