Hi,
Does the compiler check (some of the) asserts at compile time? Which of
them? Is it a warning or an error if it fails? Is it optimized out of the
exe if it is guaranted to be OK?

Some of you have expressed negative feelings about lint, and happy to
eliminate the need for it by clear code constructs. I disagree with this
opinion. I think the debug helping elements in D gives much space for a
specialized lint, which could try to (statically) check class invariants,
and contracts by value-tracking, etc. I was thinking for a long time, that
such a functionality is best built-in the compiler. IMHO, it would shorten
develelopment time.
Ideas?

yours,
Sandor Hojtsy

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:acijf0$1s2$1@digitaldaemon.com...
> Hi,
> Does the compiler check (some of the) asserts at compile time? Which of
> them? Is it a warning or an error if it fails? Is it optimized out of the
> exe if it is guaranted to be OK?

The compiler _might_ perform checks at compile-time (not sure if DMD does). Assertion failure is a deliberate error, so the program wouldn't even compile.

Concerning optimizations... I'm sure it could be done, but I don't see much reasons in it, since release build has all assertions stripped away anyhow, and debug build is not supposed to be fast...

> and contracts by value-tracking, etc. I was thinking for a long time, that such a functionality is best built-in the compiler. IMHO, it would shorten develelopment time.

Indeed. But I don't think that nowadays compilers won't be able to perform all but a few simple assertions at run-time. We shall see...

While the compiler could issue an error at compile time for asserts that will trip, for example:

    if (foo)
        assert(0);

it does not because it can't be sure that the code is even executed.


"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:acijf0$1s2$1@digitaldaemon.com...
> Hi,
> Does the compiler check (some of the) asserts at compile time? Which of
> them? Is it a warning or an error if it fails? Is it optimized out of the
> exe if it is guaranted to be OK?
>
> Some of you have expressed negative feelings about lint, and happy to
> eliminate the need for it by clear code constructs. I disagree with this
> opinion. I think the debug helping elements in D gives much space for a
> specialized lint, which could try to (statically) check class invariants,
> and contracts by value-tracking, etc. I was thinking for a long time, that
> such a functionality is best built-in the compiler. IMHO, it would shorten
> develelopment time.
> Ideas?
>
> yours,
> Sandor Hojtsy
>
>

Sandor Hojtsy wrote:

> Hi,
> Does the compiler check (some of the) asserts at compile time? Which of
> them? Is it a warning or an error if it fails? Is it optimized out of the
> exe if it is guaranted to be OK?
>
> Some of you have expressed negative feelings about lint, and happy to
> eliminate the need for it by clear code constructs. I disagree with this
> opinion. I think the debug helping elements in D gives much space for a
> specialized lint, which could try to (statically) check class invariants,
> and contracts by value-tracking, etc. I was thinking for a long time, that
> such a functionality is best built-in the compiler. IMHO, it would shorten
> develelopment time.
> Ideas?

I agree, we should try to do as much compile-time (or, at least, build-time) checking as possible.  I would like this in the compiler if possible, but it may turn out (at least to start with) that it's better to have a separate tool.  Later, if it became mature and trusted, it could be integrated into a compiler.

I envision such a tool as having at least two variants.  One would be a quick checker, able to run about as fast as a compile, that just gives you a check for obvious faults.  The other, however, would run a very long time, and attempt to do something close to an exhaustive search.  I know, I know, we get to Turing's problem that you can't prove termination of a program, and so you can't search everything...but in many cases, you can analyze the program and find out that such and such a variable can only be within a certain subset of values, and if you propogate that through the function calls, you might be able to describe - somewhat - the range of possible behaviors of the program. This might point out dead code, or find some failed assertions that a simpler tool could not.  Such a tool could be run overnight, say, and only very rarely.  Perhaps you might run it overnight on the "official" level of code right before you build a release level that you plan to give out to your customers.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter@digitalmars.com> wrote in message news:acj2o1$gnh$1@digitaldaemon.com...

> While the compiler could issue an error at compile time for asserts that will trip, for example:
>
>     if (foo)
>         assert(0);
>
> it does not because it can't be sure that the code is even executed.

I understand. But _potentially_, it could try to trace execution,
and check those assertions that will be checked anyhow. While
it's seems to be not possible nowadays, it might be worth including
in the reference: just like the compiler must _try_ to detect
uninitialized variables, missing returns, and out-of-bound indices
at compile time, it must also do it's best (which in fact means
"at least nothing") to perform assertions at compile time...

By the way, is it legal for the function to define a contract that is NEVER legal, like in this one:

    void foo(int n)
    in
    {
        assert(n - n != 0)
    }
    body
    {
        ...
    }

Obviously, such function cannot be called without contract violation.
But if it isn't called at all, is it considered a legal, even
though meaningless, D code?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:acjeth$sh8$1@digitaldaemon.com...
> Obviously, such function cannot be called without contract violation.
> But if it isn't called at all, is it considered a legal, even
> though meaningless, D code?

Some times I write code like:

void foo()
{
    assert(0);    // BUG: need to implement this function
}

Here foo() is just a placeholder for a function I need but will fill in later. Writing it in this manner ensures I won't forget to implement it. I still need it to compile successfully, because other places in the code refer to foo() and they need to link.

"Walter" <walter@digitalmars.com> wrote in message news:acjon7$15la$1@digitaldaemon.com...
>
> Some times I write code like:
>
> void foo()
> {
>     assert(0);    // BUG: need to implement this function
> }
>
> Here foo() is just a placeholder for a function I need but will fill in later. Writing it in this manner ensures I won't forget to implement it. I still need it to compile successfully, because other places in the code refer to foo() and they need to link.

Sometimes I need to check something at compile time, like:

const int timeout1 = 100;  // first chance timeout
const int timeout2 = 200;  // second chance timeout

assert(timeout1 <= timeout2);
assert(timeout1 >= 60);

What if I can put those out of any function to be checked at compile time?

Ciao

If the assert expression is a compile time constant it should be able to be checked at compile time.

Sean

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:ackr1i$271c$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:acjon7$15la$1@digitaldaemon.com...
> >
> > Some times I write code like:
> >
> > void foo()
> > {
> >     assert(0);    // BUG: need to implement this function
> > }
> >
> > Here foo() is just a placeholder for a function I need but will fill in later. Writing it in this manner ensures I won't forget to implement it.
I
> > still need it to compile successfully, because other places in the code refer to foo() and they need to link.
>
> Sometimes I need to check something at compile time, like:
>
> const int timeout1 = 100;  // first chance timeout
> const int timeout2 = 200;  // second chance timeout
>
> assert(timeout1 <= timeout2);
> assert(timeout1 >= 60);
>
> What if I can put those out of any function to be checked at compile time?
>
> Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:ackr1i$271c$1@digitaldaemon.com...
> Sometimes I need to check something at compile time, like:
>
> const int timeout1 = 100;  // first chance timeout
> const int timeout2 = 200;  // second chance timeout
>
> assert(timeout1 <= timeout2);
> assert(timeout1 >= 60);
>
> What if I can put those out of any function to be checked at compile time?

You can put it into a static constructor.

Walter wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:acjeth$sh8$1@digitaldaemon.com...
> > Obviously, such function cannot be called without contract violation.
> > But if it isn't called at all, is it considered a legal, even
> > though meaningless, D code?
>
> Some times I write code like:
>
> void foo()
> {
>     assert(0);    // BUG: need to implement this function
> }
>
> Here foo() is just a placeholder for a function I need but will fill in later. Writing it in this manner ensures I won't forget to implement it. I still need it to compile successfully, because other places in the code refer to foo() and they need to link.

I often define an Exception_Todo for exactly this reason:

    void foo()
    {
        throw Exception_Todo("void foo()");
    }

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]