Paavo Helde <myfirstname@osa.pri.ee>: Dec 31 01:35PM -0600
> 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 <grahn+nntp@snipabacken.se>: Dec 31 09:21PM
On Tue, 2015-12-29, 嘱 Tiib wrote:
>> ;-)
> Seems that comp.lang.c has done the trick somehow. He has not
> cross-posted his spam to there since August.
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 <ian-news@hotmail.com>: Jan 01 10:25AM +1300
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 <bc@freeuk.com>: Dec 31 10:43PM
On 31/12/2015 19:35, Paavo Helde wrote:
> 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
|
bleachbot <bleachbot@httrack.com>: Dec 31 07:17PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 07:22PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 07:27PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 07:48PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 08:02PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 08:12PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 08:53PM +0100
|
bleachbot <bleachbot@httrack.com>: Dec 31 09:48PM +0100
|
Ramine <ramine@1.1>: Dec 31 10:23AM -0800
Hello.......
I think i am getting crazy with C++, because in
realtime safety critical systems we must take the
programming seriously...
The following is true in C++:
1. C/C++ provide implicit type conversions between signed and unsigned
values. Unlike Ada, there is no a runtime check to make sure the value
is convertible to the new type. For example, you can readily "convert" a
negative signed value to an unsigned value.
Read it here:
http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
But what i don`t understand is that unsigned int is a good thing
to have to constrain more the system, so how can we say that
we don`t have to use signed int as say the article above...
i am not convinced because if for example we have different
cases in the source code of a realtime safety critical system
that needs to be constrained to an unsigned int by using
an unsigned int on the left of the assignement and we need
also to catch this exception if at runtime we are out of this
constraint and we can catch the exception with FreePascal
with the compiler option -Cr, but in C++ and C we can not
do it, so this is why in my opinion C++ and C are not suitable for
realtime safety critical systems.
Thank you,
Amine Moulay Ramdane.
|
Ramine <ramine@1.1>: Dec 31 10:28AM -0800
Read again please, i correct...
Hello.....
I think i am getting crazy with C++, because in
realtime safety critical systems we must take the
programming seriously...
The following is true in C++:
1. C/C++ provide implicit type conversions between signed and unsigned
values. Unlike Ada, there is no a runtime check to make sure the value
is convertible to the new type. For example, you can readily "convert" a
negative signed value to an unsigned value.
Read it here:
http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
But what i don`t understand is that unsigned int is a good thing
to have to constrain more the system, so how can we say that
we don`t have to use unsigned int as say the article above...
i am not convinced because if for example we have different
cases in the source code of a realtime safety critical system
that needs to be constrained to an unsigned int by using
an unsigned int on the left of the assignement and we need
also to catch this exception if at runtime we are out of this
constraint and we can catch the exception with FreePascal
with the compiler option -Cr, but in C++ and C we can not
do it, so this is why in my opinion C++ and C are not suitable for
realtime safety critical systems.
Thank you,
Amine Moulay Ramdane.
|
