Опитвам се да напиша малко по прегледен код на чисто С.

Имам мембър функция в структура и в кода на функцията ми трябва поинтер към родителската структура. Т.е. "this" ама в чисто С.

Мога да го прехвърля като реален параметър на функцията при извикването и... ама е грозно. По-елегантен вариант има ли?

П.С. Решението с макрос го знам, пак ми грознее, защото не се виждат прегледно типовете на аргументите.
Варианти с непортабилен код (през стека и т.н.) също са грозни.

Някой май не си е изпил кафето, ама аз ли... ти ли не знам

В чисто С нямаш мембър функции. Може да имаш указател към функция, ама неговата стойност и неговия адрес са две различни неща. И между тези неща обикновено няма връзка (освен ако не направиш врътки с линкера).

С една дума отговорът на въпроса ти е - няма по-елегантен вариант.
Това с макросите нещо не го разбирам... явно фантазията ми е слаба.

бтв. Наскоро цитирах баштаткото на С/С++ че някои правила не би нарушил за нищо на света. И особено "нулевия овърхед". Демек ако имаше някакъв теоретичен начин this да не се подава като параметър, то това щеше да е овърхед в Ц++. И Страусбърг нямаше да го одобри

Няма друг читав начин освен да се предава като първи аргумент. Да, грозно е ама поне го виждаш. Ядрото на линукс е написано по този начин така, че може да хвърлиш едно око за вдъхновение.

Това също така е критерии за правене на рефакторинг когато даден метод има параметър друг клас и работи само с методи от този друг клас - тогава е сигнал, че трябва да се премести този метод направо в другият клас.

Да де Миро, разбра ме правилно, указатели към функции са.

Понеже не съм гуру, викам си да не изпускам нещо... ама явно не изпускам.

Относно решението с макроси имах предвид просто да опаковам предаването на параметъра на функцията при викането и, че да не се вижда и да не дразни...

Понякога много ми се ще да посегна към двата плюса, ама пусто не ми се ринат нови лайна...

По-добре не го крий. Покрай този параметър следват много главоболия. Ще ти потрябва в друга структура или по друг начин ще се изкушиш да предадеш тоя указател на друго място. И в един прекрасен момент ще се окаже че работиш с указател към небитието...

Най-доброто решение е Ц++ и то не защото изглежда "по-малко грозно", а защото имаш по-добър контрол над подобни указатели. Но предполагам още не си узрял за това решение, затова следващото по хубост решение е дебело да подчертаваш използването на такива указатели и да следиш къде и как се ползват. В никакъв случай не искаш да ги сметеш под килима, повярвай ми!

Цецо - просто миризмата е различна -ла*йната са същите , е и мемори мениджмънта/юзидж е допълнителен слой с тотално различна миризма..
тука колко курсове и срещи по- повод ембедед Ц++ това животно какво е , приложимо ли е, и т.н. и след толкова години - пак Ц.

въпрос на камбанарии... ако за да сменя езика трябваше да пренапиша лайнукса, вероятно нямаше да го сменя в рамките на този живот

Очевидно има хора с такива дилеми и мога да ги разбера. Но не мога да разбера такива дето не оценяват разликите в езиците. Неща като resource safety и т.н.

Е като сме отворили кутията на Пандора, как се справя мемори мениджмънта на плюса на един прилично дребен контролер, да кажем F4 без MMU и със 128К рам? Динамичното заделяне на ресурси не му ли разказва играта?

За Ф4 не знам още, ама на Ф2 си се справя пИрфектно

Нашата работа е такава, че има много текстообработка. Постоянно се парсват XML-и и всевъзможни формати. И не говоря за малко или малки файлчета, а за стотици мегабайти, понякога и гигабайти. По време на подобни обработки може да се стигне до умопомрачителен брой алокешъни. Говоря примерно за порядъка от 100к в секунда. И ограничението за щастие идва от трансферите след това, т.е. трябва да се изчаква.
Интересното е, че някои обработки съм ги преработвал именно с цел да намаля алокейшъните. Но видим ефект няма, просто щото това не е най-тънкото място. Но няма ефект даже и в CPU-usega.

Всъщност за да има проблем с динамичната памет трябва да имаш много памет. При нас пула е 96к или нещо от сорта. Това при освобождаване няма значение, защото освобождаването се свежда само до проверка на съседните чънкове и не зависи от размера на паметта. Но при заемането има едно търсене за най-подходящо парче и там може да се забави, ако имаш много парчета. Но при 96к практически не може да имаш много. Виж ако сложим 4GB нещата може да загрубеят

едит: малко се подведох от въпроса... това дето обяснявам за бързодействието няма нищо общо със ++. Динамичната памет е реализирана на асемблер, но и това е подробност само. Смисълът на Ц++ е в защитаването на ресурси по принцип. Независимо дали става въпрос за динамична памет, заключвания или нещо друго.
Конкретно при динамичната памет, правилото ни е че никога не алокейтваме памет директно. Алокейтването е реализирано само в определени класове, да кажем като cstring. Самите класове се ползват само като референси, демек винаги в ситуация от рода на auto_ptr. Съответно като ги ползваш при тия условия, викането на деструктора не е твоя грижа и няма как по погрешка да го пропуснеш. Компилатора се грижи за това. Винаги има деструкция и дори да се препредава паметта от един стринг на друг, винаги си се освобождава. Неща като memory leak отдавна сме ги забравили. Не че не се случват, никой не може да ни предпази от собствената ни глупост. Но да кажем подобни проблеми имаме изключително, изключително рядко...

C++ кво общо има с алокатора
който е дело на ОСа или просто си е една библиотека

Пример
https://github.com/Wiz-IO/framework-que ... ew.cpp#L21

А има ли нужда да се справя? Кой каза че щом ползваш C++ си задължително наказан да имаш динамична памет? Ц++ си работи и само със статична, стига обектите ти да са статични. Щом питаш за uC гарантирано нямаш нужда от динамични, т.е. не ти трябва heap.

и още по-добре ако има и heap алокатор.... тва тук, онова там ... уж да се избяга от memory leak

Темата тръгна от криенето на "this" и че това е кофти идея на чисто Ц понеже реално го криеш от себе си. Или още по-зле от колеги, които след това ще модифицират или използват тоя код.

При Ц++ подаването на this в мембър функциите e "скрито", но това не е проблем понеже компилаторът е наясно със смисъла на този указател и се грижи да не стават инфекции. Разбира се и програмистите вземат или могат да не вземат участие в тоя процес. Въпросът е, че Ц++ има възможност да се работи безопасно с такъв тип указатели и изобщо с всякакви указатели и ресурси. Под чисто Ц няма такава възможност. Всичко опира до програмистите и до тяхната дисциплина да не допускат бъгове.

Всичко това най-лесно се илюстрира с динамична памет. Бих могъл да направя пример и с this, но мисля че динамичната памет е 100 пъти по-нагледно.



В случая имаме два указателя. И двата заемат някаква памет, но при единия програмиста трябва да се погрижи да я освободи. Демек накрая трябва някой да извика free(). В случая е очевидно че return-a в средата на функцията е проблем. Но това е очевидно, само защото функцията е малка и проста. При малко по-сложна функция тия неща не са толкова очевАдни. Даже напротив, често улисан от истинската логика виждаш някаква друга грешка, променяш някой if() и хоп функцията се изнизва без да е извикан free() за тоя указател.
Функцията обаче има и още един указател, който по същество също е "char*" но за него програмиста няма нужда да вика free(), защото шаблона auto_ptr<> се грижи за освобождаването. При това се грижи във всички ситуации, независимо как ще се изнижеш от тая функция.
Така че при Ц++ е въпрос само на "хигиена" да не се използва чисто Ц. И грешките се виждат много лесно, достатъчно е да видиш само алокейтването. Няма нужда да гледаш дали се освобождава. Просто така НЕ СЕ заема памет. НИКОГА!
В същото време и двата указателя ще генерират абсолютно един и същ код (при условие, че няма бъг в ц-версията). Демек нулев овърхед за това че ползваш Ц++.

Пак ще повторя, че това не важи само за динамична памет. По принцип идеята на Ц++ е "resource safety", без значение какъв е ресурса. Съответно твърденията на гичо, че можело това, можело онова.... Всичко може, ама аз с пръдня боя не мога да правя;-)

В гоненето на по-добър мемори мениджмънт Ц++ хич не е най-добрия пример за следване. Това, което казвах е, че с повече акъл и подход при дизайна тия проблеми просто ги няма - оттам насетне решенията им не са от значение.
'this' е принципна концепция, характерна за доста от обектните езици. Ама тоя this води до тотална невъзможност да се пишат "pure" функции - той е основата да се програмира през side effect-и вместо чисто И/О. Оттам насетне какво да го плюя повече?
Скритото подаване на инстанция е безсмислено - по-доброто е да се вижда чисто и ясно с коя интанция се вика нещото някъде.

Поради това "this" така и не разбрах как се прави поинтър към member function.