[C(++)] voor dummies - Deel 5

quote:

Op donderdag 20 juni 2013 00:54 schreef trancethrust het volgende:
Je kan er een struct van maken als in
[ code verwijderd ]

Een sizeof(receive_buffer) is dan 1500*sizeof(char).

(Overigens is dynamisch alloceren van de receive-buffer via new niet nodig)

Nee, klopt had ik idd al bedacht was meer dat ik niet zo bekent ben met memcpy en memset dus in dat opzicht had ik dat gekopieerd van iemand anders zijn code (snap wel wat het doet) Had idd ook gewoon de & en * kunnen gebruiken.
maar stel dat ik de buffer statisch alloceer als
Dan zou je zeggen dat dit ook zou moeten werken
Maar dat werkt dus niet en faalt de recvfrom functie

quote:

Op donderdag 20 juni 2013 09:40 schreef netolk het volgende:

[..]

Nee, klopt had ik idd al bedacht was meer dat ik niet zo bekent ben met memcpy en memset dus in dat opzicht had ik dat gekopieerd van iemand anders zijn code (snap wel wat het doet) Had idd ook gewoon de & en * kunnen gebruiken.
maar stel dat ik de buffer statisch alloceer als
[ code verwijderd ]

Dan zou je zeggen dat dit ook zou moeten werken
[ code verwijderd ]

Maar dat werkt dus niet en faalt de recvfrom functie

Die struct stond er voor een reden

Een
alloceert een statische array van type T en grootte n. De type van x is dan dus een array van T, ofwel een pointer naar T, en de size daarvan is sizeof( void* ).
Als je de boel in een struct gooit, dan neemt de struct de grootte van alle velden, dus de grootte van de totale char array.

quote:

Op donderdag 20 juni 2013 09:51 schreef trancethrust het volgende:

[..]

Die struct stond er voor een reden

Een
[ code verwijderd ]

alloceert een statische array van type T en grootte n. De type van x is dan dus een array van T, ofwel een pointer naar T, en de size daarvan is sizeof( void* ).
Als je de boel in een struct gooit, dan neemt de struct de grootte van alle velden, dus de grootte van de totale char array.

klinkt logisch idd
maar dan zou sizeof(*recvBuff) ook moeten werken maar bij de dynamische allocatie kreeg ik daar ook een error van recvfrom

quote:

Op donderdag 20 juni 2013 09:58 schreef netolk het volgende:

[..]

klinkt logisch idd
maar dan zou sizeof(*recvBuff) ook moeten werken maar bij de dynamische allocatie kreeg ik daar ook een error van recvfrom

Een *recvbuffer is een pointer, dus wederom 4 of 8 bytes. sizeof(recvbuffer) is wat je wilt (als recvbuffer een struct is dat de char-array bevat, zoals hierboven).

quote:

Op donderdag 20 juni 2013 10:04 schreef trancethrust het volgende:

[..]

Een *recvbuffer is een pointer, dus wederom 4 of 8 bytes. sizeof(recvbuffer) is wat je wilt (als recvbuffer een struct is dat de char-array bevat, zoals hierboven).

k, dus sizeof neemt alleen de grote van het object wat je er instopt en niet waar het naar verwijst ongeacht het gebruikt van * ?

quote:

Op donderdag 20 juni 2013 10:08 schreef netolk het volgende:

[..]

k, dus sizeof neemt alleen de grote van het object wat je er instopt en niet waar het naar verwijst ongeacht het gebruikt van * ?

Grootte van het type van het object dat je erin stopt, inderdaad, of de grootte van het type dat je meegeeft (sizeof werkt op zowel objecten/instances als datatypes). Dit is ook precies wat je wilt.

De * maakt in deze zin altijd een pointer data type.

oke, bedankt dan snap ik het

quote:

Op donderdag 20 juni 2013 09:51 schreef trancethrust het volgende:

[..]

Die struct stond er voor een reden

Een
[ code verwijderd ]

alloceert een statische array van type T en grootte n. De type van x is dan dus een array van T, ofwel een pointer naar T, en de size daarvan is sizeof( void* ).
Als je de boel in een struct gooit, dan neemt de struct de grootte van alle velden, dus de grootte van de totale char array.

Uhm, nee?

quote:

Op vrijdag 21 juni 2013 15:45 schreef Ai_KaRaMBa het volgende:

[..]

Uhm, nee?
[ code verwijderd ]

Oh. Redelijk stoned Blijkbaar wordt een (niet-dynamische array) als een soort struct gezien; nooit geweten!

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

quote:

Op vrijdag 21 juni 2013 19:10 schreef t4rt4rus het volgende:

[..]

sizeof geeft size van een object, een C array is ook gewoon een object.

Alleen zijn C arrays best wel klote want je kan niet pass by value doen, alleen maar by reference.
En als je dus in een function sizeof doet van je parameter "array" krijg je size van je reference ipv array.

http://ideone.com/jcU5D8

ahh, vandaar
Ik heb het nu opgelost door de grote in een aparte (constante) int te zetten zodat ik alleen die hoef aan te passen als ik de grote wil veranderen

quote:

Op vrijdag 21 juni 2013 19:10 schreef t4rt4rus het volgende:

[..]

sizeof geeft size van een object, een C array is ook gewoon een object.

Alleen zijn C arrays best wel klote want je kan niet pass by value doen, alleen maar by reference.
En als je dus in een function sizeof doet van je parameter "array" krijg je size van je reference ipv array.

http://ideone.com/jcU5D8

Ah ik snap de tegenstelling nu. Mijn eerste reactie was `dit is nog lelijker dan een struct'`, maar de grap is natuurlijk dat als een C array geen aparte datatype was, dat een struct zoals hier ook nooit zou kunnen werken; de struct zou anders precies de grootte zijn van een array pointer.
En een pass-by-value zou nooit letterlijk kunnen omdat de grootte van een argument nooit compile-time bepaald kon worden. Noodzakelijk kwaad. Cool, weer wat geleerd.

quote:

Op zaterdag 22 juni 2013 00:15 schreef t4rt4rus het volgende:

[..]

Je weet dat het zetten van struct voor de typename C is en niet nodig (deprecated?) in C++?

http://ideone.com/swuvZr

quote:

Zie std::array als je een array als value will passen.
In C++14 komt er waarschijnlijk een dynamic array.

Het was meer een discussie over waarom een T foo[500] geen T*-type had, wat (mij) aanvankelijk veel natuurlijker leek. Persoonlijk als ik arrays doorgeef gebruik ik pointers/iterators, het andere komt me wat onnatuurlijk over.

quote:

Op zondag 23 juni 2013 01:07 schreef t4rt4rus het volgende:
Is er al iemand die Stroustrups nieuwe boek heeft?

En zijn er mensen die C++14 een beetje volgen?

nee, ik heb een boek uit 2002 van hem (wel is waar vertaald naar NL in die tijd was ik nog niet zo'n voorstander van Engelse boeken)

Omdat het van GS42 hier moet
------------------

Hai!

Ik heb een programma dat redelijk veel verschillende handelingen op dezelfde manier (maar toch altijd net even anders) uitvoert. Het gaat om bewerkingen / analyses over OpenCV matrices.

Voor het gemak een voorbeeldje:

Dit loopt door alle pixels van een gegeven resolutie set heen, en geeft bijvoorbeeld een maximum terug, of een gemiddelde, of telt het aantal pixels > 0, soms voor de Y matrix, soms de Z, soms de X, soms een combinatie. Soms past het bovendien de matrixen aan.

Anyway, ik zou dit een beetje handiger willen verpakken want die nested for loop zit op heel veel plekken en ik heb het idee dat dit overzichtelijker kan.

Bovendien... Dit moet toch sneller kunnen? Iemand een idee of dit in C++ in een object class zou kunnen en zo ja hoe kan ik die dan toch dynamisch genoeg maken om er vanalles mee te doen? Of ben ik echt gebonden aan de huidige aanpak?

Je zou met een Lambda functie de 2 for loops kunnen vervangen.

Maar dat is waarschijnlijk minder leesbaard dan 2 for loops, om nog maar te zwijgen over de potentiële snelheidsverlies...

Of het sneller kan, zou je dat even in de OpenCV documentatie moeten halen (wellicht zijn er bepaalde iterators die je kunt gebruiken). maar zo bekend ben ik niet met OpenCV.

quote:

Op donderdag 5 december 2013 13:40 schreef Gehenna het volgende:
Je zou met een Lambda functie de 2 for loops kunnen vervangen.

Maar dat is waarschijnlijk minder leesbaard dan 2 for loops, om nog maar te zwijgen over de potentiële snelheidsverlies...

Of het sneller kan, zou je dat even in de OpenCV documentatie moeten halen (wellicht zijn er bepaalde iterators die je kunt gebruiken). maar zo bekend ben ik niet met OpenCV.

Dit is een derde sneller


en de bijbehorende functie dan zoiets is als


Doeditendat is altijd iets simpels. Soms trekt het lijntjes als x = iets, soms somt het alle waarden op, etc.

Misschien maak ik het mijzelf hierin alleen maar moeilijker, dat begrijp ik ook wel, maar ik had stille hoop dat je iets kon doen als:

(syntax is uiteraard manco)

waarbij px, py, pz bijvoorbeeld standaardtermen zijn die ie herkent als 'een punt uit die en die matrix, een punt uit die en die matrix of die en die matrix' en het 2e voorbeeld een argument meegegeven moet worden (pointersumx) omdat ie anders niets heeft om op te tellen (de sumx++). Met andere woorden, de variabele sumx zelf komt helemaal niet voor in de matrixoperation functie

quote:

Op donderdag 5 december 2013 14:14 schreef Holy_Goat het volgende:

[..]

Dit is een derde sneller
[ code verwijderd ]

en de bijbehorende functie dan zoiets is als
[ code verwijderd ]

Doeditendat is altijd iets simpels. Soms trekt het lijntjes als x = iets, soms somt het alle waarden op, etc.

Als ik het goed begrijp wil je dus graag een functie 'doeditendat' meegeven als argument van de functie 'matrixoperation'?

Dan is dit wellicht iets voor je: http://stackoverflow.com/(...)-as-a-parameter-in-c

quote:

Op donderdag 5 december 2013 14:53 schreef Gehenna het volgende:

[..]

Als ik het goed begrijp wil je dus graag een functie 'doeditendat' meegeven als argument van de functie 'matrixoperation'?

Dan is dit wellicht iets voor je: http://stackoverflow.com/(...)-as-a-parameter-in-c

Denk het wel ja
Vind het gewoon een beetje naar om o-ve-ral die dubbele forloop te hebben (ook al is het wel sneller)

quote:

Op donderdag 5 december 2013 12:29 schreef Holy_Goat het volgende:

for (size_t y = 0; y < p_Par->Xtion.CanvasYRes; y = y++)

Dit moet toch sneller kunnen?

Ja, hier staat namelijk een oneindige loop.