Friday, December 25, 2015

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

Ramine <ramine@1.1>: Dec 25 04:54PM -0800

Hello,
 
I was working on a project in C++, but i have encountered
a problem with the language that we call C++, this problem
is inherent to C++ and C, here is a small example that
shows the problem:
 
===
 
#include <iostream>
using namespace std;
 
int main()
{
unsigned int u = 1234;
int i = -1233;
 
unsigned int result1 = u + i;
std::cout << "Number is = " << result1 << std::endl;
 
}
 
==
 
 
In this example, C++ and C will convert i from a signed int type to
unsigned int type but this is not good , because this types of
conversion can cause bugs and errors of logic , so i think we must
forbid C and C++ on realtime critical systems... and i have read on
internet that C and C++ are strongly typed languages, how can you
say that ! ingnoring the simple fact that an implicit conversion
in C++ and C takes place between a signed int type and an unsigned int
type for example, so that makes C and C++ problematic and not suited for
realtime critical systems and such, ADA and Delphi and FreePascal are in
fact strongly typed and does not authorize this type of conversion.
 
 
 
Thank you,
Amine Moulay Ramdane.
Paul <pepstein5@gmail.com>: Dec 25 03:17PM -0800

On Friday, December 25, 2015 at 9:54:13 PM UTC, Ramine wrote:
> type for example, so that makes C and C++ problematic and not suited for
> realtime critical systems and such, ADA and Delphi and FreePascal are in
> fact strongly typed and does not authorize this type of conversion.
 
But the result here is in fact 1 so 1234 -1233 = 1 and you haven't illustrated any type of problem. This code might do a better job of illustrating your point.
 
Paul
 
int main()
{
unsigned y = 0;
if( -1 > y)
cout << "unexpected result which could cause bugs";
}
Ramine <ramine@1.1>: Dec 25 06:23PM -0800

Hello...
 
Read this from my other posts:
 
 
"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.
JiiPee <no@notvalid.com>: Dec 25 11:24PM

On 25/12/2015 23:17, Paul wrote:
> if( -1 > y)
> cout << "unexpected result which could cause bugs";
> }
 
I also get 1.
 
One way to solve this problem would be to create classes for each basic
types. So using
 
class UInt
 
instead of unsigned . So we could overload > operator to behave
correctly with different types.
i guess this is why Bjarne prefers using int instead of unsigned, then
we do not get this problem. If I remember correctly he discourages using
unsigned.
JiiPee <no@notvalid.com>: Dec 25 11:28PM

On 25/12/2015 23:17, Paul wrote:
> int main() { unsigned y = 0; if( -1 > y) cout << "unexpected result
> which could cause bugs"; }
 
I wonder why the compiler does not give an error here? I think it should
be like that: unsigned must be converted with static_cast to int, and
otherwise its a compilation error. Thats how it should be imo.
bleachbot <bleachbot@httrack.com>: Dec 25 10:53PM +0100

bleachbot <bleachbot@httrack.com>: Dec 25 11:32PM +0100

bleachbot <bleachbot@httrack.com>: Dec 26 12:06AM +0100

bleachbot <bleachbot@httrack.com>: Dec 26 12:23AM +0100

Ramine <ramine@1.1>: Dec 25 06:06PM -0800

Hello,
 
As you have seen me talking before in my previous posts,
i have said that C++ and C are bad, and i have explained to
you why, but as you have seen me also, i have invented many
synchronization and parallel algorithms in FreePascal and Delphi,
here they are:
 
https://sites.google.com/site/aminer68/
 
but i must be frank with you, i have tried to port some of
my projects that was wrote in Delphi and FreePascal to
C++ , i have actually ported my SemaMonitor synchonization
algorithm to C++ , and that was easy for me, but i have
encountered some problems inherent to C and C++ language
like the fact that for example implicit conversion from signed long type
to unsigned long type is authorized in C and C++ and that
make C and C++ bad languages as i have explained it to you,
also i have tried to port the scalable Hoard memory allocator and
the scalable Intel tbbmalloc memory allocator to GCC mingw, but
this was not possible because the source code didn't not
compile, but even if the dynamic libraries of those
scalable memory allocators are available, it was
too difficult to change the memory allocator of GCC mingw
for example to use the dynamic libraries, but in FreePascal
and Delphi that was easy because FreePascal and Delphi
was designed like that and permit easily to replace
the memory allocator with those dynamic libraries,
so since i have encountered those problems in C and C++,
that have made me to abondon C and C++ in favor of Delphi and
FreePascal and ADA and Java.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 25 05:32PM -0800

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.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 25 01:33PM +0100

On 12/24/2015 11:59 PM, Paul wrote:
> I'm confused about when conversions between types are allowed.
> int* z = new int(3);
> char* x= (char*)z; //works fine.
 
Assuming that by "works fine" you mean "no compilation error", then that
doesn't say much, really. Lots of code will compile but will not "work
fine".
 
However, if you mean that the expression "*x" subsequently yields the
value 3, then that's an artifact of the machine architecture.
 
Namely, that in this case it stores integers with the least significant
at lowest address, which is called little endian (reportedly due to the
terminology used in Gulliver's Travels, written by Jonathan Swift, whose
poem about the recursiveness of things provided the main inspiration for
Augustus De Morgan's ditto poem about recursive fleas, which, as De
Morgan himself, is frequently mentioned in programming and computer
science books). If instead integers were stored in big endian format, or
worse, in some middle endian jumbled format, you'd get zero.
 
 
> "expected primary expression before char" compile error. I was
> anticipating that I can cast from int* to char* this way in the same
> way that you can cast 5.3 to int by writing int(5.3);
 
Casting pointers generally means you will be interpreting the bitpattern
in some new way.
 
This is generally known as type PUNNING, and in C++ it can be expressed
as a reinterpret_cast, e.g.
 
auto x = reinterpret_cast<char*>( z );
 
In contrast, when you convert 5.3 to int you're generating a new
bitpattern that to some degree, preferably via some precisely defined
formula or algorithm, preserves the original value. This is more
commonly referred to as a CONVERSION. In C++ it can be expressed as a
static_cast, e.g.
 
auto i = static_cast<int>( 5.3 );
 
In addition to static_cast and reinterpret_cast there's dynamic_cast,
const_cast and the case of using a C style cast to cast to inaccesible base.
 
This should ideally be discussed in your textbook?
 
 
> If the second line is replaced by char*x = z; I get an error -- "can
> not convert from char* to int* in initialization" How could I have
> know that such an initialization is illegal,
 
Initializing something of type X with something of type Y is only valid
if there is a single-step implicit conversion from Y to X.
 
This is a fundamental part of static type checking, which should also be
discussed in your text book?
 
 
> given that the cast of
> the form char* x = (char*)z; is ok ?
 
Oh, the term "OK" can mean so many things here, ranging from "no
compilation error" via "is one of the supported type punnings listed in
the whatever-it-was std's paragraph" to "does what I want".
 
But what you need to know up front right now is that a C style cast
generally just tells the compiler to "shut up! because I KNOW WHAT I'M
DOING". It also tells the compiler to do whatever is implied by the
current source code. Which can CHANGE when the source is maintained.
 
Obviously that's not a good idea when one doesn't know what one's doing.
 
So, preferably just avoid casts.
 
And when you absolutely need to use a cast, then choose one of the four
named C++ style casts mentioned above, or, if needed, a combination.
 
 
Cheers & hth.,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 25 01:12PM +0100

On 12/23/2015 10:21 PM, Paavo Helde wrote:
 
> Why? If nobody is reporting, the bugs don't get fixed.
 
> I have reported a couple of MSVC bugs, and IIRC they got fixed in few years
> already!
 
Well, this one's already fixed (as a result of the reporting), and
closed, but we'll not see the fix until some new update or release.
 
Cheers,
 
- Alf
Ian Collins <ian-news@hotmail.com>: Dec 25 09:04PM +1300

Paavo Helde wrote:
>> file copy. Then run in on a file bigger than half of your RAM.
 
> You mean, a file larger than 6 GB? Don't have so many text files like
> that, sorry.
 
Try something like a VM image :)
 
> BTW, I see your moves with getline and fread, and raise you mmap(). No
> numbers and non-standard, but if you care about file I/O performance
> that's the way to go. Doesn't consume RAM either.
 
Yes, and they can play nicely with iostreams if you use a simple
streambuf class with a mapped file.
 
I just ran a quick test and at least on my system with g++, as I
expected, there's no significant difference between copying a file
rejecting 'x' by walking a mapped file or by using an
istreambuf_iterator on a streambuf created from the mapping.
 
--
Ian Collins
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)