Hi,

>>>This wouldn't be hard to do right now.  Just write a function called "verify" and place it in object.d.
>>
>>But then how would I get line number and filename?
>
>Good point :p  I think there are actually preprocessor macros you can use for this purpose (__FILE__ and __LINE__) but it's annoying having to pass them as arguments.

Yep, it'd be a little kludgy to have to pass those around ;). Plus the compiler wouldn't know that the function is "special," for cases like verify(false);.

That kind of support needs to come from the compiler itself. I hope Walter considers adding this wonderful function.

Benefits:

1) assert() doesn't have to change at all. Current code relying on assert would
work identically.

2) Allows for writefln()-style variadic messages, which would come in very
handy.

3) Provides line number / file name information.

4) The compiler can detect or eliminate dead code with it, and know when functions don't have to return.

Thanks,
--AJG.






Cheers,
--AJG.

> "Release" code should have nothing to do with contracts or safety.
> It should be about removing extra symbols, stripping useless sections,
> etc. Not safety. Not contracts. Well, IMHO, of course.

You're confusing -release with -O.  The latter is used to optimize the code, and that's what you want (unless I'm mistaken.)  In fact -release doesn't even do that at all.  The -inline and -O options are completely separate.

Neither is it "in D", it is in DMD.  I haven't read anywhere in the spec that dictates these command line options must be common to all compilers - another one could easily make -release mean optimize, and -unsafe be no contracts, etc.

-[Unknown]

On Thu, 18 Aug 2005 20:17:22 -0700, Unknown W. Brackets wrote:


[snip]

> I haven't read anywhere in the spec that dictates these command line options must be common to all compilers - another one could easily make -release mean optimize, and -unsafe be no contracts, etc.

A very good point. D is not DMD.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
19/08/2005 1:35:13 PM

In article <de3ivs$vku$1@digitaldaemon.com>, Unknown W. Brackets says...
>
> > "Release" code should have nothing to do with contracts or safety.
> > It should be about removing extra symbols, stripping useless sections,
> > etc. Not safety. Not contracts. Well, IMHO, of course.
>
>You're confusing -release with -O.  The latter is used to optimize the code, and that's what you want (unless I'm mistaken.)  In fact -release doesn't even do that at all.  The -inline and -O options are completely separate.

I really don't think I am. What does "release" mean? To me, it means "do not include debugging information." What is this "information?" Well, symbols, sections, etc. that are only useful during debugging.

Optimization ("-O", "-inline") is a whole other matter, which to me means, "make my code faster, more efficient, using whichever legal technique you can get away with."

My point is that _neither_ "optimization," _nor_ "release," should have anything to do with safety, or at the very least, nothing to do with contracts.

I think we've established that optimization already follows this "rule." So, IMO, optimization is fine.

My problem is with "release", which _in addition_ to doing what it is supposed to do, it is also taking away the safety of my code in the form of removing contracts and checks.

That's why I propose a "-contracts" argument which explicitly tells the compiler what you want it to do with your contracts and checks.

So, "don't use -release" you say. That's not a good solution. I don't want to ship debug code. I don't want to ship debugging symbols. How should I, right now, specify that the compiler:

1) Leave ALL contracts/checks/safety IN.
2) Take ALL debugging information OUT.

In other words, I do not think contracts are _solely_ "debugging" tools. They _help_ during debugging, but they are incredibly useful all around. They should be independent of debugging.

One simple example:
Array bounds checks.

I'm not sure if those are called contracts or not. Doesn't matter. At any rate, these are currently _wiped out_ in -release. I think that's a really bad decision.

Are you telling me you are so confident that you can guarantee that _all_ of your arrays, in _all_ of your code, will never, ever, overrun a single boundary once gone into production (i.e. once "released")?

I can't say such a thing, which is why I would like a separate option to be able to leave my contracts and checks in. That's all I'm asking for, a choice to be able to properly do that.

>Neither is it "in D", it is in DMD.  I haven't read anywhere in the spec that dictates these command line options must be common to all compilers - another one could easily make -release mean optimize, and -unsafe be no contracts, etc.

I beg to differ:

Spec:
http://www.digitalmars.com/d/dbc.html

Example sentence:
"For a release build of the code, the in and out code is not inserted."

Nowhere in that page is DMD even mentioned, so I think it's speaking about the language in general. Otherwise, the spec is plain misleading.

At any rate, the point is moot. I currently use DMD, and it looks to me like the only viable option to use the latest version of D. Once we start seeing multitudes of compilers (like C++), the perhaps the point would be more relevant.

Moreover, I just took a look at GDC, the one other "compiler," and I found this mapping table:

http://home.earthlink.net/~dvdfrdmn/d/

-debug   => -fdebug
-release => -frelease

So it looks like fully 100% of the D language, specification & implementation, does what I'm talking about, which is taking contracts out for production code.

This doesn't bode well for safety.

Cheers,
--AJG.

Hi,

>> I haven't read anywhere in the spec that dictates these command line options must be common to all compilers - another one could easily make -release mean optimize, and -unsafe be no contracts, etc.
>
>A very good point. D is not DMD.

Even though the statement "D is not DMD" is mostly true, the original premise is wrong. If you are interested, see my other post for details.

Cheers,
--AJG.

AJG wrote:
> In article <de3ivs$vku$1@digitaldaemon.com>, Unknown W. Brackets says...

> 
> I really don't think I am. What does "release" mean? To me, it means "do not
> include debugging information." What is this "information?" Well, symbols,
> sections, etc. that are only useful during debugging.

What "release" means to you is irrelevant. What it means to DMD is what's important here (from http://www.digitalmars.com/d/dcompiler.htm):

-release
    compile release version, which means not generating code for contracts and asserts

Notice it says nothing about debugging symbols, which are only included when you use pass -g:

-g
    add symbolic debug info

In your original post, you said:

********************************************************************
/First, I was happily coding in D under -debug. Then, I started using std.boxer
which requires that I use -release because of unresolved linking.

So I add -release (in _addition_ to -debug) and all hell breaks lose.

1) asserts no longer display anything meaningful; they segfault.
2) pre-condition (in) contracts disappear altogether./
********************************************************************

Notice what the docs say about -debug:

 -debug
    compile in debug code

Debug code in this case is anything following a 'debug' statement in your code, and has nothig to do with contracts or asserts.

The compiler already does *exactly* what you want it to. The whole point of this thread is moot. The problem stems from your understanding of the terms 'release' and 'debug', which in the case of the D compiler do not mean what they have traditionally meant in other language tools. Contracts and asserts are enabled by default. If you don't beleive me:

********************************************************************
void myfunc()
in
{
	assert(false);
}
body
{
	printf("Boo!\n");
}

void main()
{
	myfunc();
}
********************************************************************

Compile with no command line args (dmd foo.d), then run it to see what happens.

So -release doesn not mean 'compile with optimizations and whatever else release mode traditionally does', but rather 'turn off contracts and asserts'.

> So, "don't use -release" you say. That's not a good solution. I don't > want to
> ship debug code. I don't want to ship debugging symbols. How should I, > right
> now, specify that the compiler:

Simply by omitting -g (thereby leaving out debugging symbols) and also omitting -debug (thereby leaving out everything in "debug" statements").   And if you also omit release, you get to keep your contracts and asserts.

> Are you telling me you are so confident that you can guarantee that _all_ of
> your arrays, in _all_ of your code, will never, ever, overrun a single boundary
> once gone into production (i.e. once "released")?

No, I also prefer to ship with such things on (well, with the option of the faster version without the checks) but that's my choice.  By your definitions of release, that's what DMD generates (as mentioned) with no arguments at all.

Personally, I've never liked the "debug/release" mentality, anyway.  I think of it as many more stages (debugging, testing, etc.)

> "For a release build of the code, the in and out code is not inserted."

The wording can be changed, but there's nothing in that sentence that forces anyone not to have a contracts option.  It suggests that, as many programmers prefer, such things as contracts and array bounds checking won't be included in release.

I know many programmers who would look at you as if you had just sworn something strong if you suggested shipping code with array bounds checking in it.  Yes, you don't agree - and yes, I prefer my users to be able to easily report bugs to me, but this is entirely preference.  Long debates on this have been posted in this very newsgroup.

-[Unknown]

Hi,

>> Are you telling me you are so confident that you can guarantee that _all_ of your arrays, in _all_ of your code, will never, ever, overrun a single boundary once gone into production (i.e. once "released")?
>No, I also prefer to ship with such things on (well, with the option of the faster version without the checks) but that's my choice.  By your definitions of release, that's what DMD generates (as mentioned) with no arguments at all.

This appears to be true (doing some checks right now), so in this respect, you are right. I was wrong to think there was no way of accomplishing that task.

My worry is that "-release" is a misnomer. _If_ indeed _all_ it does is remove contracts, then it should be called something else. "-nocontracts", "-unsafe", or whatever. Using "-release" implies production code == contractless code.

>Personally, I've never liked the "debug/release" mentality, anyway.  I think of it as many more stages (debugging, testing, etc.)

Very much agreed.

>> "For a release build of the code, the in and out code is not inserted."
>
>The wording can be changed, but there's nothing in that sentence that forces anyone not to have a contracts option.

Well, it'd certainly like to see that option. I would very much prefer to have a "-contracts" option where I can explicitly tell the compiler to leave them in, instead of relying on iffy defaults. Call it a safety measure.

>I know many programmers who would look at you as if you had just sworn something strong if you suggested shipping code with array bounds checking in it.

Unless those programmers are working on extremely speed-sensitive code, my opinion is that they are just plain wrong. Removing array bounds for _regular_ code is a combination of premature optimization and thoughtlessness.

If indeed the code is _so_ speed-sensitive, it should probably be in assembly. Profile the code, see where the bottleneck is, and work with that part (or hand code it in asm). It is understandable to lose safety, readability, portability, etc... where it truly matters.

>Yes, you don't agree - and yes, I prefer my users to be able to easily report bugs to me, but this is entirely preference.  Long debates on this have been posted in this very newsgroup.

Hehe, I guess the wrong side has been winning? ;)

Cheers,
--AJG.

Walter always wins (except when he gives in), and so he is always the right side :P.  Thus the right side has been winning.

Seriously, though, most of the work I do is on web servers.  For me, the idea that speed is unimportant for anything but "speed sensitive" code is rediculous.  Many of my clients would definitely prefer the faster version, even with any possibility of segfaults.

-[Unknown]

AJG wrote:

> Well, it'd certainly like to see that option. I would very much prefer to have a
> "-contracts" option where I can explicitly tell the compiler to leave them in,
> instead of relying on iffy defaults. Call it a safety measure.

You don't need to tell the compiler to leave them in. They are in by default. Nothing iffy about it. 'dmd mysource.d' gives you contracts and asserts.