Differential D4834 Diff 15433 src/script/script_metrics.h

Changeset View

Standalone View

src/script/script_metrics.h

	// Copyright (c) 2020 The Bitcoin developers			// Copyright (c) 2020 The Bitcoin developers
	// Distributed under the MIT software license, see the accompanying			// Distributed under the MIT software license, see the accompanying
	// file COPYING or http://www.opensource.org/licenses/mit-license.php.			// file COPYING or http://www.opensource.org/licenses/mit-license.php.

	#ifndef BITCOIN_SCRIPT_SCRIPT_METRICS_H			#ifndef BITCOIN_SCRIPT_SCRIPT_METRICS_H
	#define BITCOIN_SCRIPT_SCRIPT_METRICS_H			#define BITCOIN_SCRIPT_SCRIPT_METRICS_H

	/**			/**
	* Struct for holding cumulative results from executing a script or a sequence			* Struct for holding cumulative results from executing a script or a sequence
	* of scripts.			* of scripts.
	*/			*/
	struct ScriptExecutionMetrics {			struct ScriptExecutionMetrics {
	int nSigChecks = 0;			int nSigChecks = 0;

				ScriptExecutionMetrics() = default;
				ScriptExecutionMetrics(int _nSigChecks) : nSigChecks(_nSigChecks) {}

				bool operator==(const ScriptExecutionMetrics &rhs) {
				return nSigChecks == rhs.nSigChecks;
				}
				deadalnixUnsubmitted Done Inline Actions I don't understand what's the prupose of this considering the struct is a pod. Or is the constructor make ti a non pod? In any are, you got to chose if you go the pod road or want to encapsulate. I'd go for the former as this would allow you to detect errors at the point where they are "created" (an ScriptExecutionMetrics with an invalid state was created) rather than at the point the error is actually bad (the ScriptExecutionMetrics is tentatively cached, but cannot). deadalnix: I don't understand what's the prupose of this considering the struct is a pod. Or is the…
				markblundebergAuthorUnsubmitted Done Inline Actions Yes I prefer the former (PoD) as well. The main reason I'm adding these members is so that code using ScriptExecutionMetrics does not start silently being buggy, if it turns out that we need to add another value: Unlike struct initializer list (where you can leave off arguments), using the constructor forces you to provide the correct number of arguments, i.e., if we add another value to this struct then all the callsites creating ScriptExecutionMetrics with specific values will turn into compile errors until they provide the new value. Likewise operator== makes sure that you're doing a proper comparison of all values; operator+= ensures that all metrics are being accumulated. Besides that, I want access via PoD semantics. markblundeberg: Yes I prefer the former (PoD) as well. The main reason I'm adding these members is so that…
				markblundebergAuthorUnsubmitted Done Inline Actions Just to add to this, I mean I want neither a strict PoD type (bare struct) nor a fully encapsulated class. Is there no middle ground allowed here? markblundeberg: Just to add to this, I mean I want neither a strict PoD type (bare struct) nor a fully…
				deadalnixUnsubmitted Not Done Inline Actions If you are concerned about semantic breaking when you change what's in it, it is that you don't want a POD. I don't think a middle ground makes any sense. Ether the struct itself is responsible for it's innards, or the code that uses it is. It cannot be both. deadalnix: If you are concerned about semantic breaking when you change what's in it, it is that you don't…
	};			};

	#endif // BITCOIN_SCRIPT_SCRIPT_METRICS_H			#endif // BITCOIN_SCRIPT_SCRIPT_METRICS_H