View mode: basic / threaded / horizontal-split · Log in · Help
August 18, 2005
Re: Where did my contracts go?
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.
August 19, 2005
Re: Where did my contracts go?
> "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]
August 19, 2005
Re: Where did my contracts go?
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
August 19, 2005
Re: Where did my contracts go?
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.
August 19, 2005
Re: Where did my contracts go?
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.
August 19, 2005
Re: Where did my contracts go?
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.
August 20, 2005
Re: Where did my contracts go?
> 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]
August 20, 2005
Re: Where did my contracts go?
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.
August 20, 2005
Re: Where did my contracts go?
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]
August 20, 2005
Re: Where did my contracts go?
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.
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home