toHash => pure, nothrow, const, @safe

[Alex Rønne Petersen]

On 12-03-2012 20:08, H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 07:41:39PM +0100, Alex Rønne Petersen wrote:
>> On 12-03-2012 19:04, H. S. Teoh wrote:
> [...]
>>> Tangential note: writing unit tests may be tedious, but D's inline
>>> unittest syntax has alleviated a large part of that tedium. So much
>>> so that I find myself writing as much code in unittests as real code.
>>> Which is a good thing, because in the past I'd always been too lazy
>>> to write any unittests at all.
> [...]
>> I stopped writing inline unit tests in larger code bases. If I do
>> that, I have to maintain a separate build configuration just for test
>> execution, which is not practical. Furthermore, I want to test my code
>> in debug and release mode, which... goes against having a test
>> configuration.
> [...]
>
> Hmm. Sounds like what you want is not really unittests, but global
> program startup self-checks. In my mind, unittests is for running
> specific checks against specific functions, classes/structs inside a

That's what I do. I simply moved my unittest blocks to a separate 
executable.

> module. I frequently write lots of unittests that instantiates all sorts
> of templates never used by the real program, contrived data objects,
> etc., that may potentially have long running times, or creates files in
> the working directory or other stuff like that.  IOW, stuff that are not

You never know if some code that seems to work fine in debug mode breaks 
in release mode then (until your user runs into a bug). This is why I 
want full coverage in all configurations.

> suitable to be used for release builds at all. It's really more of a way
> of forcing the program to refuse to start during development when a code
> change breaks the system, so that the developer notices the breakage
> immediately. Definitely not for the end-user.

Right. That's why my tests are in a separate executable from the actual 
program.

>
> If I wanted release-build self-consistency checking, then yeah, I'd use
> a different framework than unittests.

IMHO unittest works fine for both debug and release, just not inline.

>
> As for build configuration, I've given up on make a decade ago for
> something saner, which can handle complicated build options properly.
> But that belongs to another topic.

I used to use Make for this project, then switched to Waf. It's an 
amazing build tool.

>
>
> T
>


-- 
- Alex