[fpc-devel] Optimizing unused return values of inline functions
Stefan Glienke
sglienke at dsharp.org
Tue Aug 22 15:31:45 CEST 2017
Often a fluent API has some grammar described via different interfaces that are implemented by either one (in this case you always return Self) or different classes.
It is not just to chain methods together that you could also write like you did.
> On 22 August 2017 at 13:15 Michael Van Canneyt <michael at freepascal.org> wrote:
>
>
>
>
> On Tue, 22 Aug 2017, Thaddy de Koning wrote:
>
> >> On 21.08.2017 13:22, Michael Van Canneyt wrote:
> >>>
> >>>
> >>> On Mon, 21 Aug 2017, Benito van der Zander wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> This pattern is not inherently efficient. Why should it be ?
> >>>>
> >>>>
> >>>> It is not efficient, because of the pointless instruction!
> >>>
> >>> I am not speaking of the current FPC implementation. It may well be that
> >>> the
> >>> code is not most optimal.
> >>>
> >>> I am asking, why do you think *this pattern* (of always returning self)
> >>> should be inherently more efficient ?
> >>
> >> The pattern definitely has its uses. E.g. in the user space of our
> >> operating system at work we have a StdOutPrinter class that is used like
> >> this:
> >>
> >> === code begin ===
> >>
> >> StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
> >> ")->hex()->out(42)->line();
>
> Call me old-fashioned, but I much prefer
>
> With StdIO::stdOutPrinter() do
> begin
> out("Helllo World ");
> out(42);
> out("");
> hex();
> out(42);
> line();
> end;
>
> I see no point or gain in the "fluent" code.
>
> Michael.
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
More information about the fpc-devel
mailing list