Now i want to talk about Strong typed safety systems

[Ramine]

Hello,


Now i want to talk about Strong typed safety systems like ADA...

In ADA when you define two types like this:

type length is new float;
type weight is new float;


You can not assign in ADA the type length above to the type weight
above, this is possible in Delphi and FreePascal and C and C++.

And also you have seen me talking about why C and C++ are bad,
because in C and C++ an implicit conversion from for example
a signed long to an unsigned long is authorized in C and C++,
and that's bad because it can cause bugs and errors of logic and
that's not good for high integrity and realtime safety critical systems,
in ADA and FreePascal and Delphi this type of implicit conversion is not
possible and more than that ADA can not permit
in general to assign a type to another type as i have showed you above,
so ADA is really suited for high integrity and realtime safety critical
systems and this is why C and C++ are bad as i have explained to you
before.


Thank you,
Amine Moulay Ramdane.

[Paavo Helde]

Ramine <ramine@1.1> wrote in news:n5kg14$v4f$4...@dont-email.me:

> Hello,
>
>
> Now i want to talk about Strong typed safety systems like ADA...
>
> In ADA when you define two types like this:
>
> type length is new float;
> type weight is new float;

You can do this in C++ easily, the syntax is just slightly different:

struct length { float value; };

struct weight { float value; };

int main() {
length x{3.14f};
weight y = x;
}

1> main.cpp
1>main.cpp(7): error C2440: 'initializing' : cannot convert from
'length' to 'weight'
1> No user-defined-conversion operator available that can
perform this conversion, or the operator cannot be called

>
>
> You can not assign in ADA the type length above to the type weight
> above, this is possible in Delphi and FreePascal and C and C++.
>
> And also you have seen me talking about why C and C++ are bad,
> because in C and C++ an implicit conversion from for example
> a signed long to an unsigned long is authorized in C and C++,
> and that's bad because it can cause bugs and errors of logic and
> that's not good for high integrity and realtime safety critical
systems,
> in ADA and FreePascal and Delphi this type of implicit conversion is
not
> possible and more than that ADA can not permit
> in general to assign a type to another type as i have showed you above,
> so ADA is really suited for high integrity and realtime safety critical
> systems and this is why C and C++ are bad as i have explained to you
> before.

C and C++ have many pitfalls. If Ada works better for what you do, you
should use Ada.

Cheers
Paavo

[serge....@gmail.com]

This Amine guy has been spamming the Ada newsgroup too and all his post have been flagged as spam. I've proven his statement wrong and his code behaves the same in Ada as in C++. He's just ignorant of good C++ programming like he doesn't know Ada any much better, I'm wondering if he understand the difference between an Ada "type" and "subtype". Having looked as his code, it is full of untyped pointers (like void* or char*) and generic integrals like int32 or int64. It will require a lot of rework to compile properly in any strong typed language if strong typing is what he wants. He's hoping that wearing a safety belt would make him safer but he remains a reckless driver. His spitting his anger in the form of infamy on C++ because C++ failed to catch his own design mistakes.

[Paavo Helde]

serge....@gmail.com wrote in
news:6972ac94-0a32-46f2...@googlegroups.com:

> On Saturday, 26 December 2015 11:15:32 UTC+1, Paavo Helde wrote:
>> Ramine <ramine@1.1> wrote in news:n5kg14$v4f$4...@dont-email.me:
>>

>> [snipped]
>>
>> you should use Ada.

>
> This Amine guy has been spamming the Ada newsgroup too and all his
> post have been flagged as spam.

Darn, it looks like my secret plan to coax him away from c.l.c++ has failed
;-)

[Öö Tiib]

Seems that comp.lang.c has done the trick somehow. He has not cross-posted his
spam to there since August.

[BartC]

On 26/12/2015 10:15, Paavo Helde wrote:
> Ramine <ramine@1.1> wrote in news:n5kg14$v4f$4...@dont-email.me:
>
>> Hello,
>>
>>
>> Now i want to talk about Strong typed safety systems like ADA...
>>
>> In ADA when you define two types like this:
>>
>> type length is new float;
>> type weight is new float;
>
> You can do this in C++ easily, the syntax is just slightly different:
>
> struct length { float value; };
>
> struct weight { float value; };
>
> int main() {
> length x{3.14f};
> weight y = x;
> }
>
> 1> main.cpp
> 1>main.cpp(7): error C2440: 'initializing' : cannot convert from
> 'length' to 'weight'
> 1> No user-defined-conversion operator available that can
> perform this conversion, or the operator cannot be called

The C++ version is defining structs not scalars? If I try this:

length x,y,z;

x = y+z;

it fails. So does simply writing x=0.0 (or x=(length)0.0).

No doubt there are ways to make all this stuff work in C++, but you have
to do that work, and the resultant type safety depends on how well that
is done.

(x=y*z would also fail, but probably not for the right reasons! I'm not
sure whether even Ada would deal with that correctly without extra work.)

--
Bartc

[Öö Tiib]

On Wednesday, 30 December 2015 14:12:05 UTC+2, BartC wrote:
> On 26/12/2015 10:15, Paavo Helde wrote:
> > Ramine <ramine@1.1> wrote in news:n5kg14$v4f$4...@dont-email.me:
> >
> >> Hello,
> >>
> >>
> >> Now i want to talk about Strong typed safety systems like ADA...
> >>
> >> In ADA when you define two types like this:
> >>
> >> type length is new float;
> >> type weight is new float;
> >
> > You can do this in C++ easily, the syntax is just slightly different:
> >
> > struct length { float value; };
> >
> > struct weight { float value; };
> >
> > int main() {
> > length x{3.14f};
> > weight y = x;
> > }
> >
> > 1> main.cpp
> > 1>main.cpp(7): error C2440: 'initializing' : cannot convert from
> > 'length' to 'weight'
> > 1> No user-defined-conversion operator available that can
> > perform this conversion, or the operator cannot be called
>
> The C++ version is defining structs not scalars?

No. The example was how to make context-aware types and not to
use scalars directly. The 'struct' in C++ denotes a class whose base
classes and members are implicitly 'public'. Otherwise 'struct weight'
and 'class weight' are synonymous in C++.

> If I try this:
>
> length x,y,z;
>
> x = y+z;
>
> it fails. So does simply writing x=0.0 (or x=(length)0.0).

So what is bad? Defects have been detected compile time. Either illegal
operations are used on 'length' objects or interface of 'length' class is
incomplete.

>
> No doubt there are ways to make all this stuff work in C++, but you have
> to do that work, and the resultant type safety depends on how well that
> is done.

Correctness of all software depends on how well it is written.

>
> (x=y*z would also fail, but probably not for the right reasons! I'm not
> sure whether even Ada would deal with that correctly without extra work.)

It will fail also for the very same right reasons: illegal operations are rejected
or interface of class 'length' is incomplete and defect is detected compile
time. The defect can be also as simply fixed:

#include <iostream>

struct length { float value; };
struct area { float value; };

area operator*(length x, length y) {return area{x.value * y.value};}

int main()
{
length x{3.4}, y{5.6};

// length z = x * y; <- ERROR: can't convert area to length

area S = x * y; // <- FINE: S is 19.04

std::cout << S.value << "\r";
}

[Paavo Helde]

BartC <b...@freeuk.com> wrote in news:n60hh7$hbm$1...@dont-email.me:

> On 26/12/2015 10:15, Paavo Helde wrote:
>> You can do this in C++ easily, the syntax is just slightly different:
>>
>> struct length { float value; };
>>
>> struct weight { float value; };
>>
>> int main() {
>> length x{3.14f};
>> weight y = x;
>> }
>

> The C++ version is defining structs not scalars? If I try this:
>
> length x,y,z;
>
> x = y+z;
>
> it fails.

Yes, that's a good thing. The compiler does not know and should not know
if your type supports addition or not. If it does, one can easily define
the corresponding operator for the custom type.

IOW, C++ gives you the basic building blocks for defining the needed
abstractions; it does not try to guess what kind of abstractions you
need, and that's a good thing.

Cheers
Paavo

[Jorgen Grahn]

Also, his postings don't reach me via news.individual.net at all
nowadays. So I see only the enraged replies ...

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ian Collins]

Jorgen Grahn wrote:
>
> Also, his postings don't reach me via news.individual.net at all
> nowadays. So I see only the enraged replies ...

That's the drawback with using a decent server! Once upon a time my
local filters happily hid Ramine threads. Now they're back :(

--
Ian Collins

[BartC]

On 31/12/2015 19:35, Paavo Helde wrote:
> BartC <b...@freeuk.com> wrote in news:n60hh7$hbm$1...@dont-email.me:
>
>> On 26/12/2015 10:15, Paavo Helde wrote:
>>> You can do this in C++ easily, the syntax is just slightly different:
>>>
>>> struct length { float value; };
>>>
>>> struct weight { float value; };
>>>
>>> int main() {
>>> length x{3.14f};
>>> weight y = x;
>>> }
>>
>> The C++ version is defining structs not scalars? If I try this:
>>
>> length x,y,z;
>>
>> x = y+z;
>>
>> it fails.
>
> Yes, that's a good thing. The compiler does not know and should not know
> if your type supports addition or not. If it does, one can easily define
> the corresponding operator for the custom type.

It's not exactly an arbitrary type that has no meaning to the compiler.

The OP defined a new version of a primitive type. I would expect that
new type to inherit the basic operations available on that primitive
type, such as assigning literals, arithmetic, and printing values
(otherwise you could spend all day implementing all that).

That might be enough, if you just don't want to mix up length and weight
values. You only start customising further when necessary.

> IOW, C++ gives you the basic building blocks for defining the needed
> abstractions; it does not try to guess what kind of abstractions you
> need, and that's a good thing.

I was just pointing out that Ada provides those 'out-of-the-box'. The
C++ version, stopped you assigning a 'weight' struct to a 'length'
struct, but that was about it. You couldn't immediately use 'length' and
'weight' as you would 'float'.

(Not as defined in that C++ fragment anyway. Maybe (I don't know C++)
you could wrap a class around 'float', do all the work needed, and use
that to create derived versions which inherit all the usual operations.)

--
Bartc

[Paavo Helde]

BartC <b...@freeuk.com> wrote in news:n64auh$aat$1...@dont-email.me:

>
> (Not as defined in that C++ fragment anyway. Maybe (I don't know C++)
> you could wrap a class around 'float', do all the work needed, and use
> that to create derived versions which inherit all the usual
operations.)

This can be done via C++ templates.

Anyway, another important aspect here is that something like 'length'
typically makes sense only in a broader context (length of what?). Length
of a road and length of a molecule chain are not the same and probably it
would not be a good idea to add them up even if the measured physical
quantity is basically the same.

If length is considered as a property of something else, then typically
it will appear as a private member in some other class. The class will
provide needed operations which make sense for the objects of the class
(e.g. a road or a molecule) and which may or may not involve changing the
length property. This means that the length property is already
encapsulated pretty well inside the class and there might not be much use
of having a specific type for that, a simple float would do as well. In
this sense the ability to define different float-like types might not be
so important after all.

Things were different in the original Ada, which did not support OOP.
There an ability to define different float-like classes might have been
useful indeed, because of the lack of better encapsulation means. From
the viewpoint of C++ encapsulating a simple float would often mean
creating a too low-level abstraction.

Cheers
Paavo

[Jorgen Grahn]

On Fri, 2016-01-01, Paavo Helde wrote:
> BartC <b...@freeuk.com> wrote in news:n64auh$aat$1...@dont-email.me:
>
>>
>> (Not as defined in that C++ fragment anyway. Maybe (I don't know C++)
>> you could wrap a class around 'float', do all the work needed, and use
>> that to create derived versions which inherit all the usual
> operations.)
>
> This can be done via C++ templates.
>
> Anyway, another important aspect here is that something like 'length'
> typically makes sense only in a broader context (length of what?). Length
> of a road and length of a molecule chain are not the same and probably it
> would not be a good idea to add them up even if the measured physical
> quantity is basically the same.

True.

> If length is considered as a property of something else, then typically
> it will appear as a private member in some other class. The class will
> provide needed operations which make sense for the objects of the class
> (e.g. a road or a molecule) and which may or may not involve changing the
> length property. This means that the length property is already
> encapsulated pretty well inside the class and there might not be much use
> of having a specific type for that, a simple float would do as well. In
> this sense the ability to define different float-like types might not be
> so important after all.

However, if I wrote a program for manipulating roads, or one for
manipulating molecules, I might write a length class /for use in that
context/.

I've seen that strategy work well so often: to create types for things
which at first look like just plain integers or floats. But like you
noted above, it's not something you want to do once, for all possible
applications; it has to be application-specific.

> Things were different in the original Ada, which did not support OOP.
> There an ability to define different float-like classes might have been
> useful indeed, because of the lack of better encapsulation means. From
> the viewpoint of C++ encapsulating a simple float would often mean
> creating a too low-level abstraction.

To me there's no such thing. If I identify "the length of a molecule"
as a type, I can make a C++ type out of it, and benefit from it.

[Paavo Helde]

Jorgen Grahn <grahn...@snipabacken.se> wrote in
news:slrnn8dqb1.5...@frailea.sa.invalid:

I think the key words here are "If I identify...". Indeed, if creating a
separate type has benefits, then of course that's way to go. And OTOH, if
it wouldn't bring any benefits then it would be over-engineering. I have
seen plenty of the latter as well.

Of course, the border between good design and over-engineering is not so
clear in real life and depends on all kind of things, including the
actual usage of the software piece. A well-designed piece of software may
appear over-engineered when used in another context. One of the worst
examples of this I have seen is a library which wraps a SQL database in
an heavy OOP design so that each table and table row basically becomes an
OOP object. All good and fine, but in our product the business logic was
not formulated in this object-oriented interface, but in the next layer
of software sitting on top of that library. The next layer does not have
such expressiveness and basically operates in terms of simple tables
(similar to SQL). To make this work, the absolute minimal set of needed
operations was identified and wrapped up so they could be used by the
next layer. Each wrapped operation involves figuring out the needed OOP
types, instantiating them correctly, translating the content of tables to
calls to objects - and I am pretty sure somewhere deep inside the library
all this information finally gets translated into some simple SQL
statements again. So basically the main effort when using this library
(inside this product) goes to translating the table-based interface into
OOP interface with lots of types and classes nobody cares about, just so
the library can translate it back into table-based SQL again. The
compiled size of this library is 455 MB, by the way.

Cheers
Paavo

[Jorgen Grahn]

On Sun, 2016-01-03, Paavo Helde wrote:
> Jorgen Grahn <grahn...@snipabacken.se> wrote in
> news:slrnn8dqb1.5...@frailea.sa.invalid:
>
>> On Fri, 2016-01-01, Paavo Helde wrote:
>>> From the viewpoint of C++ encapsulating a simple float would
>>> often mean creating a too low-level abstraction.
>>
>> To me there's no such thing. If I identify "the length of a molecule"
>> as a type, I can make a C++ type out of it, and benefit from it.
>
> I think the key words here are "If I identify...". Indeed, if creating a
> separate type has benefits, then of course that's way to go. And OTOH, if
> it wouldn't bring any benefits then it would be over-engineering. I have
> seen plenty of the latter as well.
>
> Of course, the border between good design and over-engineering is not so
> clear in real life and depends on all kind of things, including the
> actual usage of the software piece. A well-designed piece of software may
> appear over-engineered when used in another context.

I agree.

> One of the worst
> examples of this I have seen is a library which wraps a SQL database in
> an heavy OOP design so that each table and table row basically becomes an
> OOP object. All good and fine, but in our product the business logic was
> not formulated in this object-oriented interface, but in the next layer
> of software sitting on top of that library. The next layer does not have
> such expressiveness and basically operates in terms of simple tables
> (similar to SQL). To make this work, the absolute minimal set of needed
> operations was identified and wrapped up so they could be used by the
> next layer. Each wrapped operation involves figuring out the needed OOP
> types, instantiating them correctly, translating the content of tables to
> calls to objects - and I am pretty sure somewhere deep inside the library
> all this information finally gets translated into some simple SQL
> statements again. So basically the main effort when using this library
> (inside this product) goes to translating the table-based interface into
> OOP interface with lots of types and classes nobody cares about, just so
> the library can translate it back into table-based SQL again. The
> compiled size of this library is 455 MB, by the way.

(Good grief; the most absurd library size I've seen is 80 MB,
stripped.)

That fits nicely with my other personal rule of C++ programming: "I'm
too stupid to write libraries, and so is pretty much everyone else"
:-)

I'd be very careful if I had to write a library, not trying to force
my prejudices onto others when I cannot know anything about their
needs. It seems these guys were not that careful ...

[Paavo Helde]

Jorgen Grahn <grahn...@snipabacken.se> wrote in

news:slrnn8ilhg.5...@frailea.sa.invalid:

> On Sun, 2016-01-03, Paavo Helde wrote:
>> The
>> compiled size of this library is 455 MB, by the way.
>
> (Good grief; the most absurd library size I've seen is 80 MB,
> stripped.)

This 455 MB is a Windows x64 static library, release build. Fortunately the
product only uses a small subset of the full library, so the final size of
the plugin DLL linked to this static library and implementing the needed
minimal interface is "only" 33 MB.

Cheers
Paavo