Multiple return values...

[Manu]

On 11 March 2012 16:01, Artur Skawina <art.08.09 at gmail.com> wrote:

> > which I don't imagine D will be able to support any time real soon?
>
> In fact, until GDC learns cross-module inlining, using these modes is the
> only
> way to make the compiler generate sane code


Yeah I'm very concerned by this currently. But it seems to we a well known
issue with a plan/intent to fix it right?
(Side note: I'd still really like an explicit @forceinline attribute)


> > ...and even then, relying on WPO for the language to generate good code
> in certain circumstances is a really really bad idea. This makes the task
> of implementing an efficient compiler for the language extremely difficult.
>
> There is a reason why i never even considered trying out a non-gcc-based D
> compiler... [1]
>
> For a language like D, WPO in some form is almost required; w/o it you'd
> need to
> always think about how the compiler will treat your code; which, while
> possible,
> would often result in more "unnatural" and tricky solutions. (In C/C++
> there's
> a *.h/*.c split, which helps mitigate the problem)
>

"think about how the compiler will treat your code" ... "'unnatural' and
tricky solutions" ... Outside of cross module inlining, what are some other
common problem cases?

C/C++ .h files only really simplify 2 things, inlining, and templates, but
I can't see how the situation is any different in D?
My understanding is that templates depends on .d/.di files being present
during compilation? So why doesn't D do inlining the same way? If I declare
some inline function in a .d/.di file, surely it should be capable of
inlining?
C/C++ can't inline something from a foreign object either without a
definition in a header...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120311/6199ad14/attachment.html>