* where exactly c++,c fail and Ada gets thru' @ 2006-04-24 4:19 Ananth the Boss 2006-04-24 5:05 ` jimmaureenrogers ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Ananth the Boss @ 2006-04-24 4:19 UTC (permalink / raw) we are developing safety critical software.my seniors say that c and c++ are not suitable for safety critical software development and ada is very much safe.NASA aslo uses Ada.at what point c++ or c turns to be not suitable for devleloping flight software. i may be wrong also. can any one give some more justifications for telling "ADA is safe" thanks in advance ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 4:19 where exactly c++,c fail and Ada gets thru' Ananth the Boss @ 2006-04-24 5:05 ` jimmaureenrogers 2006-04-24 7:45 ` Ananth the Boss ` (4 more replies) 2006-04-24 8:13 ` Rod Chapman 2006-04-25 1:57 ` Steve 2 siblings, 5 replies; 27+ messages in thread From: jimmaureenrogers @ 2006-04-24 5:05 UTC (permalink / raw) Ananth the Boss wrote: > we are developing safety critical software.my seniors say that c and > c++ are not suitable for safety critical software development and ada > is very much safe.NASA aslo uses Ada.at what point c++ or c turns to be > not suitable for devleloping flight software. i may be wrong also. can > any one give some more justifications for telling "ADA is safe" thanks > in advance The Coding Standards for the Joint Strike Fighter http://public.research.att.com/~bs/JSF-AV-rules.pdf give you an idea of the kinds of safety problems recognized in both C and C++. For example, the standard prohibits the use of C-style arrays as function parameters. The problem cited is the degeneration of an array function argument into a pointer. The pointer provides no information about the size of the array it points to. This problem commonly leads to overflowing arrays. Accessing elements beyond the end of an array is always problematic. The C standard explicitly allows one to access one element beyond the end of an array to support common practice in thousands of C programs. The C standard indicates that accessing more than one beyond the end of an array leads to undefined behavior. Polymorphism is one of the heavily used features of C++. Polymorphism intentionally makes it difficult to determine which over-ridden version of a function will be called. Safety critical software standards require the ability to statically determine which function will be called. Polymorphism seriously complicates such static analysis. Neither C nor C++ provides any standard means for detecting overflow or underflow of numeric types. C provides no way to ensure that a numeric type uses only a valid set of values. C++ forces you to define a class wrapping the numeric value. You must also provide all the range checking, resulting in a very inefficient use of programmer time as well as processor time. C++ allows you to define a restricted range integer class as a template. It does not allow you to define a restricted range floating point class because you cannot use floating point values as template parameters. There is no way in C++ to define a template class that achieves the equivalent of: type Normalized_Type is digits 10 range 0.0..1.0; Jim Rogers ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 5:05 ` jimmaureenrogers @ 2006-04-24 7:45 ` Ananth the Boss 2006-04-24 19:17 ` Martin Krischik ` (3 subsequent siblings) 4 siblings, 0 replies; 27+ messages in thread From: Ananth the Boss @ 2006-04-24 7:45 UTC (permalink / raw) thnk you ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 5:05 ` jimmaureenrogers 2006-04-24 7:45 ` Ananth the Boss @ 2006-04-24 19:17 ` Martin Krischik 2006-04-24 20:23 ` Simon Wright ` (2 subsequent siblings) 4 siblings, 0 replies; 27+ messages in thread From: Martin Krischik @ 2006-04-24 19:17 UTC (permalink / raw) Hi Ananth > Ananth the Boss wrote: >> NASA aslo uses Ada.at what point c++ or c turns to be >> not suitable for devleloping flight software. i may be wrong also. can >> any one give some more justifications for telling "ADA is safe" thanks >> in advance > Neither C nor C++ provides any standard means for detecting > overflow or underflow of numeric types. ï¿œC provides no way to > ensure that a numeric type uses only a valid set of values. C++ > forces you to define a class wrapping the numeric value. Just in case you have not read up on Ada typing here some pointers: http://en.wikibooks.org/wiki/Ada_Programming/Types http://en.wikibooks.org/wiki/Ada_Programming/Subtypes Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 5:05 ` jimmaureenrogers 2006-04-24 7:45 ` Ananth the Boss 2006-04-24 19:17 ` Martin Krischik @ 2006-04-24 20:23 ` Simon Wright 2006-04-24 22:34 ` Keith Thompson 2006-04-24 22:33 ` Keith Thompson 2006-04-26 15:10 ` Maciej Sobczak 4 siblings, 1 reply; 27+ messages in thread From: Simon Wright @ 2006-04-24 20:23 UTC (permalink / raw) "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > The C standard explicitly > allows one to access one element beyond the end of an array to > support common practice in thousands of C programs. The C > standard indicates that accessing more than one beyond the end > of an array leads to undefined behavior. As I remember it, you are allowed to use the address of the element one past the end of the array in a comparison with the addresses of other elements of the same array, but not to access its content? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 20:23 ` Simon Wright @ 2006-04-24 22:34 ` Keith Thompson 0 siblings, 0 replies; 27+ messages in thread From: Keith Thompson @ 2006-04-24 22:34 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > "jimmaureenrogers@worldnet.att.net" > <jimmaureenrogers@worldnet.att.net> writes: > >> The C standard explicitly >> allows one to access one element beyond the end of an array to >> support common practice in thousands of C programs. The C >> standard indicates that accessing more than one beyond the end >> of an array leads to undefined behavior. > > As I remember it, you are allowed to use the address of the element > one past the end of the array in a comparison with the addresses of > other elements of the same array, but not to access its content? Correct. Note that "allowed to" is a fairly weak statement in C; accessing elements beyond the bounds of an array isn't "allowed", but it's undefined behavior, meaning that the implementation is under no obligation to diagnose the error. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 5:05 ` jimmaureenrogers ` (2 preceding siblings ...) 2006-04-24 20:23 ` Simon Wright @ 2006-04-24 22:33 ` Keith Thompson 2006-04-25 5:23 ` Jeffrey R. Carter 2006-04-26 17:48 ` Martin Krischik 2006-04-26 15:10 ` Maciej Sobczak 4 siblings, 2 replies; 27+ messages in thread From: Keith Thompson @ 2006-04-24 22:33 UTC (permalink / raw) "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > Ananth the Boss wrote: >> we are developing safety critical software.my seniors say that c and >> c++ are not suitable for safety critical software development and ada >> is very much safe.NASA aslo uses Ada.at what point c++ or c turns to be >> not suitable for devleloping flight software. i may be wrong also. can >> any one give some more justifications for telling "ADA is safe" thanks >> in advance > > The Coding Standards for the Joint Strike Fighter > http://public.research.att.com/~bs/JSF-AV-rules.pdf > give you an idea of the kinds of safety problems recognized in both > C and C++. > > For example, the standard prohibits the use of C-style arrays as > function parameters. The problem cited is the degeneration of an > array function argument into a pointer. The pointer provides no > information about the size of the array it points to. In fact, it's not possible in C to pass an array directly as a function parameter. The language allows a parameter to be declared with array syntax, but this is exactly equivalent to declaring it as a pointer. For example, these two C declarations are exactly equivalent: void func(int arr[]); void func(int *arr); It's a common misconception that arrays are "really" pointers in C. In fact they're not, but there are some features of the language (certain implicit conversions, the above syntax for parameter declarations) that can make it look that way. If you're curious about the details, section 6 of the comp.lang.c FAQ has a good summary. I haven't looked at the coding standards document in question. Possibly it just forbids the use of array syntax to represent what's really a pointer parameter. Forbidding pointer parameters would be a serious problem; much of the standard library does this, and it's the normal way to achieve the effect of passing an array. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 22:33 ` Keith Thompson @ 2006-04-25 5:23 ` Jeffrey R. Carter 2006-04-26 17:48 ` Martin Krischik 1 sibling, 0 replies; 27+ messages in thread From: Jeffrey R. Carter @ 2006-04-25 5:23 UTC (permalink / raw) Keith Thompson wrote: > > I haven't looked at the coding standards document in question. > Possibly it just forbids the use of array syntax to represent what's > really a pointer parameter. Forbidding pointer parameters would be a > serious problem; much of the standard library does this, and it's the > normal way to achieve the effect of passing an array. It's also the source for Ritchie's observation that "C's solution to this [variable-sized array parameters] has real problems, and people who are complaining about safety definitely have a point." -- Jeff Carter "Why don't you bore a hole in yourself and let the sap run out?" Horse Feathers 49 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 22:33 ` Keith Thompson 2006-04-25 5:23 ` Jeffrey R. Carter @ 2006-04-26 17:48 ` Martin Krischik 2006-04-26 19:33 ` Keith Thompson 1 sibling, 1 reply; 27+ messages in thread From: Martin Krischik @ 2006-04-26 17:48 UTC (permalink / raw) Keith Thompson wrote: > In fact, it's not possible in C to pass an array directly as a > function parameter. Actually C99 can pass arrays. The declaration looks something like this: F (int A_Lenght, double A [A_Lenght]) or G (double A [static 10]) or even H (double A [*]) But then: AFAIK: there is only one compiler which prides itself with actually implementing C99 arrays and one compiler which at least tries and and has the failures on it's bug list. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-26 17:48 ` Martin Krischik @ 2006-04-26 19:33 ` Keith Thompson 0 siblings, 0 replies; 27+ messages in thread From: Keith Thompson @ 2006-04-26 19:33 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> writes: > Keith Thompson wrote: >> In fact, it's not possible in C to pass an array directly as a >> function parameter. > > Actually C99 can pass arrays. The declaration looks something like this: > > F (int A_Lenght, double A [A_Lenght]) > > or > > G (double A [static 10]) > > or even > > H (double A [*]) > > But then: AFAIK: there is only one compiler which prides itself with > actually implementing C99 arrays and one compiler which at least tries and > and has the failures on it's bug list. I'm fairly sure that still passes a pointer, not the actual array. For example, the expression "sizeof(A)" inside the function will yield the size of a pointer, not the size of the array. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 5:05 ` jimmaureenrogers ` (3 preceding siblings ...) 2006-04-24 22:33 ` Keith Thompson @ 2006-04-26 15:10 ` Maciej Sobczak 2006-04-26 17:32 ` Martin Krischik 4 siblings, 1 reply; 27+ messages in thread From: Maciej Sobczak @ 2006-04-26 15:10 UTC (permalink / raw) Hi, jimmaureenrogers@worldnet.att.net wrote: > The C standard explicitly > allows one to access one element beyond the end of an array to > support common practice in thousands of C programs. The "access" word is misleading. It's allowed to use such address for comparisons and in arithemtics. It is *not* allowed to dereference it. > Polymorphism is one of the heavily used features of C++. But it is not forced (as is the case in some other "OO" languages). It is perfectly possible to write programs without the use of run-time polymorphism. > Safety > critical software standards require the ability to statically > determine which function will be called. It's possible to write such programs in C++. > Neither C nor C++ provides any standard means for detecting > overflow or underflow of numeric types. That's true. > C provides no way to > ensure that a numeric type uses only a valid set of values. True. > C++ > forces you to define a class wrapping the numeric value. Yes, classes are used to define new types. Is there any problem with this? It is also necessary in Ada if we want to do just a bit more of what is provided by type and subtype constructs. > You > must also provide all the range checking, resulting in a very > inefficient use of programmer time as well as processor time. Depends. The former can be automated and the latter can be statically elided. It's all the question of how it's done and templates provide a powerful mechanism that can help here. > C++ allows you to define a restricted range integer class as a > template. It does not allow you to define a restricted range > floating point class because you cannot use floating point > values as template parameters. That's true - at least if you require direct use of floating point. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-26 15:10 ` Maciej Sobczak @ 2006-04-26 17:32 ` Martin Krischik 2006-04-27 10:07 ` Maciej Sobczak 2006-04-27 16:48 ` REH 0 siblings, 2 replies; 27+ messages in thread From: Martin Krischik @ 2006-04-26 17:32 UTC (permalink / raw) Maciej Sobczak wrote: > Yes, classes are used to define new types. Is there any problem with > this? It is also necessary in Ada if we want to do just a bit more of > what is provided by type and subtype constructs. Say: type Y_Type is range 1 .. 10; subtype X_Type is new x range 1 .. 5; function F (X: X_Type) return Y_Type is begin return X + 3; end F Now I would expect that an Ada compiler will not insert any runtime checks as X + 3 is allways in the range of Y_Type. However: function G (X: X_Type) return Y_Type is begin return X + 7; end G; may well be outside the range of Y_Type and if so CONSTRAINT_ERROR will be raised. Now say we have a suitable C++ range template: typedef range<int, 1, 10> Y_Type; typedef range<Y_Type, 1, 5> X_Type; Y_Type F (X_Type X) { return X + 3; } Y_Type G (X_Type X) { return X + 7; } Now anyone up to the challenge to define: template <typename Base_Type, Base_Type First, Base_Type Last> range::operator = (Base_Type right) template <typename Base_Type, Base_Type First, Base_Type Last> range::operator + (Base_Type right) template <typename Base_Type, Base_Type First, Base_Type Last> range::range (Base_Type right) in such a way that it works like Ada - inclusive the *realistic* change that the compiler will optimize away the range check in F (). Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-26 17:32 ` Martin Krischik @ 2006-04-27 10:07 ` Maciej Sobczak 2006-04-27 21:19 ` Keith Thompson 2006-04-28 7:00 ` Martin Krischik 2006-04-27 16:48 ` REH 1 sibling, 2 replies; 27+ messages in thread From: Maciej Sobczak @ 2006-04-27 10:07 UTC (permalink / raw) Martin Krischik wrote: > Now say we have a suitable C++ range template: > > typedef range<int, 1, 10> Y_Type; > typedef range<Y_Type, 1, 5> X_Type; > > Y_Type F (X_Type X) > { > return X + 3; > } > > Y_Type G (X_Type X) > { > return X + 7; > } > > Now anyone up to the challenge to define: > > template <typename Base_Type, Base_Type First, Base_Type Last> > range::operator = (Base_Type right) > > template <typename Base_Type, Base_Type First, Base_Type Last> > range::operator + (Base_Type right) > > template <typename Base_Type, Base_Type First, Base_Type Last> > range::range (Base_Type right) > > in such a way that it works like Ada - inclusive the *realistic* change that > the compiler will optimize away the range check in F (). The C++ standard does not define to what extent the compilers are allowed to optimize the resulting code. This is the quality of implementation issue and an area of competition between compiler vendors. Without any further checks I can claim that it is possible for the compiler to optimize it the way you want. And without any further checks I take the risk to claim that the Ada standard does not require any conforming compiler to optimize range checks away as you described (or please throw some references) - similarly, this is the QoI issue. So - what was your point? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-27 10:07 ` Maciej Sobczak @ 2006-04-27 21:19 ` Keith Thompson 2006-04-28 7:00 ` Martin Krischik 1 sibling, 0 replies; 27+ messages in thread From: Keith Thompson @ 2006-04-27 21:19 UTC (permalink / raw) Maciej Sobczak <no.spam@no.spam.com> writes: > Martin Krischik wrote: >> Now say we have a suitable C++ range template: >> typedef range<int, 1, 10> Y_Type; >> typedef range<Y_Type, 1, 5> X_Type; >> Y_Type F (X_Type X) >> { >> return X + 3; >> } >> Y_Type G (X_Type X) >> { >> return X + 7; >> } >> Now anyone up to the challenge to define: >> template <typename Base_Type, Base_Type First, Base_Type Last> >> range::operator = (Base_Type right) >> template <typename Base_Type, Base_Type First, Base_Type Last> >> range::operator + (Base_Type right) >> template <typename Base_Type, Base_Type First, Base_Type Last> >> range::range (Base_Type right) >> in such a way that it works like Ada - inclusive the *realistic* >> change that >> the compiler will optimize away the range check in F (). > > The C++ standard does not define to what extent the compilers are > allowed to optimize the resulting code. Actually, I think it does; it just doesn't define to what extent compilers are *required* to optimize. (In C, allowed optimizations are determined by what's loosely called the "as-if rule"; C++ is probably similar.) > This is the quality of > implementation issue and an area of competition between compiler > vendors. Without any further checks I can claim that it is possible > for the compiler to optimize it the way you want. > > And without any further checks I take the risk to claim that the Ada > standard does not require any conforming compiler to optimize range > checks away as you described (or please throw some references) - > similarly, this is the QoI issue. > > So - what was your point? Probably the point was that range checks are an intrinsic feature of Ada, and any decent Ada compiler will optimize them as much as practical. In C++, on the other hand, any range checks would have to be done as explicit user code, and a typical C++ compiler might be less likely to recognize an idiom that it can optimize. A sufficiently clever C++ compiler should be able, in most cases, to optimize as well as a sufficiently clever Ada compiler (though I suspect Ada's aliasing rules allow for better optimizations in some cases). I have no idea whether current C++ compilers are "sufficiently clever". -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-27 10:07 ` Maciej Sobczak 2006-04-27 21:19 ` Keith Thompson @ 2006-04-28 7:00 ` Martin Krischik 2006-04-28 12:27 ` Maciej Sobczak 1 sibling, 1 reply; 27+ messages in thread From: Martin Krischik @ 2006-04-28 7:00 UTC (permalink / raw) Maciej Sobczak wrote: > Martin Krischik wrote: > > > Now say we have a suitable C++ range template: > > > > typedef range<int, 1, 10> Y_Type; > > typedef range<Y_Type, 1, 5> X_Type; > > > > Y_Type F (X_Type X) > > { > > return X + 3; > > } > > > > Y_Type G (X_Type X) > > { > > return X + 7; > > } > > > > Now anyone up to the challenge to define: > > > > template <typename Base_Type, Base_Type First, Base_Type Last> > > range::operator = (Base_Type right) > > > > template <typename Base_Type, Base_Type First, Base_Type Last> > > range::operator + (Base_Type right) > > > > template <typename Base_Type, Base_Type First, Base_Type Last> > > range::range (Base_Type right) > > > > in such a way that it works like Ada - inclusive the *realistic* change that > > the compiler will optimize away the range check in F (). > > The C++ standard does not define to what extent the compilers are > allowed to optimize the resulting code. This is the quality of > implementation issue and an area of competition between compiler > vendors. Without any further checks I can claim that it is possible for > the compiler to optimize it the way you want. > > And without any further checks I take the risk to claim that the Ada > standard does not require any conforming compiler to optimize range > checks away as you described (or please throw some references) - > similarly, this is the QoI issue. > > So - what was your point? The point is - of corse - it that the semantic tree of the Ada compiler contains the information that X will be in the range of (1 .. 5) and then the optimizer can easily calculate that (1 .. 5) + 3 < 10 and then optimize away the check. The sematinc tree of the C++ will contain the information that X is in the range of (-2*32 .. +2*32-1) and that is a pretty useless information to the optimizer. Martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-28 7:00 ` Martin Krischik @ 2006-04-28 12:27 ` Maciej Sobczak 2006-04-29 7:03 ` Martin Krischik 0 siblings, 1 reply; 27+ messages in thread From: Maciej Sobczak @ 2006-04-28 12:27 UTC (permalink / raw) Martin Krischik wrote: > The point is - of corse - it that the semantic tree of the Ada > compiler contains the information that X will be in the range of (1 .. > 5) and then the optimizer can easily calculate that (1 .. 5) + 3 < 10 > and then optimize away the check. > > The sematinc tree of the C++ will contain the information that X is in > the range of (-2*32 .. +2*32-1) and that is a pretty useless > information to the optimizer. Except that the optimizer is not limited to use only this information. With the two example ranges (1..5 and 1..10) the result of inlining will be that the following operations - all operating on the single value - will be placed one after another: 1. compare against 5 2. add 3 3. compare against 10 It doesn't take a rocket scientist to deduce that the third operation has a dead branch and can be therefore eliminated. Of course, Ada provides more information to the compiler and the more information the compiler has, the wider are the optimization opportunities, therefore languages with richer type systems are easier to optimize. Nobody questions that. But this is very far from the optimization being guaranteed in Ada or impossible in C++ - neither is the case. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-28 12:27 ` Maciej Sobczak @ 2006-04-29 7:03 ` Martin Krischik 2006-04-29 14:08 ` REH 2006-05-02 6:43 ` Maciej Sobczak 0 siblings, 2 replies; 27+ messages in thread From: Martin Krischik @ 2006-04-29 7:03 UTC (permalink / raw) Maciej Sobczak wrote: > Martin Krischik wrote: > >> The point is - of corse - it that the semantic tree of the Ada >> compiler contains the information that X will be in the range of (1 .. >> 5) and then the optimizer can easily calculate that (1 .. 5) + 3 < 10 >> and then optimize away the check. >> >> The sematinc tree of the C++ will contain the information that X is in >> the range of (-2*32 .. +2*32-1) and that is a pretty useless >> information to the optimizer. > > Except that the optimizer is not limited to use only this information. > With the two example ranges (1..5 and 1..10) the result of inlining will > be that the following operations - all operating on the single value - > will be placed one after another: > > 1. compare against 5 > 2. add 3 > 3. compare against 10 > > It doesn't take a rocket scientist to deduce that the third operation > has a dead branch and can be therefore eliminated. But it is the callers responsibility to check the input parameter before calling the function. That way range checks need only be performed on input and type convertions. Remember that Ada defines + as: function "+" is (L, R: in Integer'Base) return Integer'Base; Back to my example: If you call F(3) no check is needed. The caller knows that 3 is in range and the callee knows that X + 3 is in range. Of course: If the optimizer spots that is a different story. Now I do wonder if REH managed some template/boolean magic to get the same result on C++. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-29 7:03 ` Martin Krischik @ 2006-04-29 14:08 ` REH 2006-05-01 10:20 ` Xcriber51 2006-05-02 6:43 ` Maciej Sobczak 1 sibling, 1 reply; 27+ messages in thread From: REH @ 2006-04-29 14:08 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:1201812.r16X2gYOJE@linux1.krischik.com... > Now I do wonder if REH managed some template/boolean magic to get the same > result on C++. > The simplistic answer is for each ranged type R, there is an intermediate type I. I has the same properties as R, except it is allowed to "grow." That is, as the results of partial expressions become large, I chooses an integer type with a larger range (sadly, my technique will not work with floating point types). If I is not able to find a type with a larger enough range, it is flagged has having the possibility of overflowing. The math is basically done by partial specializing on whether overflow is possible. The tricky part is determining whether an overflow can occur. For this I took a page from my COBOL days. If you performed an operation on two values and tried to shove it into a variable without enough digits, COBOL would warning you. For example, multiplying two two-digit values and trying to assign it to anything less than a 4-digit variable can overflow. Of course, it is trivial to determine this for every algebraic operator. So, for each operation, we calculate the maximum number of digits needed for the result and try to use a type with that ranged. The maximum digits is kept in I. This allows intermediate values to exceed the bounds of the ranged type (like doing the math using R'Base). When a type I is assigned to type R, it is ranged check if necessary. If the lower or upper bounds of I is within the bounds of R, that particular check is also removed. This is all done at compile time. As an example, assume R is an unsigned type with a ranged of [0, 100]. The number of binary digits necessary to hold R is 7. So, if x and y are variables of type R, then x * y needs at most 14 digits. On any system, unsigned int can hold a 14-digit number. No overflow can happen, so no check is done. The result is of type I. I is a class temple whose template parameters hold information needed at compile-time. I "contains" type unsigned int, and 14 for the digits. I also "knows" it's base type (R), so is able to keep types unique. R can be instantiated with or without explicit construction (defines whether or not conversion to R requires an explicit cast), and with or without conversion operators (defines whether R can be implicitly converted to other types). R can bound the largest type allowed in its calculations. For example, assume we are on a system where int is 16 bits and long is 32 bits. If we take the resulting value of type I above and do I * I, this needs a 28-digit type. Normally, the resulting I type would use unsigned long. R can be bounded to stop at 16-bits if, for some reason you do not want to use type long. Thus, instead of growing, the new I would be flagged and the operation would be checked for overflow. Now, you may ask why I didn't just define I with the resulting range of [0, 1000]. The answer is that it would be a lot nastier because then I would also have to do overflow checking on the ranges at compile-time. It would be really nasty for signed types because you cannot just do the operation and check for overflow. Allowing a signed operation to overflow is undefined behavior. The above technique works for both signed and unsigned types, and all three integer representations allowed by the C++ standard. I'd like to enhance it to handle floating points, but I currently have no clue how that could be done. I'll admit the templates are very, very complex, but for the most part the client software does not have to worry about it. You can just use you would any other numerical type. I don't recall having any issue with "error messages" while writing it. Modern C++ compiler have gotten very good at giving more sane messages. They have also gotten better at compile times. My ranged type is not perfect, and there is no way to perfectly replicate what Ada can do, but as I said I cannot always use Ada. I also realize that the class will never be able to remove as many checks as an Ada compiler, but it is much better than nothing. The checks are very expensive since they are done in standard C++ (though one could sacrifice portability for speed if their compiler supported inline assembly). On benchmarks I've run, the class can be very close to raw integers in terms of speed, where not eliminating any checks can cost 10x or more. Of course this all depends on your system, compiler, etc., and the particular expressions (what the class can catch). In particular, very complex expressions will saturate the range of the types available quickly and inhibit anymore optimizations. Breaking the expression up can help to alleviate this, but each time an I is assigned to an R, a range check may have to be done (those range checking is much, much more efficient than overflow checking). REH ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-29 14:08 ` REH @ 2006-05-01 10:20 ` Xcriber51 2006-05-01 13:55 ` REH 0 siblings, 1 reply; 27+ messages in thread From: Xcriber51 @ 2006-05-01 10:20 UTC (permalink / raw) REH, my hat is off, but say, do you mind if I query how much the treatments cost afterwards? Also, I'd be interested in that article on its implementation - and the source code. Like all mortals in coding business, I too have a thing for brain damage. :-) Thanks in advance! Cheers K ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-05-01 10:20 ` Xcriber51 @ 2006-05-01 13:55 ` REH 0 siblings, 0 replies; 27+ messages in thread From: REH @ 2006-05-01 13:55 UTC (permalink / raw) Xcriber51 wrote: > REH, my hat is off, but say, do you mind if I query how much the treatments > cost afterwards? I'm not sure that you are asking. > > Also, I'd be interested in that article on its implementation - and the > source code. Like all mortals in coding business, I too have a thing for > brain damage. :-) > The latest source can be found here: http://www.richherrick.com/software/herrick_library.html The article is in doc/articles REH ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-29 7:03 ` Martin Krischik 2006-04-29 14:08 ` REH @ 2006-05-02 6:43 ` Maciej Sobczak 1 sibling, 0 replies; 27+ messages in thread From: Maciej Sobczak @ 2006-05-02 6:43 UTC (permalink / raw) Martin Krischik wrote: > But it is the callers responsibility to check the input parameter before > calling the function. Of course - and it's where the code inlining can be useful. The biggest advantage of inlining is not in removing function call/return stuff, but in putting together things that otherwise could not be analysed together. We could now start endless debate on the cases where you can or cannot have code inlining, but the whole point in optimization is that there are many ways to do it (including global program optimization, things like JIT and so on) - and, as already said, it's where compiler vendors compete. It's easier to optimize languages that have richer type information (and again - nobody questions that), but at the end of the day it's only the sequence of *observable behaviours* that is of interest to the programmer and everything else is left at the mercy of the optimizer - in this light, range checking is one of those things that are relatively easy to optimize. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-26 17:32 ` Martin Krischik 2006-04-27 10:07 ` Maciej Sobczak @ 2006-04-27 16:48 ` REH 2006-04-28 7:49 ` Martin Krischik 1 sibling, 1 reply; 27+ messages in thread From: REH @ 2006-04-27 16:48 UTC (permalink / raw) Martin Krischik wrote: > Maciej Sobczak wrote: > > > Yes, classes are used to define new types. Is there any problem with > > this? It is also necessary in Ada if we want to do just a bit more of > > what is provided by type and subtype constructs. > > Say: > > type Y_Type is range 1 .. 10; > subtype X_Type is new x range 1 .. 5; > > function F (X: X_Type) return Y_Type is > begin > return X + 3; > end F > > Now I would expect that an Ada compiler will not insert any runtime checks > as X + 3 is allways in the range of Y_Type. However: > > function G (X: X_Type) return Y_Type is > begin > return X + 7; > end G; > > may well be outside the range of Y_Type and if so CONSTRAINT_ERROR will be > raised. > > Now say we have a suitable C++ range template: > > typedef range<int, 1, 10> Y_Type; > typedef range<Y_Type, 1, 5> X_Type; > > Y_Type F (X_Type X) > { > return X + 3; > } > > Y_Type G (X_Type X) > { > return X + 7; > } > > Now anyone up to the challenge to define: > > template <typename Base_Type, Base_Type First, Base_Type Last> > range::operator = (Base_Type right) > > template <typename Base_Type, Base_Type First, Base_Type Last> > range::operator + (Base_Type right) > > template <typename Base_Type, Base_Type First, Base_Type Last> > range::range (Base_Type right) > > in such a way that it works like Ada - inclusive the *realistic* change that > the compiler will optimize away the range check in F (). I have done this. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-27 16:48 ` REH @ 2006-04-28 7:49 ` Martin Krischik 2006-04-28 11:17 ` REH 0 siblings, 1 reply; 27+ messages in thread From: Martin Krischik @ 2006-04-28 7:49 UTC (permalink / raw) REH wrote: > Martin Krischik wrote: > > Maciej Sobczak wrote: > > > > > Yes, classes are used to define new types. Is there any problem with > > > this? It is also necessary in Ada if we want to do just a bit more of > > > what is provided by type and subtype constructs. > > > > Say: > > > > type Y_Type is range 1 .. 10; > > subtype X_Type is new x range 1 .. 5; > > > > function F (X: X_Type) return Y_Type is > > begin > > return X + 3; > > end F > > > > Now I would expect that an Ada compiler will not insert any runtime checks > > as X + 3 is allways in the range of Y_Type. However: > > > > function G (X: X_Type) return Y_Type is > > begin > > return X + 7; > > end G; > > > > may well be outside the range of Y_Type and if so CONSTRAINT_ERROR will be > > raised. > > > > Now say we have a suitable C++ range template: > > > > typedef range<int, 1, 10> Y_Type; > > typedef range<Y_Type, 1, 5> X_Type; > > > > Y_Type F (X_Type X) > > { > > return X + 3; > > } > > > > Y_Type G (X_Type X) > > { > > return X + 7; > > } > > > > Now anyone up to the challenge to define: > > > > template <typename Base_Type, Base_Type First, Base_Type Last> > > range::operator = (Base_Type right) > > > > template <typename Base_Type, Base_Type First, Base_Type Last> > > range::operator + (Base_Type right) > > > > template <typename Base_Type, Base_Type First, Base_Type Last> > > range::range (Base_Type right) > > > > in such a way that it works like Ada - inclusive the *realistic* change that > > the compiler will optimize away the range check in F (). > > I have done this. I had a look. Looks impressive with all those includes. Looks like one of thoses templates I never want to debug thrue. But don't expect me to have found that magic static analysis something trick. So: How exactly did you do it? Martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-28 7:49 ` Martin Krischik @ 2006-04-28 11:17 ` REH 2006-04-29 6:47 ` Martin Krischik 0 siblings, 1 reply; 27+ messages in thread From: REH @ 2006-04-28 11:17 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:1146210553.562353.140540@j73g2000cwa.googlegroups.com... >> I have done this. > > I had a look. Looks impressive with all those includes. Looks like one > of thoses templates I never want to debug thrue. > > But don't expect me to have found that magic static analysis something > trick. So: > > How exactly did you do it? If you are truly interested, I can email you an article about its implementation. If you are just looking for a chance to language-bash, I won't bother. I wrote it because I don't always have to luxury of language choice. REH ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-28 11:17 ` REH @ 2006-04-29 6:47 ` Martin Krischik 0 siblings, 0 replies; 27+ messages in thread From: Martin Krischik @ 2006-04-29 6:47 UTC (permalink / raw) REH wrote: > > "Martin Krischik" <krischik@users.sourceforge.net> wrote in message > news:1146210553.562353.140540@j73g2000cwa.googlegroups.com... >>> I have done this. >> >> I had a look. Looks impressive with all those includes. Looks like one >> of thoses templates I never want to debug thrue. >> >> But don't expect me to have found that magic static analysis something >> trick. So: >> >> How exactly did you do it? > > If you are truly interested, I can email you an article about its > implementation. If you are just looking for a chance to language-bash, I > won't bother. I did so many years of C++ I allways like a little language-bash. But then, I allways like to learn something new and I don't mind been proven wrong. > I wrote it because I don't always have to luxury of > language choice. So did I. And I must have missed something as my class has no magic static analysis something. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 4:19 where exactly c++,c fail and Ada gets thru' Ananth the Boss 2006-04-24 5:05 ` jimmaureenrogers @ 2006-04-24 8:13 ` Rod Chapman 2006-04-25 1:57 ` Steve 2 siblings, 0 replies; 27+ messages in thread From: Rod Chapman @ 2006-04-24 8:13 UTC (permalink / raw) Ananth the Boss wrote: > can any one give some more justifications for telling "ADA is safe" thanks > in advance Have you considered the SPARK Ada subset? Read chapters 1-3 of the SPARK textbook - that will give you a very good idea of the issues involved in the design of high-integrity languages. - Rod, SPARK Team, Praxis ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: where exactly c++,c fail and Ada gets thru' 2006-04-24 4:19 where exactly c++,c fail and Ada gets thru' Ananth the Boss 2006-04-24 5:05 ` jimmaureenrogers 2006-04-24 8:13 ` Rod Chapman @ 2006-04-25 1:57 ` Steve 2 siblings, 0 replies; 27+ messages in thread From: Steve @ 2006-04-25 1:57 UTC (permalink / raw) "Ananth the Boss" <anboss@gmail.com> wrote in message news:1145852356.559455.222600@i39g2000cwa.googlegroups.com... > we are developing safety critical software.my seniors say that c and > c++ are not suitable for safety critical software development and ada > is very much safe.NASA aslo uses Ada.at what point c++ or c turns to be > not suitable for devleloping flight software. i may be wrong also. can > any one give some more justifications for telling "ADA is safe" thanks > in advance > Learn Ada and you will have your answer. I have never heard a question like this from someone who knows Ada. Steve (The Duck) ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2006-05-02 6:43 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-24 4:19 where exactly c++,c fail and Ada gets thru' Ananth the Boss 2006-04-24 5:05 ` jimmaureenrogers 2006-04-24 7:45 ` Ananth the Boss 2006-04-24 19:17 ` Martin Krischik 2006-04-24 20:23 ` Simon Wright 2006-04-24 22:34 ` Keith Thompson 2006-04-24 22:33 ` Keith Thompson 2006-04-25 5:23 ` Jeffrey R. Carter 2006-04-26 17:48 ` Martin Krischik 2006-04-26 19:33 ` Keith Thompson 2006-04-26 15:10 ` Maciej Sobczak 2006-04-26 17:32 ` Martin Krischik 2006-04-27 10:07 ` Maciej Sobczak 2006-04-27 21:19 ` Keith Thompson 2006-04-28 7:00 ` Martin Krischik 2006-04-28 12:27 ` Maciej Sobczak 2006-04-29 7:03 ` Martin Krischik 2006-04-29 14:08 ` REH 2006-05-01 10:20 ` Xcriber51 2006-05-01 13:55 ` REH 2006-05-02 6:43 ` Maciej Sobczak 2006-04-27 16:48 ` REH 2006-04-28 7:49 ` Martin Krischik 2006-04-28 11:17 ` REH 2006-04-29 6:47 ` Martin Krischik 2006-04-24 8:13 ` Rod Chapman 2006-04-25 1:57 ` Steve
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox