Я не против комментариев в коде, но для меня важнее понятный лаконичный код, который сам всё объясняет и без комментариев.
Не очень то и помогают комментарии, если код написан в плохом стиле и непонятно.
Возврат функцией объекта, превышающего размер регистра, нежелателен.
В данном случае, при нехватке места в eax (IA32), будет неявно задействован стэк, а в eax попадёт указатель на объект. Не смертельно, но не очень и приятно. Расширение стека потока может и обломиться например и тогда удивлённый программист получит исключение на ровном месте.
Лучше использовать указатель на объект для таких случаев, или ссылку.
В Винде очень большие проблемы с исключениями, поэтому механизм SEH полностью и переписали для amd64. С++ же исключения обычно реализуются через SEH.
Генерация прерывания, переход в ядро, с раскручиванием SEH-фрэймов стэка вызовов, при этом, как правило останавливаются все конвееры процессора. Не говоря уже о локальной раскрутке, например при использовании try/finally, это нехилое замедление производительности.
Именно по этому, использование исключений кроме как для обработки ошибок, например для управления логикой программы, смертельно. Я их под IA32 вообще стараюсь не использовать. Кроме как мест, где без SEH не обойтись.
— Мне не нравится C++, большинство моих проектов на Си, даже если использую плюсы, то у меня это Си с классами, оборачивающие API.
— Я просмотрел мельком код и ничего не понял.
— Я абсолютно не понимаю, какое преимущество у этих макросов перед обычным объявлением dll-экспортируемых функций и обычной линковкой. Или использованием LoadLibrary/GetProcAddress. На первый взгляд кода не меньше. А при желании, можно написать враппер вокруг этого апи.
— Я не использую исключения в приложениях под ОС Windows, именно С++ исключения, а не чистый SEH или VEH.
Поэтому и страшно. Но на самом деле я просто ничего не понял в вашем коде, я уверен что я не один такой. А это очень плохо, если код не прозрачен. Не надо играться с чрезмерными абстракциями, на мой взгляд.
Если ее модифицировать, например динамически менять делающий вычисления код
Ничего особо не измениться.
Кстати, а зачем мучиться с переписыванием функции на пхп, если можно взять js код и подумать как выполнить его в своей программе?
Правильно, либо написать расширение php на Си, либо расширение MySQL. Если сторонний демон не устраивает (я бы написал тупо сторонний демон, который держал у себя подготовленные выражения и подставлял туда данные по требованию), тогда надо разобраться как компилируются эти выражения, где они хранятся (в процессе клиенте БД, либо в демоне и взаимодействуют через сокет).
Возможно и хучить ничего не придётся.
Да, кстати, сон не отменял никто :)
Та схема, которую вы привели выше, может быть реализована несколькими способами.
Результат будет один и тот же. Если вам интересно, то мы можем с вами написать пример и статью.
Я просто не вижу разницы откуда через интерфейс попадут данные в подготовленное выражение. Из стороннего процесса, или из своего процесса. У вас есть f(a, b) какая ей разница откуда попадут параметры? Главное, чтобы результат вернулся куда надо.
Если же вы тонко намекаете на то, что неплохо бы копировать само подготовленное выражение из процесса в процесс… Зачем? Если есть аккумулятор этой фигни. Но даже в этом случае, я более чем уверен, что можно и это скопировать. Ничего процессозависимого в скомпилированном выражении нет.
Ну можно всегда серриализовать не сам объект, а нужные данные в кэш. В любом случае доступ к памяти процесса (пускай и чужого), быстрее чем запрос к реляционной БД.
Я понял о чём вы. Я всё о том же, кто мешает не закрывать такие соединения и держать подготовленные выражения между выполнениями скрипта? Хотябы какое-то время, или до определённых действий?
Кроме этого, мне казалось, что базу можно настроить таким образом, чтобы такие вещи попадали в кэш.
Ну если процесс интерпретатора не завершается после обработки запроса, наподобие fastcgi, то можно кэшировать данные в его адресном пространстве в промежутках, или использовать что-то типа buletcache/memcache итд.
Парень к успеху шел, не фартануло, не свезло! :)
com.bzpn.vpp.system.cup.FGCFTemplateImplication.removeEntity(broken);
На первый взгляд слишком это как-то длинно.
Не очень то и помогают комментарии, если код написан в плохом стиле и непонятно.
Хоткеи и консоль выдаёт КПД быстрее любого рабочего стола.
static double epsilon()Возврат функцией объекта, превышающего размер регистра, нежелателен.
В данном случае, при нехватке места в eax (IA32), будет неявно задействован стэк, а в eax попадёт указатель на объект. Не смертельно, но не очень и приятно. Расширение стека потока может и обломиться например и тогда удивлённый программист получит исключение на ровном месте.
Лучше использовать указатель на объект для таких случаев, или ссылку.
Генерация прерывания, переход в ядро, с раскручиванием SEH-фрэймов стэка вызовов, при этом, как правило останавливаются все конвееры процессора. Не говоря уже о локальной раскрутке, например при использовании try/finally, это нехилое замедление производительности.
Именно по этому, использование исключений кроме как для обработки ошибок, например для управления логикой программы, смертельно. Я их под IA32 вообще стараюсь не использовать. Кроме как мест, где без SEH не обойтись.
— Мне не нравится C++, большинство моих проектов на Си, даже если использую плюсы, то у меня это Си с классами, оборачивающие API.
— Я просмотрел мельком код и ничего не понял.
— Я абсолютно не понимаю, какое преимущество у этих макросов перед обычным объявлением dll-экспортируемых функций и обычной линковкой. Или использованием LoadLibrary/GetProcAddress. На первый взгляд кода не меньше. А при желании, можно написать враппер вокруг этого апи.
— Я не использую исключения в приложениях под ОС Windows, именно С++ исключения, а не чистый SEH или VEH.
Поэтому и страшно. Но на самом деле я просто ничего не понял в вашем коде, я уверен что я не один такой. А это очень плохо, если код не прозрачен. Не надо играться с чрезмерными абстракциями, на мой взгляд.
Ничего особо не измениться.
Кстати, а зачем мучиться с переписыванием функции на пхп, если можно взять js код и подумать как выполнить его в своей программе?
Возможно и хучить ничего не придётся.
Да, кстати, сон не отменял никто :)
Результат будет один и тот же. Если вам интересно, то мы можем с вами написать пример и статью.
Если же вы тонко намекаете на то, что неплохо бы копировать само подготовленное выражение из процесса в процесс… Зачем? Если есть аккумулятор этой фигни. Но даже в этом случае, я более чем уверен, что можно и это скопировать. Ничего процессозависимого в скомпилированном выражении нет.
Кроме этого, мне казалось, что базу можно настроить таким образом, чтобы такие вещи попадали в кэш.