> > However, reliable warning without explanations seems to be a good
> > thing.
> How? I think it's completely useless if you have no idea what it's
> caused by and what to do about it.
> Jonas
Because I know, that I have to fiddle with program structure or something. One
less reason to loo
On 24 jan 2007, at 13:01, Пётр Косаревский wrote:
Implementing it for all cases is non-trivial and has low priority.
Actually, implementing the warning is easy, but always adding the
reason why it isn't inlined is more difficult.
I think, that there are many reasons, which will not help me
> > Implementing it for all cases is non-trivial and has low priority.
> Actually, implementing the warning is easy, but always adding the
> reason why it isn't inlined is more difficult.
> Jonas
I think, that there are many reasons, which will not help me a single bit.
However, reliable warni
On 24 jan 2007, at 12:46, Jonas Maebe wrote:
No, inline is and will always only be a hint. There are currently
no provisions in the compiler which allow it to inform you in all
cases where it does not perform the inlining (if you turn on
warnings, it will warn for some cases).
Implementi
On 24 jan 2007, at 12:03, Пётр Косаревский wrote:
Add {$inline on} to your source
So I can be sure, that if it compiles, all inlines are implemented/
forced?
No, inline is and will always only be a hint. There are currently no
provisions in the compiler which allow it to inform you in al
On Wed, 24 Jan 2007 10:49:07 +0100
Jonas Maebe wrote
HASINLINE is simply a temporary internal compiler define which was
introduced to indicate that the compiler supports the "inline"
directive. It is not to be used your own code, since it will be
removed from the compiler (it even has already bee
On 24 jan 2007, at 11:57, Пётр Косаревский wrote:
on. As of 2.1.1, it won't matter anymore either since the compiler
will always accept the inline specifier, but only actually do
something with it if inlining is turned on.
Is there a way to know (in terms of $if etc.) that compiler
actually
> on. As of 2.1.1, it won't matter anymore either since the compiler
> will always accept the inline specifier, but only actually do
> something with it if inlining is turned on.
Is there a way to know (in terms of $if etc.) that compiler actually does
something?
_
On 23 Jan 2007, at 17:19, Alexander Todorov wrote:
What is the name of the conditional when we have inline on?
I thought I can do {$IFDEF HASINLINE} but it doesn't work?
HASINLINE is simply a temporary internal compiler define which was
introduced to indicate that the compiler supports the
Hello Alexander,
If the "documented" compiler directive variable isn't working, I would just
make my own so I only had to change one of code:
{$DEFINE USEINLINE}
{$INFO = }
{$IFDEF USEINLINE}
{$INFO COMPILING WITH INLINE }
{$ELSE}
{$INFO COMPILING WITHOUT INLINE }
{$ENDIF}
Hello,
What is the name of the conditional when we have inline on?
I thought I can do {$IFDEF HASINLINE} but it doesn't work?
Can you point me to some documentation please?
At
http://community.freepascal.org:1/docs-html/prog/progap7.html#x308-31G
I don't see conditionals for the inline o
11 matches
Mail list logo
