Hejsan!
Jag undrar om det är mycket lättare att programera C# än C++. Jag har provat programmera i C++ och upptäckte att det var ganska svårt. Jag gick då över till VB som var betydligt enklare. Efter ett tag hörde jag att det kommit ett nytt programmeringsspråk som sägs vara lättare än C++ och att man kan göra precis samma saker som med C++. Jag undrar om detta är sant. Snälla, kan någon med erfarenhet på C++ som har övergått till C# svara.
Tack på förhand
MVH
Markus

Hej, C# är ett mkt enklare språk än C++ jag tänker inte räkna upp alla de saker som underlättar då det skulle ta en bra stund. C# är mer likt Java och typ lika enkelt som VB så fort man bara lärt sig dess struktur och syntax.
Helt klart värt att prova...

Dock är ju C++ mkt effektivare då det är snabbare än .Net språken, allt beror på vad det är du vill göra. Spel så är ju C++ än så länge bäst.

Mvh Johan

Hm... Du har ju c++ samt managed c++... :) "vanliga" c++ är ju det snabbaste, men managed c++ är det inte nå'n jättestor skillnad i hastighet mot resterande .net språk, även om det antagligen är marginellt snabbare... :)

Jo visst, men jag ser inte vitsen med att köra med managed c++ men det finns säkert några fördelar... Kodar inte själv i C++ då jag finner C# tillräckligt bra för de uppdrag jag utför. Mest Web apps.

Mvh Johan

C# är inte mycket enklare än C++. Det som skiljer dessa åt är att man inte använder pekar i C# (även om det går).

Den stora skillnaden som gör C# till enklare att programmera är .NET FrameWork. Det finns extremt enkla och kraftfula funktioner klara för många lösningar. Ta nätverkskommunikation med TCP. Det tar typ 10-20 rader kod att få upp en lösning som kan skicka meddelande mellan en klient och en server.

I C++ hade du behövt programmera mycket mer för samma funktionallitet. Men när du väl hade gjort det, så hade du haft din class färdig för att återanvändas. Vilket hade gjort att det hade varit lika enkelt.

Så skillnaden ligger inte så mycket i språket (även om skillnaderna finns) utan mer att .NET FrameWork gör livet enklare för dig och har mågna färdiga funktioner och rutiner. När sedan alla API har en motsvarighet .NET FrameWork så kommer livet bli mycket enklare, skall tydligen vara färdig när LongHorn kommer ut.

- M

Managed C++ lämpar sig bäst för server applikationer eller hybrid klasser där delar kommunicerar med unmamanged världen och andra delar kommunicerar med managed världen.

Ex en wrapper runt console API'erna för att från .NET kunna använda färger osv i Konsolfönstret. C++ unmanaged delen anropar och jobbar med API'erna och managed delen exponerar en klass som vi kan använda ifrån .net (__GC).

Där har vi de största vinstern. Kan tänka mig att tex vid spelprogrammering så vill man helst lägga tunga grafikrutiner i C++ unmanaged som du sedan exponerar ut mot en styr app i C# (Märk att jag inte pratar interop här utan en sömlös integration av de båda världarna)

Språkmässigt är det ju stor skillnad!
Det finns mycket mer likheter mellan Java och C# än mellan C++ och C#.
Det enda är att de syntaxmässigt påminner om varandra (som Qbasic och VB.NET ungefär... fast C++ och C# skiljer mer. De påminner om varandra, men det är fan inte samma språk!)

Mycket av det C# och Java saknar som C++ har, är sånt som de flesta C++-programmerare älskar. Tyvärr är mycket av det svårt att använda "på rätt sätt", och därför är det borta i C#/Java. Det är också en del saker som planeras (i båda språken), men varför de inte varit inkluderade innan vet jag inte.

Pekare, templates, funktionspekare, operatoröverlagring, multipelt arv, m.m. (hur är det med op-överlagring i C#? Jag vet att det inte finns i Java)

Sen finns det saker i C#/Java som skiljer sig från C++ på ett annat sätt. Ex: C++ gör inte skillnad på interfaces och klasser. Att inte göra en sån uppdelning har nackdelen att en nybörjare har svårare att förstå när klasser ska vara abstrakta och inte, men det är mer flexibelt när man vet hur det funkar.

Slutligen är det ju naturligtvis hur stort standardbibliotek det finns (jag pratar i C++-termer nu). C++ är designat för att kunna arbeta under nästan vilka förhållanden som helst, och kräver därför mycket lite av ett system - i sin "light-version" krävs det bara att ett system skall kunna använda tal, pekare och lite mer.
Ett steg till (det "vanliga" C++) är att det ska kunna finnas inmatning, utmatning, filhantering, och en del grejer till. Sen ingår en ganska diger uppsättning "container-klasser", som alltid kan fungera som en grund.

Vet man det förstår man att det inte kan finnas ett standardbibliotek som innehåller saker som grafik, ljud, fönsterhantering, osv. Detta måste istället enskilda bibliotek tillhandahålla. I C++ finns det alltså flera olika bibliotek. Flera olika för varje OS, samt ett antal icke systemberoende (som man har löst på olika sätt).

Där har Java och C# sina resp. frameworks, och båda har samma för- och nackdelar.
Grafiken finns inbyggd i språket, vilket gör grafiken systemoberoende. Det gör att man inte behöver leta efter bibliotek eller information om dem - det är samma överallt. Problemet är att frameworket drar kraft och är minneskrävande. Programmeringsspråken är inte heller lämpliga för någon form av programmering på låg nivå.

Sen skiljer sig Java och C# från C++ på sättet språken förändras. En förändring i C++ är något som skickas in till standardkommittén, analyseras noga i flera aspekt, och sen kanske, eventuellt accepteras i en ny version av språket. När det har blivit mycket förändringar så kan en ny version skapas. Det har hänt två gånger, om jag inte minns fel.

C# eller Java byggs snarare ut som ett program. "I nästa version kommer si och så"

Fördelen med att ha ett fast språk är att man kan återanvända kod i flera år utan några som helst problem. Nackdelen är att man inte kan implementera önskade detaljer.

Men slutsatsen blir att det på ett sätt är lättare att lära sig Java och C#, men att det samtidigt finns mer att lära sig på samma gång.
Förresten, angående "är lättare än C++, men kan göra samma saker": Det finns en del saker som absolut inte går att göra i C# men som man kan göra i C++. Men å andra sidan så gör man ju inte nya operativsystem varje dag precis.

Och slutligen angående exemplet med TCP. Behöver inte vara en enda rad mer kod i C++ än i C#. Beror på vilket bibliotek man använder.

Jo, operatorer kan man överlagra även i C#.
Men jag tycker att man måste skilja på C# som språk och .Net framework. Man kan ju faktiskt se C# som ett språk utan .Net framework precis som c++. Precis som man kan se c++ med .Net framework...

C# som språk utvecklas ju även det av nån kommittée nånstans. Däremot kan man ju se att väldigt mycket har blivit "lättare" med .Net framework. Men jag tycker att man skall jämföra rätt saker. Jag har ingen direkt erfarenhet av c++ men en nackdel som jag ser det är att uppstarten är lång, eftersom man måste skriva så mycket eget. Men när man väl har gjort det så är ju C++ kraftfullt. Vi använder både C#, Java och C/C++ beroende på syftet. T.ex. så använder vi c/c++ när vi skyfflar bitar på hårddisken och C# när vi gör grafiska gränsnitt. Varje språk har ju sina för/nackdelar och jag tycker att syftet måste styra...

Lite tankar...

<b>>C# som språk utvecklas ju även det av nån kommittée nånstans</b>
Det utvecklas väl av Microsoft?
Hur många uppdateringar av C# har kommit? Hur många år har det funnits?
Hur många uppdateringar av C++ har kommit? Hur många år har det funnits?
Titta på vilken typ av förändringar i språket som tillkommit i C++... Man lade till namespaces, gjorde ett enkelt namnbyte för standardbiblioteket så att man skulle kunna konvertera utan problem. Något säger mig att C# inte kommer utvecklas på det sättet.

<b>>Jag har ingen direkt erfarenhet av c++ men en nackdel som jag ser det är att uppstarten är lång, eftersom man måste skriva så mycket eget.</b>

Lite tvetydigt (tretydigt?) vad du menar med "uppstarten är lång". Menar du att man som person har en lång uppstart, att det tar lång tid att starta programmet eller att det tar lång tid att skriva i början?

Antar att du menar sista alternativet, och då handlar det om okunskap. C++ <b>bygger på</b> att man använder fristående bibliotek som passar för ändamålet.
Om man har det i åtanke undrar jag vad du menar med att man skulle behöva skriva mycket själv först.
Jag kan skriva en kod på 3 minuter i C++ som skapar ett fönster, ritar upp en fraktal och avslutas när man trycker på escape. Jag använder då ett fristående bibliotek som t.ex. libsdl. Mitt program kan jag sedan skicka till någon i en annan miljö (MAC, Windows, Linux, osv.), och denne någon kan kompilera det och köra det där utan några problem .

Jag behöver inte skriva mer "eget" än en enkel event-loop, och en uppritningsrutin, samt inkludera biblioteket. Vill jag inte ha en event-loop byter jag till QT, där jag får en event-teknik som nästan är identisk med den som finns i t.ex. VB.

Det jag menar är bara att folk som inte programmerar C++ ofta får missuppfattningar om vilka krav som ställs på programmeraren. Man behöver inte göra fundamentalt olika saker i C++ än i något annat programmeringsspråk, det är bara det att det finns så mycket mer saker man KAN göra, så att det är svårt att få en överblick.

Oavsett så faller argumentet med att man "måste göra mer själv" på det du säger innan:
<b>>Men jag tycker att man måste skilja på C# som språk och .Net framework. Man kan ju faktiskt se C# som ett språk utan .Net framework precis som c++. Precis som man kan se c++ med .Net framework...</b>


PS.
Missförstå mig inte nu, även om jag själv inte gillar C# speciellt mycket respekterar jag att ni gör det. Det är bara det att om man säger felaktiga grejer om hur C++ är så blir det ingen rättvis bedömning.

Precis som både C++ och Java så sitter absolut individuella företag och kommer på förändringar, men precis som C++ är C# en standard hos ECMA och ISO (faktiskt även CLI och CTS också). Det innebär att MS inte kan ändra i språket hur de vill de kan utveckla en variant och sedan lägga fram ändringarna som förslag hos ECMA och ISO.

Säg dessutom vad du vill om inlärningströskeln för C++, den är mycket högre än för java/c# eller VB. Dessutom, och det skulle vara intressant om du kunde motivera motsatsen, så är MFC, ATL och andra standardbibliotek för C++ inte i närheten så kompletta, genomarbetade eller enkla att sätta igång med som Java klasserna eller .net frameworks basklass bibliotek.

Jag tror snarare att du har så mycket kunskap och erfarenhet i C++ att du inte objektivt ser de problem och svårigheter språket har. Även erfarna C++ programmerare hos Microsoft går gradvis över till C# för att utveckla en hel del. (Kolla tex på fönsterhanteringen i Avalon (Longhorn)).

C++ lämpar sig bäst för opertivssystemsnära tillämpningar, där kan man inte tävla på något sätt, men C# är minst lika kraftfullt och har dessutom lägre inlärningströskel och högre RAD (Rapid Application Development) faktor än vad C++ har för fönster applikationer, webbplatser och andra standard applikationer ute hos företagen.

Jag har själv gjort mina otaliga timmar i C++ med MFC och ATL, jag tycker .net är en gudagåva för ovanstående scenarion, även om jag kompletterar med lite managed c++ / unmanaged c++ när jag vill göra något nära windows i vissa scenarion.

btw --
Pekare: Finns i C# om man vill ha dem, dessutom så har GC'n större koll på att du använder dem på rätt sätt.
Templates: Kommer som Generics i nästa version av språket.
Funktionspekare: Finns i .NET, är klasser och kallas delegater.
Operatoröverlagring: Funkar fin fint i C#
Multipelt arv: Känns fruktansvärt overkill och under alla mina OOP lektioner så har vi knappt rört scenarion där det faktiskt finns en vettig anledning att använda dem.

Fowler tex, som är fruktansvärt stor i OOP världen, hävdar att om man ofta behöver multipla arv, då har man inte förstått arv eller så har man designat sin klasshieraki väldigt galet.

Självklart finns det scenarion då det är enda lösningen men då kan du istället multipelt ärva in ett antal interface och jobba runt det den vägen.

Dessutom finns ingen funktionalitet "inbyggt" i språket. Allt ligger i klasserna du anvädner dig av och blir på det sättet extremt objektorienterat. Exempelvis så är funktionen för att göra småbokstäver av en sträng, en instans medlem på sträng klassen:

<code>
string s = "My World or Your world, doesn't really matter";
string sLowerCase = s.ToLower();
string sUpperCase = s.ToUpper();

Console.WriteLine("Original string: {0} \nLower case: {1}\nUpper case: {1}\n", s, sLowerCase, sUpperCase);

</code>

Dessutom kan du mycket väl dra en applikation skriven och kompilerad på windows in i en linux miljö och låta den exekvera så länge, precis som för c++, klassbiblioteken du använt finns på den plattformen också. (Mono är en sådan implementation)

här har du dessutom en implementation av consol klassen skriven i C# som jobbar med vanliga API'er, ngt som annars är C++ starka sida på Win plattformen.
http://www.cshrp.net/content.aspx?showID=902

Ja, jag tvivlade inte på att C# är en standard hos sådana komittéer, men man kommer ju inte ifrån att förändringarna ligger på syntax-nivå i väldigt mycket högre grad än för C++, och har fler på kort tid. Förhoppningsvis för er del så är det väl bara barnsjukdomar, ett språk som förändras hela tiden är omöjligt att arbeta i.

<b>>Säg dessutom vad du vill om inlärningströskeln för C++, den är mycket högre än för java/c# eller VB.</b>
Om vi tar och delar upp det i "programmeringsspråk i allmänhet" och "specifikt för språk", först, så blir det lite mer rättvisande. Att lära sig sekventiell programmering, rekursion, objektorientering, modularitet eller något annat generellt kan väl ta sin tid, det är ju inget konstigt med det. Men det är ju inget som är speciellt för något språk.

Att applicera en paradigm eller ett begrepp på ett specifikt språk är ju inte svårt om man kan begreppet tillräckligt bra, och om man förstår språkets syntax.
Syntaxen i C är otroligt lätt, och det viktigaste i C++ är inte speciellt mycket mer. I jämförelse med t.ex. Java och C# så tror jag det är färre nyckelord i C++.
Du nämmnde också VB som exempel. Om du menar VB != NET, så är ju VBs syntax otroligt mycket krångligare, massvis med saker inbyggda i språket osv.

När man kommer till specialsaker (typ mutable i C++), så är det klart att det tar tid att lära sig vad det är och vad det har för nytta, men det räknar inte jag som del av inlärningströskeln. Jag antar att det finns liknande grejer i C#, och vet att det finns i Java.

Sen är det ju ett väldigt "fritt" språk, så programmerar man enbart med inbyggda typer så är det (precis som jag har sagt) svårt att skriva hållbar kod. Håller man sig i skinnet och gör som alla säger - använder inbyggda behållare, använder referenser istället för pekare, osv., så bör man inte stöta på problem.

Kvar är alltså standardbibliotek.
<b>>Dessutom, och det skulle vara intressant om du kunde motivera motsatsen, så är MFC, ATL och andra standardbibliotek för C++ inte i närheten så kompletta, genomarbetade eller enkla att sätta igång med som Java klasserna eller .net frameworks basklass bibliotek. </b>
Det verkar till att börja med som att vi har olika defintion på standardbibliotek. Det jag menar är det man pratar om när man säger "standardbiblioteket" i C++ (kallades förut för "STL"). Det finns inte flera standardbibliotek, det finns ett. Det motsvaras av frameworket i .net, och av alla javas inbyggda klasser.

Detta är ganska "simpelt" i C++, och innehåller inte grafik osv. Standardbiblioteket är dock oerhört komplett, genomarbetat och enkelt att använda. Hur effektivt det är hänger på kompilatorn, men det slår oftast det mesta man kan skriva själv.

Du nämner sedan MFC och ATL. Det är två bibliotek, men de är inte på något sätt standard. Det är (väl?) Microsofts kreationer, och även om jag inte använt ATL så är jag böjd att hålla med dig om MFC, det är inte speciellt trevligt att arbeta med. Men jag har inte ens nämnt MFC...
Jag använder bibliotek som dels är systemoberoende, dels väldigt enkla att arbeta med. _DE_ biblioteken är ofta mycket "kompletta, genomarbetade och enkla att sätta igång med".

<b>>Jag tror snarare att du har så mycket kunskap och erfarenhet i C++ att du inte objektivt ser de problem och svårigheter språket har.</b>
Njaaee... det är nog att ta i. Om man inte _börjar_ i C++ så är det inte svårt. Själv lärde jag mig i hela C-syntaxen och konstruktionerna och de vanligaste funktionerna på en dag, men det kunde jag eftersom jag hade programmerat Basic innan.

<b>>och högre RAD </b>
Då rekommenderar jag att du tar dig en titt på QT, www.trolltech.com.
Där får man med en "QT Designer", som är precis lika lätt att arbeta med som VBs IDE.
Samma uppbyggnad som Java, men man ritar ut allt själv.

Men som sagt: jag dömer inte ut C# osv. Jag försvarar bara C++ - det håller än, och kommer hålla länge till.

Och för att svara på ditt andra inlägg:
1. Att konstruktionerna ingår är som jag ser det varken bra eller dåligt. Det du säger är att C# har fler konstruktioner, vilket betyder att det är svårare att lära sig. Det är en av stora skillnader mellan C++ och Java, som gör att nybörjare har mycket lättare för Java, men en van C++-programmerare saknar element i språket.

2. Jag har inte påstått att C#-program inte går att köra på Linux, det jag säger är att C++ kan det utan några som helst problem och att C# inte har mycket som C++ saknar.

Jag har setat i VB, .Net (vb.net), C++ samt lite Java ett tag nu.
Mina reflektioner är följande:

Oavsett språkets egna styrka så är det biblioteken man ska använda som kontrollerar inlärningströskeln till 100% om man redan fattar koncepten.
Bibliotekens dokumentation är avgörande för ovanstånde påstående (och dokumentationen för VB samt .Net är överlägsen).
Miljön man utvecklar i är också en stor faktor som påverkar hur svårt språket är, i Borland C++ Builder går det mesta lika fort att göra som i .Net och/eller VB6 medan VC++ är trögjobbad för grafiska tillämpningar.
Språken är olika frusterande att arbeta i också (gäller framför allt VB6 jämfört med övriga) på grund av byggtider och enkelheten att göra löjliga misstag i förhållande till byggtiderna (missa ett ; i C++ t.ex.).
En annan faktor som styr hur svårt språket är att lära sig är faktiskt debug-möjligheterna, att debugga i VB6 är som dom säger en breeze jämfört med att debugga i t.ex. C++ (även om möjligheterna inte är dåliga).

Kort sagt, personligen har jag svårt för pekarhanteringen i c++ även om jag förstår dess poänger, jag har svårt för minnesallokering och deallokering men det beror på lathet.

Jag har setat i VB, .Net (vb.net), C++ samt lite Java ett tag nu.
Mina reflektioner är följande:

Oavsett språkets egna styrka så är det biblioteken man ska använda som kontrollerar inlärningströskeln till 100% om man redan fattar koncepten.
Bibliotekens dokumentation är avgörande för ovanstånde påstående (och dokumentationen för VB samt .Net är överlägsen).
Miljön man utvecklar i är också en stor faktor som påverkar hur svårt språket är, i Borland C++ Builder går det mesta lika fort att göra som i .Net och/eller VB6 medan VC++ är trögjobbad för grafiska tillämpningar.
Språken är olika frusterande att arbeta i också (gäller framför allt VB6 jämfört med övriga) på grund av byggtider och enkelheten att göra löjliga misstag i förhållande till byggtiderna (missa ett ; i C++ t.ex.).
En annan faktor som styr hur svårt språket är att lära sig är faktiskt debug-möjligheterna, att debugga i VB6 är som dom säger en breeze jämfört med att debugga i t.ex. C++ (även om möjligheterna inte är dåliga).

Kort sagt, personligen har jag svårt för pekarhanteringen i c++ även om jag förstår dess poänger, jag har svårt för minnesallokering och deallokering men det beror på lathet.

Jag tycker man ska programmera sina program i lite olika språk. T.ex. så kan du skriva helt vanlig C++-kod, använda det i C#. Du kan också använda Java i C# (mer eller mindre krångligt iofs). Jag vet inte om jag har rätt i att det är en bra lösning men ett praktiskt exempel är att skriva en ljudapplikation i Java. Java har ett otroligt bra ljudbibliotek javax.sound (åtminstone om du frågar mig) både för sampled och midi. Med mixrar, lines osv. Men fy vad trögt det är med GUI i Java. Jag talar inte av erfarenhet när jag säger att C++ är mycket bra när man vill ha ett högpresterande GUI, men jag tror att det är så. Så varför inte skriva en "ljudklass" i java. Sedan använda JNI för att "översätta" klassen till C++. För att tillslut skriva sin ljudapplikation i C++.

Jag har alltid varit av den uppfattningen när det gäller språk vs. språk, att det handlar helt om vad man ska göra. C++ _är_ bättre än VB...på ett sätt. Men oj vad enkelt det är att programmera i VB, där _är_ VB bättre än C++.

Det jag har sett av C# har jag blivit imponerad av. Men jag har förstått att det inte är så väldigt snabbt.

/Jörgen

<b>>Oavsett språkets egna styrka så är det biblioteken man ska använda som kontrollerar inlärningströskeln till 100% om man redan fattar koncepten.</b>
Just det, eller kanske 90%. Att förstå grundkoncept för varje programmeringsstil är i sig inget som har att göra med språket. Det är biblioteken, och vissa special-grejer.

<b>>Bibliotekens dokumentation är avgörande för ovanstånde påstående (och dokumentationen för VB samt .Net är överlägsen).</b>
Skulle inte C++ ha en bra dokumentation?
Tror ärligt talat det inte existerar ett språk med en mer ingående dokumentation.

<b>>Miljön man utvecklar i är också en stor faktor som påverkar hur svårt språket är, i Borland C++ Builder går det mesta lika fort att göra som i .Net och/eller VB6 medan VC++ är trögjobbad för grafiska tillämpningar.</b>
Det där påstår folk ibland, och jag kan inte förstå varför... allt hänger på bibliotek, och om man bara ser till att använda rätt så är det inte mer trögt i C++ än i något annat språk. VC++ med Qt Designer är nästan identiskt med Borland Builder eller VB6.

Det verkar som om folk här inte riktigt hajar hur det är tänkt att man ska programmera i C++... en stor del av tiden går åt till att hitta och lära sig bibliotek. Det man gör sen är att man sammanfogar olika bibliotek på olika sätt, osv. När man väl kan ett bibliotek så tar det inte längre tid att använda än VB6, t.ex.

<b>>En annan faktor som styr hur svårt språket är att lära sig är faktiskt debug-möjligheterna, att debugga i VB6 är som dom säger en breeze jämfört med att debugga i t.ex. C++ (även om möjligheterna inte är dåliga).</b>
Det har iofs att göra med IDEt, och det finns både fria programvaror för debugging, och inbyggda i IDEn. Själv tycker jag inte det har varit krångligt nån gång; när man väl lärt sig de två grundläggande delarna (breakpoint och watch) så klarar man sig utan problem.

> Just det, eller kanske 90%. Att förstå grundkoncept för varje programmeringsstil är i
> sig inget som har att göra med språket. Det är biblioteken, och vissa special-grejer.

Det köper jag utan problem.

> Skulle inte C++ ha en bra dokumentation?
> Tror ärligt talat det inte existerar ett språk med en mer ingående dokumentation.

Miljöerna som jag jobbat i har haft en dålig dokumentation om medföljande api'er t.ex. Dokumentationen som MS står fär är tydlig och lättsökt, även om det kanske inte direkt berör språket utan snarare miljön så påverkar det inlärningströskeln väldigt mycket.

> Det där påstår folk ibland, och jag kan inte förstå varför... allt hänger på bibliotek,
> och om man bara ser till att använda rätt så är det inte mer trögt i C++ än i något
> annat språk. VC++ med Qt Designer är nästan identiskt med Borland Builder eller
> VB6.

Det må så vara att precis QT-Designer är mycket likt Borland och / eller VB6 men då måste man ha prövat det... (ska testa det)

> Det verkar som om folk här inte riktigt hajar hur det är tänkt att man ska
> programmera i C++... en stor del av tiden går åt till att hitta och lära sig bibliotek.
> Det man gör sen är att man sammanfogar olika bibliotek på olika sätt, osv. När
> man väl kan ett bibliotek så tar det inte längre tid att använda än VB6, t.ex.

Precis, hitta och lära sig bibliotek med olika nivåer på supporten, otillförlitliga tillverkare osv. Rent principiellt håller jag med dig men praktiskt så känns det alltför ofta ogenomförbart, jämfört med t.ex. .Net som har ett komplett väldokumenterat klassbibliotek även om det känns lite klumpligt ibland.

> Det har iofs att göra med IDEt, och det finns både fria programvaror för debugging,
> och inbyggda i IDEn. Själv tycker jag inte det har varit krångligt nån gång; när man
> väl lärt sig de två grundläggande delarna (breakpoint och watch) så klarar man sig
> utan problem.

Sant, men ta bara en sådan sak som att kompilatorn släpper igenom illegal memoryaccess (hände mig igår) vid ett rent kodfel. Sen om jämför IDE'n så kan ingen seriöst påstå att VB6-miljön inte är överlägsen då koden är redigeringsbar (och förändringarna slår igenom) i debug-time.

Vi är rätt överens om var skillnaderna ligger men ligger rätt långt från varandra i hur allvarliga de är tror jag...

Qt: www.trolltech.com
Grejen är att vi måste ju skilja på språket med dess standardbibliotek och övriga bibliotek. C++ som språk är mycket väldokumenterat, men enskilda bibliotek får man ju behandla för sig. Diskussionen går ju mellan språken och inte kringliggande bibliotek.

Vissa bibliotek är naturligtvis dåligt dokumenterade, men det är ju det det handlar om - att välja rätt bibliotek!


Och angående debuggingen: Det är ju i allra högsta grad beroende på i vilken miljö man sitter... Vad jag vet så klarar t.ex. VC++ ändringar i koden under debuggingen.
Det är ju också en sak man måste skilja på: Språk och utvecklingsmiljö. Diskussionen ligger ju som sagt om språken.
Utvecklingsmiljö väljer man efter vad man tycker passar bäst, samma sak med bibliotek. Om det är svårt att utveckla i C++ då så beror det på att man har gjort ett dåligt val, men det kan man byta. Språket är inte svårt för det.