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


Все проще. Компилятор считает ошибкой, если переданный указатель имеет другой тип. А если принудительно привести тип, то из-за различия пролога/эпилога программа развалится - явно указанный тип void() ничего возвращать не должен, а функция другого формата может сначала поместить что-то на стек поверх адреса возврата.

<удалено из-за того, что коллега mOleg этого не понял>

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


Так он от int приводится, а не от другого указателя.

Хорошая теория. Мне скриншоты приводить, что ли? Можно подумать, я не проверял варианты. Программа разваливается. Точка. Есть рабочий код, который позволяет смешивать функции разного формата? Прошу его сюда, всем будет полезно. Только не RTFM, и не "вот как-то так", я хочу видеть рабочий проверенный код. А пока что проверенный код есть у меня, и он показывает, что когда void() - оно работает, а когда void() и int() - оно вылетает. Возможно, это и можно победить, комбинируя pragma, но это ставит работоспособность кода в зависимость от инструментального окружения. А его же куда-то встраивать надо.

<удалено из-за того, что коллега mOleg этого не понял>

<удалено из-за того, что коллега mOleg этого не понял>

<удалено из-за того, что коллега mOleg этого не понял>

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

<удалено из-за того, что коллега mOleg этого не понял>

Разумеется. Я же стараюсь ломать код, а не искать "то самое положение провода, при котором есть контакт". Есть современные реалии - тот же D, та же Visual Studuo. Не просто gcc, а Qt Creator. Ну что ж я сделаю, если большая сборка падает от экспериментов? Предлагаете зачитывать стандарт в микрофон, чтобы компилятор устыдился? Я понимаю источник этих проблем и мне не нравится полагаться на то, что параметры всегда сами правильно удалятся. Раз этого не происходит, подход полагаем спорным и не делаем так. Потому что сейчас у нас разные результаты, а у третьего (четвертого, пятого и т.д.) автора будут какие? И где гарантия, что он не попадет в ситуацию, обнаруженную мной?

<удалено из-за того, что коллега mOleg этого не понял>

Стоп! Что именно похоже на заплатку? Я пробую совершенно штатное решение с единообразным форматом функций. Вы утверждали, что это плохо, и можно сделать эффективнее. Этого следует достигать путем отказа от статического контроля, передачей в рантайме указателей на функции с прологом/эпилогом произвольного вида. Это гораздо больше похоже на заплатку.

Он не смог исполнить код Форта. Мы об этом, или о частном случае, когда ошибка не проявилась на первом простом примере?

<удалено из-за того, что коллега mOleg этого не понял>

Да ладно! В стандарте Си написано "не используйте только void()"? Или там написано "можно принудительно приводить типы функций, при этом любая реализация должна обеспечивать нормальную работу программы при несоответствии типов в рантайме"?


А это не огромный конгломерат, а всего-навсего тот финальный продукт, в котором он должен работать. А то можно посчитать производительность алгоритма на массиве в 10 чисел, и потом удивляться, почему она не масштабируется линейно для десятка гигабайт.


Добавляем сомнительный код - не работает. Убираем сомнительный код - работает. Был бы код не сомнительным, можно было бы грешить на что-то еще.


Так напишите более качественный и разъясните, как его писать. Тема-то вполне конкретная. У меня не на код нет времени и не на обсуждение, а вот на эти лавирования между Вашими шпильками. Ошибки, увертки, непонимания основ,... чего там еще? Вы хотя бы понимаете, что у меня ни обиды, ни раздражения на такое ребячество не возникает? А возникает только ощущение "ой, у меня на работе проблемы, никто не слушает, амбиции играют, кого бы поучить, чтобы погреть ЧСВ". По-другому никак? Здесь в горло не вгрызаются, и в подпол не загоняют. Не та ситуация, нет такой конкуренции между фортерами. Что, если тут вытереть о собеседника ноги, то потом можно будет показать работодателю ссылку, и возьмут не его, а Вас? Или после бытового вампиризма веселее работается? Не тот случай. Обсуждать надо недостатки подходов, а не людей. А то все сядут по углам и надуются.

<удалено из-за того, что коллега mOleg этого не понял>

<удалено из-за того, что коллега mOleg этого не понял>