LINUX.ORG.RU

полиморфная функция

 


1

1

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

#define PR_HEX_WRAP(a, b) print_hex(a, sizeof(typeof(*a)), b)

void print_hex(void *a, size_t memb_s, size_t s) {
	size_t i;
	s = s * memb_s;
	printf("0X");
	for (i = 0; i < s; i++) {
		if ((i % memb_s == 0) && (i > 0)) 
			printf(" 0X");
		printf("%X", *((uint8_t *)a + i));
	}
	printf("\n");
}

можно передавать любой массив в ф-цию PR_HEX_WRAP и макрос автоматически передает нужный размер

★★★

typeof

Хитрожопый =), тогда уж typeof надо написать свой, но если писать свой то каждый тип перед использованием нужно заранее регистрировать. В corange так сущности (структуры данных) обрабатываются например, что-бы они потом автоматически создавались и удалялись и в целом обрабатывались.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Ну если писать что-то для себя, в рамках и так уже прибитости к гцц, или что-то GNU специфичное. Или вообще нет замаха на кроссплатформу/кросскомпил. То можно и нужно. Но шаг в лево и да лучше не надо. Нельзя когда пишешь код на дядю, можно и нужно когда для себя, стандарты могут в сторонке покурить и не мешаться.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Ну если писать что-то для себя, в рамках и так уже прибитости к гцц, или что-то GNU специфичное

Тогда вы пишете не на си, а на одном из его диалектов, если это не смущает — флаг в руки.

fernandos ★★★
()

Проверка типов, как ни странно, нужна для проверки типов. А тут, что ни скормишь, не ругнётся. Ворос зачем тогда эта шняга нужна? Скриптовать на сишке? Может тогда нафиг сишку?..

anonymous
()
Ответ на: комментарий от fernandos

Дык кланг реализует фичи гцц именно поэтому стало возможно им собирать, а не потому что кланг не держал стандарт, какраз наоборот это мир прогнулся под gcc =)

Языка си выше c89 не существует. Есть только его под/над множества и часть из этих в определённх пределах и считаются языком си, где то что-о реализовано, а где то нет это обходят, где то есть надстройки и они дефакто стандарт, да если у тебя что-то типа libSDL/2 и подобное то ты крайне чувствителен к любым несовместимостям и держишь себя в рамках. Подчеркну я за расширение когда есть инструмент и нет никаких аргументов его неиспользовать, а если они есть то их вес слишком мал с весом пользы от расширения. В общем должна быть конкретика как при использовании так и нет, без религии (за исключением мне так нравится для частного и личного случая). ИМХО это всё конечно. Всё зависит от конечного проекта, для чего,куда,как,почему и прочего.

Использовать typeof сейчас как есть, а в случае выхода программы вне пределы экосистем умеющих в typeof написать для них свою реализацию да с доп телодвижениями по регистрации типов, но проще портировать gcc на что-то новое чем каждый раз изобретать что-то, так и делаеют так и повелось, за исключением тех случаев где намеренные палки в колёса android например.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Дык кланг реализует фичи гцц именно поэтому стало возможно им собирать, а не потому что кланг не держал стандарт, какраз наоборот это мир прогнулся под gcc =)

Так я к чему? Гнутый си разросся на другой компилятор, чего бы это смущало?

Языка си выше c89 не существует

А си11 тогда что?

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

100% поддержки c11 насколько я знаю нет нигде (проприетарные компиляторы не рассматриваю) Если не реализованно хоть одно требование это пожмножество языка. Если закрыть глаза на это значит можно закрыть глаза и на расширения которые есть везде и умеются всеми, а тогда и спорить не о чем =) (я про ненужность typeof)

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от fernandos

Тогда вы пишете не на си, а на одном из его диалектов, если это не смущает — флаг в руки.

А на чём пишешь ты? На пыхпитоне?

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

GCC 4.9 Changes: “ISO C11 support is now at a similar level of completeness to ISO C99 support: substantially complete modulo bugs, extended identifiers (supported except for corner cases when -fextended-identifiers is used), floating-point issues (mainly but not entirely relating to optional C99 features from Annexes F and G) and the optional Annexes K (Bounds-checking interfaces) and L (Analyzability).”

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

Даже с99 не поддерживается…

anonymous
()
Ответ на: комментарий от firkax

А на чём пишешь ты? На пыхпитоне?

Пых, жс.

Все современные Си это диалекты, у языка децентрализованное развитие

У большинства языков децентрализованное развитие. У си есть комитет людей, которые его развивают и ряд людей, которые воплощают развитие в жизнь.

Жс, к слову —- законный именно диалект экмаскрипта.

Писатели стандартов C11 и подобных - лишь одни из равноправных участников этого развития, как бы им ни хотелось считать себя его центром.

Что такое «равноправный участник»? Писатели стандарта делают одно дело, писатели компилятора другое, вы тёплое с мягким не сравнивайте.

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

gcc поддерживает c11 на уровне поддержки c99, а с99 gcc не поддерживает на 100% насколько я знаю.

Короче, я спать , скажу проще си это как лисп. Их обоих много, но вот прям взять и выделить и сказать вот это канон! можно только про одну версию в конкретной реализации и всё. И это не плохо, такова экосистема, она гибкая и назависимая, ты просто выбираешь и простора возможностей ровно те рамки которые тебу нужны и всё. =) Доброй ночи.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

gcc поддерживает c11 на уровне поддержки c99, а с99 gcc не поддерживает на 100% насколько я знаю.

Это я к тому, что вы слишком резко откинули стандарт. Тсс, ЕМНИП, полностью поддерживает 99.

Короче, я спать , скажу проще си это как лисп

Спокойной.

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

Внезапно, sizeof принимает произвольные выражения:

#define PR_HEX_WRAP(a, b) print_hex(a, sizeof(*a), b)

typeof здесь не нужен.

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

Пых, жс.

Ну вот и не изображай эксперта там где ты не в теме.

У большинства языков децентрализованное развитие.

Как раз нет, у твоего пхп развитие централизовано в команде авторов пхп.

У си есть комитет людей, которые его развивают

Нет. Люди, которые развивают си, не состоят в единой организации.

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

Повторю: ты не в теме. И те и те придумывают спецификации. Но да, различие есть: у писателей стандарта дальше болтовни дело не идёт, а авторы компиляторов свои спецификации ещё и реализуют. Писатели стандарта заимствуют идеи у msvc/gcc, ну а авторы компиляторов заимствуют идеи друг и друга и у писателей стандарта. Это важно понять: стандарт тут не имеет никакой директивной роли над остальными, это просто сочинение одной из групп, которые даже не осилили написать свой компилятор.

firkax ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Языка си выше c89 не существует.

Скорее, c89 это та единственная точка, где прошлые разрозненные ветки развития языка обобщили в единый документ, который в дальнейшем авторы всех тех веток таки приняли за базу. Такая единая точка пересечения всех форков. Но дальше они опять разошлись.

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

да, правда, я как-то не догадался

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

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

А ещё в коде есть два бага: %X -> %02X и надо little endian учитывать: a + i -> a + s - 1 - i.

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

Ну вот и не изображай эксперта там где ты не в теме.

Разрешение забыл спросить.

Как раз нет, у твоего пхп развитие централизовано в команде авторов пхп.

Лол, вы ведь ничего не знаете про написание и принятие rfc. Нет никакой «команды авторов пхп», лишь люди, которые тратят своё время.

Нет. Люди, которые развивают си, не состоят в единой организации.

Стандарт разрабатывает и готовит комитет.

Это важно понять: стандарт тут не имеет никакой директивной роли над остальными, это просто сочинение одной из групп, которые даже не осилили написать свой компилятор

Хорошо, что реализуют писатели компиляторов? Свои сны, которые чудом со стандартом совадают?

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

Лол, вы ведь ничего не знаете про написание и принятие rfc. Нет никакой «команды авторов пхп», лишь люди, которые тратят своё время.

Есть сервер, где эти rfc лежат, есть люди с правами коммитить в официальный репозиторий, есть владелец торговой марки - это всё централизация и этого всего нет у си, потому что название «си» никому не принадлежит, и все описанные процедуры могут делать одновременно хоть 10 разных организаций, и никакая из них не будет главнее других.

Стандарт разрабатывает и готовит комитет.

Ты можешь прямо сейчас создать свой C-комитет (даже зарегить его у бюрократов всяких как официально существующую организацию) и писать свой стандарт. И формально твой стандарт будет иметь ровно такую же силу, как и стандарт от того комитета, про который ты пишешь. А именно - никакую. Разница лишь в том, что у той организации уже налаженные каналы публикации своих документов. Повторюсь, это просто публикации.

Хорошо, что реализуют писатели компиляторов?

Писатели компиляторов реализуют свою спецификацию.

чудом со стандартом совадают?

Часть спецификаций совпадает, не чудом, я уже писал - идеи заимствуются и это никто не скрывает. Даже более того, у gcc есть много режимов какую именно спецификацию выбрать, там есть и спецификации от комитета - но по дефолту выбраны не они, а своя собственная, сейчас она «gnu17» называется.

А если вспомнить, что в стандарте от комитета зачем-то сложили в кучу спецификацию синтаксиса языка и спецификацию стандартной библиотеки - то всё ещё сложнее окажется, одним gcc уже не ограничиться, смотрим на glibc или ещё десяток других реализаций библиотек, уверен степень их совпадения с какими бы то ни было комитетскими стандартами везде разная и нигде не 100%. А всё потому, что у их авторов своя точка зрения на то, какой должна быть стандартная библиотека. А ещё тут добавляется ещё куча других организаций, издававших или издающих стандарты на этот счёт (BSD, POSIX, X/Open, SUS итд) - они все друг с другом частично пересекаются, частично нет, и «главной» опять нет.

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

А ещё в коде есть два бага: %X -> %02X и надо little endian учитывать: a + i -> a + s - 1 - i.

А ещё: аргумент, соответствующий спецификатору X, должен иметь тип unsigned int, в то время как *((uint8_t *)a + i) конвертируется к int.

anonymous
()

вот придумал, как сделать

кучу проблем на пустом месте

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

gcc поддерживает c11 на уровне поддержки c99, а с99 gcc не поддерживает на 100% насколько я знаю.

Сурово там у вас, погромисты. Такой же бардак, как и у нас, в реальном мире.

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

Есть сервер, где эти rfc лежат, есть люди с правами коммитить в официальный репозиторий, есть владелец торговой марки - это всё централизация

Э нет, есть люди, принимающие рфси, есть те, кто их готовят. Принимать рфси может широкий круг людей, от Расмуса лично до создателей фреймворков и ко. То, что вам кажется, что один домен — одни люди, это не так.

название «си» никому не принадлежит, и все описанные процедуры могут делать одновременно хоть 10 разных организаций, и никакая из них не будет главнее других.

«Название паспорт никому не принадлежит, вы можете печатать свой собственный и он не будет главнее паспорта вашей страны.»

Ты можешь прямо сейчас создать свой C-комитет (даже зарегить его у бюрократов всяких как официально существующую организацию) и писать свой стандарт. И формально твой стандарт будет иметь ровно такую же силу, как и стандарт от того комитета, про который ты пишешь. А именно - никакую. Разница лишь в том, что у той организации уже налаженные каналы публикации своих документов. Повторюсь, это просто публикации.

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

Писатели компиляторов реализуют свою спецификацию.

Своя спецификация — диалект си, основаный на стандарте.

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

А ещё есть стандартизированный исошный си.

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

То, что вам кажется, что один домен — одни люди, это не так.

У домена есть владелец с ультимативным административным доступом, от этого никуда не деться. Всем остальным доступ так или иначе делегирован от его имени.

«Название паспорт никому не принадлежит, вы можете печатать свой собственный и он не будет главнее паспорта вашей страны.»

Ты можешь напечатать бумажку с надписью «паспорт» на ней. Претендовать на равенство под гос. паспорту - нельзя, у государства на этот счёт есть силовые структуры. У комитета нет никаких структур по обеспечению собственного превосходства над остальными авторами С-стандартов, а также у него нет никаких юридических бумажек чтобы то же самое сделать силами гос. структур (ну там, за нарушение торговой марки например).

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

Напишешь успешную спецификацию - будут слушать. Вот авторы gcc сделали такую, пишут под неё компилятор, и многие в итоге даже не в курсе, что существуют не-gcc диалекты языка.

Своя спецификация — диалект си, основаный на стандарте.

Стандарт - диалект си, основанный на функционале имеющихся компиляторов + доп. сочинениях комитета. Всё равноправно.

А ещё есть стандартизированный исошный си.

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

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

Я ж писал что там можно выбрать и спецификацию из т.н. «стандартов».

Вот подумал - «А чего мне в Си не хватает?» и НИЧЕГО не придумал.
Си изначально разрабатывался с целью, предоставления возможности разработки алгоритмов.
И старались его не переусложнять разным синтаксисом, который якобы что-там упростит.
То бишь язык системного программирования позволил вести разработку алгоритмов любой сложности.
Все!
Что касаемого разного рода API, то это возлагалось на библиотеки.

Вот к примеру ныне в Си метапрограммирования нет.
Да и не нужно!
Разрабатываю API, который предоставляет возможности интроспекции и рефлексии в run-time /и ни какой ЯП для динамических объектов не используется/.

Теперь предположим начнут добавлять эти возможности в Си.
Его просто

УГРОБЯТ! ...
anonymous
()
Ответ на: комментарий от anonymous

Теперь предположим начнут добавлять эти возможности в Си.
Его просто УГРОБЯТ! ...

Нет, просто сделают неудачный форк. В этом и суть децентрализации - можно только делать форки, а то что уже есть - оно так и останется.

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

В этом и суть децентрализации -

Пост был не об этом …

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

Еще не много …

ИМХО Си должен упрощать работу с базовыми типами данных, памятью + stuct.
Остальное все можно реализовать через разработку API.

Ныне разработку языков программирования ведут исходя из того, что они предоставляют ЯКОБЫ удобный синтаксис, который ЯКОБЫ упрощает разработку алгоритмов.
Хороший пример - нынешний C++ …

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

ИМХО Си должен упрощать работу с базовыми типами данных, памятью + stuct.

ИМХО struct как раз могли бы и улучшить.
У меня свой, который позволяет для каждого поля и всей структуры в целом использовать свойства ЛЮБОЙ СЛОЖНОСТИ.
Это позволяет много упростить разработку алгоритмов …

anonymous
()

понимаю, что наверно не первый такой умный,

Ну да молодец!
Года через три загляни в этот тред и УЛЫБНИСЬ …

anonymous
()
Ответ на: комментарий от firkax

У домена есть владелец с ультимативным административным доступом, от этого никуда не деться. Всем остальным доступ так или иначе делегирован от его имени.

Хватит уже сову на глобус натягивать, домен — не решающая составляющая разработки языка. Даже если он домен переадресует на ЛОР, разработка не остановится.

Ты можешь напечатать бумажку с надписью «паспорт» на ней. Претендовать на равенство под гос. паспорту - нельзя, у государства на этот счёт есть силовые структуры. У комитета нет никаких структур по обеспечению собственного превосходства над остальными авторами С-стандартов, а также у него нет никаких юридических бумажек чтобы то же самое сделать силами гос. структур (ну там, за нарушение торговой марки например).

У комитета есть авторитет.

Напишешь успешную спецификацию - будут слушать. Вот авторы gcc сделали такую, пишут под неё компилятор, и многие в итоге даже не в курсе, что существуют не-gcc диалекты языка.

Успешной она станет, когда её будут поддерживать. Чтобы её поддерживали нужен спрос, чтобы был спрос нужно, чтобы её поддерживали компиляторы.

Стандарт - диалект си, основанный на функционале имеющихся компиляторов + доп. сочинениях комитета. Всё равноправно.

У вас детская травма от написания своего стандарта? Я вам ещё раз говорю, авторитета не будет.

У тебя единственная ошибка в том, что ты стандарты считаешь директивными документами, кого-то к чему-то обязывающими.

Да нет же, стандарт — авторитетная версия языка, из-за своей авторитетности эта версия является референсной.

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

авторитета не будет.

У тебя - не будет. Но не обобщай.

авторитета

стандарт — авторитетная версия языка

Хорошее определение, только тогда придётся отказаться от заявления о том, что стандарт - это то, что опубликовал комитет. Версия языка от gcc не менее авторитетна, а может и более, следовательно она тоже стандарт. Так что возвращаемся к тому что я уже писал: есть несколько равноправных веток развития, которые взаимно обмениваются фичами.

референсной

Референсной версии языка не бывает. Бывает референсная реализация спецификации. А поскольку спецификаций много - то и референсная реализация у каждой может быть своя. Для GNU спецификаций (их тоже много) референсная реализация это gcc. Для стандартов от комитета - не существует.

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

У тебя - не будет. Но не обобщай.

И у вас не будет, форумные эксперты мало где ценятся.

Хорошее определение, только тогда придётся отказаться от заявления о том, что стандарт - это то, что опубликовал комитет. Версия языка от gcc не менее авторитетна, а может и более, следовательно она тоже стандарт

Точно не более авторитетна, напомните, шланг реализовал все гнутые дополнения и фичи?

Так что возвращаемся к тому что я уже писал: есть несколько равноправных веток развития, которые взаимно обмениваются фичами.

Отнюдь не равноправных, одни важнее.

Референсной версии языка не бывает.

Тут референсная в значении ссылочная, та, на которую ссылаются.

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

И у вас не будет, форумные эксперты мало где ценятся.

Ну, я вобщем-то и не претендовал особо. Хотя и не исключаю такой возможности - спецификацию и компилятор к ней (для личного пользования - хочется свой си с нужными фичами и без ненужных) 3 года назад начал делать, но хватило где-то на полтора месяца только, потом забил. А так вдруг когда-то доделаю, опубликую, и всем понравится, всякое может быть.

Точно не более авторитетна, напомните, шланг реализовал все гнутые дополнения и фичи?

Шланг не нужен. Но вообще они много чего повторяют за gcc - понимают, что если их компилятор не получится хотя бы в большинстве случаев просто подставить вместо gcc (включая неизменность опций командной строки) - то никому они не нужны будут.

Отнюдь не равноправных, одни важнее.

Если кто и важнее, то явно не комитет.

Тут референсная в значении ссылочная, та, на которую ссылаются.

Ссылаться можно и туда и туда.

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

в стандарте от комитета зачем-то сложили в кучу спецификацию синтаксиса языка и спецификацию стандартной библиотеки

Затем, что это была одна из двух целей создания стандарта, без достижения которой ты не сможешь реализовать даже простейшую (отличную от main(){}) программу, соответствующую стандарту - весь ввод/вывод «библиотечный», а возвращаемое значение - особенность реализации.

Шланг не нужен.

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

Пора перемотать календарик с 2012 на 2022.

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

Шланг не нужен

Ещё как нужен. Конкуренция, чем больше реализаций, тем лучше.

Если кто и важнее, то явно не комитет.

А кто же? Комитет — это люди, разработчики.

Ссылаться можно и туда и туда.

А слушать вас станут только в одном случае.

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

А кто же? Комитет — это люди, разработчики.

Разработчики реально существующих компиляторов. Программы на си пишут затем, чтобы потом компилятор сделал из них бинарники. Следовательно, исходник должен подходит под компилятор (иначе он бесполезен). Всяческая макулатура со спецификациями - вторична.

А слушать вас станут только в одном случае.

Я пока что вообще никуда не ссылался, а ты меня уже слушаешь и даже что-то отвечаешь.

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

Разработчики реально существующих компиляторов

А они слушают комитет, иногда его дополняя.

Всяческая макулатура со спецификациями - вторична

По вторичной макулатуре клепаются первичные компиляторы. Серьёзно, вы пишете на гнуСи и вам так не нравится, что это не общепринятый стандарт?

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