Friday, June 1, 2018

Digest for comp.lang.c++@googlegroups.com - 11 updates in 6 topics

Ian Collins <ian-news@hotmail.com>: Jun 02 07:36AM +1200

On 02/06/18 02:38, bart4858@gmail.com wrote:
 
Please sort your line wrap...
 
> I could copy and paste that block unchanged into a place where x and
> y are different types. Or even where they have no types at all (eg.
> to in a dynamic language where x and y don't even need declaring).
 
So just use auto; then the type is whatever evaleqexpr() returns. The
type is irrelevant to the algorithm, so why make a fuss about it or even
name it?
 
> all named 'evalOPexpr', all declaring 'int64 x,y'. Most will use y,
> in one or two it was dispensed with (such as the one I chose to
> post), but I yet make use of it in the future.
 
With clang and g++, this will generate an unused variable warning with
all but the most basic compilers options.
 
--
Ian.
Bart <bc@freeuk.com>: Jun 01 09:27PM +0100

On 01/06/2018 20:36, Ian Collins wrote:
>> y are different types. Or even where they have no types at all (eg.
>> to in a dynamic language where x and y don't even need declaring).
 
> So just use auto; then the type is whatever evaleqexpr() returns.
 
No, the type needs to be int64 in this case (in another version, I might
decide to use int32 or whatever).
 
It might happen that evaleqexpr() always returns that type too, but
confidence in that is not quite the 100% it is when being explicit about
the type.
 
> type is irrelevant to the algorithm, so why make a fuss about it or even
> name it?
 
It's not that irrelevant. But specifying it (although it might be better
in one place as a typedef), it's clear that this code [part of #if
<expr> processing for a CPP] has chosen to use signed 64-bit arithmetic.
 
>> post), but I yet make use of it in the future.
 
> With clang and g++, this will generate an unused variable warning with
> all but the most basic compilers options.
 
That's fine when you've finished your program and wrapped it up.
 
It would be a nuisance during development when you've declared a bunch
of variables but haven't got round to making use of them, or haven't
decided which are staying. Or some of them are there for possible debugging.
 
If, for example, I need to print out those two operands, then it will be
easier if the rhs one is assigned to y. But wait - I had to get rid of
it to remove that annoying warning.
 
--
bartc
Ian Collins <ian-news@hotmail.com>: Jun 02 09:38AM +1200

On 02/06/18 08:27, Bart wrote:
 
>> So just use auto; then the type is whatever evaleqexpr() returns.
 
> No, the type needs to be int64 in this case (in another version, I might
> decide to use int32 or whatever).
 
So another version would squeeze a quart into a pint pot?
 
> It might happen that evaleqexpr() always returns that type too, but
> confidence in that is not quite the 100% it is when being explicit about
> the type.
 
Why would the type be anything other than the return of evaleqexpr()?
 
 
> It would be a nuisance during development when you've declared a bunch
> of variables but haven't got round to making use of them, or haven't
> decided which are staying. Or some of them are there for possible debugging.
 
That is terrible practice. You should only introduce variables when and
were you need them. Anything is is chaos.
 
> If, for example, I need to print out those two operands, then it will be
> easier if the rhs one is assigned to y. But wait - I had to get rid of
> it to remove that annoying warning.
 
So you prefer to print uninitialised gobbledygook?
 
--
Ian.
"Öö Tiib" <ootiib@hot.ee>: Jun 01 04:20PM -0700

On Friday, 1 June 2018 18:15:30 UTC+3, Scott Lurndal wrote:
 
> Fortran (on IBM) was, perhaps atypical. COBOL and ALGOL used
> functions/subroutines very heavily (e.g. the COBOL PERFORM verb)
> as did more proprietary languages like Burroughs BPL or HP SPL.
 
One of the first programming languages I used was FORTRAN and it
made exactly the impression that I expressed. It was good since
it was easy to form clear vision what is wrong with it. Also it
is easy to recognize those wrong things (whenever pushed) to
this day. But back then one brave soul at 1982 wrote that:
"Besides, the determined Real Programmer can write FORTRAN
programs in any language." Perhaps you have read that essay.
bart4858@gmail.com: Jun 01 12:53PM -0700

On Friday, 1 June 2018 19:35:56 UTC+1, Siri Cruise wrote:
 
> You can code in Fortran 66 no matter what language you use.
 
 
Not in Python. Or any language that has decided it knows best and has got rid of 'goto', even though it's one of the simplest features to implement.
 
There are numerous uses, even if it doesn't belong in quality code, including porting algorithms from other languages that use goto or a control flow statement that doesn't exist in the target language.
 
--
bart
Siri Cruise <chine.bleu@yahoo.com>: Jun 01 04:11PM -0700

In article <7af124b6-bcb6-4a97-bf3b-763bd15cf202@googlegroups.com>,
 
> > You can code in Fortran 66 no matter what language you use.
 
> Not in Python. Or any language that has decided it knows best and has got rid
> of 'goto', even though it's one of the simplest features to implement.
 
With a compiler that optimises away tail recursion, functions become labels, and
applications become gotos.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
Sky89 <Sky89@sky68.com>: Jun 01 02:41PM -0400

Hello,
 
 
C++ vs. Ada: Which language is more strongly typed?
 
"The conclusion is that Ada is more strongly typed than C++, but how
much more strongly typed remaines an open question. Both languages
require effort from the developer to make full use of the typing
functionality that is available."
 
Read more here:
 
http://shape-of-code.coding-guidelines.com/2014/04/17/c-vs-ada-which-language-is-more-strongly-typed/
 
 
Thank you,
Amine Moulay Ramdane.
"Öö Tiib" <ootiib@hot.ee>: Jun 01 04:07PM -0700

On Friday, 1 June 2018 21:41:52 UTC+3, Sky89 wrote:
 
> C++ vs. Ada: Which language is more strongly typed?
 
Who cares? Fortran vs. JavaScript which language is more whatever typed?
The only correct answer is: Who cares?
Please, Amine Moulay Ramdane, don't post to comp.lang.c++,like you have
promised number of times. Go post to your comp.programming or what else
groups that you already destroyed. We can easily find those groups if
we want to read your opinions. If we don't then we honestly don't care.
Sky89 <Sky89@sky68.com>: Jun 01 05:54PM -0400

Hello...
 
 
Read again, i correct a typo:
 
About C++ and Delphi and ADA
 
As you know i have been programming with Delphi and with C++(i have
implemented many of my scalable algorithms in them) and
i am looking also at ADA and Rust, and what i have discovered
is that C++ is more weakly typed even with the SafeInt library that
i have presented to you here:
 
https://github.com/dcleblanc/SafeInt
 
For example you can still assign a type of char to an int type
in C++ and C and C++ and C allow also to assign two structs with some
different types in each one of them that can be assigned ! and this is
not allowed in Delphi and ADA for reliability reasons , because two
structs means two different "types" for Delphi and ADA, Delphi and ADA
don't even allow to assign two types of records(that means structs in
C++) that have the same elements with the same types ! but C++ and C
allow it.. so this is why i will stop from using C++ because C++ is less
reliable than ADA or Delphi in this strict-type safety, you can even use
"variants" that are implemented smartly in Delphi to enhance strict-type
safety(and thus reliability) in Delphi as i have showed you like the
following:
 
--
 
program test;
 
uses VARIANTS,SYSUTILS;
 
var f:double;
a:integer;
 
 
 
FUNCTION ASSIGN(a,B:VARIANT):VARIANT;
 
begin
 
IF VARTYPE(A)=VARTYPE(B) THEN
BEGIN
A:=B;
RESULT:=A;
END
ELSE RAISE EXCEPTION.CREATE('ASSIGNEMENT NOT OK');
 
 
end;
 
begin
 
a:=2;
 
f:=a;
 
A:=ASSIGN(F,A);
 
 
end.
--
 
 
Here is the Vartype function:
 
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Variants_VarType.html
 
 
 
 
So i will stop coding in C++ and i will continu to code in Delphi
and i will also code in Java and Rust.
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: Jun 01 05:44PM -0400

Hello,
 
 
About C++ and Delphi and ADA
 
As you know i have been programming with Delphi and with C++(i have
implemented many of my scalable algorithms in them) and
i am looking also at ADA and Rust, and what i have discovered
is that C++ is more weakly typed even with the SafeInt library that
i have presented to you here:
 
https://github.com/dcleblanc/SafeInt
 
For example you can still assign a type of char to an int type
in C++ and C and C++ and C allow also to assign two structs with some
different types in each one of them that can be assigned ! and this is
not allowed in Delphi and ADA for reliability reasons , because two
structs means two different "types" for Delphi and ADA, Delphi and ADA
doesn't even allow to assign two types of records(that means structs in
C++) that have the same elements with the same types ! but C++ and C
allow it.. so this is why i will stop from using C++ because C++ is less
reliable than ADA or Delphi in this strict-type safety, you can even use
"variants" that are implemented smartly in Delphi to enhance strict-type
safety(and thus reliability) in Delphi as i have showed you like the
following:
 
--
 
program test;
 
uses VARIANTS,SYSUTILS;
 
var f:double;
a:integer;
 
 
 
FUNCTION ASSIGN(a,B:VARIANT):VARIANT;
 
begin
 
IF VARTYPE(A)=VARTYPE(B) THEN
BEGIN
A:=B;
RESULT:=A;
END
ELSE RAISE EXCEPTION.CREATE('ASSIGNEMENT NOT OK');
 
 
end;
 
begin
 
a:=2;
 
f:=a;
 
A:=ASSIGN(F,A);
 
 
end.
--
 
 
Here is the Vartype function:
 
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Variants_VarType.html
 
 
 
 
So i will stop coding in C++ and i will continu to code in Delphi
and i will also code in Java and Rust.
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: Jun 01 03:12PM -0400

Hello...
 
 
Why Rust is the future of robotics
 
It is extremely difficult to write safe code. C and C++ use of memory is
unsafe and prone to human error. Many bugs are due to buffer overflow,
data corruption, or read/write in unallocated memory. Not only these are
very hard to detect and debug but many attacks and virus take advantage
of it. The more complex your project become, the harder it is to
maintain it. Said in another way: embedded programmers fear adding extra
functionalities because it could break everything!
 
Rust combines the advantages of low level languages such as C and
C++ — mainly running really blazing fast with a really small
footprint — but with a lot more guarantees that usually come from higher
level languages. It prevents segmentation faults, guarantees thread
safety. And where Rust particularly shines is that it enables all these
safety and abstraction with no additional cost at runtime. Their motto is:
 
Rust: fast, reliable, productive — pick three
 
 
Read more here:
 
https://medium.com/pollenrobotics/why-rust-is-the-future-of-robotics-81d7fb68fe37
 
 
 
Thank you,
Amine Moulay Ramdane.
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)