Vinnaren i pepparkakshustävlingen!
2022-12-23, 13:19
  #85
Medlem
SoberZealots avatar
Citat:
Ursprungligen postat av MKG
Om man tittar lite på vad som brukar orsaka runtimefel i program skrivna i C/C++ så är det några saker som är ständigt återkommande.

1) Man deklarerar en pekare, glömmer att initiera den, och när man använder pekaren till nåt så smäller det eftersom den pekar nånstans slumpmässigt i minnet. Typisk får man ett SIGSEGV avslut.

2) Man pekar på någonting, som kompilatorn optimerar och lägger i ett processorregister, och
då kan man inte peka på det längre, därför att register inte är adresserbara i de flesta processorarkitekturer. En pekare i sig är ju bara en adress (pekarens värde) och storleken på
det den pekar på (pekarens typ). Hamnar det utpekade objektet i ett processorregister så
är det inte säkert att pekaren är användbar längre...

(tanken med intrinsicen "volatile" är att förhindra sånt, men det fanns inte i tidig C)

3) Ursprungligen hade C ingen syntax för att skilja på by-value och by-reference argument till
funktioner. C++ har det (&) men på gamla C-kompilatorer skickade man över pekare eller const-pekare som argument. By value betyder ju att man kopierar värdena till stacken, funktionen använder dem, och när funktionen returnerar så kastas stacken bort. By reference, där skickar man in ADRESSERNA (pekare) till det man vill joxa med, så det man joxat med finns kvar längre upp i stacken eller på heapen.

4) Allokera minne på heapen (malloc() i C eller new i C++), få en pekare till vad man nu har allokerat,
och sedan slarvar man bort pekaren. En klassisk minnesläcka med andra ord.
Minnesallokering är i grund och botten en tjänst från operativsystemet, det är ju inte ens säkert att man har ett operativsystem, jag har aldrig fått den ynnesten på 8-bitars MCU:er, och då finns inget malloc()/free() eller new/delete. I C++ är new/delete intrinsics... jag har å andra sidan ALDRIG sett C++ kod på små 8- eller 16-bitars MCUer.

I Ada kan du inte deklarera en pekare och ha den oinitierad, kompilatorn slår dig på fingrarna direkt.

Det finns i Ada syntaktiskt stöd för argument, om de ska vara "in" (by value), "in out" (by reference) eller "out" (by reference const). Nu har ju C++ försökt göra samma sak med referenser men ADAs syntax är snyggare. Även Pascal skiljer på argument som är by value och by reference, de sistnaämnda deklarerade men med "var" i argumentlistan om jag minns rätt.

I Ada får du inte peka på en variabel med mindre än att du deklarerar variabeln som pekbar, just för att förhindra att variabeln optimeras till ett register. C/C++ "adress-of" operator (&) motsvaras av Adas 'access.

Sen gillar INTE Adakompilatorn att du blandar typer, om du har deklarerat en typ som heter TwoDigitInteger som kan vara 0-99, så kan du inte automatiskt blanda den med vanliga integers, du
måste explicit casta eller deklarera övelagrade operatorer m.m. där man hanterar hur Integer och TwoDigitInteger ska hantera varandra.

Nu har jag inte joxat med Ada på några år för det är i princip bara SAAB som använder det i Sverige, men jag har hållit på med det periodvis sedan 1999. C++ är mycket mycket vanligare.

Lite synd på sätt och vis, Ada är fanimig inget dåligt språk om man ska bygga riktigt stora system.
ADA är världens sämsta språk. Och fått sitt namn från en kvinna som knulla runt och på först på sin dödsbädd bad hon om förlåtelse.
Citera
2023-01-02, 16:50
  #86
Medlem
MKGs avatar
Citat:
Ursprungligen postat av Callebilte
ADA är väl framförallt ett ganska säkert språk. När det väl kompilerar kan man vara ganska säker på att koden är rätt (även om man som programmerare kan ha gjort syftningsfel så koden inte gör det man tänkt.. tex om man tänker 1+1 men råkar skriva 1*1 istället så är ju bägge korrekt men utfallet blir olika). Det jag kommer ihåg är att ADA användes mycket inom bl.a. flygindustrin pga av detta.

Väldigt intressant tråd förövrigt.

Angående assembler vs C (c++) så kan man givetvis i vissa fall skriva snabbare kod i assembler OM man är en riktig assembler guru men de nya kompilatorerna är så bra så jag skulle nog påstå att de spöar iallafall 80% av assemblerknackarna. Men om ni tycker assembler är för segt kan man ju gå ner direkt på 0or och 1or men den koden är lite svårläst och jobbig att underhålla

Det finns saker jag inte kunnat lösa i vare sig C, C++ eller Ada, för det går inte.
Det är inte många saker, men detta är en av dem.

1. Ett Motorola 68k-derivat (PowerPC)
2. Den saknar operativsystem, det jag skriver ÄR en del av själva operativsystemet (ska bli ett pre-emptiva Realtids-OS)
3. När en timer bottnar, ska en interruptrutin exekveras. Det är inte så konstigt, det hade man kunnat skriva i C. Grejen är att kompilatorn "bjuder" mig på kod, en s.k. "prolog" och "epilog", om jag deklarerar funktionen som en interruptrutin, med intrinsice_interrupt_ , alltså
_interrupt_ void TakeCareOfMyInterrupt ()
{
//yadda yadda
}

4. Vad prologen gör är att dumpa ut processorns register och pusha dem på en stack ("prolog-koden", 32 st register), köra TakeCareOfMyInterrupt, sedan poppa av registerena från stacken tillbaka in i processorregistren ("epilogkoden"),
och på så sätt fortsätta köra den kod som kördes när interruptet inträffade.

5. Tack det var ju snällt men nu har jag TRE stycken undansparade stackar, var och en med ett "snapshot" på hur processorns register såg ut just när interuptet kom. Process A, ProcessB och ProcessC. Om interruptet byter processA så ska prologen spara registrens från den, MEN epilogen ska läsa tillbaka register-snapshoten från processB. Så interruptet ska BYTA process...A, B , C, A, B ,C etc.
Alltså början på en enkel trådhanterare!

6. Problemet: Du kan inte kopiera från ett register till stacken, eller från stacken till register i C.
Inga kompilerande språk kommer ner så djupt i arkitekturen. Dessutom, detta måste skrivas i 68K-assembler. Du kan inte flytta den assemberkoden till t.ex. en AVR ATMega. Registeruppsättningen skiljer såg, instruktioner för move, push och pop ser olika ut på ett 68K derivat och en ATMega etc. etc.

Det är väldigt sällan jag behöver rota på sån här nivå MEN det händer när man håller på att skriva firmware för egenutvecklad hårdvara m.m.
Citera
2023-01-02, 16:54
  #87
Medlem
MKGs avatar
Citat:
Ursprungligen postat av SoberZealot
ADA är världens sämsta språk. Och fått sitt namn från en kvinna som knulla runt och på först på sin dödsbädd bad hon om förlåtelse.

Noob. C är namnet på en leverinflammation som är i stort sett obotlig och slutligen leder till cancer.
Både Ada Lovelace sexliv och hepatit Cs förmåga att förstöra levern är fullständigt ointressant vad gäller programmering. Snyt dig och lär dig koda istället.
Citera
2023-01-02, 18:02
  #88
Medlem
SoberZealots avatar
Citat:
Ursprungligen postat av MKG
Noob. C är namnet på en leverinflammation som är i stort sett obotlig och slutligen leder till cancer.
Både Ada Lovelace sexliv och hepatit Cs förmåga att förstöra levern är fullständigt ointressant vad gäller programmering. Snyt dig och lär dig koda istället.
Tog det så illa? Nej, det är inte ointressant att ada är uppkallat efter en hora. Tänk om det kommer ett språk som blir uppkallat efter Trump.

Det var helt enkelt ett dåligt namnval. På ett dåligt språk, som färre och färre använder. Och assembler
är inget snabbt språk. Tar för lång tid att göra programmen

C:s namn kommer förövrigt från att det är en efterföljare till B och inte dina skeva levervärlden.
Citera
2023-01-03, 16:32
  #89
Medlem
Citat:
Ursprungligen postat av SoberZealot
Det var helt enkelt ett dåligt namnval. På ett dåligt språk, som färre och färre använder.

Nja, logiken att ett språk är dåligt för att många använder det innebär motsatt att ett språk är bra om många använder det. Och det motsätter jag mig kraftigt mot.

Det skulle innebära att Javascript, HTML/CSS och SQL är de bästa språken (enligt SOs dev survey -22, https://survey.stackoverflow.co/2022...ogies-language)

Ada är ett fantastiskt språk för sitt syfte, och det är egentligen först i närtid som Rust har kommit ifatt och om (detta är en rent subjektiv bedömning, och en halvkvalificerad sådan då jag inte arbetar aktivt med något av språken).

Om du använder Ada för att visa trianglar som representerar 3d så gör du fel. Använder du Ada för att använda namngivna flyttalstyper med begränsade intervall (tänk MetricDistance eller ImperialDistance istället för att det kommer in en float) så gör du rätt.

Man hamrar inte med en skruvmejsel, och skruvar inte med en hammare.
Citera
2023-02-22, 02:13
  #90
Medlem
C/C++: C och C++ är lågnivåprogrammeringsspråk som ofta används för programmering av embedded system, drivrutiner, kärnkomponenterna i ett operativsystem och systembibliotek. C är standardspråket för embedded systems, medans C++ är standardspråket inom spelindustrin.

Sedan har vi väl förmodligen biljoner rader COBOL och Ada kod bakom privata väggar som användes i äldre system som utvecklades för decennier sedan. COBOL för affärsapplikationer såsom bank, finans och försäkring, och Ada för säkerhetskritiska tillämpningar som flyg-, försvars- och rymdsystem. Att flytta från COBOL eller Ada till exempelvis C eller C++ lär ju inte bli ett lätt eller roligt projekt precis.

Hur som helst, oavsett hur skicklig man känner sig i C, C++ eller Assembly, så kommer kompilatorn att optimera och översätta koden betydligt bättre.

I slutändan är språken bara ett verktyg för att programmeraren. I företagsvärlden handlar allt om tid och pengar; då använder man ofta s.k. skriptspråk och enklare språk för att snabbt producera något.

Personligen föredrar jag C, och C++ alla dagar i veckan, men tycker även Python och Lua är roligt.
__________________
Senast redigerad av S0urce 2023-02-22 kl. 02:19.
Citera
2023-03-15, 00:14
  #91
Medlem
Citat:
Ursprungligen postat av S0urce
C/C++: C och C++ är lågnivåprogrammeringsspråk som ofta används för programmering av embedded system, drivrutiner, kärnkomponenterna i ett operativsystem och systembibliotek. C är standardspråket för embedded systems, medans C++ är standardspråket inom spelindustrin.

Sedan har vi väl förmodligen biljoner rader COBOL och Ada kod bakom privata väggar som användes i äldre system som utvecklades för decennier sedan. COBOL för affärsapplikationer såsom bank, finans och försäkring, och Ada för säkerhetskritiska tillämpningar som flyg-, försvars- och rymdsystem. Att flytta från COBOL eller Ada till exempelvis C eller C++ lär ju inte bli ett lätt eller roligt projekt precis.

Hur som helst, oavsett hur skicklig man känner sig i C, C++ eller Assembly, så kommer kompilatorn att optimera och översätta koden betydligt bättre.

I slutändan är språken bara ett verktyg för att programmeraren. I företagsvärlden handlar allt om tid och pengar; då använder man ofta s.k. skriptspråk och enklare språk för att snabbt producera något.

Personligen föredrar jag C, och C++ alla dagar i veckan, men tycker även Python och Lua är roligt.
Där har vi svaret!
Citera
2023-03-15, 00:17
  #92
Medlem
Citat:
Ursprungligen postat av S0urce
C/C++: C och C++ är lågnivåprogrammeringsspråk som ofta används för programmering av embedded system, drivrutiner, kärnkomponenterna i ett operativsystem och systembibliotek. C är standardspråket för embedded systems, medans C++ är standardspråket inom spelindustrin.

Sedan har vi väl förmodligen biljoner rader COBOL och Ada kod bakom privata väggar som användes i äldre system som utvecklades för decennier sedan. COBOL för affärsapplikationer såsom bank, finans och försäkring, och Ada för säkerhetskritiska tillämpningar som flyg-, försvars- och rymdsystem. Att flytta från COBOL eller Ada till exempelvis C eller C++ lär ju inte bli ett lätt eller roligt projekt precis.

Hur som helst, oavsett hur skicklig man känner sig i C, C++ eller Assembly, så kommer kompilatorn att optimera och översätta koden betydligt bättre.

I slutändan är språken bara ett verktyg för att programmeraren. I företagsvärlden handlar allt om tid och pengar; då använder man ofta s.k. skriptspråk och enklare språk för att snabbt producera något.

Personligen föredrar jag C, och C++ alla dagar i veckan, men tycker även Python och Lua är roligt.
Nu kan man ju lita på kompilatorn på ett annat sätt. Förut när gfx och animation var ett prob fick man ju ju t.ex. inline:a asm för t.ex. 2d-scrollning. Det behöver man ju inte tänka på nu, åtminstone om man sitter på en PC och inte på en 8088:a eller nåt värre.
Citera
2023-03-30, 22:59
  #93
Medlem
Citat:
Ursprungligen postat av recyclebin2
Nu kan man ju lita på kompilatorn på ett annat sätt. Förut när gfx och animation var ett prob fick man ju ju t.ex. inline:a asm för t.ex. 2d-scrollning. Det behöver man ju inte tänka på nu, åtminstone om man sitter på en PC och inte på en 8088:a eller nåt värre.
Lita på kompilator vet jag inte, däremot är cpu så komplex nu jämfört med 8088 så det är hopplöst. Testa en modern kompilator mot 8088 så får du se att den fortfarande producerar sämre kod än dig.
Citat:
Ursprungligen postat av SoberZealot
Tog det så illa? Nej, det är inte ointressant att ada är uppkallat efter en hora. Tänk om det kommer ett språk som blir uppkallat efter Trump.

Det var helt enkelt ett dåligt namnval. På ett dåligt språk, som färre och färre använder. Och assembler
är inget snabbt språk. Tar för lång tid att göra programmen

C:s namn kommer förövrigt från att det är en efterföljare till B och inte dina skeva levervärlden.
Kan det vara så att det är Linda Lovelace du menar?
Citera
2023-03-31, 07:19
  #94
Medlem
SoberZealots avatar
Citat:
Ursprungligen postat av BrandiLove
Lita på kompilator vet jag inte, däremot är cpu så komplex nu jämfört med 8088 så det är hopplöst. Testa en modern kompilator mot 8088 så får du se att den fortfarande producerar sämre kod än dig.

Kan det vara så att det är Linda Lovelace du menar?

https://sv.wikipedia.org/wiki/Ada_Lovelace

Nej, Ada var ju känd för spelmissbruk och män. Sedan kan man ju hävda, vilket jag inte tror ett ögonblick på, att hon inte låg med dem. Spelar ju ingen roll i det fallet, när hon förnedrar sin man på det sättet och på den tiden. Hon verkar helt enkelt gjort fel saker, som hennes man förlät henne för på dödsbädden till slut.

Man kan notera att livmoderhalscancer drabbar oftare människor som har många partners.
Citera
2023-04-07, 01:22
  #95
Medlem
Citat:
Ursprungligen postat av BrandiLove
Lita på kompilator vet jag inte, däremot är cpu så komplex nu jämfört med 8088 så det är hopplöst. Testa en modern kompilator mot 8088 så får du se att den fortfarande producerar sämre kod än dig.

Nu förstår jag inte, du tror du kan slå en kompilator??
Citera
2023-04-07, 01:24
  #96
Medlem
Även när du skrev 10 PRINT "HEJ" på din ABC80 så var dess kompilator smartare än dig.
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback