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

 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

 Dear All,

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

 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


 or any equivalent mechanism?

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

 Dear All,

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

 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
      


or any equivalent mechanism?

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

Dear All,

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

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

Regards,

pts


        




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

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:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

  

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.

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


  

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


 (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


 (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

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

 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

 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

 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

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

 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

 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

 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


 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 =

 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,

 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

 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

 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

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

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


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

 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

 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

 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.

 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

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

 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

 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

 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

 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

 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


 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

 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

 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

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

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

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

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

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

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

 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




 that
 (static_cast, reinterpret_cast, etc.).


static_assert is fine with me, what is not neat is



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

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


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

 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

 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