yoshakar писал(а): ↑08.02.2015 16:51
Нет, вы знаете, для меня писать на си - удовольствие, и совсем не напряжно.
потому что у вас ответственность нулевая. Т.е. вам наплевать, что ваш код тупо возьмёт и рухнет. Вам никто не позвонит в 3 часа ночи, и не помянет вашу матушку. Потому вы можете использовать опасные и дырявые идиомы, просто ради интереса.
Вы просто не понимаете, что писать код для собственного удовольствия, и систему инициализации в продакшен — две большие разницы.
yoshakar писал(а): ↑08.02.2015 16:51
А вот если применить ваши советы, то действительно получится либо неподдерживаемое УГ, либо вообще ничего не получится, поскольку написание хэлловорлда затянется на годы.
IRL так оно и получается. Даже хуже, ибо создание helloworld ver 6.6.6 будет тормозить version 2.3.2. В итоге на практике получится половина систем на version 2.3.2-7743bis, а вторая половина на 4.7.1-172beta, который вроде как 6.6.6, но частично совместим с 2.3.2.
yoshakar писал(а): ↑08.02.2015 16:51
Вот то, что для вас это - извращение, быдлокод и очень сложно, означает, что для вас писать на си сложно, а не для меня.
ну я-бы не стал в этом случае использовать таблицу указателей на функции, а применил-бы простой switch case. А если-бы и стал, то использовал-бы size_t в качестве индекса. Ну и обмазался-бы битовыми операциями, дабы не зафейлится с делением(которое к тому же — самая долгая операция).
Но это вряд-ли, зачем мне такое извращение там, где достаточно простого switch/case? Которое, кстати, компилятор сам в состоянии переделать в таблицу как у вас, если конечно в этом есть смысл.
yoshakar писал(а): ↑08.02.2015 16:51
В ваших рассуждениях есть одно очень слабое место: вы ещё моих скриптов не видели.
в скриптах нужно *очень* постараться, что-бы вызвать UB или утечку памяти, или ещё что-то плохое. В скриптах вам никто не даст выделять память и её освобождать (вы можете только тонко намекнуть, сказав unset). Неинициализированные переменные в скриптах ВСЕГДА равны "пусто" или "0". В скриптах не бывает указателей, а следовательно, всех проблем, которые с ними связаны (есть eval с другими проблемами, но без eval можно обойтись, а без указателей — увы). Даже если в скриптовом ЯП есть ссылки, с ними тоже не бывает проблем как в C++, если вы вернёте из функции ссылку на внутреннюю переменную, то в C++ получите UB. В скрипте всё будет работать как ожидается, GC просто не будет удалять эту ссылку. Последовательность действий в скриптовых ЯП *всегда* однозначна, и прописана в документации. В C/C++ компилятор крутит как ему вздумается.
Да, это конечно плохо для производительности, но зачем она в рассматриваемом случае? Если у вас медленно "разогревается" СУБД, то чем вам сишка поможет? СУБД и так на сишке написана.
yoshakar писал(а): ↑08.02.2015 16:51
потому что писать на скриптах для меня - действительно мучение.
просто вы не удосужились изучить ЯП.
Сишка только с виду "простая", на самом деле, UB там на каждом шагу понаставлено. Интерпретатор сразу вам по рукам даст вывалив ошибку какую-то или просто неправильный результат вроде 2*2=5. А сишка скомпилируется без ошибок, и даже будет выдавать 2*2=4. ВНЕЗАПНО она вам выдаст 123278*3782=1. Почему? Да кто же его знает? А может и испортить чего-нить.
yoshakar писал(а): ↑08.02.2015 17:05
Aviator, это же просто баг. Его пофиксят, и всё будет хорошо.
в SysV такого бага нет. Ну и зачем?