Dear All,

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

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

Regards,

pts

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
>
>

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
> >
> >
>
>

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
> > >
> > >
> >
> >
>
>

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.

<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

> 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.

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

> 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

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.