Plugins en C++

[3ddie]

@3ddie Je bent hier herhaaldelijk iets aan het uitleggen wat al begrijp. Pointers bevatten zowel een geheugenadres als een type-aanduiding. Klopt! Alleen als ik dat dan expliciet maak in die zin dat pointers eigenlijk geordende paren zijn die twee gegevens bevatten (namelijk een geheugenadres en een type-aanduiding) dan doe ik zogenaamd veels te ingewikkeld en dan heb ik het volgens jou niet begrepen. Het zij zo. Ik weet zelf het beste wat ik al dan niet begrijp, en als anderen dat anders zien is dat hun probleem.

Mooi. Ik ben blij dat mijn hulp niet nodig is en dat je het allemaal begrijpt. En ik heb ook weer iets geleerd. Een pointer bevat zowel een type-aanduiding als een adres. Die moet ik ergens opschrijven voor ik het vergeet. Overigens... de wereld is gevuld met mensen die denken dat ze het begrijpen. Ik zou willen dat ik had bijgehouden hoe vaak ik shit heb moeten oplossen veroorzaakt door mensen "die dachten dat ze het begrepen".

Ik loop mijn hele leven lang al tegen het probleem aan dat ik het naadje van de kous wil weten en bewijzen wil zien, terwijl dat anderen vaak worst zal zijn

Als dat zo is dan begin je echt aan de verkeerde kant. Je gaat via high-level programmeertalen naar steeds lagere. Als je van de hoed en de rand wilt weten dan moet je beginnen met de CPU -> machine code -> assembler en dan pas C en dan pas C++. Ik kan je aanraden om een goed boek over Computer organisatie te kopen en te gaan rommelen met een virtuele eenvoudige CPU als de 6502. Dat is genoeg om alle concepten die je later in C / C++ tegenkomt te begrijpen.

Succes

 

[4-Tek]

Volgens mij komt de verwarring ook omdat pointers verschillende dingen zijn in verschillende contexten.

Als je programma gecompileerd is en draait is een pointer echt alleen nog maar een geheugenadres. Maar tijdens compilatie houdt de compiler meer informatie bij over de pointer, onder andere het type van de variabele waar de pointer naar wijst.

Hierdoor kan de compiler je een foutmelding geven als je code compileert die een functie aanroept die een pointer naar een integer verwacht maar je geeft hem een pointer naar een float mee bijvoorbeeld.

Ook de verwarring over * ontstaat omdat het twee dingen betekent afhankelijk van de context.
In een type definitie geeft het inderdaad aan dat iets een pointer is.
Maar in een expressie geeft het aan dat je de waarde van iets op het adres van de pointer wil ipv de pointer zelf. Het omgekeerde van & dus.

Overigens ben ik jaren geleden gestopt met c en c++. Dus neem wat ik zeg met een berg zout. Ik vind de syntax nog steeds erg prettig. Ik heb erna veel talen met een vergelijkbare syntax gebruikt. C#, Java en nu Rust. Maar misschien is dat stockholm syndroom.

 

[Cornerman]

@3ddie, ik zou het niet omschrijven als “in feite is het een integer” want dat is het niet. Daar zit vaak de verwarring bij mensen. In mijn eerdere omschrijving was ik ook iets te kort door de bocht. ik was de grootte vergeten.

een pointer is een waarde die aangeeft waar iets ligt, gecombineerd met een type dat bepaalt hoe groot het is en hoe je het moet interpreteren. En je bent zelf verantwoordelijk voor de geldigheid.

Je hebt overigens uiteraard gelijk hoor, maar ik merk dat als ik mensen uitleg wat pointers zijn ik beter termen die een andere betekenis hebben elders in de taal, integer, float etc, er niet in moet mengen.

@ProgHead ik begrijp even niet wat je nu nog niet kan doen binnen het kader van wat een pointer is en doet. Meer en minder dan de uitleg die in mijn zin staat is het niet. Anderen hebben ook al duidelijke voorbeelden gegeven van wat het kan. En wat de zaken zijn waar je op moet letten.

 

[Cornerman]

@3ddie Je bent hier herhaaldelijk iets aan het uitleggen wat al begrijp. Pointers bevatten zowel een geheugenadres als een type-aanduiding. Klopt! Alleen als ik dat dan expliciet maak in die zin dat pointers eigenlijk geordende paren zijn die twee gegevens bevatten (namelijk een geheugenadres en een type-aanduiding) dan doe ik zogenaamd veels te ingewikkeld en dan heb ik het volgens jou niet begrepen. Het zij zo. Ik weet zelf het beste wat ik al dan niet begrijp, en als anderen dat anders zien is dat hun probleem. Ik zal zelf wel een manier bedenken om die verwarrende syntax van C en C++ rond pointers naar iets begrijpelijks te vertalen.

Het zijn geen geordende paren, het is een aanduiding, je kan allerlei pointers maken zonder dat ze geldig zijn (om wat voor reden dan ook, onoplettendheid, onafgemaakte code) en er nog niets van orde in te bekennen. Dat wordt het pas als ze geldig zijn op het juiste moment in een proces (dus een stuk code).

 

[Disharmonic]

is er geen programmeertaal met een heel formele benadering?

Denk dat je uitkomt bij iets als Coq. Om iets te bouwen voor een toepassing in de praktijk en wat in de buurt komt, SPARK (wat een afgeleide is van Ada).

 

[ProgHead]

Fijn dat iedereen hier denkt te weten wat ik wel of niet begrijp of al gestudeerd heb. Ik heb nog meegemaakt dat dat je een computer op school in machinetaal (ja via een rij schakelaartjes op het voorpaneel) per geheugenadres met eentjes en nulletjes moest voeden. Iets later gebruikten we Assembly en Basic+. En daarna op de universiteit Pascal. Op eigen houtje heb ik nog Python geleerd en later nog wat hogere talen voor audio. @3ddie's adviezen aan mij slaan de plank dan ook volkomen mis. Wat hij hier uitlegt weet ik al, maar misschien dat andere lezers er wel iets aan hebben. Dat hoop ik dan maar, want dit wordt zo verder een zinloze discussie.

 

[ProgHead]

Het zijn geen geordende paren, het is een aanduiding, je kan allerlei pointers maken zonder dat ze geldig zijn (om wat voor reden dan ook, onoplettendheid, onafgemaakte code) en er nog niets van orde in te bekennen. Dat wordt het pas als ze geldig zijn op het juiste moment in een proces (dus een stuk code).

Wat denk je van complexe getallen, zijn dat volgens jou ook geen geordende paren?

 

[ProgHead]

Ook de verwarring over * ontstaat omdat het twee dingen betekent afhankelijk van de context.
In een type definitie geeft het inderdaad aan dat iets een pointer is.
Maar in een expressie geeft het aan dat je de waarde van iets op het adres van de pointer wil ipv de pointer zelf. Het omgekeerde van & dus.

Inderdaad - en zulke dubbelzinnigheden stichten onnodige verwarring en maken C en C++ voor mij tot lelijke talen. Wie enkel geïnteresseerd is in het gebruik van een taal zal die dubbelzinnigheid overigens een rotzorg zijn, en na een aantal jaren programmeren ziet men het niet eens meer. Maar mij is die dubbelzinnigheid een doorn in het oog. Want in een wat zorgvuldiger ontworpen taal had zulke verwarring voorkomen kunnen worden.

 

[MstrFX]

@3ddie's adviezen aan mij slaan de plank dan ook volkomen mis. Wat hij hier uitlegt weet ik al, maar misschien dat andere lezers er wel iets aan hebben. Dat hoop ik dan maar, want dit wordt zo verder een zinloze discussie.

Jullie zitten nou eenmaal niet naast elkaar met een kop koffie, dit is puur omdat je dit online via een forum doorloopt, ik lees alleen maar welwillendheid, niemand weet 100% alles wat een ander echt snapt. Ik kan me herinneren dat een docent me eens apart nam en vroeg, "weet je echt waar je mee bezig bent" Ik zij ja, maar jaren later begreep ik haar vraag pas..

 

[klaasjan]

Even wat anders, is een progje in C++ dat onder Linux werkt ook onder Windows te draaien? En zo ja - wat moet je daarvoor dan veranderen?

Ik neem aan dat je bedoelt dat je de C++ code op een Windows machine opnieuw wil compileren, want hoewel de machinecode hetzelfde kan zijn is het formaat van een Windows 'exe' anders dan van een Linux 'elf' programma.

Aangenomen dat je op Windows ook een C++ compiler hebt hoef je eigenlijk niks te veranderen als je alleen de standaard C++ libraries gebruikt. Een andere compiler kan wel andere bouw commando's vereisen maar dat is een kwestie van de handleiding lezen .
Als je cross platform libraries zoals Juce gebruikt moet je daar natuurlijk wel de Windows versie van installeren maar zou alles ook moeten compileren.
Pas als je platform specifieke dingen gebruikt zal je code moeten aanpassen.

 

[ProgHead]

@klaasjan Ik ben nog bezig mijn progje helemaal na te lopen en te fatsoeneren, maar op mijn Linux computer werkt het wel al. Zie de bijlage.

Behalve C++ zelf gebruik ik nog miniaudio en RtMidi.

 

[ano260823]

Fijn dat iedereen hier denkt te weten wat ik wel of niet begrijp of al gestudeerd heb.

Zoals gewoonlijk blijkt het weer onmogelijk voor je om je eigen kennis correct in te schatten. Dat is niks nieuws en drijft mensen keer op keer weg die (ontzettend veel) tijd steken in je proberen te helpen. Op een gegeven moment word je het zat als iemand die het duidelijk niet begrijpt zo vastbijt in zijn eigen gelijk, zich boven je verheft en je hulp geen eens op waarde schat. Dan vraag je je af waarom je het überhaupt doet. Ik begrijp 3ddie's irritatie heel goed, been there.

Mensen weten niet wat ze precies weten en niet weten, bijzonder knap dat jij dat wel kan. Een unicum.

En ja, aan de klungelige amateuristische code en continu incorrecte uitleg van wat een pointer is kunnen mensen die C en C++ onder de knie hebben inderdaad prima afleiden dat je het nog niet begrijpt. Net als dat het prima te begrijpen is wat je leuk vind - En je geschiedenisverhaaltjes hebben we ook al tientallen keren voorbij zien komen, leuk voor je dat je 62 jaar geleden basic hebt gebruikt. Ik ben ook met basic begonnen, zoals velen. So what? Moet dat indruk maken? Denk je dat de mensen die je helpen niet ook zo gestart zijn en geen carrières hebben? Waar is al die magische geavanceerde programmeer kennis die je bezit die er dan toevallig nooit uit komt in berichten, code of uitleg?

Iemand die dat wel beheerst komt niet met meerdere verkeerde uitleggen en blijft dan hameren dat die het snapt, terwijl de mensen die het snappen en tientallen jaren ervaring hebben meermaals zeggen "Nee, zo werkt het niet". Doen als je wilt hoor, maar je jaagt de mensen weg die daadwerkelijk verstand hebben en letterlijk tijd uit hun leven nemen om je op weg te helpen. Leer daar eens de waarde van inschatten in plaats van ze steeds tegen de knie te schoppen. Je maakt van de mensen die je het meest wilt helpen je vijand, god knows why.

Je bent letterlijk net begonnen met C. Je weet er nog geen eens 0.01% van en daar heb je het gros nauwelijks toegepast in de werkelijkheid. Je bent heel duidelijk geen gevorderd programmeur in welke taal dan ook en begrijpt heel vaak niet hoe C++ werkt - Dat kaart je zelf aan door alle problemen waar je tegenaan loopt. Als je denkt dat de syntax van C++ lelijk is moet je je eens afvragen waarom je denkt de kennis te hebben een syntax te beoordelen van een taal die je überhaupt niet beheerst. Alsof ik ga klagen over hoe kwasten in elkaar zitten voordat ik mijn eerste schilderij heb gemaakt. Leer het eerst eens begrijpen voordat je denkt daar een oordeel over te kunnen vellen.

Als je er niet uitkomt hoe je een simpele library als rtMidi gebruikt, die het nog letterlijk met tientallen voorbeelden tot in de puntjes uitspellen in hun documentatie, is het eens tijd te reflecteren over je eigen kunnen in plaats van zeuren waarom er geen boek over is die het je uitlegt en naar AI te grijpen.

Overigens is AI de allerslechtste manier om programmeren te leren, het zorgt er enkel voor dat je resultaten vooruit lopen op je kennis. Doen hoor, ik ben dit al lang zat.

PS: Wel grappig nadat je me zo vaak hebt verteld dat ik niet weet wat je leuk vind en dat wat ik aanraad niet bij je past - Maar er dan een week later toch een boek over kopen en het opeens wel willen leren. Echt bijzonder. Oh, en toch wat geleerd vandaag, Een pointer bevat blijkbaar zowel een type-aanduiding als een adres. Wist ik niet, dank, oh meester.

 

[Cornerman]

Wat denk je van complexe getallen, zijn dat volgens jou ook geen geordende paren?

Je hebt blijkbaar geen begrip over het concept pointer, een pointer is een pointer en hetgeen waar het de weg naar wijst wordt pas iets op een moment in het proces, niet eerder niet later. Lees mijn laatste post Gewoon een paar keer.

Je weet dingen wel, blijkbaar, maar je internaliseert ze niet.

 

[Cornerman]

Inderdaad - en zulke dubbelzinnigheden stichten onnodige verwarring en maken C en C++ voor mij tot lelijke talen. Wie enkel geïnteresseerd is in het gebruik van een taal zal die dubbelzinnigheid overigens een rotzorg zijn, en na een aantal jaren programmeren ziet men het niet eens meer. Maar mij is die dubbelzinnigheid een doorn in het oog. Want in een wat zorgvuldiger ontworpen taal had zulke verwarring voorkomen kunnen worden.

Nee, je moet weten wat in taal & programmeertaal de termen zijn en ze juist gebruiken. In beide, dus er is niets lelijks aan het is slechts een manier om dingen te duiden en mee te bouwen. Juist omdat dit soort dingen wel helder zijn kan je er hele snelle code mee schrijven. Je moet alleen even je begrippenkader in menselijke taal en de taal C++ vaststellen.

 

[HJB]

Maak de definitie van pointers niet moeilijker dan het is.
Je zou, om het minder abstract te maken, de vergelijking kunnen maken met huisadressen.
Lindelaan 1 kan het adres zijn van een woonhuis. Terwijl Lindelaan 103 een bedtijf kan zijn.
De inhoud(bewoners) van Lindelaan 1 kunnen wel verhuizen naar nummer 26(andere woning) maar niet naar nummer 103.
Je kan verwijzen naar het adres(pointer).
Of informatie ophalen over de bewoners(inhoud).
Beide soorten informatie worden op een veschillende manier gedefinieërd en benaderd.
Zo werkt het ook met pointers (in C).

 

[HJB]

Inderdaad - en zulke dubbelzinnigheden stichten onnodige verwarring en maken C en C++ voor mij tot lelijke talen. Wie enkel geïnteresseerd is in het gebruik van een taal zal die dubbelzinnigheid overigens een rotzorg zijn, en na een aantal jaren programmeren ziet men het niet eens meer. Maar mij is die dubbelzinnigheid een doorn in het oog. Want in een wat zorgvuldiger ontworpen taal had zulke verwarring voorkomen kunnen worden.

Je geeft zelf aan dat je ook machinecode/assembler hebt geprogrammeerd. Daarin wordt alle data in het geheugen als pointer behandeld.
En zal je zelf moeten bepalen wat voor data er op een geheugenplaats staat en hoe je die moet verwerken.
Hogere talen nemen je veel werk uit handen door automatisch geheugenplaatsen toe te wijzen aan variabelen en door het uitvoeren van typechecking tijdens compilatie.
Gebruik van pointers in hogere talen is een kleine stap dichter bij de machinecode.

Als dat niet is wat je wilt vermijdt dan het gebruik van pointers en accepteer de beperkingen in datamanipulatie.

 

[3ddie]

Ik heb nog meegemaakt dat dat je een computer op school in machinetaal (ja via een rij schakelaartjes op het voorpaneel) per geheugenadres met eentjes en nulletjes moest voeden. Iets later gebruikten we Assembly en Basic+. En daarna op de universiteit Pascal. Op eigen houtje heb ik nog Python geleerd en later nog wat hogere talen voor audio. @3ddie's adviezen aan mij slaan de plank dan ook volkomen mis. Wat hij hier uitlegt weet ik al, maar misschien dat andere lezers er wel iets aan hebben. Dat hoop ik dan maar, want dit wordt zo verder een zinloze discussie.

Oei, dit dreigt een ruzie te worden en daar heb ik helemaal geen zin in. Ik hoef geen online drama in mijn leven.

Laat ik beginnen met mensen te danken die reageerden op mijn uitleg met hun verbeteringen of verduidelijkingen. Ook fijn om te horen dat sommigen er in ieder geval iets aan hebben gehad.

Laat mij ook mijn excuses aanbieden aan @ProgHead. Als ik geweten had dat hij al deze ervaring en technologieën al onder de riem had dan zou ik natuurlijk nooit het advies gegeven om computer organisatie te bestuderen of assembly te gaan leren. Sorry. Ik sloeg de plank weer eens volkomen mis. De man die nog schakelaartjes heeft overgehaald op een PDP vertellen dat hij assembly moet gaan leren... pffrrt... Ik heb geen idee hoe ik bij het belachelijke idee kwam dat je deze kennis mist. Dat zal niets met jouw posts alhier te maken hebben en een hersenschim van mij te zijn.

En ik moet ook even eerlijk zijn: er zit een beetje jaloezie bij mij. Ik ben maar een boerenkinkel die niet hoeft te weten wat ik aan het doen ben. Ik hoef niet van de hoed en de rand te weten. Ik rommel maar een beetje in de marge terwijl ProgHead zijn tijd besteed aan het uitpluizen van de onderliggende concepten en echt begrijpt hoe een computer werkt. Het is mij nu duidelijk dat hij duidelijk meer weet van de onderliggende principes dan ik.

De jaloezie komt ook van wat inmiddels in de academische wereld de "ProgHead 2026 Openbaring" wordt genoemd. Het zal velen van jullie ontgaan zijn net zoals het mij initieel ontging. ProgHead zegt dat zijn hoofd vol zit met onnodige feitjes maar die hebben toch maar mooi geleid tot deze openbaring. Je moet hier even wat langer over nadenken. Niet meteen mentaal wegzappen met het idee "ik snap dit niet". Laat het op je inwerken.

Eigenlijk zegt een pointer dan niet wat er op een zekere geheugenlocatie staat, maar hoe die wat er staat interpreteert — ProgHead 2026

Dit inzicht is zo diepgaand. Stel je toch eens voor als we de strikte binaire waarden van bits openstellen voor interpretatie? Ik begin met een eenvoudig voorbeeld maar als we 7 bits samen groeperen dan kunnen we tellen van 0 tot 127 als we dit zonder sign doen. We zouden een lijstje naast de computer kunnen leggen waarbij we, en ik noem maar even een dwarsstraat, het getal 65 associeren met hoofdletter A. In plaats van getallen interpreteren we de bits nu als karakters. En nu kun je lachen maar ik voorspel dat door dit baanbrekende inzicht er apparaten gaan komen waarbij we uitkomsten van computerbewerkingen kunnen tonen op papier!! Ja lach maar....

En ik ga het nog gekker maken: jullie hebben vrijwel allemaal een televisie. Wat nu als we bits zouden interpreteren als beeldpuntjes? Dan hebben we niet eens papier meer nodig maar kunnen we de output direct op een beeldscherm zien. En we zouden zelfs plaatjes kunnen weergeven. Als we meer dan 1 bit gebruiken voor een beeldpunt kunnen we zelfs grijswaarden gebruiken. Ik maak het nog bonter: we kunnen zelfs kleur geven aan beeldpuntjes.

En ik weet dat ik hiervoor op de brandstapel ga belanden maar als je dit doortrekt dan zou een typemachine volledig overbodig worden. Je kunt op het scherm grafisch je teksten opmaken en via dat papier-apparaat dat ik eerder aanhaalde de teksten kunnen reproduceren op papier en die vervolgens verspreiden....

Wacht eens!! Als we bits toch vrij kunnen interpreteren dan kunnen we misschien zelfs computers met elkaar verbinden. En dan zouden we electronisch informatie uit kunnen wisselen. En iedereen kan zich aansluiten op dat netwerk zodat iedereen een bron van informatie kan zijn... maar ook alle andere informatie kan raadplegen... wereldwijd.....

En daar zit de jaloezie: ProgHead heeft in 2026 het fundament gelegd voor general purpose computing. Wij dachten een 1 is een 1 en een 0 is een 0... ProgHead leerde ons In 2026 dat niet iedere 1 hetzelfde is. Het gaat om de interpretatie!!

Je zou zeggen dat je dit principe in de eerste of tweede week waarin je met computer organisatie bezig bent al zou opsteken. Dat je het in de praktijk zou brengen als je assembly programmeert... maar nee hoor. Domme ik bleef denken dat een 1 een 1 is en een 0 een 0 is en niets anders!! Ik heb mijn tijd verspild sinds 1983/84.

En dan in een argeloos draadje over C/C++ programmeren schud ProgHead de computer science wereld op haar grondvesten met zijn "open interpretatie" filosofie. Ik geef me over. @ProgHead zal vereeuwigd worden als de grondlegger van general purpose computing en zal nog eeuwen na ons worden aangehaald in de academische literatuur als visionair. Grondlegger. Baanbreker... en ik ben de schlemiel met mijn domme adviezen. Ik zal vereeuwigd worden als de achterlijke boerenkinkel die niets begrijpt. Mozart vs Salieri versie 2.0

Maar let op mijn woorden: dat wereldwijde netwerk van computers waarvoor ik zal branden op de stapel gaat nog eens heel groot worden!!! Dank je wel @ProgHead. De wereld zal nooit meer hetzelfde zijn na 2026.


Mijn laatste post hier...

 

[HJB]

Voor een iets andere aanpak van pointers kun je ook eens naar C# kijken.
Dan heb je de voordelen van een hogere programmeertaal en toch een aantal opties om op een lager(machine) niveau te werken.
Echt kritische routines zou je alsnog in C of C++ kunnen schijven en ze vervolgens te linken aan de main module.

Unsafe code, pointers to data, and function pointers - C# reference

Learn about unsafe code, pointers, and function pointers. C# uses an unsafe context for operations that access unmanaged memory or invoke function pointers (unmanaged delegates).

learn.microsoft.com

 

[Nicolas 2000]

Ik begrijp code die ik gebruik graag, maar ik heb mijn limieten. Zo zijn er een paar XML bewerkingen waar ik me er bij neergelegd heb dat het werkt.

 

[ProgHead]

Vriendelijk verzoek de discussie over pointers hier te staken. Ik heb een nieuw topic over pointers in C++ aangemaakt waar degenen die dat wensen verder over pointers door kunnen discussiëren. Ik zoek het verder zelf wel uit hoe pointers - volgens mij - het beste kunnen worden begrepen. En ik ben daar vandaag ook al een flink eind mee gevorderd. Maar aangezien mijn insteek hier nagenoeg niemand interesseert is voortzetting van de discussie over pointers hier zinloos. Het zou enkel maar leiden tot een verdere ontsporing van dit topic.