Thursday, December 31, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 14 topics

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
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 31 09:23PM

On Sat, 2015-12-26, JiiPee wrote:
>> Recommendations: I recommend using signed integers for numbers and
>> using unsigned only for bitlevel things.
 
> yes this is what Bjarne seems to recommend as well
 
Where does he recommend that, so I can look it up?
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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 12:48PM -0800

Hello,
 
 
Read this about C++ and C:
 
Dynamic Memory Allocation in Critical Embedded Systems
 
http://critical.eschertech.com/2010/07/30/dynamic-memory-allocation-in-critical-embedded-systems/
 
 
It`s why i think that C and C++ are not acceptable for realtime safety
critical systems.
 
 
Please use Java instead with this hard realtime Java VM:
 
https://www.aicas.com/cms/en/JamaicaVM
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 11:56AM -0800

Hello.....
 
 
You must not to believe this Richard Heathfield of comp.programming
that defend blindly C and C++ with some stupid arguments.
 
Because read this, it`s the same that i was saying in my previous post:
 
 
``If you're performing formal verification before testing, you may argue
that run-time checks are a waste of testing time. After all, they are
never going to fail, right? Well, even with full formal verification,
errors might occur. The compiler you are using might be generating the
wrong code; or the linker might introduce an error; or the hardware
itself may be faulty. Even formal verification systems have been known
to contain errors. When we test formally verified software, any test
failure is symptomatic of a fault in the development process, tool
chain, or hardware. If we test throughly and find no errors, this gives
us confidence that the process and tool chain are sound. Testing with
run-time checks enabled (as well as without, if we intend to ship
without run-time checks) and experiencing no run-time check failures
adds to that confidence.``
 
 
Read all here please to understand me more:
 
http://critical.eschertech.com/2010/07/07/run-time-checks-are-they-worth-it/
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 11:12AM -0800

Hello,
 
 
Sorry Richard Heathfield of comp.programming,
i can not use C++ or C for realtime safety critical systems,
because C++ and C have to make it both ways , the way
of C++ and the way of Ada with its runtime checks.
 
Sorry Richard Heathfield, because of the lack of those
runtime checks of Ada, C++ and C have become dangerous
and not suitable for realtime safety critical systems.
 
 
My point is crystal clear.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 11:02AM -0800

Hello,
 
 
This was my last post in this forum.
 
 
I just wanted to make my point of view about C++ clear.
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 10:51AM -0800

Hello...
 
I wrote:
 
> 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.
 
 
And Richard Heathfield answered:
 
--
 
That's perfectly true. For example:
 
unsigned long maxval = -1;
 
That's a good thing, not a bad thing.
 
---
 
 
I think Richard Heathfield that your argument about C++ is stupid,
because in FreePascal you have it both ways, you can have it
the way of C++ if you don`t compile with the -Cr compiler option
and you can have it the Ada way if you compile it with the FreePascal
compiler -Cr option, the FreePascal -Cr compiler option is suitable
for realtime safety critical systems where you have to constrain
the system with an unsigned int and you want at runtime to catch
the exception locally in the function or you want to catch the
exception globally, that`s what you can do in FreePascal and Ada, but
you can not do it in C and C++ , so C++ and C are not suitable
for realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 31 06:33PM

On Wed, 2015-12-23, Stefan Ram wrote:
 
> Is there a »canonical« (gcc or llvm) download location
> where one can get an archive file with the source code for
> the standard library?
 
I don't know what "canonical" means in this context, but since it's
free software, of course the source code is available. See
 
https://gcc.gnu.org/
 
>>>I think user code should never call library functions
>>>directly, but always wrap them.
 
Frankly, that strikes me as a terrible idea. The thing about library
functions is that they are well known and documented. If you wrap
them, I must assume it's to make them do something else.
 
> change my custom function »warning«. It would be more
> difficult to look up every usage of »<<« and decide
> whether it's a warning and then conditionally add a bell.
 
For that purpose (to be able to just go through the warnings) I think
I'd prefer to do something like
 
std::cerr << Warning << "'x' is deprecated.\n";
 
where 'Warning' is an object which prints as the right text.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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.
Ramine <ramine@1.1>: Dec 31 10:17AM -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 signed 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.
Mr Flibble <flibble@i42.co.uk>: Dec 31 05:04PM

On 30/12/2015 23:01, Ramine wrote:
> using a secure library that uses operator overloading with
> the right tests inside them that catch the signed or unsigned int
> overflow and underflow.
 
No, you can't overload the arithmetic operators for the basic types
sausages.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 31 06:31AM +0100

On 12/30/2015 11:51 AM, Alf P. Steinbach wrote:
> I've done a bit more coding on (this re-creation of) the cppx
> header-only library, at
 
> https://github.com/alf-p-steinbach/cppx/commit/bf1081a6e5465d1dd0265f9dca9ba6d20cd288f1
 
Checked in a fix for the cppx::is_empty function template (which
automatically uses a class' member function empty() if available),
because somehow most of the unit test for that header had been commented
out and when it now was invoked it didn't even compile...
 
Fixed code:
 
https://github.com/alf-p-steinbach/cppx/commit/6bcf5be4b53e882dbf76b5414bfcf8820cddc240
 
This probably also says something about how I (can) work as a hobby
programmer, just changing the names of functions at a whim, as to my
liking, because nobody else is using this stuff yet. I think.
 
Cheers, & again, Happy Upcoming New Year!,
 
- Alf
 
PS: You (clc++) are the first to read about this and maybe look at it
and try it out. I haven't even blogged about it yet. Wordpress says I
had roughly 10 000 unique views of my main blog this year, even though I
just posted 1 short article (and that was mainly about Python), so I'm
considering starting blogging again – I have less physical pains.
red floyd <no.spam@its.invalid>: Dec 30 04:06PM -0800

On 12/30/2015 3:08 PM, Ramine wrote:
 
> So the case is closed ! so i am convinced now that C++ is good for
> realtime safety critical systems.
 
[SARCASM]
What a relief!!!! We were all going to abandon C++ because you had
told us it was bad! Now we can go back to what we were going to do
anyways.
[/SARCASM]
 
Please note: the SARCASM tags placed for the sarcasm impaired, in
compliance with the Americans with Disabilities Act.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)