digitalmars.D.learn - Do a class invariants affect -release builds?
- Andrew LaChance (10/10) Dec 05 2015 I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20
- Steven Schveighoffer (4/14) Dec 05 2015 I don't remember that the invariant was ever called in release mode. But...
- Andrew LaChance (7/30) Dec 06 2015 I think what he was saying was that even in release mode, the
- Steven Schveighoffer (6/29) Dec 07 2015 I don't think that's true. The invariant is called as part of function
- Chris Wright (20/33) Dec 05 2015 It's not true today, as you can test yourself:
- Steven Schveighoffer (32/34) Dec 05 2015 void main()
I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks!
Dec 05 2015
On 12/5/15 6:06 PM, Andrew LaChance wrote:I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks!I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement. -Steve
Dec 05 2015
On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote:On 12/5/15 6:06 PM, Andrew LaChance wrote:I think what he was saying was that even in release mode, the druntime would keep the invariant "subsystem," but just wouldn't call the invariant handlers. So even in release mode, the code to get a list of all handlers would happen, they just wouldn't be invoked. Rather than completely ripping out the invariant system.I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks!I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement. -Steve
Dec 06 2015
Steven Schveighoffer <schveiguy yahoo.com> On 12/6/15 6:01 PM, Andrew LaChance wrote:On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote:I don't think that's true. The invariant is called as part of function execution. Using obj2asm, the code emitted for an empty class function is vastly larger without -release. -SteveOn 12/5/15 6:06 PM, Andrew LaChance wrote:I think what he was saying was that even in release mode, the druntime would keep the invariant "subsystem," but just wouldn't call the invariant handlers. So even in release mode, the code to get a list of all handlers would happen, they just wouldn't be invoked. Rather than completely ripping out the invariant system.I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks!I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement.
Dec 07 2015
On Sat, 05 Dec 2015 23:06:22 +0000, Andrew LaChance wrote:I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks!It's not true today, as you can test yourself: class Foo { invariant { assert(false); } string str() { return this.toString; } } void main() { import std.stdio; writeln(new Foo().str); } $ rdmd invar.d core.exception.AssertError invar.d(3): Assertion failure $ rdmd -release invar.d invar.Foo I've never used a release build of anything. Bounds checking isn't that expensive.
Dec 05 2015
On 12/5/15 6:54 PM, Chris Wright wrote:I've never used a release build of anything. Bounds checking isn't that expensive.void main() { int[] arr = new int[10]; assert(arr.capacity == 1000); // obviously wrong arr[10] = 5; } dmd -release -boundscheck=on testboundscheck.d ./testboundscheck core.exception.RangeError testboundscheck.d(5): Range violation ---------------- 4 testboundscheck 0x000000010df8454d _d_arraybounds + 97 5 testboundscheck 0x000000010df77da6 testboundscheck.__array + 38 6 testboundscheck 0x000000010df77d71 _Dmain + 49 7 testboundscheck 0x000000010df94e83 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39 8 testboundscheck 0x000000010df94dbb void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 55 9 testboundscheck 0x000000010df94e28 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 44 10 testboundscheck 0x000000010df94dbb void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 55 11 testboundscheck 0x000000010df94d0d _d_run_main + 497 12 testboundscheck 0x000000010df77e0f main + 15 13 libdyld.dylib 0x00007fff928d15c8 start + 0 14 ??? 0x0000000000000000 0x0 + 0 -Steve
Dec 05 2015