Van C# Naar C/C++

[BlietZ]

Goedendag topic bezoeker

Over een week begin ik op mijn HBO opleiding (Technische Informatica) aan een nieuw blok (leerjaar 2 Blok 3). Ik heb mij al een beetje ingelezen over dit blok en kwam erachter (wist dit van te voren ook, maar niet zo snel verwacht) dat het nu de opdracht wordt om C/C++ te begrijpen en de opdrachten hierin te schrijven. Een niet Object Oriënted taal dus.
In het 1e leerjaar hebben wij geleerd om in C# onze programma's te schrijven. In leerjaar 2 werd dit losser gelaten en mocht je ook in andere talen de opdrachten maken, het nadeel is dat wij altijd zijn verder gegaan in C# omdat wij hier bekend mee waren.

Nu weet ik dat de stap van C# naar C++ niet heel groot is, maar toch zou ik een boek fijn vinden (mag ook digitaal)
Mijn vraag is dus, kan iemand mij adviseren welke literatuur ik hier het beste voor kan doornemen? En dan voornamelijk van C# naar C++ of C gericht.

Alvast bedankt voor je reactie!

[NMe]

Vrijwel alle boeken zullen eerder gaan over de stap van C(++) naar C# en niet andersom, omdat dat een veel meer gemaakte overstap is. Het beste boek over C++ zelf is volgens mij nog steeds de bijbel, maar ik ben er al een beetje uit dus ik weet het niet zeker.

Heeft je school trouwens geen adviezen? Die zullen naar ik aanneem wel vaker met dit bijltje gehakt hebben.

[supreme tweaker]

Je zou kunnen proberen te spelen met unsafe code in C#. Hierin kun je vast wat proberen met pointers te spelen.

Ik heb het zelf de stap gemaakt door een stuk of 10 blokuren door te brengen met een goede C++ docent. Je zal toch bij het begin moeten beginnen en practica met hulp daarbij werkte voor mij prima!

Overigens is objectorientatie in C++ goed mogelijk hoor

[pedorus]

BlietZ schreef op dinsdag 04 februari 2014 @ 21:40:
Een niet Object Oriënted taal dus.

Ga je nu c of c++ gebruiken?

De eerste chapters van de c++ bijbel staan hier online: http://isocpp.org/tour

[Hydra]

NMe schreef op dinsdag 04 februari 2014 @ 22:17:
Vrijwel alle boeken zullen eerder gaan over de stap van C(++) naar C# en niet andersom, omdat dat een veel meer gemaakte overstap is. Het beste boek over C++ zelf is volgens mij nog steeds de bijbel, maar ik ben er al een beetje uit dus ik weet het niet zeker.

Dat boek is ook gewoon nog steeds erg goed.

In mijn tijd hebben we die overstap ook gemaakt, maar dan van Java naar C++. Alles wat je moet weten staat prima in dat boek uitgelegd. Mij lijkt het dat dat boek ook op de lijst zou moeten staan als je opleiding met C++ aan de slag gaat.

[ Voor 7% gewijzigd door Hydra op 05-02-2014 09:12 ]

[BlietZ]

NMe schreef op dinsdag 04 februari 2014 @ 22:17:
Heeft je school trouwens geen adviezen? Die zullen naar ik aanneem wel vaker met dit bijltje gehakt hebben.

Het vak is nog niet begonnen, en ik wil graag voor de les al een beetje bekend zijn.

supreme tweaker schreef op dinsdag 04 februari 2014 @ 22:20:
Overigens is objectorientatie in C++ goed mogelijk hoor

pedorus schreef op dinsdag 04 februari 2014 @ 22:22:
[...]
Ga je nu c of c++ gebruiken?

Ah ok! ik was er vanuit gegaan dat C++ niet object oriented is, de opdracht is namelijk als volgt:
3. Implementatie. Deze bevat minimaal:
a. Werkende code geschreven in C / C++ (geen OO)

Bedankt voor de info in ieder geval! Nu kan ik ff vooruit met die digitale versie, en zodra de lessen beginnen zal de docent vast en zeker het een en ander toelichten. Een extra taal leren is nooit verkeerd.

[EddoH]

Beetje vage eis. Waarom zou je geen OO gebruiken als je de beschikking hebt tot C++. Wordt er misschien bedoeld dat OO geen eis is maar wel mag?

[BlietZ]

EddoH schreef op woensdag 05 februari 2014 @ 11:26:
Beetje vage eis. Waarom zou je geen OO gebruiken als je de beschikking hebt tot C++. Wordt er misschien bedoeld dat OO geen eis is maar wel mag?

Dat zou ook kunnen, of omdat we C# hebben geleerd, en je perse C of C++ moet gebruiken. Alleen niet OO schrijven in C++..
Ik krijg het zeker te horen zodra de lessen beginnen.

[ Voor 42% gewijzigd door BlietZ op 05-02-2014 11:49 ]

[NMe]

BlietZ schreef op woensdag 05 februari 2014 @ 11:09:
[...]

Het vak is nog niet begonnen, en ik wil graag voor de les al een beetje bekend zijn.

Dat het vak nog niet begonnen is wil niet zeggen dat je de leraar niet kan aanspreken of mailen.

EddoH schreef op woensdag 05 februari 2014 @ 11:26:
Beetje vage eis. Waarom zou je geen OO gebruiken als je de beschikking hebt tot C++. Wordt er misschien bedoeld dat OO geen eis is maar wel mag?

Zo vreemd is zo'n eis niet. Als je alleen OO hebt geprogrammeerd en je vervolgens op de arbeidsmarkt gedumpt wordt waar je embedded software moet programmeren met C dan sta je ineens mooi te kijken. Het zal niet meer zijn dan een kwestie van je een beetje non-OO-ervaring op laten doen zodat je het in elk geval eens gezien hebt.

[EddoH]

NMe schreef op woensdag 05 februari 2014 @ 11:55:

Zo vreemd is zo'n eis niet. Als je alleen OO hebt geprogrammeerd en je vervolgens op de arbeidsmarkt gedumpt wordt waar je embedded software moet programmeren met C dan sta je ineens mooi te kijken. Het zal niet meer zijn dan een kwestie van je een beetje non-OO-ervaring op laten doen zodat je het in elk geval eens gezien hebt.

Ik doelde meer op de combinatie C++ en niet-OO. Doe dan als toegestane taal alleen C, wat in de embedded wereld vaker gebruikt wordt. C++ is oorspronkelijk ontwikkeld als uitbreiding op C om juist OO mogelijk te maken.

De eis zelf om OO niet toe te staan kan ik wel inkomen.

[ Voor 5% gewijzigd door EddoH op 05-02-2014 12:03 ]

[NMe]

EddoH schreef op woensdag 05 februari 2014 @ 12:01:
[...]


Ik doelde meer op de combinatie C++ en niet-OO. Doe dan als toegestane taal alleen C, wat in de embedded wereld vaker gebruikt wordt. C++ is oorspronkelijk ontwikkeld als uitbreiding op C om juist OO mogelijk te maken.

De eis zelf om OO niet toe te staan kan ik wel inkomen.

C++ voegt natuurlijk nog wel meer toe bovenop C dan alleen OO. Niet in de laatste plaats strings in plaats van character arrays en andere/makkelijkere manieren om met input en output om te gaan. Daar kun je prima gebruik van maken zonder een letter OO te schrijven.

Daarbij is C++ sowieso niet zuiver OO maar hybride, dus de programmeur kan zelf kiezen of hij OO gebruikt of niet en áls hij dat doet, of hij het al dan niet combineert met puur procedurele code.

[Ghannes]

Het boek van Straustrup is inderdaad een must have voor elke C++ engineer. Heb nog een exemplaar liggen, mocht je interesse hebben

[EddoH]

NMe schreef op woensdag 05 februari 2014 @ 12:44:
[...]

C++ voegt natuurlijk nog wel meer toe bovenop C dan alleen OO. Niet in de laatste plaats strings in plaats van character arrays en andere/makkelijkere manieren om met input en output om te gaan. Daar kun je prima gebruik van maken zonder een letter OO te schrijven.

Daarbij is C++ sowieso niet zuiver OO maar hybride, dus de programmeur kan zelf kiezen of hij OO gebruikt of niet en áls hij dat doet, of hij het al dan niet combineert met puur procedurele code.

Ik vind het gewoon nutteloos om C++ te pakken om vervolgens krampachtig de OO features te vermijden. Het is van weinig educatieve waarde en het voelt geforceerd. Doe dan een real-world scenario, en pak C, zoals je bij een embedded platform vaak tegenkomt.

Maargoed, aan deze discussie heeft de TS ook niets.

[ Voor 3% gewijzigd door EddoH op 05-02-2014 14:03 ]

[devvy]

Ik ken zelf C# niet goed, maar wel Java en C++. Het beste kan je C++ helemaal van de grond af leren, zonder C# in je achterhoofd te hebben. Advies: download een C++ compiler zoals Visual C++ Express en probeer wat samples uit.
Een paar jaar geleden heb ik nog een cursus C++ ontwikkeld dus als je in de buurt woont dan wil ik die best geven

[ThomasG]

Ik denk dat een groot struikelblok voor mensen die van Java en/of C# naar C/C++ gaan, dat Java en C# talen met een hogere abstractie zijn, en "virtual draaien." Vooral bij C# gaat een heleboel "vanzelf." Veel dingen zijn al in de syntax ingebouwd (al komt dat met C++11 en C++14 ook al steeds meer.) Daarnaast kun de garbage collector een beetje sturen, maar het geheugen beheer gaat automagisch. Bij talen als C++ is het belangrijk om goed in het hoofd te hebben hoe een processor omgaat met het geheugen, de stack, de heap, etc. Dat is opzicht niet zo moeilijk, en bij kleine projecten vaak niet zon probleem, maar wel fundamenteel om de taal goed onder de knie te krijgen. Omdat je daar lelijke fouten mee kunt maken, en dat is voor veel mensen een struikelblok (uit mijn ervaring.)

[LOTG]

Memory management en pointers zijn vooral struikelblokken als je van een managed taal af komt.
Naar C++ is nog niet zo een groot probleem, maar naar C is dat een erg grote stap. C++ voegt echt heel veel handige dingen aan C toe buiten object orientation.

Verder zijn er vooral dingen die al standaard in C# verwerkt zitten en niet in C++. Boost is overigens een veel gebruikte library voor C++ om veel gebruikte zaken te toe te voegen (smart pointers bijvoorbeeld).

[EddoH]

LOTG schreef op woensdag 05 februari 2014 @ 15:09:
Memory management en pointers zijn vooral struikelblokken als je van een managed taal af komt.
Naar C++ is nog niet zo een groot probleem, maar naar C is dat een erg grote stap. C++ voegt echt heel veel handige dingen aan C toe buiten object orientation.

Verder zijn er vooral dingen die al standaard in C# verwerkt zitten en niet in C++. Boost is overigens een veel gebruikte library voor C++ om veel gebruikte zaken te toe te voegen (smart pointers bijvoorbeeld).

Die je dan niet mag gebruiken omdat die OO zijn

[Kevinp]

C++ is zeker object orientated. En probeer dat ook zo veel mogelijk te doen.

De beste tips (algemeen programmeren)

Pointers zijn niet nodig (tuurlijk zijn er uitzonderingen, maar erg vaak is dit niet nodig)

"New" heb je echt maar zelden nodig. Object p("bla","bla"). gaat net zo goed als Ojbect p = new Object("bla", "bla" ).

Ik weet niet of je STL mag/moet gebruiken (niet dat je er aan ontkomt). Maar kijk wat daar in zit. En afhankelijk van de compiler kijk ook naar de c++11 standaard. Hier zitten gewoon handige dingen in.


Tip voor memory leaks (niet qua snelheid, maar zo complex zijn school projecten toch niet). Kijk eens naar unique pointesr en shared pointers. Deze lossen je problemen rondom "New" op als je memory leaks hebt.

[Markieman]

ThomasG schreef op woensdag 05 februari 2014 @ 14:41:
Ik denk dat een groot struikelblok voor mensen die van Java en/of C# naar C/C++ gaan, dat Java en C# talen met een hogere abstractie zijn, en "virtual draaien." Vooral bij C# gaat een heleboel "vanzelf." Veel dingen zijn al in de syntax ingebouwd (al komt dat met C++11 en C++14 ook al steeds meer.) Daarnaast kun de garbage collector een beetje sturen, maar het geheugen beheer gaat automagisch. Bij talen als C++ is het belangrijk om goed in het hoofd te hebben hoe een processor omgaat met het geheugen, de stack, de heap, etc. Dat is opzicht niet zo moeilijk, en bij kleine projecten vaak niet zon probleem, maar wel fundamenteel om de taal goed onder de knie te krijgen. Omdat je daar lelijke fouten mee kunt maken, en dat is voor veel mensen een struikelblok (uit mijn ervaring.)

Dit.

Probeer niet een wijsneus te zijn, maar ga gewoon naar de colleges en laat je uitleggen hoe C++ werkt.
Juist de "techniek", die door de hogere talen afgeschermd wordt is essentieel om goed uitgelegd te krijgen.
Ik vind het overigens vreemd dat een opleiding ervoor kiest eerst C# te leren en dan pas C++, het had imo handersom gemoeten.

Het risico van je zelf verdiepen in dit soort materie is dat je dingen verkeerd begrijpt, straks ga je nog dit soort uitspraken doen:

Pointers zijn niet nodig.

[gast128]

C++ is een hybride taal. Je kan oo programmeren maar ook bv generiek programmeren wordt goed ondersteund. Voor Java en c# programmeurs is handmatig memory management vaak het grootste probleem. Modern c++ lost dat op door 'vector' (ipv dynamische arrays) en smart pointers (ipv ruwe pointers).

Het beste boek over C++ zelf is volgens mij nog steeds de bijbel

Stroustrup's boek is geen goed leerboek, maar meer als 2^e boek voor verdieping. Ik heb het zelf 16 jaar geleden geleerd met 'Aan de slag met c++', maar ik weet niet hoe goed dit boek modern c++ of de std library beschrijft. Goed programmeren draait namelijk ook om library kennis, zodat je bewezen standaard oplossingen gebruikt. Als je echt serieus c++ wil oppakken zou je daarna ook nog Sutter's en Scott Meyers literatuur tot je moet nemen.

[NMe]

gast128 schreef op woensdag 05 februari 2014 @ 18:56:
Stroustrup's boek is geen goed leerboek, maar meer als 2^e boek voor verdieping. Ik heb het zelf 16 jaar geleden geleerd met 'Aan de slag met c++', maar ik weet niet hoe goed dit boek modern c++ of de std library beschrijft.

Het "probleem" is dat de topicstarter al kan programmeren (of in elk geval de basis daarvan beheerst) en dat de meeste boeken over C++ juist ingaan op alle OO-mogelijkheden en de TS die juist niet mag gebruiken. Vandaar ook dat Stroustrup's boek misschien niet eens zo'n slecht plan is: de basale werking van de taal snapt hij al omdat hij C# kent, al het andere kan hij doelgericht opzoeken.

[Squ1zZy]

NMe schreef op woensdag 05 februari 2014 @ 19:07:
[...]

Het "probleem" is dat de topicstarter al kan programmeren (of in elk geval de basis daarvan beheerst) en dat de meeste boeken over C++ juist ingaan op alle OO-mogelijkheden en de TS die juist niet mag gebruiken. Vandaar ook dat Stroustrup's boek misschien niet eens zo'n slecht plan is: de basale werking van de taal snapt hij al omdat hij C# kent, al het andere kan hij doelgericht opzoeken.

Maar niets voor beginners? Kan ik niet helemaal opmaken uit de tekst.

[Hydra]

gast128 schreef op woensdag 05 februari 2014 @ 18:56:
Stroustrup's boek is geen goed leerboek, maar meer als 2^e boek voor verdieping. Ik heb het zelf 16 jaar geleden geleerd met 'Aan de slag met c++', maar ik weet niet hoe goed dit boek modern c++ of de std library beschrijft. Goed programmeren draait namelijk ook om library kennis, zodat je bewezen standaard oplossingen gebruikt. Als je echt serieus c++ wil oppakken zou je daarna ook nog Sutter's en Scott Meyers literatuur tot je moet nemen.

Niet mee eens. Voor iemand die al kan programmeren is dat boek perfect.

[BlietZ]

Ik waardeer alle reacties! Dit helpt mij in ieder geval goed op weg.
Het rooster is vandaag eindelijk bekend geworden en as maandag komen we bij elkaar. De tips van de docent en verdere uitleg over de opdrachten drop ik sowieso hier voor de geïnteresseerden

[Kevinp]

Markieman schreef op woensdag 05 februari 2014 @ 17:29:
[...]

t soort materie is dat je dingen verkeerd begrijpt, straks ga je nog dit soort uitspraken doen:


[...]

Ik sta bij mijn standpunt. Wanneer je begint met C++ programmeren en dat OO doet zijn pointers slechts zelden echt nodig.

Ik durf zelfs te stellen dat in de meeste code er pointers worden gebruikt waar dit meestal een teken van onkunde is omdat er een keuze is gemaakt in het opzetten van de structuur.

Die uitspraak was natuurlijk erg zwart wit, maar ik denk dat in elke schoolopdracht je pointers of het doorgeven / opslaan van pointers kan vermijden door goede objecten te creëren.

Let wel ik zie pointers en references als verschillende dingen. Hoewel sterk gerelateerd.

Daarnaast blijven pointers gevaarlijk.

Je kan namelijk gewoon Pointer++ doen, wat je code dan doet, weet ik niet, maar de compiler zal het goed vinden.

C++ is veel meer nadenken, vooral rondom het woordje "new".

Overigens zit er een verschil tussen C++ en C++/stl meestal wordt dat laatste wel meegenomen omdat er gewoon erg veel makkelijke dingen in zitten. (OA de string).

[ Voor 7% gewijzigd door Kevinp op 05-02-2014 22:26 ]

[farlane]

Kevinp schreef op woensdag 05 februari 2014 @ 22:25:
Je kan namelijk gewoon Pointer++ doen, wat je code dan doet, weet ik niet, maar de compiler zal het goed vinden.

Als je dat niet weet, moet je zorgen dat je er achter komt ipv rare uitspraken doen, want pointer arithmetic hoort er nou eenmal bij. Pointers zijn de basis en je moet eenvoudigweg met die dingen overweg kunnen als je met C en/of C++ aan de gang gaat. ( Ook als je met C# aan de gang gaat moet je het weten als je het verschil tussen reference en value types wilt begrijpen overigens )

Een C++ programmeur die niet met pointers overweg kan, tja ....

[Verwijderd]

Kevinp schreef op woensdag 05 februari 2014 @ 22:25:
[...]

Ik sta bij mijn standpunt. Wanneer je begint met C++ programmeren en dat OO doet zijn pointers slechts zelden echt nodig.

Ik durf zelfs te stellen dat in de meeste code er pointers worden gebruikt waar dit meestal een teken van onkunde is omdat er een keuze is gemaakt in het opzetten van de structuur.

Die uitspraak was natuurlijk erg zwart wit, maar ik denk dat in elke schoolopdracht je pointers of het doorgeven / opslaan van pointers kan vermijden door goede objecten te creëren.

Let wel ik zie pointers en references als verschillende dingen. Hoewel sterk gerelateerd.

Daarnaast blijven pointers gevaarlijk.

Je kan namelijk gewoon Pointer++ doen, wat je code dan doet, weet ik niet, maar de compiler zal het goed vinden.

C++ is veel meer nadenken, vooral rondom het woordje "new".

Overigens zit er een verschil tussen C++ en C++/stl meestal wordt dat laatste wel meegenomen omdat er gewoon erg veel makkelijke dingen in zitten. (OA de string).

References en pointers zijn hele verschillende dingen. Een pointer kan 'NULL' zijn, een reference NOOIT.
Je pointer 'verhogen met 1' is niks anders dan dat je je pointer 4 bytes opschuift:

code:

int henk1 = 2;
int henk2 = 4;
int *henk1_ptr = &henk1;
int *henk2_ptr = ++henk1_ptr;

printf("%i\n", *henk2_ptr);

Output: 4

Niks undefined behaviour. Gewoon slim omgaan met pointers. Maar zoals gezegd, voorkom het gebruik van rauwe pointers in C++ (uitzonderingen daar gelaten).

1. const reference
2. reference
3. weak pointer
4. shared pointer
5. raw pointer

Dus pas in het laatste geval een rauwe pointer gebruiken ^^ For the fuck sake, gebruik const reference:

code:

void henk1(std::string henk)
{
}

void henk1(const std::string &henk)
{
}

Scheelt je weer geheugen allocaties etc...

[Verwijderd]

farlane schreef op woensdag 05 februari 2014 @ 23:22:
[...]

Als je dat niet weet, moet je zorgen dat je er achter komt ipv rare uitspraken doen, want pointer arithmetic hoort er nou eenmal bij. Pointers zijn de basis en je moet eenvoudigweg met die dingen overweg kunnen als je met C en/of C++ aan de gang gaat. ( Ook als je met C# aan de gang gaat moet je het weten als je het verschil tussen reference en value types wilt begrijpen overigens )

Een C++ programmeur die niet met pointers overweg kan, tja ....

Can I like this?

[Radiant]

Verwijderd schreef op woensdag 05 februari 2014 @ 23:55:
[...]


References en pointers zijn hele verschillende dingen. Een pointer kan 'NULL' zijn, een reference NOOIT.
Je pointer 'verhogen met 1' is niks anders dan dat je je pointer 4 bytes opschuift:

code:

int henk1 = 2;
int henk2 = 4;
int *henk1_ptr = &henk1;
int *henk2_ptr = ++henk1_ptr;

printf("%i\n", *henk2_ptr);

Output: 4

Niks undefined behaviour. Gewoon slim omgaan met pointers. Maar zoals gezegd, voorkom het gebruik van rauwe pointers in C++ (uitzonderingen daar gelaten).

Ik snap wat je wil laten zien met je voorbeeld maar dit is nou juist weer een gevaar van pointers als je het als leek letterlijk neemt. Als henk1 en henk2 op de stack staan: wat nou als je compiler henk2 wegoptimaliseert (je doet er namelijk niks expliciet mee als je puur die pointer gebruikt), of de stack andersom is opgebouwd op een architectuur waar je code op gaat draaien? Beide levert undefined behaviour op.

[Zoijar]

Kevinp schreef op woensdag 05 februari 2014 @ 15:42:
"New" heb je echt maar zelden nodig. Object p("bla","bla"). gaat net zo goed als Ojbect p = new Object("bla", "bla" ).

[...]

Tip voor memory leaks (niet qua snelheid, maar zo complex zijn school projecten toch niet). Kijk eens naar unique pointesr en shared pointers. Deze lossen je problemen rondom "New" op als je memory leaks hebt.

Dit geeft op zich al een onbegrip (of niet geheel correct) van C++ memory mangement aan Bij (1) is er een wereld van verschil tussen stack en free-store (niet heap!) allocatie en object lifetime. En bij (2), correct gebruik van smart pointers kan je helpen bij geheugen management, maar lossen zeer zeker niet alles zo automagisch op. Zoals gezegd, een shared pointer is eigenlijk niets beter dan een global.

Het punt is dat je, net als bij elk goed design, duidelijk moet weten wie waar ownership over heeft. Als dat duidelijk is heb je vaak niet meer dan raw pointers nodig. Dat heb je eigenlijk in elke taal, alleen in C++ merk je het sneller als je het fout doet.

Verwijderd schreef op woensdag 05 februari 2014 @ 23:55:
Niks undefined behaviour.

Wel. Die ene pointer na increment wijst nergens gegarandeerd naar. Je optimizer kan het voorzover jij weet wel allemaal in registers gooien en nooit je geheugen aanraken. Of je kan te maken krijgen met alignment waar je nu naar random padding wijst. Etc.

Gewoon slim omgaan met pointers. Maar zoals gezegd, voorkom het gebruik van rauwe pointers in C++ (uitzonderingen daar gelaten).

Ook daar onbegrip. Raw pointers zijn snel en handig. Voorkom alles in een shared_ptr met memory locks te wrappen en oneindig de reference counts uppen en downen door ze rond te passen. Als iets ownership heeft en blijft houden zijn raw pointers prima.

[ Voor 26% gewijzigd door Zoijar op 06-02-2014 08:46 ]

[EddoH]

Verwijderd schreef op woensdag 05 februari 2014 @ 23:55:
[...]

Je pointer 'verhogen met 1' is niks anders dan dat je je pointer 4 bytes opschuift

Dat ligt maar net aan het datatype waar de pointer heen wijst. Een char pointer gaat geen 4 bytes 'opschuiven' als je hem increment maar sizeof(char).

[gast128]

Hydra schreef op woensdag 05 februari 2014 @ 20:56[/message]:[/b]
[...]

Niet mee eens. Voor iemand die al kan programmeren is dat boek perfect.

Goed ieder zijn mening. Als je c++ al kent geef ik je gelijk; als je c++ nog niet kent (maar toch al kan programmeren) zou ik een beginnersboek nemen. Er zitten nu eenmaal wat concepten in c++ (call by value, call by reference; pointer arithmetic; overloading, stack or heap based) die je niet of minder bij Java of c# hebt. Stroustrups boek gaat daar erg snel overheen.

[Caelorum]

Ik vond zelf toen ik overstapte van C# naar C++ C++ Primer een erg fijn boek. Verder ook Accelerated C++.
Verder ben ik het eens met sommige voorgaande reacties dat memory management het grootste probleem gaat zijn. Je moet echt goed de tijd nemen om die te leren. Dus lees er over en check elke regel die je typt of je goed met het geheugen om gaat. Wees erg kritisch op jezelf want je gaat het vaak genoeg fout doen en maak simpele testprojectjes als je iets niet helemaal snapt.

[Kevinp]

Het hangt natuurlijk af wat je wil. Wil je je school projecten zo snel/makkelijk mogelijk maken hoef je veel optimalisaties niet te kennen.

Ik weet niet waar je op school zit, maar tijdens mijn opleiding was het als volgt

1. Java met Bluej, hierdoor werd je gedwongen OO te werken.(iig dat was de kracht van de interface)
2. C vooral voor embedded programmeren en kennis van geheugen management. (wanneer je geheugen alloceerd van 20 bytes moet je daar geen 21 bytes in stoppen). Dit kan je ook redelijk OO maken, maar dan moet je zelf wel veel meer doen.
3. C++ (met stl mogelijkheden). Hier ga je weer terug naar 1 om OO te programmeren met een C taal. Een verademing als je van C af komt. Alleen in mijn ogen wordt door een school te snel over STL heen gestapt daar zitten veel handige dingen in waarvan vele (oa ik) ons niet eens echt realiseren dat deze dingen in STL zitten.

[MSalters]

De grootste winst van C++ over C is inderdaad de Standard Library (iostream, strings, STL, smart pointers, etc). OO is maar een klein onderdeel in vergelijking. OO lost namelijk maar weinig echte problemen op, het is een bouwblok.

Overigens is de verplichting om C++ zonder OO te schrijven natuurlijk net zo arbitrair cq. stupide als de verplichting om C++ te schrijven zonder de letter 'Z' te gebruiken. Het kan, maar het levert je geen beter product op. En is het ook onduidelijk wat je precies dan mag. `std::string` gebruiken? Er zijn genoeg C++ libraries waarin dat een afgeleide class is. `std::cout` is dat zeker.

[Verwijderd]

Zoijar schreef op donderdag 06 februari 2014 @ 08:34:
[...]

Dit geeft op zich al een onbegrip (of niet geheel correct) van C++ memory mangement aan Bij (1) is er een wereld van verschil tussen stack en free-store (niet heap!) allocatie en object lifetime. En bij (2), correct gebruik van smart pointers kan je helpen bij geheugen management, maar lossen zeer zeker niet alles zo automagisch op. Zoals gezegd, een shared pointer is eigenlijk niets beter dan een global.

Het punt is dat je, net als bij elk goed design, duidelijk moet weten wie waar ownership over heeft. Als dat duidelijk is heb je vaak niet meer dan raw pointers nodig. Dat heb je eigenlijk in elke taal, alleen in C++ merk je het sneller als je het fout doet.


[...]

Wel. Die ene pointer na increment wijst nergens gegarandeerd naar. Je optimizer kan het voorzover jij weet wel allemaal in registers gooien en nooit je geheugen aanraken. Of je kan te maken krijgen met alignment waar je nu naar random padding wijst. Etc.


[...]

Ook daar onbegrip. Raw pointers zijn snel en handig. Voorkom alles in een shared_ptr met memory locks te wrappen en oneindig de reference counts uppen en downen door ze rond te passen. Als iets ownership heeft en blijft houden zijn raw pointers prima.

Dat is nou juist de grap ^^ GCC staat het toe en de output is netjes 4. Terwijl de MSVC compiler hem inderdaad weg optimaliseerd.

Met dat laatste ben ik het niet volledig eens. Dit is maar net wat voor stijl je prefereerd, en wat voor toepassing je applicatie heeft. Het is een safe vs performance dingetje.

[Zoijar]

Verwijderd schreef op donderdag 06 februari 2014 @ 22:53:
Dat is nou juist de grap ^^ GCC staat het toe en de output is netjes 4. Terwijl de MSVC compiler hem inderdaad weg optimaliseerd.

Met dat laatste ben ik het niet volledig eens. Dit is maar net wat voor stijl je prefereerd, en wat voor toepassing je applicatie heeft. Het is een safe vs performance dingetje.

Dat ligt denk ik maar net aan je gcc settings en je platform. De output is ook niet 'netjes 4', de output is heel toevallig 4.

shared_ptrs zijn niet per se safe. Als er twee naar elkaar wijzen heb je alsnog een leak bv. Maar het kan ook dat je shared_ptr nog wel bestaat maar je context al lang is verdwenen. En als je het dan op de manier dat je ref altijd bestaat safe wilt spelen heb je bv een weak_ptr. Ik denk dat de beste code alleen unique_ptrs gebruikt voor simpele RAII, en verder duidelijk ownership semantics heeft en raw pointers gebruikt.

[ Voor 3% gewijzigd door Zoijar op 06-02-2014 23:19 ]

[NMe]

MSalters schreef op donderdag 06 februari 2014 @ 11:52:
Overigens is de verplichting om C++ zonder OO te schrijven natuurlijk net zo arbitrair cq. stupide als de verplichting om C++ te schrijven zonder de letter 'Z' te gebruiken. Het kan, maar het levert je geen beter product op.

Het gaat hier dan ook niet om een beter product maar om te leren programmeren. Als je als student altijd alleen maar OO gezien hebt is de eis om géén OO te gebruiken en zo wat bekender te worden met procedureel programmeren niet eens zo gek. Dan is het natuurlijk wél belangrijk dat de docent goed uitlegt dat dit puur een oefening is en niet iets is wat je later vol wil houden, maar dat zal vast goedkomen.

[Radiant]

Verwijderd schreef op donderdag 06 februari 2014 @ 22:53:
[...]


Dat is nou juist de grap ^^ GCC staat het toe en de output is netjes 4. Terwijl de MSVC compiler hem inderdaad weg optimaliseerd.

Met dat laatste ben ik het niet volledig eens. Dit is maar net wat voor stijl je prefereerd, en wat voor toepassing je applicatie heeft. Het is een safe vs performance dingetje.

Als je een array gebruikt, zoals het hoort, verschilt dat niks in performance en kan de optimizer van gcc aan, wat je hoogstwaarschijnlijk een bak meer performance oplevert dan een pointertruukje. Denken dat je beter optimaliseert dan een compiler is allang niet meer van deze tijd.

[Verwijderd]

Zoijar schreef op donderdag 06 februari 2014 @ 23:18:
[...]

Dat ligt denk ik maar net aan je gcc settings en je platform. De output is ook niet 'netjes 4', de output is heel toevallig 4.

shared_ptrs zijn niet per se safe. Als er twee naar elkaar wijzen heb je alsnog een leak bv. Maar het kan ook dat je shared_ptr nog wel bestaat maar je context al lang is verdwenen. En als je het dan op de manier dat je ref altijd bestaat safe wilt spelen heb je bv een weak_ptr. Ik denk dat de beste code alleen unique_ptrs gebruikt voor simpele RAII, en verder duidelijk ownership semantics heeft en raw pointers gebruikt.

De output zou 4 moeten zijn, kwa logica dan.

Niks is veilig in C++, een shared pointer kan altijd nog 'invalid' zijn. Maar als je de smart pointers goed gebruikt (shared_ptr/weak_ptr/unique_ptr) dan KAN het een heel stuk veiliger zijn dan raw pointers. Als nog geldt dat je altijd je koppie erbij moet houden.

[Verwijderd]

Radiant schreef op vrijdag 07 februari 2014 @ 07:35:
[...]


Als je een array gebruikt, zoals het hoort, verschilt dat niks in performance en kan de optimizer van gcc aan, wat je hoogstwaarschijnlijk een bak meer performance oplevert dan een pointertruukje. Denken dat je beter optimaliseert dan een compiler is allang niet meer van deze tijd.

Het was een voorbeeld om te demonstreren wat er bijvoorbeeld mogelijk is met pointers. Het gaat niet om optimaliseren door wat pointer arithmetic te doen. Maar, door het gebruik van pointers voorkom je bijvoorbeeld wel dat je onnodige geheugen allocaties doet. Natuurlijk geldt dit niet alleen voor pointers, maar ook voor references etc..

Een compiler kan stukken beter optimaliseren dan de programmeur, alleen kun je als programmeur daar nog wat bovenop leggen. Er zijn genoeg situaties te bedenken die geoptimaliseerd kunnen worden, terwijl de compiler dat niet zou kunnen, is natuurlijk nog compiler afhankelijk ook.

[EddoH]

Verwijderd schreef op vrijdag 07 februari 2014 @ 08:38:
[...]


De output zou 4 moeten zijn, kwa logica dan.

Ook als je een upward growing stack hebt? Ligt maar net aan je platform.
Ook qua logica zou de output niet 4 moeten zijn: tenzij het een array met 2 waarden is. Aannemen dat 2 waarden op de stack opeenvolgend in memory liggen is gewoon fout.

NMe schreef op vrijdag 07 februari 2014 @ 00:19:
[...]

Het gaat hier dan ook niet om een beter product maar om te leren programmeren. Als je als student altijd alleen maar OO gezien hebt is de eis om géén OO te gebruiken en zo wat bekender te worden met procedureel programmeren niet eens zo gek. Dan is het natuurlijk wél belangrijk dat de docent goed uitlegt dat dit puur een oefening is en niet iets is wat je later vol wil houden, maar dat zal vast goedkomen.

Maar dan zou het toch veel logischer zijn om een taal de nemen die alléén puur procedureel is. Nu kun je de stl half wel/niet gebruiken omdat er OO in toegepast wordt. Of je gebruikt eht wel en laat de studenten denken dat sommige dingen dus wél kunnen in een prodedurele omgeving etc terwijl die specifiek C++ zijn. Het is gewoon nutteloos geforceerd IMO.

[Verwijderd]

EddoH schreef op woensdag 05 februari 2014 @ 13:42:
[...]


Ik vind het gewoon nutteloos om C++ te pakken om vervolgens krampachtig de OO features te vermijden. Het is van weinig educatieve waarde en het voelt geforceerd. Doe dan een real-world scenario, en pak C, zoals je bij een embedded platform vaak tegenkomt.

Maargoed, aan deze discussie heeft de TS ook niets.

Het is sowieso een rare tekst. In c# kun je ook gewoon niet OO programmeren...

[EddoH]

Verwijderd schreef op vrijdag 07 februari 2014 @ 10:59:
[...]


Het is sowieso een rare tekst. In c# kun je ook gewoon niet OO programmeren...

Volgens mij gebruik je in C# in ieder geval altijd classes (in ieder geval 1)? Of het gebruik van classes al als OO gekenmerkt kan worden is een tweede..

[gast128]

Zoijar schreef op donderdag 06 februari 2014 @ 23:18
shared_ptrs zijn niet per se safe. Als er twee naar elkaar wijzen heb je alsnog een leak bv. Maar het kan ook dat je shared_ptr nog wel bestaat maar je context al lang is verdwenen. En als je het dan op de manier dat je ref altijd bestaat safe wilt spelen heb je bv een weak_ptr.

Ja circulaire referenties worden niet opgeruimd door shared_ptr's. Maar garbage collection heeft ook zo zijn eigen dynamica, denk maar bv aan het feit dat de IDisposable interface is uitgevonden.

Ik denk dat de beste code alleen unique_ptrs gebruikt voor simpele RAII, en verder duidelijk ownership semantics heeft en raw pointers gebruikt.

Idealiter heb je wellicht helemaal geen pointers nodig, maar veel modelleringen vereisen dit nu eenmaal. Shared_ptr's zijn dan duidelijk een verbetering tov ruwe pointers. Met applicaties van 10000 regels heb je het overzicht nog wel, maar hoe groter het wordt hoe minder dat overzicht wordt. Ik gebruik zelf eigenlijk nauwelijks meer ruwe pointers.

[Zoijar]

Verwijderd schreef op vrijdag 07 februari 2014 @ 08:38:
De output zou 4 moeten zijn, kwa logica dan.

Haha, nee Het is undefined (of unspecified, weet ik even niet) behaviour: de output kan alles zijn en moet niks zijn. Er zijn ook namelijk genoeg gevallen met alignment dat het geen 4 is.

Niks is veilig in C++, een shared pointer kan altijd nog 'invalid' zijn. Maar als je de smart pointers goed gebruikt (shared_ptr/weak_ptr/unique_ptr) dan KAN het een heel stuk veiliger zijn dan raw pointers. Als nog geldt dat je altijd je koppie erbij moet houden.

Tsja. Ik zie in ieder geval zeer zelden de noodzaak meer tegenwoordig voor een shared_ptr. Ik gebruik unique_ptr's wel, maar alleen eigenlijk voor simpele resource allocatie wrapper door een owner. Het is een beetje een hype waar je voor uit moet kijken; men gebruikt overal smart pointers en denkt dan idd veilig te zijn. Ook zijn ze zeer zeker niet gratis: een shared_ptr doet een memory lock op een reference count die behoorlijk duur is. Dus om je hele code base trager te maken voor iets dat je niet nodig hebt... hmmm.

gast128 schreef op vrijdag 07 februari 2014 @ 13:27:
Ja circulaire referenties worden niet opgeruimd door shared_ptr's. Maar garbage collection heeft ook zo zijn eigen dynamica, denk maar bv aan het feit dat de IDisposable interface is uitgevonden.

Garbage collection is al helemaal een log beest dat je niet nodig hebt

Idealiter heb je wellicht helemaal geen pointers nodig, maar veel modelleringen vereisen dit nu eenmaal. Shared_ptr's zijn dan duidelijk een verbetering tov ruwe pointers. Met applicaties van 10000 regels heb je het overzicht nog wel, maar hoe groter het wordt hoe minder dat overzicht wordt. Ik gebruik zelf eigenlijk nauwelijks meer ruwe pointers.

Dus eigenlijk heb je al je pointers vervangen door trage globals? Als je grotere applicaties hebt moet je juist een goed ontwerp van ownership en lifetimes hebben. Shared_ptrs zijn vrijwel nooit een verbetering op raw pointers. Het zegt: dit is een object, en ik weet eigenlijk niks over de lifetime of wie er ownership heeft (i.e. een global static). Dan heb je later in grote projecten nog allemaal diepe cirulaire referenties waar je totaal geen overzicht meer op kan hebben... ik ben er na vele jaren juist van overtuigd geraakt dat ze bijna nooit nodig zijn en je code vertragen. (dit dus met uitzondering van de RAII resource wrapper unique_ptr)

En Bjarne agrees

Please don't thoughtlessly replace pointers with shared_ptrs in an attempt to prevent memory leaks; shared_ptrs are not a panacea nor are they without costs:

a circular linked structure of shared_ptrs will cause a memory leak (you'll need some logical complication to break the circle, e.g. using a weak_ptr),
"shared ownership objects" tend to stay "live" for longer than scoped objects (thus causing higher average resource usage),
shared pointers in a multi-threaded environment can be expensive (because of the need to avoid data races on the use count),
a destructor for a shared object does not execute at a predictable time, and
the algorithms/logic for the update of any shared object is easier to get wrong than for an object that's not shared.

. A shared_ptr represents shared ownership but shared ownership isn't my ideal: It is better if an object has a definite owner and a definite, predictable lifespan.

[ Voor 53% gewijzigd door Zoijar op 07-02-2014 18:41 ]

[gast128]

Zoijar schreef op vrijdag 07 februari 2014 @ 18:24:
Tsja. Ik zie in ieder geval zeer zelden de noodzaak meer tegenwoordig voor een shared_ptr. Ik gebruik unique_ptr's wel, maar alleen eigenlijk voor simpele resource allocatie wrapper door een owner. Het is een beetje een hype waar je voor uit moet kijken; men gebruikt overal smart pointers en denkt dan idd veilig te zijn. Ook zijn ze zeer zeker niet gratis: een shared_ptr doet een memory lock op een reference count die behoorlijk duur is. Dus om je hele code base trager te maken voor iets dat je niet nodig hebt... hmmm.

'Relatief' duur want ik mag aannemen dat jouw applicatie performance niet meetbaar beïnvloed wordt door gebruik shared_ptr vs raw pointer. Vergeet de 80/20 regel niet.

Dus eigenlijk heb je al je pointers vervangen door trage globals?

shared_ptr's zij geen globale variabelen.

Als je grotere applicaties hebt moet je juist een goed ontwerp van ownership en lifetimes hebben.

Design is essentieel. In dat design kan naar voren komen dat objecten gedeeld worden en daar gebruik je shared pointers voor. Dat is zelfs een dominant use case. Althans het vakgebied waar ik in werk.

Daarnaast zijn er implementatie redenen. Je kan denken aan ingewikkelde object interacties. In de afbraak daarvan kan het wel eens misgaan. Een andere voorbeeld je bv een (const) object aanbiedt aan andere objecten, en dat objecten vrij zijn om hem vast te houden, maar als niemand hem vasthoudt moet hij wel verdwijnen. Met ruwe pointers wordt dat heel moeilijk. Ander voorbeeld is de esthetische kant dat een vector van shared_ptr (of unique_ptr) eenvoudig met clear op te ruimen is.

Shared_ptrs zijn vrijwel nooit een verbetering op raw pointers. Het zegt: dit is een object, en ik weet eigenlijk niks over de lifetime of wie er ownership heeft (i.e. een global static).

Nogmaals het zijn geen globals. Je geeft nu juist aan dat dit object gedeeld kan worden; wellicht zelfs meerdere eigenaren kan hebben, of dat er wel een verhouding owner-observer (= weak_ptr) in zit.

Dan heb je later in grote projecten nog allemaal diepe cirulaire referenties waar je totaal geen overzicht meer op kan hebben...

Dat is een nadeel van shared_ptr's. Gc scoort hier beter in. Het komt wel eens voor. Vaak moet je dan arbitrair de cycle doorbreken met een weak_ptr.

ik ben er na vele jaren juist van overtuigd geraakt dat ze bijna nooit nodig zijn en je code vertragen. (dit dus met uitzondering van de RAII resource wrapper unique_ptr)

Unique_ptr's (of scoped_ptr) zijn ook beter dan ruwe pointers maar voegen nu juist weinig toe omdat ze vaak in scope worden gebruikt waar de lifetime duidelijk is.

En Bjarne agrees

Ik ben op dit punt dan niet hem eens. Het valt me sowieso al op dat de c++ comité gedomineerd wordt door library- i.p.v. applicatie bouwers en dan heb je een andere focus.

Anyway ze zijn er allemaal over eens dat ruwe pointers nauwelijks meer nodig zijn:

http://channel9.msdn.com/...Keynote-Bjarne-Stroustrup
http://channel9.msdn.com/Events/Build/BUILD2011/TOOL-835T

[Zoijar]

gast128 schreef op vrijdag 07 februari 2014 @ 21:30:
'Relatief' duur want ik mag aannemen dat jouw applicatie performance niet meetbaar beïnvloed wordt door gebruik shared_ptr vs raw pointer. Vergeet de 80/20 regel niet.

Ligt aan je use-case; bij ons zijn nano's belangrijk in de inner loops.

shared_ptr's zij geen globale variabelen.

Nee, doh, maar de semantics zijn min of meer gelijk in veel gevallen.

Design is essentieel. In dat design kan naar voren komen dat objecten gedeeld worden en daar gebruik je shared pointers voor. Dat is zelfs een dominant use case. Althans het vakgebied waar ik in werk.

Daarnaast zijn er implementatie redenen. Je kan denken aan ingewikkelde object interacties. In de afbraak daarvan kan het wel eens misgaan. Een andere voorbeeld je bv een (const) object aanbiedt aan andere objecten, en dat objecten vrij zijn om hem vast te houden, maar als niemand hem vasthoudt moet hij wel verdwijnen. Met ruwe pointers wordt dat heel moeilijk.

Dan heb je inderdaad een specifieke use-case waar ze prima zijn -- als je anders handmatig reference counting zou gaan implementeren. Merk op dat ik niet zeg, gebruik ze nooit, maar je hebt ze meestal niet nodig. Je kan bij shared ownership ook een derde partij introduceren die ze gewoon owned.

Ander voorbeeld is de esthetische kant dat een vector van shared_ptr (of unique_ptr) eenvoudig met clear op te ruimen is.

Unique_ptr's (of scoped_ptr) zijn ook beter dan ruwe pointers maar voegen nu juist weinig toe omdat ze vaak in scope worden gebruikt waar de lifetime duidelijk is.

Juist unique_ptrs zijn handig, omdat ze je toestaan makkelijk exception safe code te schrijven dmv RAII. Ook staan juist die toe om bv een vector van objecten te alloceren, zonder dat je je druk hoeft te maken over hoe ze opgeruimd worden. Maar de ownership is duidelijk in dat geval.

Anyway ze zijn er allemaal over eens dat ruwe pointers nauwelijks meer nodig zijn:

Nee, je hebt bijna geen new en delete nodig, omdat je inderdaad alloceert met make_unique, en dan de wrapper het op laat ruimen (wederom RAII vanwege exception safety). Niemand zegt dat je ineens al je objecten shared ownership moet gaan geven. Letterlijk het tegendeel.

Wat je bv ook vaak ziet is dit: double doCalculation(std::shared_ptr<Data> data) const; Dat is bv al gewoon fout, dan verhoog en verlaag je de reference count, twee memory locked operaties, voor niks. Die functie moet gewoon iets als double doCalculation(Data*) const zijn. Dat bedoel ik met raw pointers. Mijn code zou dus zijn:

C++:

// class
double doCalculation(Data*) const;
...

mData = std::make_unique<Data>(...);
...
doCalculation(mData.get());

De foute code zou zijn:

C++:

double doCalculation(std::shared_ptr<Data> data) const;
...
mData = std::make_shared<Data>(...);
...
doCalculation(mData);

[ Voor 12% gewijzigd door Zoijar op 08-02-2014 11:01 ]

[BlietZ]

Bedankt voor de vele reacties in ieder geval, en bedankt voor de tips welke boeken handig zijn. We hebben een aantal drill oefeningen gekregen, basis hoe je een en ander doet in C met pointers etc.
Vanuit de school wordt aangeraden om C te gebruiken, zelf doe ik dit dan met NetBeans en cygwin(GCC).

Om C goed te leren zijn die drill oefeningen omdat we allemaal al met C# ervaring hebben. De eerste 20 opdrachten zijn als volgt.

1. Druk “Hello World” af. 2. Druk 20 keer “Hello World” af. 3. Tel de getallen van 1 tot en met 30 op. 4. Tel de getallen 10 tot en met 40 op. 5. Tel de getallen van a tot en met b op, waarbij a en b worden ingevoerd. 6. Vermenigvuldig de getallen van 100 tot en met 103. 7. Vermenigvuldig de getallen van 1000 tot en met 1004. 8. Bereken 7 tot de macht 5. 9. Tel een rij getallen op die ingevoerd wordt. 10. Bereken het gemiddelde van een rij ingevoerde getallen. 11. Druk het laatste getal en het voorlaatste getal (in die volgorde) af van een rij ingevoerde getallen. 12. Vraag een persoonsnaam als invoer en begroet deze vriendelijk. 13. Voer een letter van het alfabet in en druk het alfabet af vanaf deze letter. 14. Tel van een ingevoerde rij getallen alle getallen kleiner dan 100 op. 15. Voer een temperatuur in °C in en reken hem om naar °F 16. Voer een woord in en druk dit 20 keer af en wel in 4 rijen van 5. 17. Voer een tentamencijfer in en druk de waardering in tekst af (bijv. 8 is “goed”) 18. Schrijf een programma dat onophoudelijk uitvoer produceert die leuk is om naar te kijken (screensaver!) 19. Druk een tabel af van de getallen van 1 tot en met 10, hun kwadraten en hun derde machten. 20. Maak het spelletje “raad een getal onder de 10”.

Verder krijgen we ook nog uitgebreid uitleg over de grote verschillen en hoe pointers etc. werken.

Als iemand nog een boek wilt aandragen die nog niet is genoemd mag dat zeker Thanks!