Hur nära kan man komma åt hårdvaran via C vs C++?

[sodjan]

Notera att i mitt exempel så länkas det i och för sig in en del
speciell C++ kod från biblioteken, men "transfer address" (där
koden EXEn startar efter att ha laddats) är fortfarande main()
från C filen. Så EXEn blir större, men jag förväntar mig ingen
speciell skillnad när det körs.

Notera också att i detta fall innehåller koden inget C++ specifikt,
det var enbart för att jämföra en "ren" C fil i de båda kompilatorena.

[victor_passe]

Frågan känns felaktig.
I C:
int a=5;
Nu har du kommit åt hårdvaran, grattis. Bara att se till att "a" ligger på "rätt" ställe och sätts till "rätt" värde så kan du få hårdvaran att göra allt den kan.

Du "är en C programmerare", vet inte varför du programmerar i C eller hur man kommer åt hårdvara i språket. Det är lite imponerande får jag ta och säga.

[sodjan]

Det var det jag menade med att det inte har med C i sig att göra.
Någon måste lägga till stödet för att mappa de adresser som
utgör "hårdvaran". Det måste även stödjas genom hela
processen med kompilering/länkning. Men det har som
sagt ingenting med C i sig att göra.

[Al_Bundy]

jag har skrivit en del kod i både c och c++ för en stm32 processor. Om den klassas som stor eller liten vet jag inte riktigt..

Jag har kodat i C under flera år och min kod har blivit mer och mer objektorienterad, dvs att man gör en struct med funktionspekare och variabler och att man alltid skickar med denna strukt i sina funktions-anrop.

Anledningen till detta är att mina program har ofta blivit ganska stora och att man skriver samma kod om och om igen med små skillnader. Hittar man buggar är det lätt att man fixar på ett ställe och missar på ett annat. Problemet med denna metod i C är att det lätt blir rörigt med alla pekare och man gör wrappers i defines som kan hitta på hyss om man inte har stenkoll på läget.

Det där med att en massa konstruktorer körs om man initierar i C++ jämfört med C vet jag inte riktigt vad det innebär. Innan man kört sin main-funktion så har väl inga klasser skapats? Däremot initieras en hel del variabler innan man kommer till main vilket är lika för både c och c++. Det är bara att sätta en break-point i c-startup filen så kan man se vad som händer och vad som initieras. jag har inte gjort detta för c++ så jag vet inte om någon kod från klasser körs innan man kommer till main.
Sedan har jag för mig att det sker en extra kopiering när man kör c++ och returnerar ett värde. Men även här skulle man lätt kunna kontrollera om detta gäller för en specifik kompilator genom att stega koden och se hur många cykler en retur-kopiering tar beroende om man kompilerar för c/c++.

Det var lite problem med interrupt i C++, har för mig att man inte kan kalla på ett objekt från ett interrupt. Jag mins inte på rak arm exakt vad problemet var.

Det går även att kompilera vissa filer (t.ex *.c) med en c kompilator och andra filer (*.cpp) med c++ kompilator därefter kan man länka ihop objektfilerna till en körbar fil för processorn om man skulle vilja detta. Precis på samma sätt som att man kan kompilera vissa filer i asm och länka ihop med C kod.

Kan inte du visa en exempelkod av C som är objektorienterad? Ta något enkelt t.ex bil, färg, modell osv?

[Al_Bundy]

Jag ser fler och fler skriver "man kan visst programmera objektorienterat med C!!!". Men varför sägs det allmänt att man inte kan göra det?

Jag är helt övertygad att man kan programmera objektorienterat via C, utan dessa "C++ klasser". Men jag har aldrig sett något exempel

[Nerre]

Det är klart man KAN. Du kan skriva objektorienterat i Basic.

Skillnaderna är främst att om du skriver i C så måste du skapa en massa strukturer, funktioner och sånt manuellt. Det blir alltså mer jobb och dessutom ökar såklart risken för fel.

Googlade lite snabbt och hittade den här boken
http://www.cs.rit.edu/~ats/books/ooc.pdf

[Icecap]

Om man inte är en synnerligt usel programmör är all kod man skriver ju objektorienterat. Det är helt enkelt det enda sätt man kan hålla ordning på programmet.

C++ tillför klasser och i "större system" är det i många fall en fördel, man kan se dom som funktioner man kan ta in i projekt och då ha "färdiga, ganska komplexa" rutiner. Detta har stor betydelse för återvinning av kod och det kan vara av stor vikt att ha en rutin som behandlar data på att visst sätt och sedan använda samma kod i olika projekt som jobbar mot samma data.

Med klasser kommer även minneshanterintg, constructors och destructors och det har sina bra sidor men även avigsidor. Problemet är, som skrivit tidigare i denna tråd, att man kan behöva att ha en hårdvarainitiering i en specifik sekvens, något som en "vanlig" constructor kan ställa till problem med.

[baron3d]

Är man många i ett projekt är det bra att kunna deklarera virtuella basklasser, för t.ex. kommunikation. När någon skall koda ett interface så inkluderas basklassen och kodaren måste implementera klassen för den aktuella hårdvaran. På detta vis blir koden interfacet samma för alla kommunikations typer. Hårdvaran kan initieras automatiskt i konstruktorn.

[Al_Bundy]

Tror ni C kommer dö ut? Typ att C++ skulle ta över.

[Nerre]

Eftersom C i princip ingår i C++ så kan C liksom inte dö ut:)

Men nej, lika lite som assembler helt kommer att dö ut. Lågnivåspråk kommer nästan alltid att behövas. Frågan är om det finns nåt stort programmeringsspråk som är helt utdött idag?

[Al_Bundy]

B är utdött. Pascal och COBOL är väll också utdöende språk.

Så för att utveckla C++ så krävs C? Vad krävs det då för att utveckla C?
Jag har fått för mig att dessa är fristående från varandra, trots att dom har samma syntax.

[sodjan]

Eftersom B snarast var en förenklad C, så är det ju inte
underligt om just det har försvunnit.
Pascal är knappast försvunnet, bl.a bygger Delphi på Pascal.
Cobol är ett av de mest använda verktygen över huvud taget
om man tittar på själva användningen av applikationerna.

> Så för att utveckla C++ så krävs C?

Nej.

> Vad krävs det då för att utveckla C?

Du menar för att "skriva en C kompilator".
Rent tekniskt i princip vad som helst, en Fortan kompilator
skulle fungera. Det är ju inget speciellt med just en kompilator,
det är bara en applikation bland andra som har en viss uppgift...

[TomasL]

Jag har fått för mig att dessa är fristående från varandra, trots att dom har samma syntax.

C++ var till en början en utveckling/påbyggnad/vidarutveckling av C.

[Nerre]

B är utdött. Pascal och COBOL är väll också utdöende språk.

Jag skrev "stort programmeringsspråk", B var väl aldrig så stort? :)

Pascal används som sagt var i Delphi, jag tror inte Cobol är helt utdött heller. Det finns i alla fall en OpenCobol som fick sin senaste uppdatering 28 augusti i år.

[TomasL]

Det är väl möjligen FORTH, Fortran, ADA, LISP och några fler som är på nedåtgående trend