On Thu, 12 Aug 2010 16:47:40 -0400, dsimcha dsim...@yahoo.com wrote:
== Quote from Don (nos...@nospam.com)'s article
Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts
bra...@puremagic.com
wrote:
On 8/11/2010 6:19 AM, dsimcha wrote:
An issue that's come up
On Fri, 13 Aug 2010 09:21:00 -0400, Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 16:47:40 -0400, dsimcha dsim...@yahoo.com wrote:
== Quote from Don (nos...@nospam.com)'s article
Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts
bra...@puremagic.com
wrote:
On 8/11/2010 6:19 AM, dsimcha wrote:
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in. From reading some
disassemblies, the reason seems to be because of all the ASM code that's
required for lazy parameters. I
On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts bra...@puremagic.com
wrote:
On 8/11/2010 6:19 AM, dsimcha wrote:
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in. From
reading some
disassemblies, the reason
On Wed, 11 Aug 2010 18:10:53 -0400, Tomek Sowiński j...@ask.me wrote:
Steven Schveighoffer napisał:
Hold on, can't we have enforce and lenforce (lazy enforce)?
From a simple grep, 99% of enforce instances are:
enforce(condition)
-or-
enforce(condition, compile-time-string)
-or-
Steven Schveighoffer Wrote:
[...]
Hold on, can't we have enforce and lenforce (lazy enforce)?
Or couldn't we have an overload for enforce that takes a string, and another
overload that takes a void delegate returning a string?
It makes the syntax a little grottier, but...
From a simple
== Quote from Pillsy (pillsb...@gmail.com)'s article
...if you have to write
enforce(condition,
(){ return compile-time-string ~ type.stringof; });
one time in a hundred, is it really that bad?
Cheers,
Pillsy
I think the point was that even this should be automagically
Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts bra...@puremagic.com
wrote:
On 8/11/2010 6:19 AM, dsimcha wrote:
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in. From
reading some
== Quote from Don (nos...@nospam.com)'s article
Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 02:00:00 -0400, Brad Roberts bra...@puremagic.com
wrote:
On 8/11/2010 6:19 AM, dsimcha wrote:
An issue that's come up here several times before is that enforce()
effectively disables
On Thursday, August 12, 2010 13:47:40 dsimcha wrote:
Just to clarify: enforce() calls a function called bailOut() if necessary
that actually does the throwing. This of course is not inlined w.r.t.
enforce(). However, the lazy parameter also prevents inlining of enforce()
itself and generates
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in. From reading some
disassemblies, the reason seems to be because of all the ASM code that's
required for lazy parameters. I wonder if either of the following is
dsimcha:
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in.
This is a problem because many Phobos functions, even small ones, are sprinkled
with enforce().
If the purpose of enforce() is just to stop the
On Wed, 11 Aug 2010 09:19:01 -0400, dsimcha dsim...@yahoo.com wrote:
An issue that's come up here several times before is that enforce()
effectively disables inlining of the function it's used in. From
reading some
disassemblies, the reason seems to be because of all the ASM code that's
Steven Schveighoffer napisał:
Hold on, can't we have enforce and lenforce (lazy enforce)?
From a simple grep, 99% of enforce instances are:
enforce(condition)
-or-
enforce(condition, compile-time-string)
-or-
enforce(condition, compile-time-string ~ type.stringof)
There are a few
14 matches
Mail list logo
