www.digitalmars.com         C & C++   DMDScript  

D - assert at compile time

reply "Sandor Hojtsy" <hojtsy index.hu> writes:
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
May 23 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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...
May 23 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
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
May 23 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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?
May 23 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
May 23 2002
next sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"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
May 24 2002
next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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
May 24 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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.
May 24 2002
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
May 29 2002
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
May 23 2002