LINUX.ORG.RU

А стоит ли придерживаться такого стиля?

 ,


0

3
void CALLBACK UpdateDependentHandle(_UNCHECKED_OBJECTREF *pObjRef, uintptr_t *pExtraInfo, uintptr_t lp1, uintptr_t lp2)

//обратите внимаение на lp2

{
Object **pPrimaryRef = (Object **)pObjRef;
    Object **pSecondaryRef = (Object **)pExtraInfo;
  
LOG((LF_GC|LF_ENC, LL_INFO10000, LOG_HANDLE_OBJECT("Querying for new location of ", 
            pPrimaryRef, "to ", *pPrimaryRef)));
    LOG((LF_GC|LF_ENC, LL_INFO10000, LOG_HANDLE_OBJECT(" and ", 
            pSecondaryRef, "to ", *pSecondaryRef)));

promote_func* callback = (promote_func*) lp2; //и здесь


callback(pPrimaryRef, (ScanContext *)lp1, 0);
callback(pSecondaryRef, (ScanContext *)lp1, 0);
}

выдержка из реального кода. стоит ли продолжать писать подобным образом?

чуть не забыл, ф-ция вызывается ровно 1 раз.

функция приведена полностью, выкинул только #ifdef _DEBUG разные, чтобы не отвлекаться

★★★★★

Последнее исправление: next_time (всего исправлений: 3)

Смахивает на провокацию, однако...

если стиль нравится, почему бы не писать на нем? если проект не твой, то лучше использовать стиль проекта

reprimand ★★★★★
()

Если бы в конце вместо второго вызова коллбэка в первый передавался он сам и pSecondaryRef в качестве аргументов, то получился бы вполне каноничный CPS.

annulen ★★★★★
()
Ответ на: комментарий от Harald

это кроссплатформенный код. поддерживается фряха, отдельно убунта, отдельно опенсюс, отдельно дебиан.

next_time ★★★★★
() автор топика
Ответ на: комментарий от E

в том, чтобы вместо прямого определения указателя на функции в её аргументах, указывать uintptr_t, к которому и из которого всё время приводить во время вызова и внутри ф-ции

next_time ★★★★★
() автор топика
Ответ на: комментарий от reprimand

проект не мой, и я к нему не имею никакого отношения. вопрос именно, в «оценить».

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

по каким критериям определяли, если не секрет?

а если я создам тему, спросив «какой дистрибутив лучше?», это тоже не будет провокацией? да, холивар между любителями разных стилей не такой ярый, но он имеет место быть. Странно что до сих пор не начался.

reprimand ★★★★★
()
Ответ на: комментарий от i-rinat

да и «поддерживается фряха, отдельно убунта, отдельно опенсюс, отдельно дебиан.» я не соврал.

next_time ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Кстати, ты сломал форматирование.

вопросы к ЛОРу. мог починить, конечно, но лень.

next_time ★★★★★
() автор топика
Ответ на: комментарий от reprimand

да, но я ещё и выяснить хотел кой чего по делу. догадываюсь, что typedef uintptr_t сделан так для удобства смены типа внутри функции и снаружи, но всё же не совсем уверен, оправдан ли такой подход для ф-ции, которая вызывается ровно один раз. может, я ещё что-то не учитываю. i-rinat

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

для ф-ции, которая вызывается ровно один раз

Это колбек, его тип определяется функцией, в которую его передают. А она принимает ещё и другие колбеки.

Я считаю, код можно было бы чуть-чуть подправить, но толку от этого мало. Причём когда в этот уголок придёт другой программист, он захочет поправить по-своему, и так до бесконечности.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)

Формально, function pointer вроде как нельзя кастовать в void *, но вот как это напрямую соотносится с uintptr_t — хз, тут нужен юрист. Можно заставить передавать в lp2 указатель на объект типа function pointer, тогда все гарантированно будет ок. В целом все нормально (для тех кого не тошнит от винапи-стиля).

arturpub ★★
()
Ответ на: комментарий от i-rinat

не очень ясно, почему, хотя бы, не void* вместо uintptr

функцией, в которую его передают

у переданной функции разве что возвращаемое значение может отличаться, иначе UB выйдет

А она принимает ещё и другие колбеки.

не принимает. её ровно 1 раз вызывают

next_time ★★★★★
() автор топика

Во-первых тут используется «системная венгерская» нотация, что само по себе говорит о низком качестве начавшегося его программиста. Даже микрософт уже давненько нирикамендует ее использовать.

А дляуказателей на функции лучше держать отдельный тип и не заниматься ерундой.

//школьник-кун

anonymous
()

ну, во первых не надо писать строки длиной шире, чем экран. не считаю, что у меня маленький монитор, но строка с хэдером функции вылезла за пределы квотирования. вместе с этим хедер почему-то отвалился от самого тела функции аж на три линии. это художественная авторская идея или попытка ввести читателя кода в заблуждение?
вообще, я такой код читать не люблю. хотя признаю, что иногда подобное встречается. правда, чаще именно под маздаем. почему-то маздайщики любят пестроту с заглавными буквами. не лень же им шифт жмакать по пять раз на одну переменную. впрочем, они, наверное в IDEшеках с автозаполнением сидят. иначе бы быстро перестали страдать такими названиями.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Как будто в gtk_button_create_new_full шифт не надо жмакать.

наверное в IDEшеках с автозаполнением сидят

Сейчас же любой блокнот умеет дополнять однажды набранные слова.

arturpub ★★
()
Ответ на: комментарий от arturpub

Как будто в gtk_button_create_new_full шифт не надо жмакать.

дык, не надо создавать переменные_длиной_в_целое_предложение, например. их и писать неудобно, и читать тоже. и вся эта пестрота не способствует пониманию кода.

Iron_Bug ★★★★★
()
Ответ на: комментарий от arturpub

Как будто в gtk_button_create_new_full шифт не надо жмакать.

gtk_button_create_new_full --- это глобальное имя, лежащее в пространстве имён с кучей похожих, там от шифта некуда не деться. А вот pPrimaryRef в функции из семи строк --- это уже извращение.

Сейчас же любой блокнот умеет дополнять однажды набранные слова.

Вот когда блокноты ещё и читать код будут за меня, тогда и можно начинать пользоваться дополнением.

Jini ★★
()

А зачем там uintptr_t?

Deleted
()
Ответ на: комментарий от Jini

Не согласен с обоими. Нет занятия дебильнее, чем разбирать мстчкве скрщня кодеров, не осиливших средство ввода. Длинные имена это оверкилл для счетчиков коротких циклов и генерик-поинтеров (типа lp2, ага), но не для всего остального. Можете вскладчину переписать эту функцию на upddh(ob, ext, lp1, lp2) r1=ob, r2=ext и попробовать быстро воткнуть в происходящее через годик-другой. Без мощных IDE уровня ctags/grep/ctrl-f, разумеется ;)

Поругать тут можно разве что хунгарщину и смазанные типы, и это уже сделано.

arturpub ★★
()
Ответ на: комментарий от Jini

gtk_button_create_new_full --- это глобальное имя, лежащее в пространстве имён с кучей похожих, там от шифта некуда не деться.

блин, эти самонадеянные глобалисты задрали. ну ладно, в С нет неймспейсов, но там можно в структуры всё завернуть и радоваться жизни. никаких головных болей с пересечением имён. я запарилась писать разрабам либ, что они обосрались с выбором имён и конфликтуют иногда даже с кернельными хэдерами и libc! и да, в локальных переменных названия длиной в 20 символов удивляют. особенно пафосные названия счётчиков или каких-то временных переменных.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от next_time

Ох щи, перепутал uintptr_t с простым uint-ом.

Судя по манам, uintptr_t введён для манипуляций над самим указателем, а для сокрытия реализации лучше void* ничего не придумали.

E ★★★
()
Последнее исправление: E (всего исправлений: 1)

Правильно говорят выше, в сях не определено приведение указателей на функции ни к указателям на данные, ни к uintptr_t. Есть только один повод плюнуть на все эти «теоретические» заморочки: необходимость заворачивать вызовы функций из одного языка в другой. Если в повестке только си или кресты, то используй хотя бы void(*)(), а лучше настоящий тип.

const86 ★★★★★
()
Ответ на: комментарий от Harald

«никаких головных болей с пересечением имён.» ну-ну

next_time ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

в контексте «в С нет неймспейсов»? ну можно извратиться с указателем на статическую ф-цию внутри структуры, но зачем?

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

эм... в общем, иди, почитай K&R. там про указатели на функции где-то почти сразу на первых страницах вроде было написано было. и указатели на функции в структурах - это весьма популярное в сишном мире решение. это почти что классы, просто реализованные вручную. люди до появления плюсов таким образом создавали аналоги виртуальных таблиц методов. этих структур с указателями полно в кернеле. на них работают ioctl'ы, в них хранятся списки callback'ов. изначально всё именно от этих сишных указателей и пошло. потом их назвали методами, немного подшаманили перегрузку и сделали встроенным средством языка С++.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

люди до появления плюсов таким образом создавали аналоги виртуальных таблиц методов. этих структур с указателями полно в кернеле.

сам так писал, когда был привязан к си. и прекрасно знаю, что это больно и уныло.

потом их назвали методами

нет, метод, в общем случае, не реализован через указатель

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

да хоть выше, хоть ниже, хоть вдоль. один фиг иди читай K&R.

Iron_Bug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.