Objekt orientering suger

Bra rubrik.

Går ju alldeles utmärkt att hoppa över allt som har med objektorientering att göra i C++, sitta och harva allt i assembler kommer ta onödigt långt tid. Mitt tips är alltså att hålla dig till C och gå över och skriva objektorienterat så fort du sett vitsen med det.

EDIT:
Om det nu var bara för att du tycker assembler verkar intressant och inte bara ville komma ifrån OO så kan du använda sockets från assembler också om du vill (t ex. här är ett exempel i MASM).

Lycka till.

Winsock-funktionerna är skrivet för att vara kompatibelt med c vilket är ett lågnivåspåk.

De lärde tvistas fortfarande om det är lågnivå eller högnivå vad jag vet.
Men det är i varje fall mer högnivå än Assembly, men mer lågnivå än säg Java.

Angående öppningsposten, min första tanke är att du inte verkar ha förstått helt vad objektorientering är och vad det går ut på (möjligen samma sak med C++). Min andra tanke är att din uppfattning om vad du faktiskt behöver av ett språk är lite skum, samt att du inte är alltför insatt i vad Assembly är.
Dessutom, om NÅGOT språk kan kommunicera med OS:et så skulle jag vilja påstå att det är Assembly.
Slutligen, man måste inte koda OO för att använda Winsock.

EDIT: Tills nästa gång, välj en mer beskrivande ämnesrad.

Jag kan hålla med om att objekt orientering suger men bara i c++. Kolla i stället på andra språk som gör (enligt min mening) objekt orientering mycket bättre än vad c++ gör. Ex Java, Ruby, D (http://www.digitalmars.com/d/index.html) D är ungefär c++ på rätt sätt.

Vem har sagt att man ska skapa klasser/instanser för allt? Vad är det mest avancerade du har skrivit i C++ (eller något språk överhuvudtaget) ? Hello World? Fördelen med OOP märker man främst när man kodar större projekt, vilket du tydligen inte har någon som helst erfarenhet av. Men visst, koda allt i assembler om du vill, lycka till, det kommer du behöva.

På vilket sätt suger OOP i C++? Och på vilket sätt skulle OOP i Java vara bättre?

Nu är det ju så att OOP i C++ är lite av ett fulhack, mycket för att C++ skulle vara bakåtkompatibelt och lite andra saker. Kan faktiskt hålla med om att språk som Ruby och D ä bättre på det. Speciellt D är ju intressant då det faktist kompileras och blir i princip lika snabbt som C/C++.

Also, in b4 fullständigt utspårad tråd om hur mycket OOP suger och vilka språk som gör det bra/dåligt samt Java-bashing.

Vad för fel är det exakt på C++:s OOP modell? D, Ruby, Java, C# är alla mycket nyare språk än C++, så att dessa har lite "egenskaper" som inte finns i C++ är ju en självklarhet, men att säga C++ OOP modell är ett fulhack är ju bara larvigt.

Inte som om det är omöjligt även utan OO.

Tror han menar C++. Objective-C är ju OO i C done right.

Det är inte Objective-C jag tänker på, det verkar ju ännu krångligare med läskig syntax. Det stora problemet med C++ är att det man inte har suttit ner och tänkt igenom språket från början i sin helhet. Det började typ med C som dom la på klasser på. Sen fortsatte dom att lägga på nya saker och sen om en syntax som passade var upptagen så fick dom ta en annan osv. Om sen två saker inte gick att använda tillsammans så sa dom ungefär "Använd dom inte tillsammans då". Hela attityden är lika, "om du gör fel får du skylla dig själv", i stället för som i de andra nämnda språken som skyddar programmeraren lite. Ok nu gled jag iväg lite från oo men för att ta några exempel som är dåligt med C++s oo. Man måste skriva virtual på de funktioner som ska ha det. Det har inte riktiga interface, det har multipelt arv, man måste hålla på både med pekar- och värdesemantik när man håller på med klasser. Man kan inte initiera en variabel när man deklarerar den i en klass.

" Det stora problemet med C++ är att det man inte har suttit ner och tänkt igenom språket från början i sin helhet"

C++ har till skillnad ifrån många andra språk en standardkommitté, så ditt argument är bara löjligt. Man går igenom allt extremt noggrant innan en ny standard sätts.

* "om du gör fel får du skylla dig själv"
Vem ska man skylla på då? Ska man behöva göra språket idiotsäkert eller? C++ används i extremt komplexa system, där behövs det flexibilitet och prestanda.

* "Man måste skriva virtual på de funktioner som ska ha det"
På vilket är detta dåligt? Virtuella funktioner medför bland annat en prestanda förlust, så är väl ganska bra att programmeraren får avgöra om det behövs eller inte.

* "Det har inte riktiga interface"
Och? Skapa en rent virtuell klass och då har du en interface klass. Ser ingen anledning till att bloata ett språk med massor av onödiga nyckelord.

* "det har multipelt arv"
Och vad är det för fel på multipelt arv?

* " man måste hålla på både med pekar- och värdesemantik när man håller på med klasser"
Nej, man kan använda klasser på lika enkelt sätt som i Java, C# etc, skillnaden är att C++ möjliggör saker som andra språk inte gör.

Jepp, det insåg jag idag efter att jag blev tvungen att använda java efter ett års bojkott. Tack vare att ett bibliotek inte riktigt fungerade på skolans datorer men i Java så fanns motsvarande funktionalitet. De första 30 minuterna fick man ägna åt att skapa klasser och objekt. Wehooo fest :D:D:D:D

Objective-C är ju ett av de bättre objektorienterade språken, det har till och med dynamisk dispatch av meddelanden, så man kan göra massor av roliga saker.

Mina tankar på vad som gör c++ till ett sämre objektorienterat språk:
- Manuell länkning
C++ har väldigt strikta regler om hur du ska skriva saker för att länkaren ska förstå. Regler som är en kvarleva från svunna tider och som inte fyller någon funktion. Funktionsprototyper, fördefinitioner utav klasser och dylikt.
- Allt är värdetyper
Referenstyper går inte att deklarera utan man blir tvungen att använda pekare, som kräver egen syntax för behandling av något som borde vara transparant. Vilket också leder till nästa poäng.
- Ingen automatisk minneshantering
På grund av att den enda referenstypen innefattar pekare finns det inga svaga referenser således blir det omöjligt att ha automatisk minneshantering (aka garbagecollection) utan utökningar utav språket (se visual c++).

Punkt 1 och 2 finns det ingen anledning (performance wise) till att det måste vara på det sättet, det är en begränsning i språket som lever kvar från hur gammalt det är. Garbage collectors är inte alltid optimalt i alla förhållanden så det kan man klart förstå varför det inte används.

Sen så ska man inte säga att c++ är ett dåligt språk, det har många fördelar som bland annat portabilitet, en stor mängd välfungerande legacykod, bra prestanda (nu håller väl iofs JIT:ade managed språk på att bli snabbare än native kod så det är frågan hur länge det varar) och mycket liten overhead. STL har också gjort mycket för språket.

Vad har detta med en Objektorientering att göra? .. Just det, inte ett skit.

Har en kompis som älskar klasser och C#. Anledningen till att han gillar det är att han kan dela upp i flera filer och därmed öppna i olika flikar när han programmerar.

Själv tycker jag det är ologiskt att använda objektorientering till just programmering.

Det gör det JOBBIGARE att skriva objektorienterat, jag vet att det är fullt möjligt att skriva objektorienterat fortfarande men det är en smärta att hålla koll på.

Underbar tråd med underbar klarsynt start

Inte för att jag är något C++-fan, men att bygga applikationer i assembler - vilken tortyr! Assembler kan passa för att bygga riktigt hårdvarunära styrkod, men annars kastar man bara bort en massa tid på att återuppfinna det som finns i standardbibliotek i stort sett alla moderna språk - objektorienterade eller inte.

Förutom att ta lång tid så måste man dessutom vara bättre på att optimera assemblerkod än vad en kompilator är (nu finns väl visserligen verktyg för det i ASM också så jämförelsen är inte helt rättvis). Faktum kvarstår att även om gjort av expert är prestandavinsten klart försumbar i nästan alla fall.

Det är viktigare att ha en väldokumenterad, lättläst och återanvändbar kod än att spara några cykler i exekveringen.

Måste säga att ASM känns hopplöst dumt om man verkligen inte har expertkunskap och ändamålet synnerligen helgar medlena (hårdvara, extrem kodoptimering, etc).

Vad har det med objektorientering och göra?
Du gnäller på syntaxen men C++ ligger närmare processorn, det är inte lika abstraherat som en del andra språk. Men det är fullt möjligt (och också tanken) att abstrahera funktionalitet för att passa de typer av applikationer man skall göra.

Du kan bygga objekt i c++ som gör att du slipper deklarera typ (det är så andra språk hanterar det internt men någon annan har redan kodat det åt dig).

inte en chans

Men snälla nån du lyssnar ju inte ens. Jag klagar inte på syntaxen, den är okej men det finns ingen anledning till att kompilatorerna ska ha så strikta regler bortsett från legacy skäl. För att ge dig ett exempel tänk att du har två klasser , klass A och klass B, klass A har en funktion som kräver att den arbetear med klass B och klass B har en funktion som kräver att den arbetar med klass A. För att kunna göra detta måste du först deklarera de två klasserna med forward-declaration sedan deklarera dem normalt och sist göra funktionernas definitioner. Tre steg som kompilatorn borde hålla koll på själv, som inte har någonting med hur nära processorn c++ ligger utan hur kompilatorn arbetar.

Du måste även hålla koll på header guards och hur dina include statements ska arbeta för att inte ge kollision. Något som även det kompilatorn borde hålla koll på och inte ger någon skillnad i binären.

Sen angående managed kod och jit:ning kan jag ju upplysa dig om att det finns väldigt fina runtime optimeringar som som frameworken kan göra på programmen, bland annat för att hantera minnesfragmentering som ger enorm prestandavinst i vissa förhållanden.

Sen påstår jag fortfarande inte att c++ är ett dåligt språk. Jag påpekar bara de brister som c++ har.

Hur skulle du implementera sizeof operatorn i C++?

Mitt tips är att du tar och köper eller lånar Stroustrups bok "Design and Evolution of C++" och läser ut den innan du fäller fler "expertkommentarer" om C++ och vad kompilatorn borde ha koll på.

Genom att gå igenom alla medlemmar i datastrukturen och addera deras sizeof() + padding såklart.

Tyck vad du vill, men jag säger bara att det inte finns en enda vettig anledning till att jag ska behöva hålla koll på ordning och dylikt för mina klassdeklarationer själv. Om du nu vill påstå något annat kan du ju säga den anledningen istället för att säga åt mig att fördjupa mig i ämnet tills jag håller med dig.

Jag påstår fortfarande inte att c++ är ett dåligt språk, jag bara nämner saker som är problem i språket.

Det finns ett ord för det där och det är varje (mer professionell) programmerares mardröm, nämligen spagettikod. Lyckas man med spagetti med bara två objekt så är det imponerande illa.

Skall man sitta och leka ihop något program och aldrig mer göra mer än så då är givetvis C++ mindre smart val. Men skall du göra något mer proffsigt så är det i princip det enda valet.

En nybörjare kan tycka att regler är ett hinder, men samtidigt finns det en logik bakom alla regler samt att reglerna tvingar en till och tänka till. Det läggs stort ansvar på programmeraren och strukturera koden bra samt göra rätt. Skall man programmera bra objektorienterad kod så måste man tänka till ordentligt innan.

Det är många projekt som kraschat på grund av att programmerare inte haft tillräckliga kunskaper i C++ alternativt varit för dåliga så språket varit en för svårt att bemästra.

Angående snabbhet i C++ kontra andra språk. Man programmerar annorlunda i C++ jämfört med andra språk. I C++ gör man mycket mer själv, i andra språk handlar det mer om att leta funktionalitet i något gigantiskt bibliotek eller någon komponent som annan gjort. Givetvis finns det komponenter och kod i C++ med men det är liksom inte det första man söker efter om man skall göra något.

Menar du att detta skulle vara något bra? Best practice enl. mig är att först undersöka om någon redan löst ens problem och först om så inte är fallet att göra det själv. Peer-review är en betydligt bättre garant för stabilitet än att leka Rambo och tro att man gör allt bäst själv.

I synnerhet i verkligheten där brist på tid oftast innebär att det värsta med "Worse is Better" nästan alltid slår ut det bästa med "MIT approachen".

Två klasser som kan interagera med varandra är knappast "spaggetikod".
Och ja, jag vet nyttan utav god struktur men manuellt arbete med header guards, includes och arbete med ordningen på deklarationer är knappast något som bidrar till strukturen.

Det är klart det finns logik bakom reglerna det gör de alltid. Men knappast så bidrar de här reglerna till bättre strukturer. C++ är för övrigt ett ganska svagt typat språk jämfört med till exempel C# och Java, vars regler medför bättre strukturer och tydligare kod till skillnad från de här reglerna.

Och ännu en gång måste jag säga, jag klagar inte på c++ i helhet, jag klagar på just specifika saker i c++ som kunde ha varit bättre.
"Expert" är ju en fin titel som jag skulle kunna titulera mig med, men jag fördedrar en mer ödmjuk titel, insatt i ämnet.

Ja, när du får lite erfarenhet och kodat mot en del "komponenter" så kommer du märka att denna lösning som såg ut och spara så mycket tid i början tar väldigt mycket tid efter ett tag. Kunders önskemål kanske ändrar sig med tiden och då kan "komponenten" vara det som hindrar eftersom den ej har stöd för vad kunden önskar.

Konsulter kan säkert tycka det är smidigt och använda sig av färdigskriven kod men göra man mer generell programvara som flera kunder använder sig av så bör man tänka både en och fem gånger innan man plockar in något extra.

Lägg till en och alla tre interagerar med varandra så har du spagetti, två är kanske inte kan kallas för spagetti men man är inte långt borta.

Djupa arvshierarkier, objekt som har mer än en funktionalitet eller måste ha flera andra objekt som ligger längre ut på grenen för att fungera är exempel på lösningar där man måste tänka till för att se om det verkligen är nödvändigt.