[ALG] Blijven bij C++ of overstappen naar C#?

[hneel]

Ik ben pas geleden bij een nieuw bedrijf begonnen en ik mag nu een nieuw ontwikkelpakket uitzoeken. Bij mijn vorige bedrijf werkte ik met Borland C++ Builder (versie 5). In eerste instantie wilde ik hier weer hetzelfde pakket bestellen (versie 2007 dan). Maar dit is misschien een goed moment om eens na te denken of ik niet beter over kan stappen op nieuwere programmeertalen. Bijvoorbeeld C#. Of eventueel Java?

Het werk wat ik doe is vooral technisch van aard. Een belangrijk aspect is communicatie via de seriele poort. Onder C++ was dit aanvankelijk erg complex om dit goed te laten werken, maar dat heb ik inmiddels onder de knie. Kan dit onder C# niet zo makkelijk? Werken met threads, aansturen van hardware, enz. Kan dat nog gewoon allemaal? Het is toch hoop ik niet zo dat C# meer op andere toepassingen toegesneden is?

Argumenten om over te stappen: in de nieuwere talen is vziw een hoop afgeschermd waardoor veel voorkomende fouten zoals met bv verkeerd gebruik van pointers, voorkomen wordt. Voor de rest ben ik me er nog een beetje in aan het verdiepen, maar die nieuwe talen zijn natuurlijk niet voor niets ontwikkeld, lijkt me. Een ander argument: gewoon meegaan met mijn tijd. Als ik over een x aantal jaren nog eens een andere baan zou willen zoeken kan de ervaring handig zijn. Het valt me op dat het nu al in advertenties een en al .NET en Java/j2ee is wat de klok slaat. Al ligt dat natuurlijk ook aan het terrein waarop gewerkt wordt. Of je bv administratieve programma's maakt, of web applicaties of hardware-geoirienteerde software kan nog wel verschil maken.

[Alarmnummer]

Waarom zou het een volledige overstap moeten worden? Meerdere talen/platformen leren kan sowieso nooit kwaad. Ik heb in het verleden veel met Prolog gedaan en die kennis is bv onder Java (dat al tijden mijn main language is) erg handig. Verder doe ik nu zo nu en dan wat Groovy en Ruby. Ruby omdat er GTK bindings zijn (dus leuk om linux applicaties in elkaar te hakken) en omdat je zo nu en dan eens nieuwe ideeen moet kunnen opdoen. Dan realiseer je dat sommige oplossingen gewoon ruck zijn omdat de taal/platform achterhaald is... of dat sommige oplossingen in 1e instantie leuk zijn, maar na een tijdje worden ze te duur (dus complex, niet onderhoudbaar etc). Op die manier kun je dingen veel beter relativeren en dat maakt je een stuk rijker.

Het kan trouwens geen kwaad voor je salaris om wat .NET/Java kennis te hebben aangezien dit wel de platformen zijn waar de meeste banen in te vinden zijn (zoals je zelf al aangaf). Voor integratie met hardware is c/c++ uiteraard nog steeds de taal bij voorkeur.

[.oisyn]

Je zou in eerste instantie natuurlijk eens naar C++/CLI kunnen kijken. Dan kun je voor het .Net platform ontwikkelen, terwijl je toch bij C++ blijft en daar makkelijk op terug kunt vallen voor bijv. legacy code of idd het aansturen van hardware (C++ code en C++/CLI code kan in principe gewoon gemixed worden).

[mOrPhie]

Heel concreet is het wellicht een idee om dit even door te lezen:

http://www.codeproject.com/csharp/SerialCommunication.asp

Seriele poort communicatie zit tegenwoordig in het .NET Framework (in 1.0 zat dat nog niet). Threads zit ook in het framework. Aansturen van hardware is natuurlijk een ruim begrip. Hoe bedoel je dit?

[farlane]

.Net (en waarschijnlijk ook de standaard Java versie maar daarmee heb ik geen ervaring ) is een no go als je low level software schrijft. Je hebt te weining controle over timing, geheugenbeheer en dat soort dingen.

Een combinatie van de twee is eigenlijk de beste situatie: gebruik C/C++ voor de tijd/geheugen kritische dingen en bijvoorbeeld Java/.Net voor bijvoorbeeld de UI/data access.

Verder kan ik me alleen maar aansluiten bij Alrmnummer, een programmeur kan alleen maar zijn voordeel doen met goede kennis van meerdere talen. De kennis die je daarbij opdoet kun je vaak veel breder toepassen dan die ene taal waar je mee bezig bent.

Verder zou ik je willen aanraden om voor die serieele poort ook zo zachtjes aan een alternatief te vinden, als je zelf/je bedrijf beslissingen kan maken over de hardware. Dit omdat het inmiddels behoorlijk legacy begint te worden.

Ik wil zelf eigenlijk meer naar een (industrieel) ethernet communicatie zoals bijvoorbeeld http://www.ethernet-powerlink.org/

[Niemand_Anders]

Is het bedrijf zelf ook nieuw of ben alleen jij nieuw? Dan maakt nogal een verschil. Als het bedrijf al langer bestaat lijkt mij dat er al eerder code geschreven is voor de aansturing van hardware via de seriele port. Tegenwoordig hebben volgens mij alle talen wel support voor aansturing van de seriele port.

Zoals enkele andere al hebben aangegeven denk ik dat Visual Studio Professional een zeer goede keuze zal zijn. Dan heb je direct support voor C#, C++ en C++/CLI. In c++ kun je dan de directe aansturing van de hardware doen en andere programmeurs kunnen dan vanuit elke .NET taal jouw 'wrapper' aanspreken.

Helaas is dit eigenlijk een slecht moment om Visual Studio aan te schaffen omdat ik februari 2008 namelijk VS2008 uitkomt. Maar je kunt momenteel natuurlijk ook VS2008 Beta 2 downloaden en daarin eens goed rondkijken. Noteer voor je zelf of jij in VS de handigheidjes uit Borland Studio kan terug vinden, maar vergeet zeker niet te kijken welke talen de rest van je team of het bedrijf al gewend is. .NET ondersteuning zal als grote voordeel hebben dat vrijwel iedereen aan de slag zal kunnen gaan met programmeren. Zelfs een beginnende programmeur kan starten met VB.NET. Veel van deze programmeurs gaan later over op c#. Maar vanwege de zeer expliciete schrijfwijze is VB erg eenvoudig te leren. Je programmeurs zullen uiteindelijk dus evolueren. Als ze c# goed onder de knie hebben zou je zelfs enkele van die programmeurs kunnen inwijden in de wereld van C++/CLI. Dat bied al meer vrijheden dan C#, maar heeft nog wel carbage collection (resource management) en buffer overflow beschermingen. En uiteindelijk kan zo'n programmeur ook in native c++ gaan programmeren.

Op die manier kun je elke programmeur de uitdagingen geven waar hij (zij) de tanden kan inzetten. Iedereen groeit door en uiteindelijk zul je steeds meer programmeurs krijgen welke je op alle fronten kunt inzetten.

Hoewel .NET steeds verder in Windows wordt geintregreerd, is nog steeds het overgrote deel van de libraries alleen via C(++) te benaderen. Die brengen wij dan zelf naar het .NET platform zodat andere programmeurs ermee aan de slag kunnen. Ik ben zelf erg tevreden over Visual Studio en de mogelijkheden het mij geeft, maar ook hoe eenvoudig beginnende programmeurs kunnen beginnen.

[hneel]

De seriele poort is cruciaal. Verder is er eigenlijk weinig directe hardware aansturing nodig. In het kort komt het er op neer dat ik moet kunnen communiceren met bestaande microcontroller systemen. Daar omheen kan dan allerlei extra functionaliteit worden gebouwd, maar dat zijn eigenlijk alleen standaard technieken. De standaard GUI dingen, af en toe een timertje, wat standaard file I/O, enz.

Dus als ik de seriele poort aan de praat kan krijgen zit ik in principe goed, denk ik.

[mOrPhie]

Dan heb je, zover ik nu kan overzien, qua technische haalbaarheid gezien gewoon een "Go" met C#.

[.oisyn]

Dan zou ik gewoon een C++ communicatie-implementatie maken met een C++/CLI schil eromheen zodat je het makkelijk vanuit elke .Net taal aan kunt spreken.

[voodooless]

Wij hebben hier zowel in C# als in Java seriele poort apps gemaakt, en dat werkt eigenlijk gewoon prima . Let wel erop dat als je platform onafhankelijkheid wil, je met C# in dit geval niet uit de voeten kan, want mono heeft (nog) geen serial port api implementatie.

[flowerp]

hneel schreef op dinsdag 16 oktober 2007 @ 12:01:
maar die nieuwe talen zijn natuurlijk niet voor niets ontwikkeld, lijkt me.

Eigenlijk is de eerste versie van Java (begin 96) ouder dan de eerste echte officiele (gestandaardiseerde) versie van C++ (ergens in 98). Maar Java is sindsdien natuurlijk steeds uitgebreid (zowel qua language als qua std library), terwijl C++ sindsdien nagenoeg stil heeft gestaan. Voor de eerste officiele C++ standaard kwamen er wel telkens features bij (zoals templates, het boolean type, de // comment, virtual functions etc). C++ in haar diverse incarnaties is natuurlijk wel ouder, van halverwege jaren 80.

Er wordt tevens nog de mogelijkheid opengehouden dat er ooit nog eens een nieuwe versie van C++ komt; met als hoopvolle codenaam C++0x. Voor deze nieuwe versie is al flink wat werk verzet, dus misschien gaat het er inderdaad nog eens echt van komen. Of er tegen die tijd nog echt veel mensen op zitten te wachten is natuurlijk wel de vraag. (Mede) vanwege het uitblijven van zichtbare veranderingen aan de taal zie ik hele hordes mensen die vroeger allemaal C++ deden steeds meer overstappen naar andere platformen. Je geeft dit argument zelf ook al een beetje aan.

En zelf -als- C++0x inderdaad nog dit decennium uitkomt, dan kan het nog wel 10 jaar duren voordat er ook echt compilers zijn die de standaard voor 99% implementeren [sarcasme[ (C++ wordt altijd zo gespecificeerd dat eigenlijk geen enkele compiler binnen afzienbare tijd 100% aan de standaard kan voldoen). [/sarcasme]

[.oisyn]

flowerp schreef op dinsdag 16 oktober 2007 @ 23:19:
En zelf -als- C++0x inderdaad nog dit decennium uitkomt

WG21 volgende ben ik daarvan overtuigd

dan kan het nog wel 10 jaar duren voordat er ook echt compilers zijn die de standaard voor 99% implementeren [sarcasme[ (C++ wordt altijd zo gespecificeerd dat eigenlijk geen enkele compiler binnen afzienbare tijd 100% aan de standaard kan voldoen). [/sarcasme]

Da's een beetje onder de gordel . Vroeger was standard compliance een stuk minder belangrijk dan tegenwoordig. Ik denk voornamelijk door een idealistisch ingestelde generatie die nu volop in de banenmarkt zit, terwijl het er vroeger toch veel pragmatischer aan toeging. Bovendien voelen de compilerbouwers van nu steeds meer de hete adem van de concurrentie in de nek.

Anyway, de grootste fout in C++98 is export, maar indertijd stond de ontwikkeling van C++ verder af van de compilerbouwers dan nu. Zo wordt er nu meteen een implementatie van features geschreven, zodat er gekeken kan worden hoe haalbaar een feature is, hoe hij in de praktijk uitpakt en hoe de regels verbeterd kunnen worden. Zo biedt ConceptGCC al een hoop ground breaking changes van C++0x, zoals r-value references, variadic templates en natuurlijk concepts (en kleinere features als auto/decltype, range-based for iteration, etc.).

De mensen van het C++ standards committee zijn zich terdege bewust van de terechte punten die je aanhaalt, en dat er nu echt iets moet gebeuren aan de taal om het weer populair te maken. Dit vertaalt zich dan oa weer naar een threading library, een goedgedefinieerd memory en concurrency model, de optionele mogelijkheid voor garbage collection en natuurlijk modules om nu maar eens een einde te maken aan die irritante header files en de langzame compiletijden die daaruit voortkomen.

[ Voor 14% gewijzigd door .oisyn op 16-10-2007 23:47 ]

[roy-t]

Threads zijn errrg makkelijk in C# (zelfs ik snap het )

Serial poorten dacht ik ook (dunno gebruik ze nooit)

En tsja verder heb je het fijne Visual Studio (maarja ik weet niet of je "office' applicaties ontwikkeld, zoniet dan is dat wat minder waard, maar ook de intellisense e.d. van VS zijn erg fijn (een van mijn grootste anti-java argumenten, of nouja eigenlijk mijn enige is dat de ontwikkelprogramma's niet zo fijn zijn)

Maargoed ik geloof niet dat je Java uberhaupt overwoog.

Zelf heb ik geen kennis van C++, behalve dan dat het een vrij oude taal is. Dus ja, C# is hardstikke nieuw up-to date en fijn met threads (en zo te lezen ook met serial poorten)

nadeeltje: .Net nodig (is normaal geen nadeel maar misschien wel voor oude apperatuur waar nog even een C++ programmatje op moet draaien)

Verder is Oisyn' idee natuurlijk ook het overwegen waard, hoewel dat een beetje halve weg is. Zelf zou ik liever 'echt' voor iets kiezen ipv alles door elkaar heen.

[hneel]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
nadeeltje: .Net nodig (is normaal geen nadeel maar misschien wel voor oude apperatuur waar nog even een C++ programmatje op moet draaien)

Hmm, dit kan inderdaad nog wel een praktisch probleempje worden. We werken hier nog veel met oude win9x laptopjes, en de software moet daar wel (vlot) op draaien.

[Janoz]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
En tsja verder heb je het fijne Visual Studio (maarja ik weet niet of je "office' applicaties ontwikkeld, zoniet dan is dat wat minder waard, maar ook de intellisense e.d. van VS zijn erg fijn (een van mijn grootste anti-java argumenten, of nouja eigenlijk mijn enige is dat de ontwikkelprogramma's niet zo fijn zijn)

Grappig dat je dat zegt . Over het algemeen loopt Visual Studio behoorlijk achteraan mbt features. Het enige voordeel dat VS heeft is dat het out of the box goed integreerd met andere MS software (ISS, Office, SourceSafe en Sharepoint ed). Als dit je enige argument is zou ik als ik jou was maar niet naar Intellij gaan kijken aangezien je dan waarschijnlijk een nieuwe taal meot leren ... Maar goed, om dit maar niet teveel op te rakelen toch maar ff op de topicstart reageren.

De beste oplossing lijkt me inderdaad .oisyns voorstel. Schrijf als het ware een 'driver' in C++ die je vervolgens in elke .net taal kunt aanspreken.

[farlane]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
Verder is Oisyn' idee natuurlijk ook het overwegen waard, hoewel dat een beetje halve weg is. Zelf zou ik liever 'echt' voor iets kiezen ipv alles door elkaar heen.

Op die manier gebruik je de right tool voor de right job.

[flowerp]

farlane schreef op woensdag 17 oktober 2007 @ 13:02:
[...]
Op die manier gebruik je de right tool voor de right job.

.oisyn's idee is denk ik inderdaad een goed idee. Het is ook absoluut niet 'raar' ofzo en zelfs wel logisch. Veel systemen maken gebruik van een hardware driver die in b.v. C of zelfs assembly is geschreven, maar natuurlijk ga je niet de GUI in assembly schrijven en alleen de echte diehards maken hun GUI volledig in C (of het groepje fanatieke Linux aanhangers natuurlijk die in het "objects are evil" verhaal mee gaan, maar laten we die even buiten beschouwing houden)/

Ook in b.v. de web wereld zie je al rustig zo'n 9(!) talen door elkaar gebruikt worden: java voor de backend en business logic, SQL om met de DB te praten, reguliere expressies om patronen te matchen, taglibs en expression language om de GUI en de bindings naar je code
te definiëren, diverse XML dialecten voor de configuratie, her en der wat directe HTML voor dingen die je components niet lekker doen, natuurlijk bind je ook nog stukjes javascript voor client-side behaviours en, hoe kan ik het niet als eerste noemen, voor AJAX. Last but not least voorzien we onze components nog van een mooie styling via de taal CSS.

C++/CLI voor de lowend stuff en C# voor de GUI vind ik dan nog een hele magere diversiteit aan talen

[H!GHGuY]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
Threads zijn errrg makkelijk in C# (zelfs ik snap het )

Ik wou onlangs terug beginnen met C# en wou messaging based threading gebruiken.
Geen locking, maar function-calls waar nodig omzetten in messages die dan in de juiste thread afgehandeld worden. Met andere woorden: InvokeRequired en Invoke.

Ik vroeg me echt af waarom een high-level taal als C# dit nog niet in de library heeft.
De System.Windows.Forms heeft dit wel, maar daar ben ik niet veel mee voor een console app.

Bovendien ben ik flexibiliteit verloren door dit zelf te implementeren, hoewel ik met wat reflection-trucken deze kan terugwinnen, maar tegen welke kost?

Ik vind dit een groot gebrek. Natuurlijk hebben ze locks en threads en zijn ze gemakkelijk in gebruik; zonder higher-level concept zijn ze niet altijd even bruikbaar.

[Verwijderd]

voordeel C# lekker makkelijk
voordeel C++ je mag alles lekker zelf doen. Meer werk maar vooral als je beperkte resources hebt ga ik zeker voor c++ (en assembly als ik in een hardcore bui ben )
ik hou zoizo meer van c++. maar dat is ook omdat ik het gewend ben.

wat eerder werd gezegt kan ik het ok alleen maar mee eens zijn.. het is altijd goed meerdere talen te kennen en dan kan je afhankelijk van je project kiezen wat je wilt toepassen. dit doe ik zelf ook. laatst nog een prog in java (blegh;) ) geschreven omdat degene voor wie het was zelf enkel java kent en graag er zelf aan verder wil werken.

[roy-t]

Janoz schreef op woensdag 17 oktober 2007 @ 09:16:
[...]

Grappig dat je dat zegt . Over het algemeen loopt Visual Studio behoorlijk achteraan mbt features. Het enige voordeel dat VS heeft is dat het out of the box goed integreerd met andere MS software (ISS, Office, SourceSafe en Sharepoint ed). Als dit je enige argument is zou ik als ik jou was maar niet naar Intellij gaan kijken aangezien je dan waarschijnlijk een nieuwe taal meot leren ... Maar goed, om dit maar niet teveel op te rakelen toch maar ff op de topicstart reageren.

Misschien waar, maar VS werkt out of the box meteen goed, en je hoeft niet eerst een paar uur te zoeken naar fijne plugins om dezelfde functionaliteit te verkrijgen als VS.

Maar misschien is het voor de niet "Ik hobby een beetje aan"-hobbyist geen gedoe om eerst uren je Eclipse in te stellen (zeker voor een groot project is het het waard). En als je eenmaal de fijne tools kent dan gaat dit natuurlijk in 10min.

Ik vraag me wel af welke technieken eclipse bijvoorbeeld mee voorloopt op VS? Waarschijnlijk moet ik me ook eens in java gaan verdiepen (ivm studie switch )

[Bobco]

therat10430 schreef op woensdag 17 oktober 2007 @ 23:57:
[...]
Misschien waar, maar VS werkt out of the box meteen goed, en je hoeft niet eerst een paar uur te zoeken naar fijne plugins om dezelfde functionaliteit te verkrijgen als VS.

Maar misschien is het voor de niet "Ik hobby een beetje aan"-hobbyist geen gedoe om eerst uren je Eclipse in te stellen (zeker voor een groot project is het het waard). En als je eenmaal de fijne tools kent dan gaat dit natuurlijk in 10min.

Ik vraag me wel af welke technieken eclipse bijvoorbeeld mee voorloopt op VS? Waarschijnlijk moet ik me ook eens in java gaan verdiepen (ivm studie switch )

Volgens mij had Janoz het over IntelliJ IDEA en niet over Eclipse. Zelf ben ik ook een fervente IntelliJ gebruiker. IntelliJ zit vol met handigheidjes die het leven van een ontwikkelaar heel veel gemakkelijker maken.

Kijk er voor de lol maar eens naar en vergelijk de features met Eclipse en VS.Net. Je zult zien dat IntelliJ de meest rijpe IDE op de markt is, tenminste IMHO. Goed, je kunt er geen C# in kloppen, maar dat is maar een klein nadeel

Iets waar bijvoorbeeld IntelliJ veel verder mee is is automatische refactoring. Verder zijn er stapels handigheidjes: CTRL-O geeft een lijst van methodes die je zou kunnen overriden. Je selecteert degene die je wilt en IntelliJ zet de method signatures voor je neer. Body schrijven en klaar.

[farlane]

Bobco schreef op donderdag 18 oktober 2007 @ 14:53:
Iets waar bijvoorbeeld IntelliJ veel verder mee is is automatische refactoring. Verder zijn er stapels handigheidjes: CTRL-O geeft een lijst van methodes die je zou kunnen overriden. Je selecteert degene die je wilt en IntelliJ zet de method signatures voor je neer. Body schrijven en klaar.

Mwah dat doet VS 2005 ook, als ik override tik geeft ie me een lijst van te overiden functies die ik met tab kan invoegen.

[Janoz]

therat10430 schreef op woensdag 17 oktober 2007 @ 23:57:
[...]


Misschien waar, maar VS werkt out of the box meteen goed, en je hoeft niet eerst een paar uur te zoeken naar fijne plugins om dezelfde functionaliteit te verkrijgen als VS.

Maar misschien is het voor de niet "Ik hobby een beetje aan"-hobbyist geen gedoe om eerst uren je Eclipse in te stellen (zeker voor een groot project is het het waard). En als je eenmaal de fijne tools kent dan gaat dit natuurlijk in 10min.

Ik vraag me wel af welke technieken eclipse bijvoorbeeld mee voorloopt op VS? Waarschijnlijk moet ik me ook eens in java gaan verdiepen (ivm studie switch )

3 dingen:

1: Ik had het inderdaad niet over Eclipse. Eclipse heeft inderdaad als nadeel dat een beginner de plugins nog niet kent. Zou je echter in een ingerichte omgeving ingezet worden dan valt dit verschil alvast weg en kunnen beide platformen zich goed aan elkaar meten. Daarnaast worden er genoeg redelijk compleet uitgeruste eclips varianten geleverd door verschillende leveranciers.
2: De omgevingen waar ik met Eclipse gewerkt heb waren absoluut geen 'ik hobby een beetje aan' omgevingen. (Bedenk bijvoorbeeld dat de ontwikkel omgevingen van IBM en Oracle ook op Eclipse gebaseerd zijn)
3: De afgelopen reclame campagne omtrent VS heeft mij ernstig verbaasd. Bij al die 'nieuwe features' was ik met stomheid geslagen dat dat blijkbaar nog niet eens in VS zat. Kijk voor de gein eens naar de features van versie 7 van IntelliJ: http://www.jetbrains.com/idea/features/index.html . Let bijvoorbeeld eens op de refactor mogelijkheden (2e kolom bovenaan). Zelfs de refactoring mogelijkheden van versie 3 van IntelliJ (die ergens rond 2003 op de markt kwam w2as uitgebreider dan wat nu in VS zit.

[ Voor 3% gewijzigd door Janoz op 18-10-2007 15:10 ]

[/\/\|)]

Voor de volledigheid wijs ik even op het bestaan van Resharper (ook van JetBrains), de VS.net/C# tegenhanger van IntelliJ.

[roy-t]

@ Janoz en consorten.

Ik bedoelde met aanhobbyen zeg maar dat dat mijn manier van programmeren is en bedoelde dan de plugin structuur van Eclipse juist als voordeel voor "echt" programmeren.
(even zodat ik zeker weet dat we elkaar begrijpen)

Hmm ik heb die opties nog nooit gemist.. maarja tot 2jr terug was ik tevreden met visual studio 6 (97)

Ik zal zeker eens kijken naar IntelliJ want wie weet misschien moet ik voor school zo in java gaan werken. En het kan nooit kwaad je horizon te verbreden .

Maargoed sorry voor deze unintended topic kaping, ik heb iig weer wat geleerd. Al enig nieuws wat de TS overal van vind?

Edit:

Ho ho wacht is even, IntelliJ er bij betrekken is niet echt eerlijk, Visual Studio Express is gratis, Netbeans is gratis, Eclipse is gratis. maar IntelliJ kost voor de meest simpele licentie al €500,-

*dat wordt dus toch Eclipse+plugins over een tijdje :P*

[ Voor 17% gewijzigd door roy-t op 18-10-2007 17:39 ]

[flowerp]

therat10430 schreef op donderdag 18 oktober 2007 @ 17:27:
maarja tot 2jr terug was ik tevreden met visual studio 6 (97)

Studenten van bijvoorbeeld de Universiteit Leiden moeten het nog steeds doen met VS6, en zullen dat zo ongeveer de komende 10 jaar nog moeten doen (het pakket zal dan 20 jaar oud zijn!). Als dit bij andere CS opleidingen ook zo is dan worden er behoorlijk weinig mensen opgeleid met al die leuke truukjes en handigheidjes in Eclipse, IntelliJ en de nieuwere releases van VS.

[roy-t]

Nog steeds met VS6? Waarom zetten ze er niet Visual Studio Express op? Is gratis (ook voor educatie dacht ik) en imho en mijn ervaring al een stuk gebruiksvriendelijker en beter dan VS6 (wat opzich ook niet zo slecht was, maar een beetje ehm meer zelf doen, en geen refactoring behalve dan cltr+f )

[flowerp]

therat10430 schreef op donderdag 18 oktober 2007 @ 20:03:
Nog steeds met VS6? Waarom zetten ze er niet Visual Studio Express op?

Geen idee, gewoonte misschien, of het feit dat je op een universiteit toch niet echt hele lappen code ontwikkeld, maar voornamelijk kleine stukjes eigenlijk. Toch is het jammer voor hen die er mee moeten werken want VS6 ondersteunde ~70% van de C++ standaard ofzo.

beter dan VS6 (wat opzich ook niet zo slecht was, maar een beetje ehm meer zelf doen, en geen refactoring behalve dan cltr+f )

Ik heb jaren met VS6 gewerkt en nog een poosje met VS 2002 en heel kort met 2003 (die laatste zelf nog aangeschaft, maar vlak daarna bijna volledig op Java overgegaan).

1 ding wat ik miste in VS was de mogelijkheid om snel naar code te navigeren. In Eclipse druk ik op de ctrl key en alle methods en variablen worden hyperlinks als ik er met de muis overheen ga. Met 1 click zit ik de definitie of bij de declaratie.

1 ding wat overigens in Eclipse mist is dat de debugger aangeeft wat de return value was na een method call. Eclipse kan dit niet, en dat is soms heel erg lastig.

[Janoz]

@therat10430: Ik probeer je ook absoluut niet over te halen en wil al helemaal niet de java evangelist uithangen. Ik wilde alleen even rechtzetten dat, ondanks wat MS beweert, VS niet de meest vooruitstrevende IDE is, maar dat het eerder achterop loopt in vergelijking met de mogelijkheden in andere ontwikkel omgevingen.

[whoami]

Mag ik de mensen er eens op wijzen dat dit topic ondertussen 'verzand' is in een discussie die eigenlijk niet veel meer met de originele vraag te maken heeft ?

De oorspronkelijke vraag was: 'moet ik bij c++ blijven voor de dingen die ik wil doen, of kan ik dat ook met c#', en ondertussen zijn we bezig over IDE's ...

[ATS]

therat10430 schreef op woensdag 17 oktober 2007 @ 00:21:
Threads zijn errrg makkelijk in C# (zelfs ik snap het )

Serial poorten dacht ik ook (dunno gebruik ze nooit)

En tsja verder heb je het fijne Visual Studio (maarja ik weet niet of je "office' applicaties ontwikkeld, zoniet dan is dat wat minder waard, maar ook de intellisense e.d. van VS zijn erg fijn (een van mijn grootste anti-java argumenten, of nouja eigenlijk mijn enige is dat de ontwikkelprogramma's niet zo fijn zijn)

Maargoed ik geloof niet dat je Java uberhaupt overwoog.

Zelf heb ik geen kennis van C++, behalve dan dat het een vrij oude taal is. Dus ja, C# is hardstikke nieuw up-to date en fijn met threads (en zo te lezen ook met serial poorten)

nadeeltje: .Net nodig (is normaal geen nadeel maar misschien wel voor oude apperatuur waar nog even een C++ programmatje op moet draaien)

Verder is Oisyn' idee natuurlijk ook het overwegen waard, hoewel dat een beetje halve weg is. Zelf zou ik liever 'echt' voor iets kiezen ipv alles door elkaar heen.

Nu wil ik niet lullig doen, maar in feite voeg je helemaal niets toe met dit bericht. OK, threads zijn makkelijk, maar dat was al gezegd, en verder is alles uit de tweede hand.

* ATS is zich ervan bewust dat ook dit bericht niets aan de oorspronkelijke vraag toevoegt.

[ Voor 3% gewijzigd door ATS op 19-10-2007 17:04 ]

[phobosdeimos]

Ik zie geen enkele reden waarom je van C++ zou willen afwijken.
Het is nog steeds de industriestandaard voor serieuze software, het geeft je de vrijheid om te ontwikkelen op welke manier je maar wil (linux, mac, windows, makefiles, scons, vim, emacs, visual studio, eclipse, netbeans, kladblok, je doet maar).
C# is leuker voor de mensen die graag met het handje genomen worden, maar verder houdt de overstap enkel nadelen en beperkingen in (alsjeblief laat niemand nu met een opmerking over Mono afkomen).

[ Voor 34% gewijzigd door phobosdeimos op 23-10-2007 21:07 ]

[.oisyn]

phobosdeimos schreef op dinsdag 23 oktober 2007 @ 21:00:
C# is leuker voor de mensen die graag met het handje genomen worden

Oh kom op zeg, dit slaat werkelijk helemaal nergens op. Alsof softwaredevelopment in C# of Java niet serieus is. Waar baseer je dat in hemelsnaam op, op het feit dat je zelf je geheugen moet kunnen managen? Of dat je niet "op je vingers getikt" wil worden als je buiten een buffer schrijft?

Als C++ zealot vind ik C++ natuurlijk een hele mooie en fijne taal om in te ontwikkelen, maar het gaat helemaal nergens over om te zeggen dat C# een taal is voor mensen die bij het handje genomen willen worden.

En het heeft al helemaal niet enkel nadelen en beperkingen. Het .Net framework is erg uitgebreid en compleet, daar waar standaard C++ juist erg summier is (geen threading, geen xml support, geen regex, geen GUI, ...).

[ Voor 13% gewijzigd door .oisyn op 23-10-2007 21:12 ]

[MrBucket]

@phobosdeimos Wat een zeldzaam ongenuanceerde en ongefundeerde mening heb je daar neergepend zeg...

Maar goed. Vooropgesteld: ik, als vroegere C++ fan, kan je C# van harte aanraden Zeker met de komst van generics in .NET 2.0 (de C++ "templates") is het een erg fijne programmeertaal.

hneel schreef op dinsdag 16 oktober 2007 @ 13:48:
De seriele poort is cruciaal. Verder is er eigenlijk weinig directe hardware aansturing nodig. In het kort komt het er op neer dat ik moet kunnen communiceren met bestaande microcontroller systemen. Daar omheen kan dan allerlei extra functionaliteit worden gebouwd, maar dat zijn eigenlijk alleen standaard technieken. De standaard GUI dingen, af en toe een timertje, wat standaard file I/O, enz.

Dus als ik de seriele poort aan de praat kan krijgen zit ik in principe goed, denk ik.

Nu is het wel zo dat Mircosofts .NET platform met name geent is op enterprise applications. Dat uit zich in veel ondersteuning voor user-interface implementatie, database-support, web-applicaties, webservices, xml, etc. Het is niet bedacht met zaken als compact, low-level, en tijdskritisch operaties kunnen uitvoeren in het achterhoofd. Je zult .NET code met "aan zekerheid grenzende waarschijnlijkheid" niet kunnen compilen om op een microcontroller te draaien.

Maar microcontrollers aansturen vanuit .NET kan zonder meer. Misschien dat er al custom libraries in .NET voor bestaan, en anders is er nog geen man over boord. Dan kun je nl. gewoon de basic operaties die je nodig hebt om zo'n controller aan te sturen (ik vermoed het uitlezen van en schrijven naar hardware porten?) uitwerken in C++, en als je dit als DLL compiled kun je deze DLL gewoon vanuit .NET gebruiken om je applicatielogica en UI omheen te bouwen.

Ik zeg: doen!

[ Voor 3% gewijzigd door MrBucket op 23-10-2007 21:29 ]

[Verwijderd]

C# is leuker voor de mensen die graag met het handje genomen worden

Met alle respect, maar wat een onzinnige en denigrerende opmerking is dat!

offtopic:
Spuit 11... Niet eerst een half uurtje bellen en dan op submit drukken...

[ Voor 22% gewijzigd door Verwijderd op 23-10-2007 21:38 ]

[flowerp]

phobosdeimos schreef op dinsdag 23 oktober 2007 @ 21:00:
Ik zie geen enkele reden waarom je van C++ zou willen afwijken.
Het is nog steeds de industriestandaard voor serieuze software,
C# is leuker voor de mensen die graag met het handje genomen worden

De 'grap' is dat er een legioen mensen is die ongeveer hetzelfde zegt van C vs C++. Ik denk dat C# zeker een hele serieuze taal is en op sommige punten C++ overtreft. Dan heb ik het niet over de .NET library (die zeer uitgebreid is), maar puur over de taal zelf.

C++, Java, C# hebben misschien wel allemaal hun eigen marktsector (die ook dikwijls enigszins overlappen) , maar elk op zich zijn het dikwijls de tools van serieuze software developers.

Ik zou zeggen dat C++ ongeveer de high-performance games markt en de 'legacy' desktop software heeft (d.w.z. software waar op zich nog steeds nieuwe versies van komen, maar die al vrij lang bestaan en dus niet hergeschreven gaan worden in een andere taal). Java heeft een groot gedeelte van de serverside/web app markt , met name de serieuze kant ervan (systemen waar vliegvelden of banken op draaien) en de mobile (eenvoudige) games markt, terwijl C# met name domineert op het gebied van redelijk recent geschreven desktop software en ook qua serverside/web app sterk aanwezig is en zich ongeveer op dezelfde markt als Java richt.

Concreet voor deze thread pakt C++ dan ook nog een stukje van de low-level hardware control markt, hoewel voor de echte low-level stuff volgens mij C nog steeds overheerst.

[phobosdeimos]

C heeft an sich niet veel te maken met C++, behalve de overeenkomsten qua syntax, en de (gedeeltelijke) compatibiliteit waarbij je C broncode ook met een C++ compileren kan gaan compileren.
C wordt voornamelijk gebruikt voor programmeren op systeemniveau, terwijl C++ een taal is die vooral dient om applicaties in te schrijven.

[.oisyn]

Leuk verhaaltje. Ga je nog in op de inhoudelijke kritiek op je eerste reactie of laat je het hierbij?

[farlane]

flowerp schreef op woensdag 24 oktober 2007 @ 00:04:
Concreet voor deze thread pakt C++ dan ook nog een stukje van de low-level hardware control markt, hoewel voor de echte low-level stuff volgens mij C nog steeds overheerst.

Eigenlijk wordt voor embedded spul ( uP dan, niet het 'PDA embedded spul' daarvan zou ik het niet durven zeggen ) eigenlijk alleen C gebruikt, met heel af en toe een platform waarop ook C++ gebruikt kan worden. ( Er wordt vaker nog in asm *shudder* gepielt dan in C++ heb ik het idee )

[phobosdeimos]

.oisyn schreef op woensdag 24 oktober 2007 @ 01:24:
Leuk verhaaltje. Ga je nog in op de inhoudelijke kritiek op je eerste reactie of laat je het hierbij?

Liever hier bij laten. Ik gebruik zowiezo niets wat uit de Microsoft stal komt, en ik heb inderdaad een denigrerende positie ten opzichte van zaken zoals het .Net platform.
Maar uit ervaring weet ik dat je over zo'n dingen beter kan zwijgen, om geen flame wars te creeëren
In ieder geval: the best tool for the job.
Als het werkt voor jou in jouw situatie, dan zou ik het gewoon gebruiken, iedereen tevreden.

[whoami]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 11:35:
[...]


Liever hier bij laten. Ik gebruik zowiezo niets wat uit de Microsoft stal komt, en ik heb inderdaad een denigrerende positie ten opzichte van zaken zoals het .Net platform.

Hoe kan je een onderbouwde mening over iets hebben - of uberhaupt een mening over iets hebben, als je het niet gebruikt.
Ik zou zeggen, werk er eerst eens even mee, vooraleer je dingen gaat afbreken.

---

[Hydra]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 11:35:
Liever hier bij laten.

Ja, je zal er ook eens compleet uitgeluld worden

C++ wordt tegenwoordig in zowel back-end, server applicaties als ook webapplicaties compleet voorbijgestreefd door Java en C#. Er is ook VEEL meer vraag naar mensen met Java en C# ervaring, dan vraag naar C++-ers.

C++ is geweldig als het op snelheid aankomt, maar dat is het voornaamste voordeel. GUI applicaties en grote multi-tier systemen worden tegenwoordig fijn in talen gebouwd waar ontwikkelen gewoon twee keer zo snel in gaat.

[.oisyn]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 11:35:
Maar uit ervaring weet ik dat je over zo'n dingen beter kan zwijgen, om geen flame wars te creeëren

Klopt, flames -zoals je eerdere post nu blijkt te zijn- kun je beter achterwege laten. Onderbouwde meningen echter, hoe controversieel ook, worden gewoon op prijs gesteld (door mij iig, en ik zal ze zelf ook niet onder tafels of stoelen schuiven)

[ Voor 6% gewijzigd door .oisyn op 24-10-2007 12:28 ]

[phobosdeimos]

whoami schreef op woensdag 24 oktober 2007 @ 11:41:
[...]
Hoe kan je een onderbouwde mening over iets hebben - of uberhaupt een mening over iets hebben, als je het niet gebruikt.
Ik zou zeggen, werk er eerst eens even mee, vooraleer je dingen gaat afbreken.

---

Misschien ligt het ook aan je achtergrond, ik heb zowiezo een lage dunk van de microsoft ontwikkelmethode, en op menig universiteit worden wetenschappelijke projecten gewoonweg in C++ geschreven omdat dat de taal is die je de vrijheid en snelheid geeft om dergelijke zaken te realiseren.
Kies je voor C#, dan kies je voor vendor lock-in.
Ik snap dat er miljoenen zoniet miljarden mensen tevreden zijn in de Windows/Office gevangenis, maar ik hoor daar niet bij, dus blijf ik ook zo ver mogelijk weg van .Net.
Ik heb trouwens niets negatief gezegd over Java.
Sun doet ten minste moeite om Java open te maken/houden, en ik kan mijn Java software draaien op alle platformen zonder zorgen hoeven te maken of Sun volgend jaar plots een rechtzaak aan mijn neus hangt (cfr: microsoft die linux distro's bedreigt en aanklaagt, samenzwering met SCO en Novell, etcetera).

[Verwijderd]

Hydra schreef op woensdag 24 oktober 2007 @ 12:17:
C++ is geweldig als het op snelheid aankomt, maar dat is het voornaamste voordeel.

En ook dat is allang niet meer waar. Sterker nog, Vitual Machines zijn vaak en hebben de theoretische mogelijkheid om sneller te code uit te voeren dan statisch gecompileerde talen. Enkel waar direct hardware aangesproken kan worden heeft C++ nog altijd de overhand, hoewel bijvoorbeeld .Net dat gat behoorlijk dicht.

[phobosdeimos]

Ja, op theoretisch vlak zou het mogelijk moeten zijn, totdat je effectief een C++ en een .NET of Java implementatie naast elkaar benchmarkt, en dan zal je grote ogen trekken
Ook te lezen in deze leuke benchmark suite.
Daar zie je dat puur op CPU tijd Java6 een stuk of 2.6 keer trager is dan C, en C# met Mono pakweg 3.2 keer trager gemiddeld.
Als je daarbij ook nog het geheugenverbruik in rekening zou nemen dan komt het op respectievelijk 4.3 en 4.1 keer slechter uit.

[ Voor 52% gewijzigd door phobosdeimos op 24-10-2007 12:48 ]

[RayNbow]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 12:30:
en op menig universiteit worden wetenschappelijke projecten gewoonweg in C++ geschreven omdat dat de taal is die je de vrijheid en snelheid geeft om dergelijke zaken te realiseren.

Gewoonweg? Volgens mij worden wetenschappelijke projecten geschreven in een taal die past bij de eisen van het project. Het wetenschappelijke project Tribler maakt bijv. gebruik van Python vanwege reeds bestaande code.

Kies je voor C#, dan kies je voor vendor lock-in.

.NET is gewoon een standaard.

phobosdeimos schreef op woensdag 24 oktober 2007 @ 12:39:
Ja, op theoretisch vlak zou het mogelijk moeten zijn, totdat je effectief een C++ en een .NET of Java implementatie naast elkaar benchmarkt, en dan zal je grote ogen trekken

Benchmarks... jaaaa.... Ga dan voor de functionele taal van de universiteit Nijmegen genaamd Clean. [Benchmark]

[Janoz]

Tja, dat je van alles roept over dingen terwijl je er eigenlijk geen ervaring in of onderbouwing voor hebt was ons eerder ook al duidelijk geworden ....

[google=benchmark java c++ .net]

[phobosdeimos]

Janoz schreef op woensdag 24 oktober 2007 @ 12:50:
Tja, dat je van alles roept over dingen terwijl je er eigenlijk geen ervaring in of onderbouwing voor hebt was ons eerder ook al duidelijk geworden ....

[google=benchmark java c++ .net]

Aha dus mijn benchmarks van het Debian language shootout project dat noem je "geen onderbouwing", maar jouw google zoekopdracht is wel een degelijke onderbouwing?

[Janoz]

Toen ik mijn bericht begon te tikken stond er nog geen onderbouwing bij. Tijdens het tikken heb ik meerdere benchmarks doorgelezen om te kijken wat er in stond om te zien wat de uitkomsten waren.

[phobosdeimos]

Wel in ieder geval, daarom kun je beter over dergelijke zaken niet beginnen, want het resulteert toch in een welles-nietes spelletje. Ik haal benchmarks boven in het voordeel van C, dan haalt iemand anders er boven waar bewezen wordt dat Java stukken sneller is dan C++. Windows vs Linux, Vim vs Emacs, Java vs C#: eindeloze discussies die meestal eindigen in oeverloos gezwam
Ik gebruik geen microsoft technologie (meer), ik heb daar mijn redenen en overtuigingen voor, en zoals mij zijn er steeds meer mensen te vinden.

[RayNbow]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 12:52:
[...]
Aha dus mijn benchmarks van het Debian language shootout project dat noem je "geen onderbouwing", maar jouw google zoekopdracht is wel een degelijke onderbouwing?

Benchmarks zeggen ook geen fuck. Benchmarks zijn namelijk erg te beinvloeden.

Om m'n punt duidelijker te maken:
[q=http://www.gamedev.net/community/forums/viewreply.asp?ID=2754633]
Original post by Emmanuel Deloget:
I remember a test done by a C++ guru and a C# guru. The whole point was to play with the STL and the corresponding part of the CLR. In the end, the C++ guru won (its code was running in 60 ms, while the managed code was running in 100 ms IIRC). Of course, this is a rather big improvement. Hovewer, this improvement has to be minimized since:

• it took 6 iterations to the C++ guru to be able to beat the first C# version of the program
• the C++ guru had to play with his own allocator implementation and had to be really clever about how to organize and micro-optimize his code in order to just run at twice the speed of the C# version.
• So far, it tells us a big story: C# is not that slow, and can beat C++ if you don't have time to waste on a large scale micro-optimization process (which is usually the case in most development teams, even game development teams: money is not auto-generating itself in order to match the wasted develoment time).

quote: http://www.gamedev.net/co.../viewreply.asp?ID=2754869

Original post by Promit:
So here's the thing. The C# version in tht race ran equally fast at the end of everything. Emmanuel neglected to mention that the times cited include executable start up and shutdown time -- that is, the time was taken immediately before the process started and immediately after the process terminated. .NET binaries take longer to start up and shutdown, for a number of (mostly obvious) reasons -- by the time Main was executed for the C# version, 60ms had already passed. The actual algorithm running time for the two was basically identical, but the C++ version took several times more work and a metric asston of extra code to match the C# one.

In other words, C# won that race, and won it easily. And frankly, I'm willing to bet I can write faster games in C# than most people here can do in C++.

Meer achtergrondinformatie is te lezen in deze blogpost van de C# progger in kwestie. Het is ook interessant te lezen dat de new operator een van de trage punten was in de C++ implementatie is.

Nou ja, memory allocation kan gewoon traag zijn in een unmanaged taal:

quote: http://www-128.ibm.com/de...=dgr-jw22JavaUrbanLegends

Pop quiz: Which language boasts faster raw allocation performance, the Java language, or C/C++? The answer may surprise you -- allocation in modern JVMs is far faster than the best performing malloc implementations. The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources).

[.oisyn]

Om overigens het hele game verhaal te ontkrachten, ik moet de eerste compiler nog zien die scalar math omzet naar vector math door gebruik te maken van SIMD instructies van het onderliggende platform. Tot die tijd kun je in de meeste C++ implementaties gewoon gebruik maken van SIMD intrinsics (alsmede als intrinsics voor memory fences, data prefetches, etc.), dus met een goed geïmplementeerde vector en matrix lib schrijf je zonder moeite al fantastisch geoptimaliseerde code.

Memory allocation is idd een issue, en de standaard C++ allocator is natuurlijk opgezet als general purpose allocator, daar waar JIT compiled talen een allocator kunnen kiezen op basis van het gebruik van bepaalde objects in bepaalde contexts. Maar elke fatsoenlijke game heeft een tal van custom geïmplementeerde allocators in zich (fixed block heaps, transient heaps, stack based heaps, ...), dus dat is meestal een non-issue. C++ is en blijft de ideale taal voor games.

That said, games en simulaties vallen onder de uitzonderingen, en benchmarks van bepaalde algoritmes zeggen natuurlijk helemaal geen fuck over dagelijkse softwaredevelopment.

[EfBe]

Rico Mariani is de performance engineer voor het C# team, dus geen wonder dat hij er snelle code uit perst. Ik denk niet dat een random C# developer net zulke snelle code zal afleveren.

[RayNbow]

IMO wordt C++ door gamebedrijven gebruikt vanwege de code base die ze al hebben en hun ervaring met C++. Tevens moeten deze bedrijven vaak het uiterste uit het target platform halen en dan is het idd lonend om veel controle te hebben zoals in C++.

Ik zou echter niet zeggen dat C++ de ideale taal is voor gamedev in het algemeen. Voor de AAA titels is de taal zeker geschikt, maar voor bijv. een hobbyist is een taal als C# net zo geschikt. Zo'n hobbyist hoeft namelijk niet het onderste uit de kan te halen.

Deze post is natuurlijk overbodig als je met games sowieso de AAA titels bedoelde.


Edit:

EfBe schreef op woensdag 24 oktober 2007 @ 13:46:
Rico Mariani is de performance engineer voor het C# team, dus geen wonder dat hij er snelle code uit perst. Ik denk niet dat een random C# developer net zulke snelle code zal afleveren.

Maar de eerste implementatie ziet er niet bijzonder uit. Dit kan denk ik elke C# devver wel maken.

[ Voor 29% gewijzigd door RayNbow op 24-10-2007 13:52 ]

[.oisyn]

Als ik het over games heb, dan heb ik het over echte games in mijn vakgebied, en niet over hobbyisten-crap, jamba-troep, photoplay-ruk of mijnenveger (ja, AAA titels dus ). Het staat buiten kijf dat de kleinere spelletjes (mobiel, webgames, etc) ook prima in andere talen geschreven kunnen (of moeten) worden

[ Voor 32% gewijzigd door .oisyn op 24-10-2007 13:57 ]

[Hydra]

.oisyn schreef op woensdag 24 oktober 2007 @ 13:21:
That said, games en simulaties vallen onder de uitzonderingen, en benchmarks van bepaalde algoritmes zeggen natuurlijk helemaal geen fuck over dagelijkse softwaredevelopment.

Executiesnelheid is belangrijk in games, maar niet bijzonder relevant in de meeste server systemen. Een 2e server kopen en hosten is vaak een stuk goedkoper dan de extra kosten die een C++ i.p.v. een Java implementatie met zich meebrengen.

[EfBe]

Hydra schreef op woensdag 24 oktober 2007 @ 14:26:
[...]
Executiesnelheid is belangrijk in games, maar niet bijzonder relevant in de meeste server systemen. Een 2e server kopen en hosten is vaak een stuk goedkoper dan de extra kosten die een C++ i.p.v. een Java implementatie met zich meebrengen.

Waar is dat op gebaseerd? Je onderbuik? Server performance is erg belangrijk, ook bij VM gebruikende talen en je kunt wel roepen dat 'een paar servers extra de kosten niet zijn' t.o.v. C++ gebruik, maar zonder wetenschappelijke analyse is er geen zinnig woord over te zeggen. Immers: meer servers betekent ellende mbt state, load balancing etc.

[phobosdeimos]

EfBe schreef op woensdag 24 oktober 2007 @ 17:02:
[...]

Waar is dat op gebaseerd? Je onderbuik? Server performance is erg belangrijk, ook bij VM gebruikende talen en je kunt wel roepen dat 'een paar servers extra de kosten niet zijn' t.o.v. C++ gebruik, maar zonder wetenschappelijke analyse is er geen zinnig woord over te zeggen. Immers: meer servers betekent ellende mbt state, load balancing etc.

Als ik Azureus (bekende Java bittorrent client) op heb staan, gebruik die ergens tussen de 200 en 600 megabyte ram geheugen (van een totaal van 1gb), afhankelijk van de situatie.
Als ik Transmission aan heb staan (C++ GTK bittorrent client) gebruikt die 12 megabyte voor dezelfde functionaliteit.
Wetenschappelijk? Nee.

[Hydra]

EfBe schreef op woensdag 24 oktober 2007 @ 17:02:
Waar is dat op gebaseerd? Je onderbuik?

Ervaring. Natuurlijk chargeerde ik nogal, het is OOK belangrijk, maar die 10%/90% regel geldt daar ook. Als je 10% snelheidswinst haalt met 90% van de inspanning, is het het vaak gewoon niet waard. Dat geldt ook voor server software.

En wat betreft 'problemen' kwa state: daar heb je sowieso rekening mee te houden. Als je schaalbaarheid wil moet je d'r niet vanuit gaan dat je er mee wegkomt met een net iets nieuwere snellere server in je rack te schuiven ter vervanging van de oude.

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:30:
Als ik Azureus (bekende Java bittorrent client) op heb staan, gebruik die ergens tussen de 200 en 600 megabyte ram geheugen (van een totaal van 1gb), afhankelijk van de situatie.
Als ik Transmission aan heb staan (C++ GTK bittorrent client) gebruikt die 12 megabyte voor dezelfde functionaliteit.
Wetenschappelijk? Nee.

Je gebruikt Azureus dus voor porno met dikke vrouwen? Busted!

[ Voor 28% gewijzigd door Hydra op 24-10-2007 17:34 ]

[phobosdeimos]

Hydra schreef op woensdag 24 oktober 2007 @ 17:32:

Je gebruikt Azureus dus voor porno met dikke vrouwen? Busted!

[.oisyn]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:30:

Als ik Azureus (bekende Java bittorrent client) op heb staan, gebruik die ergens tussen de 200 en 600 megabyte ram geheugen (van een totaal van 1gb), afhankelijk van de situatie.
Als ik Transmission aan heb staan (C++ GTK bittorrent client) gebruikt die 12 megabyte voor dezelfde functionaliteit.
Wetenschappelijk? Nee.

utorrent.exe gebruikt bij mij 4mb. Ergo, C++ is blijkbaar 3x zo goed als C++.

[phobosdeimos]

.oisyn schreef op woensdag 24 oktober 2007 @ 17:50:
[...]

utorrent.exe gebruikt bij mij 4mb. Ergo, C++ is blijkbaar 3x zo goed als C++.

Als je zoals Hydra wil over gaan op onzinnige opmerkingen, doet het dan eventueel in PM naar elkaar?

[RayNbow]

Laten we niet ingaan op het geheugengebruik dat bijv. Task Manager weergeeft. Ik kan Task Manager laten geloven dat bijv. MSN Messenger 7.5 maar 1 MB geheugen in gebruik neemt...

Nog een relevante blogpost over perceived memory usage:
Xiaobin Lu's Blog: Perception == Reality

[Hydra]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:53:
Als je zoals Hydra wil over gaan op onzinnige opmerkingen, doet het dan eventueel in PM naar elkaar?

Hey, jij begint er onzinnige dingen aan de haren bij te slepen, niet ik...

[.oisyn]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 17:53:

Als je zoals Hydra wil over gaan op onzinnige opmerkingen, doet het dan eventueel in PM naar elkaar?

Blijkbaar zie je de onzinnigheid in je eigen opmerking niet, en dat probeerde ik aan te tonen met een vergelijkbare opmerking waarin je de onzinnigheid wel ziet. Je vergelijkt een willekeurige applicatie met een willekeurige andere applicatie die ogenschijnlijk dezelfde features bieden, maar waarbij de ene dat overduidelijk efficienter doet dan de andere, en je denkt vervolgens dat dat te ontlenen valt aan het feit dat de ene in Java is geschreven en de andere in C++, terwijl daar geen enkel causaal verband tussen hoeft te bestaan. Vergelijkbaar voorbeeld van wat jij zegt: het broeikaseffect is in de afgelopen jaren toegenomen. Zo ook het aantal piraten. Blijkbaar waren piraten een tegenpool voor het broeikaseffect.

Een andere mogelijke verklaring is dat de makers van Azareus prutsers zijn, terwijl de programmeurs van Transmission veel tijd hebben gespendeerd aan het optimaliseren van hun applicatie.

[ Voor 21% gewijzigd door .oisyn op 24-10-2007 18:26 ]

[phobosdeimos]

Dus oisyn als zelfverklaarde informaticus-expert heeft nog niet opgemerkt dat een willekeurige Java-desktop of server applicatie steevast een veelvoud van het geheugen gebruikt dan een functioneel equivalente C++ implementatie?
Nee RayNBow ik kijk niet naar Task Manager want ik gebruik geen windows.

[.oisyn]

Ik geloof niet dat ik verklaard heb informaticus-expert te zijn, ik geef enkel aan dat een willekeurig programma A tegenover willekeurig programma B nog geen bewijs vormt voor jouw stelling. En je hoeft geen informaticus-expert te zijn om dat in te zien. Ik zeg dus niet dat je ongelijk hebt (want blijkbaar lijk jij zoiets af te leiden uit mijn woorden), ik zeg dat je argumentatie niet klopt.

[ Voor 21% gewijzigd door .oisyn op 24-10-2007 18:28 ]

[phobosdeimos]

Het was het eerste praktijkvoorbeeld dat ik tevoorschijn kon toveren, maar een vergelijking met andere Java/C++ desktop applicaties zal gelijkaardige feiten laten zien.

[ Voor 5% gewijzigd door phobosdeimos op 24-10-2007 18:39 ]

[RayNbow]

---

Kijk eens... Azureus is best een efficient programma. Het gebruikt minder dan 4 MB!

Bij het maken van deze screenshot...
[list]
• draaide Azureus met 1 actieve, seedende torrent en 56 stopped torrents.
• is geen Photoshop oid gebruikt om het geheugengebruik aan te passen.


Toch heb ik Task Manager doen laten geloven dat Azureus maar 4 MB gebruikt.

[phobosdeimos]

Raynbow, who cares?
Ik gebruik geen Windows.
Het enige wat je nu aantoont is dat je task manager van windows kan misleiden om een verkeerde hoeveelheid geheugen te rapporteren.

[RayNbow]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 18:55:
Raynbow, who cares?
Ik gebruik geen Windows.
Het enige wat je nu aantoont is dat je task manager van windows kan misleiden om een verkeerde hoeveelheid geheugen te rapporteren.

Wat gebruik je dan? Linux? Heb je de eerdere link die ik gepost heb gelezen? Volgens mij niet...

"Perceived" footprint is the number reported by the operating system (by tools such as "ps" and "top" on Unix/Linux, and "Task Manager" on Windows) that a process takes up in RAM. In reality, the size a process takes up in memory consists of executable code, global data, stack and heap etc. However, to the end-user running one of these process-viewing tools, the size of a process is much different since sometimes these tools include some memory that is not actually allocated in RAM at all.

[MrBucket]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 18:55:
Raynbow, who cares?
Ik gebruik geen Windows.
Het enige wat je nu aantoont is dat je task manager van windows kan misleiden om een verkeerde hoeveelheid geheugen te rapporteren.

We care.

En uitspraken als
• "Ik gebruik geen microsoft technologie (meer), ik heb daar mijn redenen en overtuigingen voor, en zoals mij zijn er steeds meer mensen te vinden.",
• "...oisyn als zelfverklaarde informaticus-expert...",
• "C# is leuker voor de mensen die graag met het handje genomen worden, maar verder houdt de overstap enkel nadelen en beperkingen in (alsjeblief laat niemand nu met een opmerking over Mono afkomen)."
• "Raynbow, who cares? Ik gebruik geen Windows."
geven niet echt blijk van enige sociale vaardigheden of kennis van zaken. Imo vervuil je gewoon het topic met offtopic en slecht onderbouwd geblaat.

[.oisyn]

RayNbow schreef op woensdag 24 oktober 2007 @ 18:46:
[afbeelding]

---

Kijk eens... Azureus is best een efficient programma. Het gebruikt minder dan 4 MB!

Bij het maken van deze screenshot...
[list]
• draaide Azureus met 1 actieve, seedende torrent en 56 stopped torrents.
• is geen Photoshop oid gebruikt om het geheugengebruik aan te passen.


Toch heb ik Task Manager doen laten geloven dat Azureus maar 4 MB gebruikt.

Wat niet wegneemt dat Azureus idd een draak van een programma is (die CPU tijd in je screenshot is ook een mooie indicator daarvan), maar dat ligt geheel aan Azureus en geenszins aan Java .

Verder sluit ik me aan bij MrBucket. Ik heb niet de illusie dat die plaat voor phobosdeimos' hoofd met valide argumenten weg te praten is, dus ik steek er verder ook geen moeite meer in.

.edit @ hieronder: beetje jammer dat die kennis dan gevangen zit achter die plaat zodat het zich niet kan ontplooien . Ook blijf je weer erg zwart-wit bezig. Niemand beweert hier dat .Net en Java volledige vervangers zijn van C++. Dat is een uitspraak die alleen leeft in jouw hoofd.

[ Voor 24% gewijzigd door .oisyn op 24-10-2007 19:21 ]

[phobosdeimos]

Ok laten we besluiten dat .Net en Java prachtige omgevingen zijn, die C en C++ volledig kunnen vervangen, en uiterst zuinig omspringen met CPU tijd en beschikbaar RAM geheugen.
Eerder zullen jullie toch niet tevreden zijn.
MrBucket: over mijn kennis van zaken zou ik zeker niet twijfelen, dan ga je bedrogen uitkomen.

[RayNbow]

.oisyn schreef op woensdag 24 oktober 2007 @ 19:14:
[...]

Wat niet wegneemt dat Azureus idd een draak van een programma is (die CPU tijd in je screenshot is ook een mooie indicator daarvan), maar dat ligt geheel aan Azureus en geenszins aan Java

Het CPU gebruik is hoog vanwege 't trucje dat ik gebruik om Taskman te misleiden . Vlak voor en na 't trucje gebruikt Azureus maar 0-2% CPU.

[Cloud]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 19:17:
Ok laten we besluiten dat .Net en Java prachtige omgevingen zijn, die C en C++ volledig kunnen vervangen, ...

Wat is er gebeurd met "the right tool for the job"?

Niemand loopt hier te beweren dat er één (of twee) omgeving is die alle andere kan vervangen, dat is bullshit. Er is geen beste. Er is alleen de beste meest geschikte, voor een bepaalde situatie.

[Brent]

MrBucket schreef op woensdag 24 oktober 2007 @ 19:03:
En uitspraken als
• "Ik gebruik geen microsoft technologie (meer), ik heb daar mijn redenen en overtuigingen voor, en zoals mij zijn er steeds meer mensen te vinden.",
• "...oisyn als zelfverklaarde informaticus-expert...",
• "C# is leuker voor de mensen die graag met het handje genomen worden, maar verder houdt de overstap enkel nadelen en beperkingen in (alsjeblief laat niemand nu met een opmerking over Mono afkomen)."
• "Raynbow, who cares? Ik gebruik geen Windows."
geven niet echt blijk van enige sociale vaardigheden of kennis van zaken. Imo vervuil je gewoon het topic met offtopic en slecht onderbouwd geblaat.

Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

RayNbow schreef op woensdag 24 oktober 2007 @ 19:18:
[...]

Het CPU gebruik is hoog vanwege 't trucje dat ik gebruik om Taskman te misleiden . Vlak voor en na 't trucje gebruikt Azureus maar 0-2% CPU.

Zo lust ik er nog een paar Bovendien vergeet je volgens mij java.exe mee te nemen.

[MrBucket]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
[...]

Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

Nja. In theorie is C++ platform-onafhankelijk en zou je je programma zonder al te veel problemen moeten kunnen porten om (bijv.) onder linux te draaien. Maar dat is de theorie; in praktijk zul je echt veel moeite moeten doen om je applicatie zo te programmeren dat het ook op Linux te gebruiken valt. En zeker wanneer je met zaken als user interfaces (of andere dingen waarvoor je het OS aan moet spreken) aan de gang gaat.

Bovendien, wanneer was de laatste keer dat jij besloot dat je applicatie opeens op een ander OS moest kunnen draaien?

@TS: _{waar issie heen, trouwens - die zal het gekibbel wel zat zijn geworden...}
Don't take our word for it, probeer het anders gewoon zelf uit. Visual C# Express is een lichtgewicht Visual Studio variant die gratis te downloaden is, en er zijn genoeg C# tutorials te vinden.

Kijk maar eens of het je wat lijkt

[H!GHGuY]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 19:17:
MrBucket: over mijn kennis van zaken zou ik zeker niet twijfelen, dan ga je bedrogen uitkomen.

Net jouw overschatting van jezelf zorgt dat _jij_ bedrogen uitkomt.

Dat de memory footprint van een Java/C# app groter is dan die van een C++ app... sure!
Dat hyperoptimized C++ sneller is dan hyperoptimized C#... sure!
Dat C# voor veel applicaties een fractie van de code nodig heeft van een C++ app... sure!
Dat de .NET omgeving het beste MS product is... my opinion!
Dat een heel groot deel van de informatica markt bestaat uit Java/C# development... sure!
Dat jij jezelf voor aap zet met je hoge-toren geblaat... sure!

Dat je veel weet mag best zijn, zo'n attittude kunnen we hier missen.

Ik heb overlaatst een eenvoudig system tray tooltje in elkaar geflanst om windows te arrangen zoals ik het wil met multi-monitor support en what else. Resultaat: een executable van enkele K groot, een minimale hoeveelheid code, geen last van performantie (niet dat dit een issue zou (kunnen) zijn) en wat nog.

Bovendien kun je nu blaten dat mijn app mss 10MB geheugen in beslag neemt door het .NET platform, maar dan is mijn eenvoudige reactie dezelfde als die van jouw: who cares.
- Het zijn SHARED libraries, nog een .NET app in het geheugen maakt het extra verbruik minimaal.
- Als het geheugen niet gebruikt wordt, dan swapt mijn OS het wel uit. De working set is quasi niets dus eenmaal uitgeswapt heb ik nog steeds geen performance penalty.

Ikzelf "ken" beide talen en het zijn beide mijn favorieten voor development in managed omgeving en development in unmanaged omgeving, linux, ... (Ik zie C# gewoon als (managed ((c)++)++))

Het is zelfs puur als niet-taalkennis een zeer interessante taal aangezien bepaalde problemen anders aangepakt worden dan in C++. Het zorgt dus zeker voor een rijkere kennis in programmeren algemeen. Ook naar later kan het zeker een plus zijn als je C# kent.

Algemene tip:
Google een paar dagen intensief op alles wat C# en .NET is en kijk of het je bevalt en of jouw programma past in de taal. (niet omgekeerd) Kies je alsnog voor C++ dan kan het wel mooi zijn om in je vrije tijd eens een C#-tooltje in elkaar te boksen.

[RayNbow]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
[...]

Zo lust ik er nog een paar Bovendien vergeet je volgens mij java.exe mee te nemen.

Al sinds een aantal versies van Azureus wordt er slechts 1 proces gestart, genaamd Azureus.exe, onder Windows. Vroeger had je idd een aparte launcher (Azureus.exe) en de werkelijke applicatie (javaw.exe), maar nu is het dus 1 proces (Azureus.exe).

Om iets van m'n trucje te onthullen, het CPU gebruik van Azureus steeg omdat ik 't venster minimaliseerde.

[FTL]

C# en Java ontwikkelen gewoon erg snel. Minimale inspanning met maximaal resultaat. Het wordt steeds meer declaratief (WAT je wil, niet per definitie HOE).

Bijkomend voordeel is dat de managed talen ook veel veiliger zijn out of the box. Type safety, checked indexes, sandboxen, garbage collection (niet expliciet destructen) e.d.

Ikzelf heb de laatste tijd met Netbeans, Eclipse en VS2005 gewerkt, ik moet met MS nageven: VS wint qua ontwikkel snelheid. Ja lees goed, ik heb het hier over de IDE, niet over de taal! Geen uitgesproken voorkeur voor Java of C#.

En jah: de standaard plumbing code wordt dan gegenereerd. Daar is niets mis mee: als je maar weet wat en hoe hij het doet. Wil je echt l33t zijn: er is mogelijkheid voor in deze talen en IDE's.

Ze zullen misschien wel wat trager zijn met bepaalde dingen of meer geheugen gebruiken maar ze hebben voordelen die vele malen belangrijker zijn: ontwikkel-snelheid en veiligheid.

In gemiddelde situaties zal het een gebruiker worst zijn of hij 4 of 5 ms moet wachten op resultaat. De server kant kan simpel en goedkoop de capaciteit uitgebreid worden mocht je toch die 20% extra snelheid willen. De kosten van hardware uitbreidingen zijn nog altijd goedkoper dan de uren van ontwikkelaars.

In praktisch elke applicatie zal de snelheid van managed talen meer dan voldoende zijn. Functionaliteit en ontwikkel snelheid zullen belangrijker zijn.
Programma's die als functionele eis: maximale snelheid hoe dan ook zullen misschien native talen moeten kiezen.

Alle ontwikkel tools die je nodig bent voor .net (of java for that matter) zijn gratis aanwezig en hebben zelfs open-source varianten, geen echte reden om bang te zijn voor vendor-lockin. de CLI is gewoon een standaard.

Vergis je niet, ben niet tegen c++ e.d., maar weet de dingen te relativeren.
Naar mijn idee heb je met C++ wat meer 'controle' en mischien snelheid, met als nadeel dat het ontwikkelen trager zal zijn.

Persoonlijk geeft ik dus vaak de voorkeur aan Visual Studio als IDE en .NET als framework (voelt meer native windows aan qua GUI) en C# als taal, toch C(++) achtige syntax.

[edit] Er zijn natuurlijk altijd situaties te bedenken dat sommige bovenstaande stellingen niet opgaan, het zal altijd per situatie bekeken moeten worden wat het slimst is om te gebruiken.

[ Voor 4% gewijzigd door FTL op 25-10-2007 08:05 ]

[whoami]

phobosdeimos schreef op woensdag 24 oktober 2007 @ 19:17:

MrBucket: over mijn kennis van zaken zou ik zeker niet twijfelen, dan ga je bedrogen uitkomen.

Kijk, ik kan natuurlijk ook over mezelf verklaren dat ik veel kennis heb op een bepaald vakgebied, maar daarmee is het nog altijd niet bewezen.

Daarnaast is het jammer dat dit topic helemaal verziekt is door mensen die met on-onderbouwde meningen komen.
Daarom: probeer eens niet op de man te spelen, kom met onderbouwde meningen ipv de knuppel in het hoenderhok te gooien met boude statements, anders zie ik me genoodzakt om dit topic te sluiten

[ Voor 16% gewijzigd door whoami op 24-10-2007 21:27 ]

[.Gertjan.]

Programmeertaal is toch slechts een gereedschap? (zo zie ik het in ieder geval) In principe is het handig om meerdere talen te kunnen gebruiken. Zelf ben ik op school "groot gebracht" met Java en een stuk C++. Toen vond ik C++ een stuk krachtiger, maar tegelijk ook moeilijker.

Na mijn opleiding ben ik me (vanwege het bedrijf waar ik ging werken) gaan specialiseren in .NET 1.1 en later 2.0 (C#) en dat is me eingelijk best goed bevallen. Ook ik was zoals sommige anderen een beetje terughoudend betreft .NET, omdat ik het eerst als een JAVA achtige clone zag en de platform onafhankelijkheid niet echt terug zag.

Maar toen ik er eenmaal mee werkte wilde ik eigenlijk niet meer terug. Toen had ik al een vermoeden dat het misschien toch erg populair kon worden en het nuttig zou zijn om me in .NET te specialiseren. En het lijkt inmiddels toch vrij populair (zie ook projecten als MONO en de hoeveelheid gevraagde .NET ontwikkelaars).

Binnenkort moet ik me "omscholen" naar VB.NET. Bij omscholen hoef je in principe alleen de syntax en een stuk van de standaard libraries kennen (libraries zijn nu niet van toepassing). Maar zelfs als je een hele tijd in .NET werkt weet je nog niet alle functionaliteiten binnen het framework. En het fijne is dat je meerdere talen kan gebruiken binnen .NET.

Ik geloof dat er ook boeken/online tutorials zijn die C++ ontwikkelaars helpen bij hun overstap naar .NET. Misschien nuttig om eens naar te kijken.

[farlane]

FTL schreef op woensdag 24 oktober 2007 @ 20:39:
In gemiddelde situaties zal het een gebruiker worst zijn of hij 4 of 5 seconden moet wachten op resultaat.

Die gemiddelde situatie is alleen van toepassing op jouw situatie want die toepassingen die ik maak wil de gebruiker ( of dat nou een mens of machine is ) echt niet zolang wachten.

Ik geloof dat er ook boeken/online tutorials zijn die C++ ontwikkelaars helpen bij hun overstap naar .NET

Waarom nou overstap? Kunnen we het niet gewoon erbij doen?

[FTL]

farlane schreef op woensdag 24 oktober 2007 @ 23:30:

Die gemiddelde situatie is alleen van toepassing op jouw situatie want die toepassingen die ik maak wil de gebruiker ( of dat nou een mens of machine is ) echt niet zolang wachten.

Ik bedoel het verschil in tijd natuurlijk, lees anders 4ms (C++) of 5ms (C#).
Dacht dat dat wel duidelijk was, toch maar ff uitgelegd.

[.Gertjan.]

farlane schreef op woensdag 24 oktober 2007 @ 23:30:
[...]


Die gemiddelde situatie is alleen van toepassing op jouw situatie want die toepassingen die ik maak wil de gebruiker ( of dat nou een mens of machine is ) echt niet zolang wachten.


[...]

Waarom nou overstap? Kunnen we het niet gewoon erbij doen?

good point

Met overstappen bedoel ik eigenlijk dat je geholpen wordt om aan de hand van je C++ kennis C# te leren... Na de "overstap" ben je (hopelijk) niet alle C++ kennis kwijt.

[riezebosch]

FTL schreef op woensdag 24 oktober 2007 @ 20:39:
[...]
Ze zullen misschien wel wat trager zijn met bepaalde dingen of meer geheugen gebruiken maar ze hebben voordelen die vele malen belangrijker zijn: ontwikkel-snelheid en veiligheid.
[...]

Vergeet niet de onderhoudbaarheid

.Gertjan. schreef op woensdag 24 oktober 2007 @ 21:40:
[...]
Ik geloof dat er ook boeken/online tutorials zijn die C++ ontwikkelaars helpen bij hun overstap naar .NET. Misschien nuttig om eens naar te kijken.

Zelf vond ik dit wel een goeie uitleg: Appendix D: C# for C++ Developers.
Let wel: het is een appendix van Professional C# 3rd edition (2004).

[EfBe]

Hydra schreef op woensdag 24 oktober 2007 @ 17:32:
[...]
Ervaring. Natuurlijk chargeerde ik nogal, het is OOK belangrijk, maar die 10%/90% regel geldt daar ook. Als je 10% snelheidswinst haalt met 90% van de inspanning, is het het vaak gewoon niet waard. Dat geldt ook voor server software.

Ervaring? Wat voor ervaring? Dit soort dingen moet je niet baseren op nattevingerwerk van de koude grond, maar harde feiten. Een toets van n=1 (jij) is volstrekt irrelevant. Met wat 'handwaving' wat opmerkingen plaatsen dat het wel zo zal zijn gebaseerd op eigen ervaring is niet toereikend om toegepast te worden in een andere situatie, plus wie zegt dat de situaties waar jij mee te maken hebt gehad beter af zijn in een VM gebruikende taal?

Dom voorbeeld horen? Ik maakte een aantal jaren geleden voor onze webapps (we praten over 1998-2002) de COM components vaak in VB6, omdat dat makkelijk was: geen gezeik met memory, veel code is native compiled (de runtime lib) etc.

Voor de gein heb ik een deel van die dingen toen eens in C++ herschreven. De code was qua grootte bijna gelijk. Door de smart pointer generation mbt COM components (ADO is com based en echt niet zo brak als de .NET marketeers je willen doen geloven) is het nauwelijks meer werk.

Veel meer tijd moeten investeren? Nee niet echt. Echter liep die code wel een klap harder dan die vb com components.

[EfBe]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
[...]

Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

Waarom moet er ingegaan worden op een BS argument? C# is een standaard, iedereen kan een implementatie maken (zie bv Mono).

Platformgebondenheid is sowieso altijd aanwezig. Of wil je beweren dat bij Java je geen gebondenheid hebt aan je applicatieserver of bij C++ niet aan de gebruikte libs? De illusie dat een random programma met veel functionaliteit overal compileerbaar is is precies dat: een illusie.

[Hydra]

Brent schreef op woensdag 24 oktober 2007 @ 19:41:
Even afgezien van opmerking drie, brengt hij weldegelijk een punt van C#/.net onder de aandacht, waar inderdaad niet inhoudelijk op ingegaan wordt, en dat is de (in bepaalde mate) platformgebondenheid. Of dat een probleem is voor de TS weet ik niet, maar kan een showstopper zijn.

Als je kiest voor Java OF C# is het sowieso makkelijk genoeg over te stappen later. C# heeft als 'nadeel' dan dat als je overstapt naar Java opeens een aantal dingen (delegates, properties) moet missen. Even wennen maar daar kom je wel doorheen.

Het is wat anders als je gaat webdevven want Asp.net is compleet anders dan JSP, en dan is ASP.Net 2 WEER compleet anders dan Asp.net (1).

whoami schreef op woensdag 24 oktober 2007 @ 21:26:
Daarom: probeer eens niet op de man te spelen, kom met onderbouwde meningen ipv de knuppel in het hoenderhok te gooien met boude statements, anders zie ik me genoodzakt om dit topic te sluiten

Sorry dat ik misschien een metadiscussie start hiermee, maar ik vind dit een beetje een vreemde manier van modden. Alle participanten 'straffen' omdat een gozer de arrogante lul uit zit te hangen.

EfBe schreef op donderdag 25 oktober 2007 @ 10:04:
Ervaring? Wat voor ervaring? Dit soort dingen moet je niet baseren op nattevingerwerk van de koude grond, maar harde feiten. Een toets van n=1 (jij) is volstrekt irrelevant. Met wat 'handwaving' wat opmerkingen plaatsen dat het wel zo zal zijn gebaseerd op eigen ervaring is niet toereikend om toegepast te worden in een andere situatie, plus wie zegt dat de situaties waar jij mee te maken hebt gehad beter af zijn in een VM gebruikende taal?

Nouja, als je tegenwoordig een project doet waarbij webservices of webapplicaties opgeleverd moeten worden, hoef je sowieso niet aan te komen met C++ lijkt me? Dat is mijn 'ervaring', dat de default basis .Net of Java is. Waarom is dat? Onderhoudbaarheid en ontwikkelsnelheid. Dat de executietijd marginaal langer is, is voor de opdrachtgever niet relevant.

Ik zeg niet dat Java / .Net ALTIJD de beste tool for the jo zijn, heck, in een project een tijdje terug is nog iemand (gelukkig niet ik) in COBOL bezig geweest, maar het meeste nieuwe spul code je daar niet in

Dom voorbeeld horen? Ik maakte een aantal jaren geleden voor onze webapps (we praten over 1998-2002) de COM components vaak in VB6, omdat dat makkelijk was: geen gezeik met memory, veel code is native compiled (de runtime lib) etc.

Voor de gein heb ik een deel van die dingen toen eens in C++ herschreven. De code was qua grootte bijna gelijk. Door de smart pointer generation mbt COM components (ADO is com based en echt niet zo brak als de .NET marketeers je willen doen geloven) is het nauwelijks meer werk.

Veel meer tijd moeten investeren? Nee niet echt. Echter liep die code wel een klap harder dan die vb com components.

Ik begrijp niet helemaal wat je hiermee wil bereiken, maar ik zie niet hoe de snelheid van een VB COM component hier relevant is. 'Vroegah' was ik ook fijn in VBS binnen ASP bezig, maar dat vind ik niet relevant in deze discussie.

Daarnaast is iets 'herschrijven' kwa tijdsinvesteringsvergelijking niet helemaal eerlijk. Als ik een Java app van mij herschrijf in Java, is java opeens ook 2x zo snel als java kwa devven?

[.Gertjan.]

Hydra schreef op donderdag 25 oktober 2007 @ 11:52:
[...]
Als je kiest voor Java OF C# is het sowieso makkelijk genoeg over te stappen later. C# heeft als 'nadeel' dan dat als je overstapt naar Java opeens een aantal dingen (delegates, properties) moet missen. Even wennen maar daar kom je wel doorheen.

Het is wat anders als je gaat webdevven want Asp.net is compleet anders dan JSP, en dan is ASP.Net 2 WEER compleet anders dan Asp.net (1).

Zo heel veel verschillen .NET 1.0 en 2.0 toch niet van elkaar. Wel ben ik met je eens dat beiden anders werken dan PHP, JSP en het klassieke ASP (3), omdat het hele model eigenlijk anders in elkaar zit. Werken met pagina's als objecten, de flow van asp.net en andere zaken. Dat is even wennen.

Maar 1.0 en 2.0 verschillen alleen van elkaar op het gebied van "leuke extratjes" zoals masterpages. Neemt niet weg dat ik als ASP.NET ontwikkelaar hier niet blij mee was, ik kon bij wijze van spreken juist een vreugde sprongetje maken

Over java weet ik niet helemaal of je gelijk hebt, heeft java niet inmiddels ook de mogelijkheid om properties te maken (is al ruim 3 jaar geleden dat ik met java heb gewerkt). En anders maak je de get en set methodes aan (kun je vast wel een snippet of plugin voor vinden/maken), is denk ik een kwestie van gewoon aanleren En betreft delegates, ik dacht dat java dat ook kon... Maar goed java had dan weer anonieme methodes, want .net pas sinds kort heeft.

Zo heeft iedere taal zijn charme. Zoals het with keyword in visual basic. Die miste ik in het begin (toen ik na een tijdje VB als hobby naar de informatica opleiding ging waar we java kregen), maar na verloop van tijd kijk/werk je daar omheen en mis je het niet zo zeer meer

[EfBe]

Hydra schreef op donderdag 25 oktober 2007 @ 11:52:
[...]
Nouja, als je tegenwoordig een project doet waarbij webservices of webapplicaties opgeleverd moeten worden, hoef je sowieso niet aan te komen met C++ lijkt me? Dat is mijn 'ervaring', dat de default basis .Net of Java is. Waarom is dat? Onderhoudbaarheid en ontwikkelsnelheid. Dat de executietijd marginaal langer is, is voor de opdrachtgever niet relevant.

Ik zie niet in wat een taal met onderhoudbaarheid te maken heeft. Ontwikkelsnelheid is ook niet 'vanzelfsprekend korter' in een VM gebruikende taal, puur omdat er een GC in zit. Mensen die de STL als hun broekzak kennen, rennen rondjes om jou en je java met wellicht nog minder geinvesteerde tijd ook. Niet onderhoudbaar? Kost erg veel tijd? Lijkt me niet, want is het niet zo dat de meeste tijd van een softwareproject wordt gespendeerd aan andere zaken dan code tikken?

Overigens, als ik C++ door php vervang, is het dan ineens zo dat VM gebruikende talen brak zijn want de ontwikkeltijd is langer dan bij PHP?

Ik zeg niet dat Java / .Net ALTIJD de beste tool for the jo zijn, heck, in een project een tijdje terug is nog iemand (gelukkig niet ik) in COBOL bezig geweest, maar het meeste nieuwe spul code je daar niet in

Volgens mij weet jij niet half in wat voor talen de meeste software geschreven wordt. Die paar websites die gebouwd worden hier en daar... dat is een fractie van de bakken met code die overal ter wereld aan applicaties worden toegevoegd. En ja, nieuwe dingen op grote machines worden wellicht nog altijd in cobol gedaan, of RPG, domweg omdat de rest dat ook is. Ouwe-lulle code? Troep? nee, realiteit.

[...]
Ik begrijp niet helemaal wat je hiermee wil bereiken, maar ik zie niet hoe de snelheid van een VB COM component hier relevant is. 'Vroegah' was ik ook fijn in VBS binnen ASP bezig, maar dat vind ik niet relevant in deze discussie.

Het is wellicht een rare opmerking, maar 'nieuwe' software is echt niet relevant voor deze wereld. het gros van de software developers werkt al voor korte of langere tijd aan bestaande code en dat wordt alleen maar erger.

Wat ik wilde aangeven is dat een VM gebruikende taal (VB) met dezelfde karakteristieken als Java en C# mbt geheugenbeheer en pointermanagement niet zoveel sneller is qua ontwikkelsnelheid als C++ voor hetzelfde programma. Tuurlijk, een UI bouwen in C++ is wellicht wat lastiger, maar is dat de applicatie an sig? Lijkt me niet meer dan een onderdeel.

Daarnaast is iets 'herschrijven' kwa tijdsinvesteringsvergelijking niet helemaal eerlijk. Als ik een Java app van mij herschrijf in Java, is java opeens ook 2x zo snel als java kwa devven?

Lees die opmerking nu eens over, en ga dan eens nadenken waar de meeste tijd kennelijk gaat zitten mbt software development en je hebt zelf antwoord gegeven of het echt relevant is welke taal je gebruikt (ok, brainfuck daargelaten ) mbt ontwikkelsnelheid. (hint: als ik dus gewoon goed nadenk en daar 2/3e van de tijd aan besteed, boeit het niet in welke taal ik het opschrijf)

[Hydra]

EfBe schreef op donderdag 25 oktober 2007 @ 13:00:
Het is wellicht een rare opmerking, maar 'nieuwe' software is echt niet relevant voor deze wereld. het gros van de software developers werkt al voor korte of langere tijd aan bestaande code en dat wordt alleen maar erger.

*shrug*

Best, we lullen langs mekaar heen. Ik zeg dat mijn ervaring is dat NIEUWE systemen (en dan heb ik het over multi-tier systemen met zowel een frontoffice deel alsook een customer facing webapp interface) in projecten waar WIJ inzitten 9 van de 10 keer in Java of .Net gebouwd worden (en die 10e is dan PHP). Ik ben op dit moment met een project bezig waarbij we een stuk infrastructuur aan het ombouwen zijn naar een Java SOA structuur omdat de oude meuk (Cap Gemini zooi) te ononderhoudbaar is bijvoorbeeld. En dit is bij een groot overheidsbedrijf hier in NL. Dit is mijn ervaring. Je hebt 100% gelijk dat er een hoop oude systemen zijn waar dingen bijgeklust worden (vandaar m'n opmerking over COBOL, ik heb dat ook gezien ja, alleen de uitvoer daarvan werd door een Java service verwerkt), maar ik refereerde aan NIEUWE systemen.

Een discussie prima, maar aan het typische PRG ik-weet-het-beter haantjesgedrag heb ik een broetje dood. Dus: toedels.

[EfBe]

Hydra schreef op donderdag 25 oktober 2007 @ 13:50:
[...]
*shrug*
Best, we lullen langs mekaar heen. Ik zeg dat mijn ervaring is dat NIEUWE systemen (en dan heb ik het over multi-tier systemen met zowel een frontoffice deel alsook een customer facing webapp interface) in projecten waar WIJ inzitten 9 van de 10 keer in Java of .Net gebouwd worden (en die 10e is dan PHP).

Dat is fijn, maar jij presenteert het alsof het DE realiteit is voor ALLE software. Dat is waar ik een opmerking over had.

Ik ben op dit moment met een project bezig waarbij we een stuk infrastructuur aan het ombouwen zijn naar een Java SOA structuur omdat de oude meuk (Cap Gemini zooi) te ononderhoudbaar is bijvoorbeeld. En dit is bij een groot overheidsbedrijf hier in NL. Dit is mijn ervaring. Je hebt 100% gelijk dat er een hoop oude systemen zijn waar dingen bijgeklust worden (vandaar m'n opmerking over COBOL, ik heb dat ook gezien ja, alleen de uitvoer daarvan werd door een Java service verwerkt), maar ik refereerde aan NIEUWE systemen.

Maar het gros van de developers op aarde maakt al geen NIEUWE systemen meer. Ga dan niet jouw ervaringen projecteren op de groep developers als zijnde 'de waarheid' want die is echt wel even anders, hoe hard jij ook wilt gaan roepen dat wat jij meemaakt toch echt erop lijkt alsof iedereen dat meemaakt.

Een discussie prima, maar aan het typische PRG ik-weet-het-beter haantjesgedrag heb ik een broetje dood. Dus: toedels.

Hoe kun je een discussie houden wanneer jij niet kunt hebben dat iemand anders een andere mening heeft en wellicht verstand van zaken heeft? Of denk jij dat ik geen reet verstand heb van waarover ik praat?

[Cloud]

EfBe schreef op donderdag 25 oktober 2007 @ 13:00:
Ik zie niet in wat een taal met onderhoudbaarheid te maken heeft. Ontwikkelsnelheid is ook niet 'vanzelfsprekend korter' in een VM gebruikende taal, puur omdat er een GC in zit. Mensen die de STL als hun broekzak kennen, rennen rondjes om jou en je java met wellicht nog minder geinvesteerde tijd ook. Niet onderhoudbaar? Kost erg veel tijd? Lijkt me niet, want is het niet zo dat de meeste tijd van een softwareproject wordt gespendeerd aan andere zaken dan code tikken?

NOFI: Misschien doe je opzettelijk alsof je niet begrijpt wat de beste man bedoelt, of misschien snap je het echt gewoon niet.
We hebben het over nieuwe projecten. En in dit licht, hebben we het ook over nieuwe mensen die aan die projecten werken. Tuurlijk een ervaren rot in C++ doet dingen sneller dan een beginner die met .NET/Java werkt. Maar daar gaat het helemaal niet over, we hebben het over doorsnee programmeurs.

De productiviteit van .NET ligt nu eenmaal (veel) hoger dan die van C++ als je die van doorsnee gebruikers vergelijkt. Zeker voor beginnende programmeurs! Er is een hele berg aan componenten/api's kant-en-klaar om te gebruiken voor de meest uit een lopende zaken. Onderhoudbaarheid is ook beter in .NET simpelweg vanwege het feit dat de taal zoveel simpeler is. Dat betekent dat nieuwe mensen zich sneller in de code kunnen werken, dit ook omdat er gebruik gemaakt kan worden van standaard functionaliteit die zij al kennen.

Goed, dat is dat. Dit is vooralsnog een discussie die geen donder met de vraag van de TS te maken heeft.

@TS:
Het lijkt mij een mooi moment voor je om (al dan niet geheel) over te stappen op C#. Zoals al gezegd is en je ongetwijfeld zelf ook hebt gezien, er zijn verschrikkelijk veel .NET/Java vacatures. Het aantal C++ begint gewoon af te nemen.

Daarnaast, als je met C# leert werken, leer je een framework kennen. Je kunt dus web applicaties, webservices, standalone applicaties, mobile applicaties maken, allemaal vanuit één framework en taal. Dit is m.i. een van de grootste voordelen van een overstap. Je bent klaar voor de toekomst, want hoe je het ook wendt of keert, het aantal C++ vacatures zie ik niet meer (fors) stijgen

[.oisyn]

wolkje schreef op donderdag 25 oktober 2007 @ 16:03:
Daarnaast, als je met C# leert werken, leer je een framework kennen. Je kunt dus web applicaties, webservices, standalone applicaties, mobile applicaties maken, allemaal vanuit één framework en taal. Dit is m.i. een van de grootste voordelen van een overstap. Je bent klaar voor de toekomst, want hoe je het ook wendt of keert, het aantal C++ vacatures zie ik niet meer (fors) stijgen

Maar als senior C++ developer zie ik mijn rate daarentegen wel stijgen, want ik word zeldzaam. Dus idd, iedereen moet vooral gaan .Netten

[Cloud]

.oisyn schreef op donderdag 25 oktober 2007 @ 16:08:
[...]

Maar als senior C++ developer zie ik mijn rate daarentegen wel stijgen, want ik word zeldzaam. Dus idd, iedereen moet vooral gaan .Netten

Fair enough Zo kun je het natuurlijk ook bekijken.

[EfBe]

wolkje schreef op donderdag 25 oktober 2007 @ 16:03:
[...]
NOFI: Misschien doe je opzettelijk alsof je niet begrijpt wat de beste man bedoelt, of misschien snap je het echt gewoon niet.

Erm... hij deed een opmerking over onderhoudbaarheid e.d. mbt taalkeuze. Die connectie is er echt niet, onderhoudbare software kan in alle talen en onmogelijke crap evenzeer.

We hebben het over nieuwe projecten. En in dit licht, hebben we het ook over nieuwe mensen die aan die projecten werken. Tuurlijk een ervaren rot in C++ doet dingen sneller dan een beginner die met .NET/Java werkt. Maar daar gaat het helemaal niet over, we hebben het over doorsnee programmeurs.

Mja, wat is doorsnee programmeur. Ik wil niet arrogant overkomen, maar de doorsnee programmeur op .NET is echt niet zo productief bezig, omdat deze zich veelal meer laat verleiden door het spenderen van veel tijd in designers en andere tijdvreters en minder in het goed opzetten van code en het schrijven van slimme classes.

De productiviteit van .NET ligt nu eenmaal (veel) hoger dan die van C++ als je die van doorsnee gebruikers vergelijkt. Zeker voor beginnende programmeurs!

Ik ben het wel met je eens dat beginners wellicht iets meer uit .net krijgen dan uit C++. Maar beginners moeten zich geen illusies maken: ze zijn in alle talen een beginner en dat heeft niets met de taal te maken, het zijn beginnende programmeurs, dus prutsen ze zich een slag in de rondte. Dat is niet erg, daar zijn het beginners voor. Maar programmeren heeft niet zoveel met talen an sig te maken, dus welke taal je kiest is eigenlijk irrelevant. Vind je de taal WEL relevant, dan beschouw je de programmeur als een menselijke code generator. Nu is het echter zo dat een digitale code generator het er meestal wat beter vanaf brengt, dus om nu in te gaan zetten op het noeste typewerk, dat lijkt me niet erg slim.

Er is een hele berg aan componenten/api's kant-en-klaar om te gebruiken voor de meest uit een lopende zaken. Onderhoudbaarheid is ook beter in .NET simpelweg vanwege het feit dat de taal zoveel simpeler is. Dat betekent dat nieuwe mensen zich sneller in de code kunnen werken, dit ook omdat er gebruik gemaakt kan worden van standaard functionaliteit die zij al kennen.

Maar een C++ programmeur kent ook zn libraries.
En onderhoudbaarheid heeft geen ruk met taalkeuze te maken! Ik vind het overigens knap dat mensen die aan nieuwe dingen sleutelen, een voorstelling kunnen maken hoe onderhoudbaar .NET code is tov. hoe onderhoudbaar C++ code is. Immers, wanneer zijn deze experts op het gebied van onderhoudbaarheid dan bezig met een project dat een grote applicatie van versie x naar versie y migreert? (en waarbij de software al een tijdje bestaat)

Hint: erg belangrijk bij onderhoudbaarheid is dat je begrijpt wat de code doet. Een transactional graph versioner in C# is voor jou abracadabra als jij niet weet wat een graph versioner is en hoe transacties werken op graphs van objects in-memory.

Goed, dat is dat. Dit is vooralsnog een discussie die geen donder met de vraag van de TS te maken heeft.

Waarom niet? Omdat jij dat vindt? Ik zie allerlei mensen uitspraken doen mbt .NET en andere VM based platforms mbt onderhoudbaarheid, tijd die het kost om software te schrijven en wat al niet...

Als je daar dan geen kanttekeningen bij mag plaatsen, mij best, maar hou dan geen discussie.

Daarnaast, als je met C# leert werken, leer je een framework kennen. Je kunt dus web applicaties, webservices, standalone applicaties, mobile applicaties maken, allemaal vanuit één framework en taal. Dit is m.i. een van de grootste voordelen van een overstap. Je bent klaar voor de toekomst, want hoe je het ook wendt of keert, het aantal C++ vacatures zie ik niet meer (fors) stijgen

waarom dan geen Java? of ruby? No offence, en als woorden van een C# MVP zoals ondergetekende klinkt dit wellicht leip, maar ik zou echt voor Java kiezen ipv C#.

[Cloud]

EfBe schreef op donderdag 25 oktober 2007 @ 21:01:
[heel veel praat]
Waarom niet? Omdat jij dat vindt? Ik zie allerlei mensen uitspraken doen mbt .NET en andere VM based platforms mbt onderhoudbaarheid, tijd die het kost om software te schrijven en wat al niet...

Dat waren allemaal offtopic reacties. Daarom stelde ik voor om weer terug naar de TS te gaan. Het gaat hier om de vraag of het wenselijk is voor de TS is om over te stappen van C++ naar C# (of Java), en niet om onderhoudbaarheid, ontwikkelsnelheid etc. En dan kunnen nog zo veel lui daar over blaten, dat betekent nog steeds niet dat dit topic daarvoor bedoeld is. Toch?

Kortom: ik vind helemaal niets, ik lees de topicstart.

[...]
waarom dan geen Java? of ruby? No offence, en als woorden van een C# MVP zoals ondergetekende klinkt dit wellicht leip, maar ik zou echt voor Java kiezen ipv C#.

En jij gaat ons natuurlijk niet vertellen waarom je bijvoorbeeld Java zou moeten kiezen. Wederom een loze uitspraak zonder onderbouwing, waar (ik herhaal) de TS geen donder aan heeft.

offtopic:
sorry als dit een beetje persoonlijk over komt, maar je weet blijkbaar niet van ophouden

Nog maar een poging tot ontopic:
Overigens kan ik Ruby meteen al afraden. Het is een leuk taaltje, met veel potentie, maar er is werkelijk niemand die er commercieel in bezig is (even uitgaande van vacatures). Eerst maar even een paar jaar wachten voordat dat aantrekkelijk wordt. Hobbyen kan natuurlijk altijd.

Trouwens Java is net zo'n goede keuze als C# hoor, het punt wat ik probeerde te maken is dat overstappen van C++ af, wel een goede beslissing is in mijn ogen. De markt heeft veel meer vraag naar Java en .NET programmeurs.
Overigens al wel weer lang geleden dat de TS een reactie geplaatst heeft. Issie al overgestapt ofzo?