In article <pan.2004.09.29.23.56.34.302280@teqdruid.com>, teqDruid says...

>It'd be nice if there was some way to run dmd with -release, but keep some of the implicit assertions in, most notably the array bounds checking.

Indeed - and I note this code from dmd/src/mars.d:
#   global.params.useAssert = 1;
#   global.params.useInvariants = 1;
#   global.params.useIn = 1;
#   global.params.useOut = 1;
#   global.params.useArrayBounds = 1;
#   global.params.useSwitchError = 1;
#   global.params.useInline = 0;

Seems a shame these flags are not individually settable from the command line.

Arcane Jill

Arcane Jill wrote:
> 
> In article <cjg4vv$1v6s$1@digitaldaemon.com>, Deja Augustine says...
> 
> >my issue is that those
> >sorts of comments don't belong in a FAQ.
   =================
> 
> By definition, any frequently asked question belongs in a FAQ. That's what "FAQ"
                                      ================
> stands for. So the only criterion for inclusion should be: is this question /actually/ frequently asked?

Now you changed your mind.

If you think, the question doesn't belong into this FAQ, you can delete it.

I don't think that you are right, because one can feel which questions (intelligent ones, that are obvious but have no obvious answer) belong into an FAQ.

Any forum visitor will look for the FAQ to avoid standard questions.
The quality and size of an FAQ therefore also tells about the quality of what we
are doing here. If we do it in 2 years it is better than to count questions for
5 years and then start working on it.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

> Then again, there's always writing good error handling code.  If you use exceptions, you can do a much more efficient job of catching errors in your program and give much more useful errors than the assertion failures.

"Critics of DBC, and Eiffel, have argued that to 'fail hard' in real life situations is sometimes literally dangerous. In an attempt to address this, Eiffel treats contract breaches as exceptions that can be caught, allowing a system to recover from its own defects. The degree to which this approach succeeds is arguable."

http://encyclopedia.thefreedictionary.com/Design%20by%20Contract

> I strongly agree that contracts are excellent tools, but I feel that to discourage people from even considering it as a possibility to do without merely encourages lazy programming.  Regardless of your personal opinions on the usefulness of -release mode, my issue is that those sorts of comments don't belong in a FAQ.

There's some interesting text in OOSC page 396 and onward about this.

In article <415C0295.79A533E@hls.via.at>, Helmut Leitner says...
>
>Arcane Jill wrote:
>> 
>> In article <cjg4vv$1v6s$1@digitaldaemon.com>, Deja Augustine says...
>> 
>> >my issue is that those
>> >sorts of comments don't belong in a FAQ.
>   =================
>> 
>> By definition, any frequently asked question belongs in a FAQ. That's what "FAQ"
>                                      ================
>> stands for. So the only criterion for inclusion should be: is this question /actually/ frequently asked?
>
>Now you changed your mind.

I frequently change my mind - that's no crime.

But in this particular case, I didn't. I never said that the item in question either should or shouldn't be in the FAQ, either before or after the above statement. I ventured, and continue to venture, no opinion whatsoever on the subject.



>If you think, the question doesn't belong into this FAQ

I didn't say that. And neither did I say the converse. Therefore I have nothing either to justify or refute.


>I don't think that you are right,

About what?

I simply made a generalization - that questions which are frequently asked are precisely the questions which (by definition) belong in a FAQ. I said nothing about whether or not this /particular/ question falls into that category - and nor would I, because I don't know enough to make that assessment.


>because one can feel which questions (intelligent
>ones, that are obvious but have no obvious answer) belong into an FAQ.

I'd say that such questions belong in official documentation, such a manual, or a properly indexed page on a web site.

But hey - I don't care. Honestly. This really is too trivial to argue about. Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cjgppc$2a13$1@digitaldaemon.com...
> By definition, any frequently asked question belongs in a FAQ. That's what
"FAQ"
> stands for. So the only criterion for inclusion should be: is this
question
> /actually/ frequently asked?

I view it a little differently. If it's a reasonable question, and someone is willing to provide an answer, by all means, put it in the FAQ.  I often review FAQs and move the answers into the regular documentation. Also, with the advent of great search tools, the FAQ won't get unwieldy no matter how many questions and answers are in it. The more the better.

teqDruid wrote:

> On Wed, 29 Sep 2004 14:32:38 -0500, Deja Augustine wrote:
> 
>> Helmut Leitner wrote:
>>> Looks like a nice FAQ entry.
>>> 
>>>    <http://www.wikiservice.at/wiki4d/wiki.cgi?FaqRoadmap#-releaseflag>
>>> 
>>> Burton Radons wrote:
>>> 
>>>>Lynn Allan wrote:
>>>>
>>>>
>>>>>The dmd compiler has several flags for controlling whether optimizing or debugging features are activated. I think I understand -g -O -debug and -version, but I'm unclear what the -release flag does and how/if it is used with code.
>>>>
>>>>-release eliminates assertion tests explicit:
>>>>
>>>>    assert (x);
>>>>
>>>>and implicit:
>>>>
>>>>    // if -release is not given, this checks that y is in bounds for x.
>>>>    x [y] = z;
>>>>
>> 
>> -release also turns off unittests and class invariants.  It basically boils down to disabling the Design-By-Contract constructs (asserts, invariants, unittests and the like) to create code that runs faster.
>> 
>> 
>>>>-release essentially turns all runtime safety controls off.  I don't recommend it - if your program goes bad, it'll be very difficult to find out where and why.  Array-using code is impacted by the checks, but you can get around that safely in inner loops by using pointers.
>> 
>> <rant>
>> The DbC constructs are meant purely for debugging purposes and should
>> not be relied upon to catch things such as erronious input.  Good code
>> should compile and run the exact same way from the user's point of view
>> whether compiled using release or debug modes.
>> 
>> To say that it's not recommended is the entirely wrong attitude.  It is
>> meant for exactly what it says, builds to be released.  DbC is a useful
>> tool while developing a program, but it has no place in a final release
>> build.
>> </rant>
>> 
>> -Deja
> 
> It'd be nice if there was some way to run dmd with -release, but keep some of the implicit assertions in, most notably the array bounds checking.

I agree, but want to add one suggestion - that '-O' itself always implies what it currently does - maximum (pragmatic) optimizations apply.

What I'm seeing in the great majority of make files for GCC applications is the repetition of the same flags; e.g.: '-O2 -fomit-frame-pointer'. Other compilers basically do all this with with one switch, like -o for DMC, -fast for Intel and /Ox or whatever for MSVC.

This is to underscore that I think -O should simply do what it implies (and does now): Optimize code by default, including removing array bounds checks. The bounds checking requirement is purposely /not/ a hard-and-fast rule for D as it is for Java because it shouldn't be forced on D executables, or D compiler developers.

As for safety of release executables, personally I have started to try and always use D language constructs like array concatention operators along with foreach, etc. when I write my code. This is a win-win-win in many cases - code that is safer, easier to write and easier for the compiler/GC to optimize.

Besides, with buffer overflow type attacks, it may be the actual intent of the overflow to have the software abort itself immediately. For this reason and the (currently) more common case where the overflow is directly exploited, there is really no excuse to not write code protecting buffers anyhow.

IMO, the 'extra' compiler switch clutter should be introduced to release code make files only when it is desirable that a common optimization be turned off, because that will be a smallish minority of cases from what I'm seeing.

- Dave

Dave wrote:

> teqDruid wrote:
> 
[snip]
>> 
>> It'd be nice if there was some way to run dmd with -release, but keep some of the implicit assertions in, most notably the array bounds checking.
> 
> I agree, but want to add one suggestion - that '-O' itself always implies what it currently does - maximum (pragmatic) optimizations apply.
> 
> What I'm seeing in the great majority of make files for GCC applications is the repetition of the same flags; e.g.: '-O2 -fomit-frame-pointer'. Other compilers basically do all this with with one switch, like -o for DMC, -fast for Intel and /Ox or whatever for MSVC.
> 
> This is to underscore that I think -O should simply do what it implies (and does now): Optimize code by default, including removing array bounds checks. The bounds checking requirement is purposely /not/ a hard-and-fast rule for D as it is for Java because it shouldn't be forced on D executables, or D compiler developers.
> 

Ack - Once again I've made the mistake of thinking that -O removes bounds checking when of course it is '-release'.

Basically what I was getting at is that I think -release should continue to remove bounds checking by default. An explicit -bounds-check flag added to override the default behaviour would be fine by me <g>.

- Dave