www.digitalmars.com         C & C++   DMDScript  

D - new char[-1]

reply pts+d math.bme.hu writes:
Dear All,

I think the following code should generate a compile-time error or warning:

char []a=new char[-1];

Regards,

pts
Sep 03 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
You'd think! ;)

Walter, this sparks a semi-related thought: does D have static assertions,
or any equivalent mechanism?

<pts+d math.bme.hu> wrote in message news:bj4c9c$28vj$1 digitaldaemon.com...

 Dear All,

 I think the following code should generate a compile-time error or


warning:

 char []a=new char[-1];

 Regards,

 pts
Sep 03 2003
parent reply "Walter" <walter digitalmars.com> writes:
What are static assertions?

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj60c0$1eqr$1 digitaldaemon.com...

 You'd think! ;)

 Walter, this sparks a semi-related thought: does D have static assertions,
 or any equivalent mechanism?

 <pts+d math.bme.hu> wrote in message


news:bj4c9c$28vj$1 digitaldaemon.com...

 Dear All,

 I think the following code should generate a compile-time error or


 warning:

 char []a=new char[-1];

 Regards,

 pts
Sep 03 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
In C++

   #define stlsoft_static_assert(_x)        do { typedef int ai[(_x) ? 1 :
0]; } while(0)

as in

  stlsoft_static_assert(sizeof(int) <= 4);

basically, any compile-time evaluable condition that can be subjected to a
compile-time invariant check by this.

Does D have such things? If not, can we have it?

btw, this uses the nasty empty/-ve array dimension trick. It'd be much nicer
if D said something like:

 "Static assertion check failure: etc."




"Walter" <walter digitalmars.com> wrote in message
news:bj6ndk$2e47$1 digitaldaemon.com...

 What are static assertions?

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bj60c0$1eqr$1 digitaldaemon.com...

 You'd think! ;)

 Walter, this sparks a semi-related thought: does D have static




assertions,

 or any equivalent mechanism?

 <pts+d math.bme.hu> wrote in message


 news:bj4c9c$28vj$1 digitaldaemon.com...

 Dear All,

 I think the following code should generate a compile-time error or


 warning:

 char []a=new char[-1];

 Regards,

 pts
Sep 04 2003
next sibling parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Matthew Wilson wrote:


In C++

   #define stlsoft_static_assert(_x)        do { typedef int ai[(_x) ? 1 :
0]; } while(0)

as in

  stlsoft_static_assert(sizeof(int) <= 4);

basically, any compile-time evaluable condition that can be subjected to a
compile-time invariant check by this.

Does D have such things? If not, can we have it?

btw, this uses the nasty empty/-ve array dimension trick. It'd be much nicer
if D said something like:

 "Static assertion check failure: etc."




"Walter" <walter digitalmars.com> wrote in message
news:bj6ndk$2e47$1 digitaldaemon.com...
  


What are static assertions?

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bj60c0$1eqr$1 digitaldaemon.com...
    


You'd think! ;)

Walter, this sparks a semi-related thought: does D have static
      




assertions,
  


or any equivalent mechanism?

<pts+d math.bme.hu> wrote in message
      


news:bj4c9c$28vj$1 digitaldaemon.com...
    


Dear All,

I think the following code should generate a compile-time error or
        


warning:
      


char []a=new char[-1];

Regards,

pts


        


      


    



  


I'd be nice if the compiler could use normal assertions as static 
assertions when it identifies that the assertion parameters are constant.
Sep 04 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
<snip>


 I'd be nice if the compiler could use normal assertions as static
 assertions when it identifies that the assertion parameters are constant.


I'd rather have the control myself, in the form of a separate construct.

That's not to say that it (the compiler) couldn't help out in such
circumstances as you describe
Sep 04 2003
parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Matthew Wilson wrote:


<snip>

  


I'd be nice if the compiler could use normal assertions as static
assertions when it identifies that the assertion parameters are constant.
    


I'd rather have the control myself, in the form of a separate construct.

That's not to say that it (the compiler) couldn't help out in such
circumstances as you describe

  


I think there probably should be a assertS, or something like that, for 
people who want to make sure that their assertion is using correct 
variables (static-type-checking). However, it often is the case that the 
programmer changes from constants to variables.  In these cases the 
programmer does not want to be searching through the code looking for 
all asserts and changing them to assertS. Futhermore, if you pass in 
constant parameters into a function such as:

void func(int X)
{
assert(X > 0);
}

...
func(10); //Contant
...
int y = z+10;
func(y);


The compiler should be able to identify these and apply them as if the 
assert was static, at compile time. Otherwise you'd need to write two 
versions of the function to have one with static assertion.

Anyway, earlier catchment of errors, leads to better programming.

Anderson
Sep 04 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 I think there probably should be a assertS, or something like that, for
 people who want to make sure that their assertion is using correct
 variables (static-type-checking).


What's wrong with static_assert()? If it's ugly, I have no problem with that
(static_cast, reinterpret_cast, etc.).


 However, it often is the case that the
 programmer changes from constants to variables.  In these cases the
 programmer does not want to be searching through the code looking for
 all asserts and changing them to assertS. Futhermore, if you pass in
 constant parameters into a function such as:

 void func(int X)
 {
 assert(X > 0);
 }

 ...
 func(10); //Contant
 ...
 int y = z+10;
 func(y);


 The compiler should be able to identify these and apply them as if the
 assert was static, at compile time. Otherwise you'd need to write two
 versions of the function to have one with static assertion.


If I change something that was formerly subject to a static assertion, it is
a *very good thing* that the compiler balks in one or more places where an
assertion was applied to the thing changed. The compiler is doing exactly
what it should, in bringing to my attention as many of the ramifications of
my change as possible. Hiding it is just asking for trouble.

Of course, ease of maintenance is a delicate balancing act, and an approach
of "as hard as possible" is just as unhelpful as "as easy as possible". I
think in this case to do what you suggest would be beyond going too far
towards the easy side.

Matthew
Sep 04 2003
parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Matthew Wilson wrote:


I think there probably should be a assertS, or something like that, for
people who want to make sure that their assertion is using correct
variables (static-type-checking).
    


What's wrong with static_assert()? If it's ugly, I have no problem with that
(static_cast, reinterpret_cast, etc.).


static_assert is fine with me, what is not neat is stlsoft_static_assert.


  


However, it often is the case that the
programmer changes from constants to variables.  In these cases the
programmer does not want to be searching through the code looking for
all asserts and changing them to assertS. Futhermore, if you pass in
constant parameters into a function such as:

void func(int X)
{
assert(X > 0);
}

...
func(10); //Contant
...
int y = z+10;
func(y);


The compiler should be able to identify these and apply them as if the
assert was static, at compile time. Otherwise you'd need to write two
versions of the function to have one with static assertion.
    


If I change something that was formerly subject to a static assertion, it is
a *very good thing* that the compiler balks in one or more places where an
assertion was applied to the thing changed. The compiler is doing exactly
what it should, in bringing to my attention as many of the ramifications of
my change as possible. Hiding it is just asking for trouble.
  


I wouldn't call this hiding, I'd call it early detection of possible 
errors.  Non-static asserts would be promoted to static asserts if 
possible.  The compiler already *hides* plenty of things. If you pass a 
constant as a parameter into a function that takes variables, it doesn't 
spat off error messages that your passing in a contant (of couse you can 
have functions which only take in constants). Besides, you don't always 
have to opportunity of changing other's code. You'd be forced to use 
constant variables if they defined a static assert (which is not 
nessarly a bad thing in some cases).


Of course, ease of maintenance is a delicate balancing act, and an approach
of "as hard as possible" is just as unhelpful as "as easy as possible". I
think in this case to do what you suggest would be beyond going too far
towards the easy side.

Matthew


  


What I suggest is a third assert, that does both static and non-static. 
I think easy is a good thing.
Sep 05 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 What's wrong with static_assert()? If it's ugly, I have no problem with




that

 (static_cast, reinterpret_cast, etc.).





static_assert is fine with me, what is not neat is stlsoft_static_assert.


Well, in D we don't have the spectre of the global namespace polluting macro
preprocessor to worry about, so static_assert is fine. When you're dealing
with C/C++, you absolutely have to make your macros practically clash-proof,
hence the ugly (to you, naturally its beautiful to me) prefix stlsoft_

:)
Sep 05 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
"Matthew Wilson" <matthew stlsoft.org> a écrit dans le message de
news:bj9fa4$bnr$1 digitaldaemon.com...

 What's wrong with static_assert()? If it's ugly, I have no problem with




 that

 (static_cast, reinterpret_cast, etc.).





static_assert is fine with me, what is not neat is stlsoft_static_assert.


 Well, in D we don't have the spectre of the global namespace polluting


macro

 preprocessor to worry about, so static_assert is fine. When you're dealing
 with C/C++, you absolutely have to make your macros practically


clash-proof,

 hence the ugly (to you, naturally its beautiful to me) prefix stlsoft_

 :)


A better solution would be to provide some knid of module/namespace
concept for C imported stuff... so it would be C names that would be
uglier and not the D ones...

The best thing would be import with the possibility to qualify imported
names (see also .h to D conversion thread).
Sep 05 2003
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Philippe Mori wrote:


 A better solution would be to provide some knid of module/namespace
 concept for C imported stuff... so it would be C names that would be
 uglier and not the D ones...


You haven't really read this thread, have you? :)
It's technically impossible (and infeasible) to import 
stlsoft_static_assert into D, however hard you try! :)
Nor is it possible to import any template library at all...
It was about adding the language feature.


 The best thing would be import with the possibility to qualify imported
 names (see also .h to D conversion thread).


Why the hell? D forces modules on *everything*...
Each source file is in a separate namespace.

-eye
Sep 05 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Ok, everyone. I'm getting confused, and I suspect I'm not alone.

All I want is something that is analogous to assert(), except that it is
evaluated at compile-time, and called static_assert() (or, if we must,
ct_assert(), though I think that's ugly).

static_assert() would:
  - not issue code under any circumstances. It's entirely compile-time
  - issue a compile-time warning if the invariant was invalid. It would
provide a meaningful message. (For those of you that have used ct-asserts in
C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
stuff isn't perfect.)
  - issue a rejection, plus appropriately distinct (i.e. from from invariant
invalidity) message if the code is run-time evaluable.

Now some have argued that we should have a third category that checks
invariants at compile-time if possible, otherwise at runtime. I do not think
this is a good thing, but this is a different argument from whether we have
a static assert. IMO the two things are entirely different, and should
remain so. Even if we were to "allow" an implementation to do compile-time
checks on runtime assertions, I think this would have unforeseen -ve
consequences, though of course I cannot say what, since I have not foreseen
them :(

So, I'd be keen to know everyone's desire for static assertions? Good
thing/bad thing?

I'm not trying to stifle debate on whether a mixed-mode (compile-time if
poss, falling back on runtime) assertion is a good thing, in fact I will be
interested in such a debate. I'd just like to know what everyone thinks
about a pure compile-time assertion, and (because I can't imagine anyone
would not want one) what features we think it should have.

Matthew


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bjb3fb$2l9s$1 digitaldaemon.com...

 Philippe Mori wrote:


 A better solution would be to provide some knid of module/namespace
 concept for C imported stuff... so it would be C names that would be
 uglier and not the D ones...


 You haven't really read this thread, have you? :)
 It's technically impossible (and infeasible) to import
 stlsoft_static_assert into D, however hard you try! :)
 Nor is it possible to import any template library at all...
 It was about adding the language feature.


 The best thing would be import with the possibility to qualify imported
 names (see also .h to D conversion thread).


 Why the hell? D forces modules on *everything*...
 Each source file is in a separate namespace.

 -eye
Sep 05 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 Ok, everyone. I'm getting confused, and I suspect I'm not alone.

 All I want is something that is analogous to assert(), except that it is
 evaluated at compile-time, and called static_assert() (or, if we must,
 ct_assert(), though I think that's ugly).

 static_assert() would:
   - not issue code under any circumstances. It's entirely compile-time


This is a good thing as some C++ solutions will generate extra code
at least in debug version when the stuff doesn't get inlined.


   - issue a compile-time warning if the invariant was invalid. It would
 provide a meaningful message. (For those of you that have used ct-asserts


in

 C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
 stuff isn't perfect.)


By default, it should be an error and ideally we would have some control
on the displayed message (being able to print constants or type...).

We would then decide one oof the following solution:

1) Uses some printf style message maybe with limited formatting.

        static_assert(sizeof a < sizeof b, "a is too big (a = %d, b = %d)",
sizeof a, sizeof b)

    that will output something like :

        a is too big (a = 34, b = 4)

2) The compiler would have an option to display "computed expression
automatically (we might have a verbose option)

        static_assert(sizeof a < sizeof b, "a is too big")

    that will output something like

        a is too big
        34 {sizeof a} < 3 {sizeof b}

3) Something between those 2 options:

        static_assert(sizeof a < sizeof b, "a is too big", sizeof a, sizeof
b)

       thew ouput would be

        a is too big
        sizeof a : 34
        sizeof b : 3


I think I prefer the third solution. The first argument is the condition,
the
second one is the message displayed to the user and remainding arguments
are optional expression to evaluate and display if the verification fails.

The message is also optional... A default message is displayed if
none is provided.


   - issue a rejection, plus appropriately distinct (i.e. from from


invariant

 invalidity) message if the code is run-time evaluable.


Yes, it would be an error if the condition cannot be evaluated at compile
time. The message would be somewhat different to the message when
the evaluation fails... We should indicated which part cannot be evaluated.


 Now some have argued that we should have a third category that checks
 invariants at compile-time if possible, otherwise at runtime. I do not


think

 this is a good thing, but this is a different argument from whether we


have

 a static assert. IMO the two things are entirely different, and should
 remain so. Even if we were to "allow" an implementation to do compile-time
 checks on runtime assertions, I think this would have unforeseen -ve
 consequences, though of course I cannot say what, since I have not


foreseen

 them :(


In fact, I'm not sure if a third type is necessary or if we should try to
evaluate all normal assertion at compile time...

I do however think we need to be able to support an assertion that
can be both at the same time.

Say that I have a function f in class A and B (where B derives from A)
and that f is not yet implemented in class B... I would like that the
compiler
issues an error when it is know at compile time that B.f() is called and
issues a run-time assertion if called at run-time...

IMO, it would be better to have a third category as it would allows us
to have more controls on what happens at compile-time vs what happen
at run time...


 So, I'd be keen to know everyone's desire for static assertions? Good
 thing/bad thing?


Static assertion are a good thing and being able to knows for sure that
an assertion is compile-time, run-time or both is usefull. We need at least
2 categories (compile-time and both run-time and compile-time).

Note that we may add a 4 category if it is desirable that run-time
generate an error if they can always be evaluated at compile-time.
That category would be either and won't be affected by changes
that make something be constant or not at compile time. This could
be the case if someone want to uses global constant to control
check that are active.

const bool assertion_enabled = false;

assert(assertion_enabled && my_check());

Here it is possible to activate/desactivate a group of check using
a constant...

Another possibility would be to have a modifier to indicate that
a function is an assertion function...

I would also like the ability to display expression for failed
run-time assertiion....


 I'm not trying to stifle debate on whether a mixed-mode (compile-time if
 poss, falling back on runtime) assertion is a good thing, in fact I will


be

 interested in such a debate. I'd just like to know what everyone thinks
 about a pure compile-time assertion, and (because I can't imagine anyone
 would not want one) what features we think it should have.


Pure compile-time is need and run-time is also required...
Sep 06 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
How about:

if (!condition)
    bomb("assert %d failed on object %.s", ptr, obj.name());

Ok, you could call it error, or whatever.  It could even be an exception
class that you have to throw.  The nice thing about this is that if() is
already done at compile time if the argument is a constant expression.  It's
a bit more explicit than assert, and more versatile.   If the compiler
detects an unhandled throw that will always happen maybe it could show an
error at compile time.

I still think we need a form of sprintf that produces a D string, so we
won't have so many copies of the same printf functionality.

Sean

"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bjcs0m$28bm$1 digitaldaemon.com...

 Ok, everyone. I'm getting confused, and I suspect I'm not alone.

 All I want is something that is analogous to assert(), except that it is
 evaluated at compile-time, and called static_assert() (or, if we must,
 ct_assert(), though I think that's ugly).

 static_assert() would:
   - not issue code under any circumstances. It's entirely compile-time


 This is a good thing as some C++ solutions will generate extra code
 at least in debug version when the stuff doesn't get inlined.


   - issue a compile-time warning if the invariant was invalid. It would
 provide a meaningful message. (For those of you that have used




ct-asserts

 in

 C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
 stuff isn't perfect.)


 By default, it should be an error and ideally we would have some control
 on the displayed message (being able to print constants or type...).

 We would then decide one oof the following solution:

 1) Uses some printf style message maybe with limited formatting.

         static_assert(sizeof a < sizeof b, "a is too big (a = %d, b =


%d)",

 sizeof a, sizeof b)

     that will output something like :

         a is too big (a = 34, b = 4)

 2) The compiler would have an option to display "computed expression
 automatically (we might have a verbose option)

         static_assert(sizeof a < sizeof b, "a is too big")

     that will output something like

         a is too big
         34 {sizeof a} < 3 {sizeof b}

 3) Something between those 2 options:

         static_assert(sizeof a < sizeof b, "a is too big", sizeof a,


sizeof

 b)

        thew ouput would be

         a is too big
         sizeof a : 34
         sizeof b : 3


 I think I prefer the third solution. The first argument is the condition,
 the
 second one is the message displayed to the user and remainding arguments
 are optional expression to evaluate and display if the verification fails.

 The message is also optional... A default message is displayed if
 none is provided.


   - issue a rejection, plus appropriately distinct (i.e. from from


 invariant

 invalidity) message if the code is run-time evaluable.


 Yes, it would be an error if the condition cannot be evaluated at compile
 time. The message would be somewhat different to the message when
 the evaluation fails... We should indicated which part cannot be


evaluated.

 Now some have argued that we should have a third category that checks
 invariants at compile-time if possible, otherwise at runtime. I do not


 think

 this is a good thing, but this is a different argument from whether we


 have

 a static assert. IMO the two things are entirely different, and should
 remain so. Even if we were to "allow" an implementation to do




compile-time

 checks on runtime assertions, I think this would have unforeseen -ve
 consequences, though of course I cannot say what, since I have not


 foreseen

 them :(


 In fact, I'm not sure if a third type is necessary or if we should try to
 evaluate all normal assertion at compile time...

 I do however think we need to be able to support an assertion that
 can be both at the same time.

 Say that I have a function f in class A and B (where B derives from A)
 and that f is not yet implemented in class B... I would like that the
 compiler
 issues an error when it is know at compile time that B.f() is called and
 issues a run-time assertion if called at run-time...

 IMO, it would be better to have a third category as it would allows us
 to have more controls on what happens at compile-time vs what happen
 at run time...


 So, I'd be keen to know everyone's desire for static assertions? Good
 thing/bad thing?


 Static assertion are a good thing and being able to knows for sure that
 an assertion is compile-time, run-time or both is usefull. We need at


least

 2 categories (compile-time and both run-time and compile-time).

 Note that we may add a 4 category if it is desirable that run-time
 generate an error if they can always be evaluated at compile-time.
 That category would be either and won't be affected by changes
 that make something be constant or not at compile time. This could
 be the case if someone want to uses global constant to control
 check that are active.

 const bool assertion_enabled = false;

 assert(assertion_enabled && my_check());

 Here it is possible to activate/desactivate a group of check using
 a constant...

 Another possibility would be to have a modifier to indicate that
 a function is an assertion function...

 I would also like the ability to display expression for failed
 run-time assertiion....


 I'm not trying to stifle debate on whether a mixed-mode (compile-time if
 poss, falling back on runtime) assertion is a good thing, in fact I will


 be

 interested in such a debate. I'd just like to know what everyone thinks
 about a pure compile-time assertion, and (because I can't imagine anyone
 would not want one) what features we think it should have.


 Pure compile-time is need and run-time is also required...
Sep 06 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> a écrit dans le message de
news:bjd0f6$2edn$1 digitaldaemon.com...

 How about:

 if (!condition)
     bomb("assert %d failed on object %.s", ptr, obj.name());

 Ok, you could call it error, or whatever.  It could even be an exception
 class that you have to throw.  The nice thing about this is that if() is
 already done at compile time if the argument is a constant expression.


It's

 a bit more explicit than assert, and more versatile.   If the compiler
 detects an unhandled throw that will always happen maybe it could show an
 error at compile time.


But some compiler gives a warning if a conditionnal expression is always
true...

Maybe the solution would be to uses a modifier to tag static, run-time (and
both)
assertion functions so that the compiler will knows the purpose but the user
would be able to provide as many functions as he would like and we could
even add an optionnal clause that would give a condition when the assertion
is checked (maybe, this could be done with version)

And as in my previous message, I think that the variable arguments
that are output as a string would be very nice particulary if it also
works at run-time.

And it should also be possible to pass information like __FILE__ and
__LINE__.

So something similar to that

runtime assert(__FILE__ as string f, __LINE__ as int l, bool cond, ... as
string s)
{
    // Do what you want here...
}

where s is a string from concatenation of all arguments so that we can
for example write some values that are used in the expression when it fails
and that both at compile or run-time.

For static assertion, the body would be empty and the compiler would write
the messsage that would include the string s.

compiletime static_assert(bool cond, ... as string s)
{    // empty body (or only declaration)
}

We could have both overload if we want more customization of the
message (for ex. internationalisation of run-time errors with multiples
arguments).


 I still think we need a form of sprintf that produces a D string, so we
 won't have so many copies of the same printf functionality.


But for the assertion purpose, I think that variable arguments converted
to string in order would be a good way since it is simple and safe...
Sep 09 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjbrk0$kua$2 digitaldaemon.com...

 Now some have argued that we should have a third category that checks
 invariants at compile-time if possible, otherwise at runtime. I do not


think

 this is a good thing, but this is a different argument from whether we


have

 a static assert. IMO the two things are entirely different, and should
 remain so. Even if we were to "allow" an implementation to do compile-time
 checks on runtime assertions, I think this would have unforeseen -ve
 consequences, though of course I cannot say what, since I have not


foreseen

 them :(


I can't foresee any problems either.  I want to know about assert failures
as early as possible, at compile time is better than at runtime in all
cases.


 So, I'd be keen to know everyone's desire for static assertions? Good
 thing/bad thing?


Good thing.


 I'm not trying to stifle debate on whether a mixed-mode (compile-time if
 poss, falling back on runtime) assertion is a good thing, in fact I will


be

 interested in such a debate. I'd just like to know what everyone thinks
 about a pure compile-time assertion, and (because I can't imagine anyone
 would not want one) what features we think it should have.


I think the compiler should have some way of doing compile-time asserts.
I'd rather just have the mixed-mode assert, where the compiler attempts to
evaluate the expression at compile time, and if triggered, gives a compiler
error, and if it isn't fully evaluatable at compile time, generates runtime
code.

This would be useful to keep people from instantiating template libraries
with invalid parameters and such.  Stuff that the compiler wouldn't
otherwise catch but which would be an obvious error to the template library
writer.  We don't have parameter type constraints yet.  What if your integer
template can only handle values > 0?


 Matthew
Sep 06 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjbrk0$kua$2 digitaldaemon.com...

 static_assert() would:
   - not issue code under any circumstances. It's entirely compile-time
   - issue a compile-time warning if the invariant was invalid. It would
 provide a meaningful message. (For those of you that have used ct-asserts


in

 C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
 stuff isn't perfect.)
   - issue a rejection, plus appropriately distinct (i.e. from from


invariant

 invalidity) message if the code is run-time evaluable.


I'm with you, except that I think that a failed assertion should issue an
error instead of a warning. If you remember Walter's Web page on the origin
of D, well, I'm one of those who enable maximum warning level and have the
compiler stop on warnings... :)

About "mixed-mode" assertions, well, if an expression is completely
evaluable at compile time (an optimizing compiler should give it a try, no
matter if it is inside an assert or not...) it will always either fail or
pass, which makes the use of such an expression as an assertion at the least
questionable; so I think a compile-time warning (if not an error) should be
issued in _both_ cases.

Ric
Sep 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bjh9r7$2itd$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjbrk0$kua$2 digitaldaemon.com...

 static_assert() would:
   - not issue code under any circumstances. It's entirely compile-time
   - issue a compile-time warning if the invariant was invalid. It would
 provide a meaningful message. (For those of you that have used




ct-asserts

 in

 C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
 stuff isn't perfect.)
   - issue a rejection, plus appropriately distinct (i.e. from from


 invariant

 invalidity) message if the code is run-time evaluable.


 I'm with you, except that I think that a failed assertion should issue an
 error instead of a warning. If you remember Walter's Web page on the


origin

 of D, well, I'm one of those who enable maximum warning level and have the
 compiler stop on warnings... :)


Sorry. I hadn't realised I'd written that. I most certainly do not want a
warning. I should have written

   - issue a compile-time *error* if the invariant was invalid. It would
provide a meaningful message. (For those of you that have used ct-asserts in
C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
stuff isn't perfect.)
   - issue an *error*, plus appropriately distinct (i.e. from from invariant
invalidity) message if the code is run-time evaluable.
Sep 08 2003
parent reply John Boucher <John_member pathlink.com> writes:
As I've followed this discussion, I've seen where a built-in assert() is indeed
useful if it will work at compile-time. However I'm still of the opinion that
the developer should be able to define his own assert(), at least for run-time.
My earlier comment that I want to specify _what_ information is logged when an
assert() fails still holds, but I remembered that I also want to specify _where_
that information is logged.
I prefer to log to stderr rather than stdout (remember, I'm an OpenVMS kind of
guy). And on my last job, log messages where actually sent across the network to
a server that was monitored by tech support 24/7.

John Boucher
The King had Humpty pushed.
Sep 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I agree. Run-time assert should be pluggable.

"John Boucher" <John_member pathlink.com> wrote in message
news:bjid13$15s8$1 digitaldaemon.com...

 As I've followed this discussion, I've seen where a built-in assert() is


indeed

 useful if it will work at compile-time. However I'm still of the opinion


that

 the developer should be able to define his own assert(), at least for


run-time.

 My earlier comment that I want to specify _what_ information is logged


when an

 assert() fails still holds, but I remembered that I also want to specify


_where_

 that information is logged.
 I prefer to log to stderr rather than stdout (remember, I'm an OpenVMS


kind of

 guy). And on my last job, log messages where actually sent across the


network to

 a server that was monitored by tech support 24/7.

 John Boucher
 The King had Humpty pushed.
Sep 08 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjj58f$2a81$1 digitaldaemon.com...

 I agree. Run-time assert should be pluggable.


Absolutely. My target systems hardly have a console at all, go figure!

Ric
Sep 09 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 A better solution would be to provide some knid of module/namespace
 concept for C imported stuff... so it would be C names that would be
 uglier and not the D ones...


 You haven't really read this thread, have you? :)
 It's technically impossible (and infeasible) to import
 stlsoft_static_assert into D, however hard you try! :)
 Nor is it possible to import any template library at all...
 It was about adding the language feature.


Well, I might have not understand well from where stlsoft_static_assert
come from... I was thinking that stlsoft_ prefix was added to avoid
some conflicts with other definition of static_assert...


 The best thing would be import with the possibility to qualify imported
 names (see also .h to D conversion thread).


 Why the hell? D forces modules on *everything*...
 Each source file is in a separate namespace.


Not for D stuff. It would be a pain but maybe if we uses
C stuff, we might like to make it appears as one module
to ensure it won't conflict with D.

So my suggestion was essentially to make name that
come from C uglier if necessary and ensure that D name
are friendly....
Sep 06 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bjb2ug$2kjk$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> a écrit dans le message de
 news:bj9fa4$bnr$1 digitaldaemon.com...

 What's wrong with static_assert()? If it's ugly, I have no problem








with

 that

 (static_cast, reinterpret_cast, etc.).





static_assert is fine with me, what is not neat is






stlsoft_static_assert.

 Well, in D we don't have the spectre of the global namespace polluting


 macro

 preprocessor to worry about, so static_assert is fine. When you're




dealing

 with C/C++, you absolutely have to make your macros practically


 clash-proof,

 hence the ugly (to you, naturally its beautiful to me) prefix stlsoft_

 :)


 A better solution would be to provide some knid of module/namespace
 concept for C imported stuff... so it would be C names that would be
 uglier and not the D ones...


Sorry, dude. I suspect we may be talking at cross-purposes. I was explaining
the ugliness of the STLSoft static assert, precisely because it must take
care of the CPP. I don't want anything like that in D. There's no need.

(Maybe we're in violent agreement. Dunno. :)

Matthew
Sep 05 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"J Anderson" <anderson badmama.com.au.REMOVE> wrote in message
news:bj7bls$a1d$1 digitaldaemon.com...

 I'd be nice if the compiler could use normal assertions as static
 assertions when it identifies that the assertion parameters are constant.


That's a good thought, but it would be hard to make it not trip for things
like:

    if (somecondition)
        assert(0);

when the flow of control is not known at compile time.
Sep 14 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 In C++

    #define stlsoft_static_assert(_x)        do { typedef int ai[(_x) ? 1 :
 0]; } while(0)


I don't see the advantage of using a do/while loop for the check...
I think that without the loop, the check could be done at more
place like inside a class declaration or at global scope...


 as in

   stlsoft_static_assert(sizeof(int) <= 4);

 basically, any compile-time evaluable condition that can be subjected to a
 compile-time invariant check by this.

 Does D have such things? If not, can we have it?

 btw, this uses the nasty empty/-ve array dimension trick. It'd be much


nicer

 if D said something like:

  "Static assertion check failure: etc."


In C++, I prefer static assertion based on template as it allows to
produces more helpfull message with many compiler. In particular,
it is possible to see the expected and computed values in the
error message with a message like "cannot convert
StaticCheck::Value<2> to StaticCheck::Value<4>". Here is some
of the code:

namespace StaticCheck
{
 // Uses by macro STATIC_CHECK_EQUAL to validate that both size are
 // equal.
 template <long> struct Value { };

 // Used by macros that compare 2 values. If the condition is not satisfied
 // the last template argument won't match.
 template <long p1, long p2, bool p3> struct ValueCond { };
}

/*
 STATIC_CHECK_EQUAL      a == b

 Ensure at compile-time that two values are identical.

 Can be used to validate that a structure has the expected size.

 Example: STATIC_CHECK_EQUAL(sizeof(int), 4); // 4 bytes int ?
*/

#define STATIC_CHECK_EQUAL(a, b) \
 StaticCheck::Value<(a)>(((void)0, StaticCheck::Value<(b)>()))


/*
 STATIC_CHECK_LOWER(a, b)    a <  b ?
 STATIC_CHECK_LOWER_EQUAL(a, b)   a <= b ?
 STATIC_CHECK_GREATER(a, b)    a >  b ?
 STATIC_CHECK_GREATER_EQUAL(a, b)  a >= b ?
 STATIC_CHECK_NOT_EQUAL(a, b)   a != b ?


 Allows to do some compile-time comparisons.

 For example, to ensure that a buffer can contains at least 40 items,
 the following test could be done:

  STATIC_CHECK_GREATER(sizeof buffer / sizeof *buffer, 40);
*/

#define STATIC_CHECK_LOWER(a, b) \
 StaticCheck::ValueCond<(a), (b), ((a) < (b))> \
  (((void)0, StaticCheck::ValueCond<(a), (b), true>()))

#define STATIC_CHECK_LOWER_EQUAL(a, b) \
 StaticCheck::ValueCond<(a), (b), ((a) <= (b))> \
  (((void)0, StaticCheck::ValueCond<(a), (b), true>()))

#define STATIC_CHECK_GREATER(a, b) \
 StaticCheck::ValueCond<(a), (b), ((a) > (b))> \
  (((void)0, StaticCheck::ValueCond<(a), (b), true>()))

#define STATIC_CHECK_GREATER_EQUAL(a, b) \
 StaticCheck::ValueCond<(a), (b), ((a) >= (b))> \
  (((void)0, StaticCheck::ValueCond<(a), (b), true>()))

#define STATIC_CHECK_NOT_EQUAL(a, b) \
 StaticCheck::ValueCond<(a), (b), ((a) != (b))> \
  (((void)0, StaticCheck::ValueCond<(a), (b), true>()))


Ideally, I would like to be able to do similar check
with better compiler support. One clean way would
be to have static check functions and the possibility
to output customized error message like that:

void metafunction test_ge(int i1, int i2)
{
    compile_check(i1 >= i2, "%s is not greater or " \
        "equal to %s, i1.toString(), i2.toString());
}

where arguments would need to be compile time
expression (required for metafunction) but they
could be template so that we can make the above
works for any simple types.

If fact metafunction could be used in other
situations in meta-programming and
compile_check would be usable anywhere
a declaration could appears...

For the formatting, we might support a
simplified syntax and might only support
types that the compiler knows and that
with simplified formatting.
Sep 04 2003