Currently expensive checks are guarded with command line flags. It'd be nice if there could be one unified command line flag -expensivechecks that subsumes -checkmempool and so on. On Wed, Jun 4, 2014 at 6:42 PM, Jannis Froese wrote: > There are reasons to have assertions enabled by default in software like > Bitcoin Core, where incorrect behaviour can be costly. But this comes at a > prize: our assertions have to satisfy certain performance requirements. > It's no longer possible to do expensive, redundant checks in performance > critical code, which is one of the main advantages of asserts. Imho, > asserts are not intended for small range checks etc, but are meant for > checks that a hash hasn't changed, that a tree structure is still a tree, > that data is still sorted, or that data structures are in sync. > > I think most concerns about the current use of asserts would be resolved > if the currently used asserts would be changed to a nicer definition which > is independent of NDEBUG, and a second class of debugging asserts would be > introduced, which is exclusively for expensive, redundant checks and is > disabled by NDEBUG. > > > > Am 2014-06-04 12:15, schrieb Gregory Maxwell: > > On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn wrote: > >> Hi Ron, >> >> FYI your mail is being spamfoldered due to Yahoo's DMARC policy and the >> brokenness of the SF.net mailing list software. I would not expect to get >> replies reliably whilst this is the case. I think we should move away from >> SF.net for hosting mailing lists personally, because it's this list that's >> at fault not Yahoo, but until then you may wish to send to the list with a >> different email address. >> >> As to your question, >> >> assert() should have *no* side effects, that is the problem. >>> >>> See >>> >>> http://books.google.com/books?id=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false >>> >>> a great book, BTW. Everyone who thinks they know what they are doing >>> when they write C++ should read this book! They will realize that they >>> don't know Jack [image: Roll Eyes] >>> >>> Why weren't these and all the other examples of amateur, i.e., >>> non-professional, software fixed way back in version 0.3.0 in 2010, before >>> any more releases were done? And why were these and other sub-standard >>> coding practices continued and expanded in later releases, right up until >>> the present? >>> >> >> Back in 2010 most code was still being written by Satoshi so perhaps >> you should ask him. Regardless, it's very common for professional codebases >> to require assertions be enabled. For example the entire Google C++ >> codebase uses always-on assertions that have side effects liberally: it's >> convenient and safe, when you have the guarantee the code will always run, >> and the performance benefits of compiling out assertions are usually >> non-existent. >> >> So for this reason I think Bitcoin Core currently will fail to build if >> assertions are disabled, and that seems OK to me. >> > > As a matter of procedure we do not use assertions with side effects— the > codebase did at one point, but have cleaned them up. In an abundance of > caution we also made it refuse to compile without assertions enabled: A > decision who's wisdom was clearly demonstrated when not long after, some > additional side-effect having assert was contributed. In the real world > errors happen here and there, and making robust software involves defense > in depth. > > Considering the normal criticality of the software it should always be > with the assertions. Without them is an untested configuration. It would > probably be superior to use our own assertion macros (for one, they can > give some better reporting…) that don't have the baggage ordinary > assertions have, but as a the codebase is a production thing, making larger > changes all at once to satisfy aesthetics would be unwise... simply > refusing to compile in that untested, unsupported configuration is prudent, > for the time being. > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today!http://p.sf.net/sfu/NeoTech > > > > _______________________________________________ > Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >