Alting der er galt med C++

#51 - arne_v
22. jul. 2019 00:00

Septi (46) skrev:
arne_v (39) skrev:

Korrekt.

Men nogen sprog fanger fejl tidligere/nemmere end andre.

Compile time fejl er bedre end runtime fejl hvor problemet findes.

Runtime fejl hvor problemet findes er bedre end runtime fejl på et andet sted senere.

C og C++ er sprog som giver den sidste type fejl oftere end stort set alle andre sprog (assembler ikke inklusive).

Det lyder mere som du diskutere managed vs. unmanaged kode? Enig i at det er bedre at "Fail Fast". Men i alle unmanaged sprog sidder du med de samme udfordringer, blandt unmanaged sprog er C/C++ klart det bedste.

Nej.

Check på array index og kontrol med pointere er ikke specifik for managed sprog.

Det er noget som de fleste unmanaged sprog har eller har mulighed for. C og C++ er undtagelser her.

#52 - arne_v
22. jul. 2019 00:14

#51

C:\Work\safe>type test.cpp
#include <iostream>

using namespace std;

int main()
{
int a[2];
for(int i = 0; i < 3; i++)
{
a[i] = i + 1;
cout <g++ -Wall test.cpp -o test.exe

C:\Work\safe>test
0 : 1
1 : 2
3 : -13104

C++ får karakteren 03 for ikke at opdage problemet

C:\Work\safe>type test.pas
program test(input,output);

{$R+}

var
a : array [0..1] of integer;
i : integer;

begin
for i := 0 to 2 do begin
a[i] := i + 1;
writeln(i:1,' : ',a[i]:1);
end;
end.

C:\Work\safe>fpc test.pas
Free Pascal Compiler version 3.0.4 [2018/05/19] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling test.pas
Linking test.exe
14 lines compiled, 0.1 sec, 31152 bytes code, 1300 bytes data

C:\Work\safe>test
0 : 1
1 : 2
Runtime error 201 at $00000001000014B4
$00000001000014B4
$0000000100001576

Pascal / FPC får karakteren 7 for at opdage fejlen runtime (ville have fået 8 hvis range check var default)

$ type test.pas
program test(input,output);

var
a : array [0..1] of integer;
i : integer;

begin
for i := 0 to 2 do begin
a[i] := i + 1;
writeln(i:1,' : ',a[i]:1);
end;
end.
$ pas test
$ link test
$ run test
0 : 1
1 : 2
%PAS-F-ARRINDVAL, array index value is out of range
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
TEST TEST TEST 9 00000000000000B0 00000000000200B0
0 FFFFFFFF8037FC44 FFFFFFFF8037FC44
%TRACE-I-END, end of TRACE stack dump

Pascal / VMS får karakteren 8 for at opdage fejlen runtime (som default)

C:\Work\safe>type test.adb
with Ada.Text_IO,Ada.Integer_Text_IO;

use Ada.Text_IO,Ada.Integer_Text_IO;

procedure Test is

A : array (0..1) of Integer;

begin
for I in 0..2 loop
A(I) := I + 1;
Put(I,Width=>1);
Put(" : ");
Put(A(I),Width=>1);
New_Line;
end loop;
end Test;

C:\Work\safe>gnat make test.adb
gcc -c test.adb
gnatbind -x test.ali
gnatlink test.ali

C:\Work\safe>test
0 : 1
1 : 2

raised CONSTRAINT_ERROR : test.adb:11 index check failed

Ada (Pascal style) får karakteren 8 for at opdage fejlen runtime (som default)

C:\Work\safe>type test2.adb
with Ada.Text_IO,Ada.Integer_Text_IO;

use Ada.Text_IO,Ada.Integer_Text_IO;

procedure Test2 is

type TIX is range 0..1;
type TA is array(TIX) of integer;

A : TA;

begin
for I in 0..2 loop
A(I) := I + 1;
Put(I,Width=>1);
Put(" : ");
Put(A(I),Width=>1);
New_Line;
end loop;
end Test2;

C:\Work\safe>gnat make test2.adb
gcc -c test2.adb
test2.adb:14:11: expected type "TIX" defined at line 7
test2.adb:14:11: found type "Standard.Integer"
test2.adb:17:15: expected type "TIX" defined at line 7
test2.adb:17:15: found type "Standard.Integer"
gnatmake: "test2.adb" compilation error

Ada (Ada style) får karakteren 11 for at opdage fejlen compile time

#53 - arne_v
22. jul. 2019 00:14

(duplikat)

#54 - Claus Jørgensen
22. jul. 2019 00:35

#52

Swift:

for i in 0...2 {
print("\(i) : \(i + 1)")
}

Output:

0 : 1
1 : 2
2 : 3

... fixed length arrays er ikke så normale mere. Jeg er ikke helt sikker på at jeg tror at de faktisk allokere mindre hukommelse end sprog hvor det er op til kompileren/runtime at finde ud af det.

#55 - Claus Jørgensen
22. jul. 2019 00:49

Men så igen, funktionel programmering to the rescue:

Swift:

[Int](repeating: 0, count: 2).indices.map { ($0, $0 + 1) }.forEach {
print("\($0.0) : \($0.1)")
}

Output:

0 : 1
1 : 2

Ingen fejl, fordi du ikke kan skrive koden forkert ;-)

Swift tillader slet ikke for(i; i<3; i++) {} style loops mere. Vi kan heller ikke tilgå chars in strings med numerisk index mere.

#56 - arne_v
22. jul. 2019 01:03

#54

Den kode bruger jo slet ikke array.

Hvad gør Swift hvis du har et array 0..1 og du forsøger at tilgå 0..2

#57 - arne_v
22. jul. 2019 01:08

#56

Googling antyder at Swift giver en runtime exception EXC_BAD_INSTRUCTION i det tilfælde. En 8'er.

Er ikke Swift kyndig nok til at checke.

#58 - Septi
22. jul. 2019 07:50

#38

Jeg har ikke lavet kode i .net hvor Endian har været en udfordring, så her må jeg være svar skyldig. Men jeg synes du sammenligner æbler og bananer når du sammenligner have C/C++ Native kan med Java som benytter java.nio.ByteBuffer. Boost biblioteket til C/C++ kan håndtere Endian lige så nemt.

#59 - Septi
22. jul. 2019 07:58

Det er rigtigt smart.

Der er hundredetusinder af eksempler på at man har porteret applikationer mellem OS.

Jeg tror at der er nul eksempler på at styresystemet har ødelagt sprog bibliotek ved at ændre API for filstørrelse.

Her må vi blot være uenig.Jeg Kan ikke sige med API til filstørrelse, men der er massere af eksempler på at API til OS har ødelagt application, når der er indført ændringer eller nye version. Man kan ikke være bagud kompatible i al evighed.

#60 - Septi
22. jul. 2019 08:02

arne_v (51) skrev:
Septi (46) skrev:
arne_v (39) skrev:

Korrekt.

Men nogen sprog fanger fejl tidligere/nemmere end andre.

Compile time fejl er bedre end runtime fejl hvor problemet findes.

Runtime fejl hvor problemet findes er bedre end runtime fejl på et andet sted senere.

C og C++ er sprog som giver den sidste type fejl oftere end stort set alle andre sprog (assembler ikke inklusive).

Det lyder mere som du diskutere managed vs. unmanaged kode? Enig i at det er bedre at "Fail Fast". Men i alle unmanaged sprog sidder du med de samme udfordringer, blandt unmanaged sprog er C/C++ klart det bedste.

Nej.

Check på array index og kontrol med pointere er ikke specifik for managed sprog.

Det er noget som de fleste unmanaged sprog har eller har mulighed for. C og C++ er undtagelser her.

Det er ikke korrekt, hvis du vil have den slags auto checks, så kan man benytte STL, så som std:array eller lign. Så får du hel sammen funktionalitet.

Du har bare også muligheden for at gå "bare metal" så at sige, men det ansvar der følger med til det.

Du bliver ved med at sammenligne sprog, hvor den funktionalitet der findes i STL, reelt er indbygget. Det var derfor jeg skrev du bliver nød til at inkludere dette hvis vi skal have en reel sammenligning.

#61 - larsp
22. jul. 2019 08:06

Septi (42) skrev:
arne_v (35) skrev:

Bemærk at det ikke er en standard feature, men en feature i visse implementationer.

Alle C/C++ kompilere understøtter packed strukture, med forskellige keywords (mit eksempel var fra GCC), det er brugt utroligt meget i driver udvikling og netværks programmering. Hvordan den enkelte kompilere skal sættes op, kan variere, men er ikke nogen større udfordring.

Den eneste skudsikre og platformsuafhængige måde at implementere en binær protokol i C er at tage én byte af gangen og selv bygge words og dwords op. Man vil altid risikere at komme galt afsted hvis man bruger større datatyper eller structs med felter, pga. endianness og padding. Ja, selv hvis man beder compileren om ikke at padde, kan den blive nød til det pga. arkitekturen. Traditionel ARM f.eks. understøtter ikke unaligned 32-bit læsninger. Det er muligt at nogle compilere kan indsætte noget magi til at komme uden om det problem, men jeg ville ikke stole på det i robust driverkode.

I et bedre lowlevel sprog kunne der være en alternativ struct definition hvor man deklarerer helt præcis hvordan data skal kodes, inklusiv endianness, bit bredde og offsets. Så kunne compileren klare det bøvlede arbejde med at oversætte fra platformens native typer til det der kræves af protokollen.

Jeg ved det godt, det er bare mig der drømmer, men det er feature der kunne hjælpe meget i driververdenen. Nogen der ved om den slags findes i Go / Rust?

#62 - Septi
22. jul. 2019 08:50

#52

Det er lidt en stråmand du prøver at lave her for at bevise din pointe.

Hvis man kigger på det du anser som det værste (C/C++) og bedste Ada, så er det jo slet ikke det samme du laver. I dit kode eksempel for C/C++ arbejder du direkte på hukommelsen med en pointer, når du benytter et array på den måde.

I Ada arbejder du på hele datastrukturen, eller et array object om man vil. (Som godt nok er skjult for dig). (https://learn.adacore.com/courses/intro-to-ada/chapters/arrays.html)

Hvis du skal sammenligne med Ada (eller de andre) skal du sammenligne med stl::array, eller evt. stl::vector.

Det er lidt noget vås at sammenligne direkte hardware adgang, med det at benytte et object, som har implementeret en masse checks. Det er jo to forskellige ting, som genere meget forskellige kode.

#63 - Septi
22. jul. 2019 09:00

larsp (61) skrev:
Septi (42) skrev:
arne_v (35) skrev:

Bemærk at det ikke er en standard feature, men en feature i visse implementationer.

Alle C/C++ kompilere understøtter packed strukture, med forskellige keywords (mit eksempel var fra GCC), det er brugt utroligt meget i driver udvikling og netværks programmering. Hvordan den enkelte kompilere skal sættes op, kan variere, men er ikke nogen større udfordring.

Den eneste skudsikre og platformsuafhængige måde at implementere en binær protokol i C er at tage én byte af gangen og selv bygge words og dwords op. Man vil altid risikere at komme galt afsted hvis man bruger større datatyper eller structs med felter, pga. endianness og padding. Ja, selv hvis man beder compileren om ikke at padde, kan den blive nød til det pga. arkitekturen. Traditionel ARM f.eks. understøtter ikke unaligned 32-bit læsninger. Det er muligt at nogle compilere kan indsætte noget magi til at komme uden om det problem, men jeg ville ikke stole på det i robust driverkode.

I et bedre lowlevel sprog kunne der være en alternativ struct definition hvor man deklarerer helt præcis hvordan data skal kodes, inklusiv endianness, bit bredde og offsets. Så kunne compileren klare det bøvlede arbejde med at oversætte fra platformens native typer til det der kræves af protokollen.

Jeg ved det godt, det er bare mig der drømmer, men det er feature der kunne hjælpe meget i driververdenen. Nogen der ved om den slags findes i Go / Rust?

Jeg er helt enig, når vi snakker structs og packing i det hele taget, kan man rende ind i udfordringen inden for de enkelt CPU arkitekture, samt kompilere som lavere sjove ting med mpdding eller andet (sikkert i bedste mening). Jeg synes nu ikke G++ eller GCC har vært slem til dette.

Jeg er ikke så stærk i Go eller Rust, så kan ikke hjælpe til der. Jeg ved Go mangler mulighed for at lave union, men ikke meget ud over det. Men prøv at se her. http://www.catb.org/esr/structure-packing/ synes det er en fin artikle som giver et godt overblik.

#64 - arne_v
24. jul. 2019 23:44

Septi (58) skrev:

Men jeg synes du sammenligner æbler og bananer når du sammenligner have C/C++ Native kan med Java som benytter java.nio.ByteBuffer. Boost biblioteket til C/C++ kan håndtere Endian lige så nemt.

java.nio.ByteBuffer kommer med Java.

Boost kommer ikke med C++.

#65 - arne_v
24. jul. 2019 23:52

Septi (60) skrev:

Det er ikke korrekt, hvis du vil have den slags auto checks, så kan man benytte STL, så som std:array eller lign. Så får du hel sammen funktionalitet.

Du har bare også muligheden for at gå "bare metal" så at sige, men det ansvar der følger med til det.

Du bliver ved med at sammenligne sprog, hvor den funktionalitet der findes i STL, reelt er indbygget. Det var derfor jeg skrev du bliver nød til at inkludere dette hvis vi skal have en reel sammenligning.

Septi (62) skrev:

Det er lidt en stråmand du prøver at lave her for at bevise din pointe.

Hvis man kigger på det du anser som det værste (C/C++) og bedste Ada, så er det jo slet ikke det samme du laver. I dit kode eksempel for C/C++ arbejder du direkte på hukommelsen med en pointer, når du benytter et array på den måde.

I Ada arbejder du på hele datastrukturen, eller et array object om man vil. (Som godt nok er skjult for dig). (https://learn.adacore.com/courses/intro-to-ada/chapters/arrays.html)

Hvis du skal sammenligne med Ada (eller de andre) skal du sammenligne med stl::array, eller evt. stl::vector.

Det er lidt noget vås at sammenligne direkte hardware adgang, med det at benytte et object, som har implementeret en masse checks. Det er jo to forskellige ting, som genere meget forskellige kode.

C array, C++ array, Pascal array of Ada array er præcis det samme. Bare et antal elementer kontinerligt i memory. Ingen metoder. VMS Pascal og Ada83 har slet ikke klasser og metoder (og Ada eksemplet virker helt ens i Ada83, selvom jeg har testet i nyere Ada).

C++ STL std::array er en klasse med metoder.

Du skal være meget forsigtigt med et ord som objekt.

I OO sprog a la Java er et objekt en instans af en klasse.

I C, C++ og Ada et objekt bare en variabel.

#66 - arne_v
24. jul. 2019 23:58

Med hensyn til std::array så vil jeg lige notere at det i første ogang slet ikke løser problemet.

C:\Work\safe>type test2.cpp
#include <iostream>
#include <array>

using namespace std;

int main()
{
array<int,2> a;
for(int i = 0; i < 3; i++)
{
a[i] = i + 1;
cout <g++ -Wall test2.cpp -o test2.exe

C:\Work\safe>test2
0 : 1
1 : 2
3 : -13195

Man er nødt til at bruge at metoden for at få fejl.

C:\Work\safe>type test3.cpp
#include <iostream>
#include <array>

using namespace std;

int main()
{
try
{
array<int,2> a;
for(int i = 0; i < 3; i++)
{
a.at(i) = i + 1;
cout <g++ -Wall test3.cpp -o test3.exe

C:\Work\safe>test3
0 : 1
1 : 2
array::at: __n (which is 2) >= _Nm (which is 2)

Men OK. C++ kommer med std::array og ved at lave et ekseplict metode kald af at i.s.f. indeksering kan man fremtvingen run runtime fejl.

Så vi kan vel hæve C++ karakteren fra 03 til 5.

#67 - arne_v
25. jul. 2019 01:07

Der er selvfølgelig nogen gange hvor man har brug for lidt gris, men der synes jeg at Rust har lavet det rigtigt.

fn main() {
let a: [i32; 2] = [ 1, 2];
unsafe {
for i in 0..3 {
println!("{} : {}", i, a.get_unchecked(i));
}
}
for i in 0..3 {
println!("{} : {}", i, a[i]);
}
}

giver:

0 : 1
1 : 2
2 : 2949120
0 : 1
1 : 2
thread 'main' panicked at 'index out of bounds: the len is 2 but the index is 2', src\main.rs:9:27

Ved normal brug checkes der på indeks.

Men i en:

unsafe { }

blok og med brug af get_unchecked metoden kan man få lov til at grise.

Det er OK - det er der ingen udvikler som kommer til ved et uheld - og det springer i øjnene ved code review.

Det vil jeg faktisk give et 9 tal.

#68 - larsp
25. jul. 2019 05:35

#66 Jeg prøvede lige dine kode på ubuntu:

$ ./test2
0 : 1
1 : 2
2 : 3
*** stack smashing detected ***: ./test2 terminated
Aborted (core dumped)

$ ./test3
0 : 1
1 : 2
array::at: __n (which is 2) >= _Nm (which is 2)

Pudsigt nok crasher test2 med et brag her. Måske har det noget at gøre med at jeg kører gcc v7:

$ g++ --version
g++ (Ubuntu 7.4.0-1ubuntu1~16.04~ppa1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Rust lyder interessant med unsafe deklarationen. Jeg installerede rustc på min linux og får:

$ ./testrust
0 : 1
1 : 2
2 : 0
0 : 1
1 : 2
thread 'main' panicked at 'index out of bounds: the len is 2 but the index is 2', testrust.rs:9:24
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Men... se lige størrelsen på binarys >:(

$ ll
total 2520
drwxrwxr-x 2 lars lars 4096 Jul 25 08:30 ./
drwxrwxr-x 10 lars lars 4096 Jul 25 08:15 ../
-rwxrwxr-x 1 lars lars 9280 Jul 25 08:12 test2*
-rw-rw-r-- 1 lars lars 184 Jul 25 08:12 test2.cpp
-rwxrwxr-x 1 lars lars 13864 Jul 25 08:15 test3*
-rw-rw-r-- 1 lars lars 260 Jul 25 08:14 test3.cpp
-rwxrwxr-x 1 lars lars 2529664 Jul 25 08:30 testrust*
-rw-rw-r-- 1 lars lars 163 Jul 25 08:29 testrust.rs

Testen i rust fylder 2.5 MB... well... måske hjælper strip

$ strip test2 test3 testrust
$ ll
total 244
drwxrwxr-x 2 lars lars 4096 Jul 25 08:33 ./
drwxrwxr-x 10 lars lars 4096 Jul 25 08:15 ../
-rwxrwxr-x 1 lars lars 6296 Jul 25 08:33 test2*
-rw-rw-r-- 1 lars lars 184 Jul 25 08:12 test2.cpp
-rwxrwxr-x 1 lars lars 10512 Jul 25 08:33 test3*
-rw-rw-r-- 1 lars lars 260 Jul 25 08:14 test3.cpp
-rwxrwxr-x 1 lars lars 207120 Jul 25 08:33 testrust*
-rw-rw-r-- 1 lars lars 163 Jul 25 08:29 testrust.rs

Det var da lidt bedre. Tror jeg vil kigge lidt nærmere på rust.

#69 - arne_v
25. jul. 2019 13:49

larsp (68) skrev:

#66 Jeg prøvede lige dine kode på ubuntu:

$ ./test2
0 : 1
1 : 2
2 : 3
*** stack smashing detected ***: ./test2 terminated
Aborted (core dumped)

Stack smashing protection er rigtigt smart og bør altid være enablet.

Jeg ved ikke hvorfor det ikke er default på min Windows GCC.

Men det fanger ikke alle tilfælde.

C:\Work\safe>type test2.cpp
#include <iostream>
#include <array>

using namespace std;

int main()
{
array<int,2> a;
for(int i = 0; i < 3; i++)
{
a[i] = i + 1;
cout <g++ -Wall test2.cpp -o test2.exe

C:\Work\safe>test2
0 : 1
1 : 2
3 : -13195

C:\Work\safe>g++ -Wall -fstack-protector test2.cpp -o test2.exe

C:\Work\safe>test2
0 : 1
1 : 2
2 : 3

C:\Work\safe>g++ -Wall -fstack-protector-strong test2.cpp -o test2.exe

C:\Work\safe>test2
0 : 1
1 : 2
2 : 3
*** stack smashing detected ***: terminated
1 [main] test2 9856 cygwin_exception::open_stackdumpfile: Dumping stack trace to test2.exe.stackdump

C:\Work\safe>type test4.cpp
#include <iostream>
#include <array>

using namespace std;

struct z
{
array<int,2> a;
int something;
};

int main()
{
struct z o;
for(int i = 0; i < 3; i++)
{
o.a[i] = i + 1;
cout <g++ -Wall -fstack-protector-strong test4.cpp -o test4.exe

C:\Work\safe>test4
0 : 1
1 : 2
2 : 3

#70 - arne_v
25. jul. 2019 14:06

larsp (68) skrev:

Det var da lidt bedre. Tror jeg vil kigge lidt nærmere på rust.

C og C++ vil være udbredt i 25-50 år endnu.

Masser af eksisterende kode og masser af folk med skills.

Men der er folk som kigger på alternativer.

For high level business kode skifter man til Java, C#, PHP, Python etc..

For low level kode kigger man på (og jegtror at "logger på" er mere korrekt end "skifter til") Rust og Go.

Og ja - Go checker default også array indeks.

#71 - CBM
25. jul. 2019 15:16

Første job efter man er færdig uddannet indenfor IT

"Okay, slick. But let me tell you something about all your skills. As of right now, they mean precisely... dick."

#72 - larsp
25. jul. 2019 17:53

arne_v (70) skrev:

C og C++ vil være udbredt i 25-50 år endnu.

Masser af eksisterende kode og masser af folk med skills.

Jeg var fornylig i en situation hvor vi skulle vælge arkitektur, sprog, det hele, på en ny embedded Linux platform, så det var i princippet et sted man kunne have valgt et nyt smart sprog. Vi valgte at holde fast i C til lowlevel og Python3 til highlevel, af forskellige årsager. En af dem var rigtig nok de skills der var til rådighed i teamet. En anden årsag var legacy kode. Men med en frisk beslutning kunne vi nok have valgt at gå med rust og kommet godt af sted med det. Spørgsmålet er så om fordelene opvejer omkostningerne.

#73 - arne_v
25. jul. 2019 18:07

#72

Og risikoen.

Der er en vis taktisk risiko ved at vælge et sprog som man har meget lidt erfaring. Passer det nu rent faktisk godt til det man vil lave.

Men der er også en strategisk risiko.

De fleste så gerne noget andet en C/C++.

Og det er vel derfor overvældende sandsynligt at der om 25 år findes et eller flere sprog som har taget en stor mundfuld af det som idag er mest C/C++.

Men der er ingen garanti for at Rust er blandt dem.

Måske dukker der et nyt sprog op imorgen som løber med markedet.

Så der er en vis risiko ved at satse på Rust idag.

Bliver Rust en success, så har man valgt rigtigt og fået et forspring.

Bliver Rust ikke en success, så har man valgt forkert og må enten skifte til noget andet eller leve med at være i en niche.

#74 - arne_v
26. jul. 2019 15:16

arne_v (22) skrev:
Apropos.

https://www.theregister.co.uk/2019/07/18/microsoft...

Efter en god uge kom den til Danmark:

https://www.version2.dk/artikel/microsoft-rust-kan...

Jeg vil tillade mig at citere et afsnit, da det ligesom matcher ovenfor:

I Rust skal der stå ‘unsafe’ i koden, før man kan slippe for de skrappe regler.

#75 - larsp
26. jul. 2019 17:44

#74 Så den godt. Det virker som rust er ved at få momentum.

Check også denne artikel, http://lucumr.pocoo.org/2012/10/18/such-a-little-t... om bl.a. semicolon og det smarte de har fundet på i den sammenhæng. Der er sgu tænkt over det.

Jeg er gået igang med at løbe den terminalbaserede rustling tutorial igennem. Det er som et lille spil, enormt sødt. Jeg må sige at rust grows on me ;)

#76 - Septi
28. jul. 2019 21:44

C array, C++ array, Pascal array of Ada array er præcis det samme. Bare et antal elementer kontinerligt i memory. Ingen metoder. VMS Pascal og Ada83 har slet ikke klasser og metoder (og Ada eksemplet virker helt ens i Ada83, selvom jeg har testet i nyere Ada).

Det er simpelthen ikke korrekt. Du må have misforstået noget, følgende er fra Ada documentation :

"Semantically, an array object in Ada is the entire data structure, and not simply a handle or pointer. Unlike C and C++, there is no implicit equivalence between an array and a pointer to its initial element."

Der er intet sammenligneligt mellem et C/c++ Array og en Ada Array. I Ada er det netop ikke kontinuerligt i hukommelsen. Den nærmeste sammenligning er en af stl containerne.

C++ STL std::array er en klasse med metoder.

Det er det sådan set også i Ada

Du skal være meget forsigtigt med et ord som objekt.

I OO sprog a la Java er et objekt en instans af en klasse.

I C, C++ og Ada et objekt bare en variabel.

Brugen er "objekt" i dette tilfælde fra den dokumentation som er tilgængelig (se Link fra tidligere) Sidste jeg tjekkede var C++ indregnet som et OO sprog, man da naturligvis multi-paradigm da det understøtter mange måde at gøre tingene på, der af C/c++ styrke.

Men jo forskellige sprog definerer jo "object" forskelligt.

#77 - Septi
28. jul. 2019 22:32

#69

larsp kom selv ind på -fstack-protector-strong flaget. Så vil ikke gå ind i det.

Jeg udvikler selv pt. kun på linux, unix og macos, så skal ikke gøre mig klog på hvor g++ reagere på windows.

Angående dit kode eksempel vil jeg blot sige at når du benytter '[]' i stedet for '.at' til tilgå et stl array, er der absolut ingen forskel på dette og så det at direkte tilgå et standard array.

Når man benytter STL er det god stil at bruge iterators, så kan man også helt undgå out-of-bounds fejl. (Har kastet et hurtigt eksempel ind, kan sikkert laves pænere) Det er lavet med STL Array, men normalt ville jeg bruge STL Vector, da det er noget mere flexibel.

/*----START----*/

#include <iostream>
#include <array>

using namespace std;

int main()
{
try
{
array<int,2> a;
array<int,2>::iterator ptr;
int index = 0;

for(ptr = a.begin(); ptr < a.end(); ptr++)
{
a.at(index) = index + 1;
cout << index << " : " << a.at(index) << endl;
index++;
}

}
catch(const out_of_range& oor)
{
cout << oor.what() << endl;
}
return 0;
}

#78 - Septi
28. jul. 2019 22:54

#73

Er helt enig med din antagelse her, antallet af udviklings sprog som er kommet til siden 1972/1973 (hvor C sproget blev udviklet af Bell Labs) er massivet.

Antal af disse sprog som stadig bliver brugt professionelt i dag er minimalt.
Se evt. (https://en.wikipedia.org/wiki/Timeline_of_programming_languages)

Det er altid fristende at gå med den nye trend, prøve noget nyt. Mine udviklere vil da også gerne være med på moden, og vi afprøver da også de nyeste trends når muligheden byder sig. Men igen har det også noget med risikoen at gøre, hvis du er first mover på et nyt smart sprog, og det fejler efter nogle år, står du med en kode base, som er svær at vedligeholde, og udviklere som er svære og sikkert dyre at få fat på. I sidste ende skal du sikkert lavet det hele om.

Min mening er, at C/C++ har stået the "test of time", ikke fordi det er det bedste til alt, men det er fleksibelt, og har i dag langt de fleste features som tidligere har gjort andre sprog unikke.

Vil der komme en afløser en dag, ja helt sikkert i en eller anden form, men jeg kan pt ikke få øje på noget jeg ville kalde en klar vinder.

#79 - arne_v
4. aug. 2019 18:55

Septi (76) skrev:

C array, C++ array, Pascal array of Ada array er præcis det samme. Bare et antal elementer kontinerligt i memory. Ingen metoder. VMS Pascal og Ada83 har slet ikke klasser og metoder (og Ada eksemplet virker helt ens i Ada83, selvom jeg har testet i nyere Ada).

Det er simpelthen ikke korrekt. Du må have misforstået noget, følgende er fra Ada documentation :

"Semantically, an array object in Ada is the entire data structure, and not simply a handle or pointer. Unlike C and C++, there is no implicit equivalence between an array and a pointer to its initial element."

Der er intet sammenligneligt mellem et C/c++ Array og en Ada Array. I Ada er det netop ikke kontinuerligt i hukommelsen. Den nærmeste sammenligning er en af stl containerne.

Nej - det er dig som læser den tekst forkert.

Der står intet om at det ikke er kontinuerligt i hukommelsen.

Teksten konstaterer kun at array og pointere ikke er ekvilente i Ada.

Og det er de ikke.

Af type sikkerheds årsager.

#80 - arne_v
4. aug. 2019 19:00

Septi (76) skrev:

Du skal være meget forsigtigt med et ord som objekt.

I OO sprog a la Java er et objekt en instans af en klasse.

I C, C++ og Ada et objekt bare en variabel.

Brugen er "objekt" i dette tilfælde fra den dokumentation som er tilgængelig (se Link fra tidligere)

(linket var ikke til dokumentation men til en tutorial)

Men igen har du vist ikke fattet pointen.


A : array (0..1) of Integer;

begin
for I in 0..2 loop
A(I) := I + 1;
Put(I,Width=>1);
Put(" : ");
Put(A(I),Width=>1);
New_Line;
end loop;

A er et objekt.

Det er I også.

Per Ada terminologi.

Men da objekt bare er synonym for variabel (ligesom i C og C++), så betyder det at A er et objekt ligesom ikke noget.

#81 - arne_v
4. aug. 2019 19:04

Septi (77) skrev:

Angående dit kode eksempel vil jeg blot sige at når du benytter '[]' i stedet for '.at' til tilgå et stl array, er der absolut ingen forskel på dette og så det at direkte tilgå et standard array.

Når man benytter STL er det god stil at bruge iterators, så kan man også helt undgå out-of-bounds fejl. (Har kastet et hurtigt eksempel ind, kan sikkert laves pænere) Det er lavet med STL Array, men normalt ville jeg bruge STL Vector, da det er noget mere flexibel.

Der er sikre måder at gøre det på i C++.

Men et sikkert sprog er ikke et sprog hvor der er en sikker måde at gøre det på - et sikkert sprog er et sprog hvor der ingen usikre måder er at gøre det på - og et rimeligt sikkert sprog er et sprog hvor det kræver en del krumspring at gøre det på en usikker måde.

#82 - arne_v
4. aug. 2019 19:07

Septi (78) skrev:

Er helt enig med din antagelse her, antallet af udviklings sprog som er kommet til siden 1972/1973 (hvor C sproget blev udviklet af Bell Labs) er massivet.

Antal af disse sprog som stadig bliver brugt professionelt i dag er minimalt.
Se evt. (https://en.wikipedia.org/wiki/Timeline_of_programming_languages)

Der er rigtigt mange sprog som er kommet og gået igen.

Men langt størstedelen af den kode som skrives idag bliver skrevet i sprog nyere end C.

#83 - arne_v
5. aug. 2019 01:26

#sprog der forsvinder

Ruby, Haskell, Objective-C, R og Perl påståes her at være truet:

https://insights.dice.com/2019/07/29/5-programming...

#84 - arne_v
29. aug. 2019 02:35

#75

https://hub.packtpub.com/rust-is-the-future-of-sys...

#85 - larsp
29. aug. 2019 08:19

#84 Interessant artikel.

Rust was built with safety and concurrency in mind making it the perfect choice for rewriting many components of Firefox under Project Quantum. It is also using Rust to develop Servo, an HTML rendering engine that will eventually replace Firefox’s rendering engine. Many other companies have also started using Rust for their projects including Microsoft, Google, Facebook, Amazon, Dropbox, Fastly, Chef, Baidu, and more.

Stærkt at de bruger Rust i Firefox production code, der skal være high performance og high security.

Rust virker efterhånden som en hest der er værd at vædde på.

#86 - Claus Jørgensen
29. aug. 2019 08:30

Absolut. Jeg var nysgerrig, saa jeg kiggede paa et par af deres commits. Her er et eksempel med unsafe:

https://github.com/servo/servo/commit/736f6859b0a3...

#87 - arne_v
29. aug. 2019 12:33

#85

At FF bruger Rust har været kendt længe.

https://newz.dk/firefox-quantum-er-i-beta-hastighe...

#88 - arne_v
12. sep. 2019 19:26

En pro-Ada artikel:

https://hackaday.com/2019/09/10/why-ada-is-the-lan...

#89 - arne_v
17. okt. 2019 17:56

AWS er nu sponsor for Rust:

https://aws.amazon.com/blogs/opensource/aws-sponso...

#90 - CBM
21. okt. 2019 05:33

arne_v (89) skrev:
AWS er nu sponsor for Rust:

https://aws.amazon.com/blogs/opensource/aws-sponso...

Jeg tænker de også skulle sponsere rust væk for at skabe balance

#91 - larsp
21. okt. 2019 09:56

Amazon korroderer!

Godt nyt. Rust er ved at opnå kritisk masse.

#92 - CBM
22. okt. 2019 03:42

larsp (91) skrev:
Amazon korroderer!

Godt nyt. Rust er ved at opnå kritisk masse.

Har de indgået samarbejde med pava?

#93 - larsp
22. okt. 2019 07:24

#92 Jeg er bange for det er for sent, forbroen er næsten gennemtæret ;)

#94 - arne_v
22. okt. 2019 14:55

Spørgsmål: ruster Rust kode mere hvis det editeres med Corrosion?

:-)

#95 - larsp
23. okt. 2019 08:15

#94 Ja, det er et genialt navn for en Rust IDE :) Der skal nok komme nogle flere spil på det navn, som rustbeskyttelse, jernoxid, osv.

#96 - arne_v
24. okt. 2019 16:38

#95

De folk har en vis evne til at finde interessante navne.

#97 - KimMadsen
25. okt. 2019 07:14

larsp (25) skrev:
Septi (23) skrev:
fuld kontrol over bytes i structs (C indsætter padding), ... bedre styr på bits i felter

Der er som sådan rimelig gode feaetures for bit fields i C, enten via unions eller structs.

http://www.tutorialdost.com/C-Programming-Tutorial...

Tilsvarende kan du force forskellige alignments inde i en struct. Men da nogle datatyper kræves alignet til f.eks 16 byte boundaries, for at CPU'en kan behandle data, så kan jeg godt forstå at C default vælger alignment af disse. Ønskes en special alignment, så må man caste til pointer til char.

mboost-dp1

Nyheder

Seneste kommentarer i nyheder

Seneste kommentarer i forum