Я как раз и имел в виду, что некорректно сравнивать разные по своей природе NoSQL хранилища. Если говорить конкретно о RocksServer, то его основную область применения я вижу в достижении высокой производительности за счет переноса данных с HDD на более быстрый носитель и экономия на инфраструктуре за счет использования SDD вместо памяти. Тут не так уж и много вариантов для сравнения.
Для полиморфизма:
Динамическое(во время выполнения) определение типов
Так и не понял зачем для полиморфизма динамическое определение типа? Видимо это как то связано с реализацией.
Идея написать язык на препроцессорных директивах весьма экстравагантна. Хотя сама идея иметь ООП язык конвертируемый в С вполне может быть оправдана.
Я бы для этой задачи использовал лексер.
Это конечно старый спор, но на сегодняшний день нет никаких причин считать, что C++ медленнее С. С отдают предпочтение перед С++ вовсе не из-за производительности программы, а совсем по другим причинам: 1) не везде есть компилятор С++, но почти везде есть компилятор С 2) программисты «старой школы» так и не принявшие С++
Посмотрел еще раз. К сожалению, наскоком так не смог найти почему я от нее отказался. На первый взгляд, с того момента когда я последний раз ее смотрел, код очень сильно поменялся.
Каково ваше впечатление от использования? Какие-нибудь глюки ловили? В последнее время я часто вижу ее в топе Гитхаба в разделе C++. Может быть ее уже допилили и там действительно все хорошо.
Я у себя так и собираю. src/description-pak у меня как раз для checkinstall и лежит. Просто по идее сборка может проходить на любом Линукс дистрибутиве. Поэтому я не стал про это здесь писать. Тем более на Хабре уже много раз про checkinstall писали, поэтому мне показалось что не обязательно еще раз напоминать. Кстати для удаления я не забыл добавит команду make uninstall. Так что в данном конкретном случае make install вполне безопасен.
Да я ее видел. Я тоже изначально хотел ее использовать. Честно, сейчас уже не вспомню что мне не понравилось, но отказался я от нее поковыряв исходники. Сейчас еще раз посмотрю попробую ответить подробнее.
У RocksDB специфичная область применения. Поэтому сравнивать его нужно с хранилищами одного класса. Разумеется Redis'у она проиграет (по крайней мере при старте точно должна). Логичным было бы сравнивать, я думаю, с RethinkDB т.к. это тоже зрелое решение пригодное для установки на SDD носитель. Но я таких тестов не видел, а у самого пока руки не дошли их написать.
Полностью поддерживаю автора. Хабр как-то плавно, но уверенно из крутого IT ресурса превратился в коллективный блог про космос и гаджеты. Раньше так не было.
По поводу слива кармы и минусования адекватных топиков. Сам такое видел не раз.
Исправить ситуацию могло бы обязательное коментирование кнопки «минус» у топика что бы отдельные граждане с синдромом вахтера не минусовали просто потому что им кажется, что автор не прав. Но лишь в том случае, когда четко могут объяснить в чем именно не прав.
На самом деле ваш комментарий не опровергает мой, а подтверждает: увлечение ассоциативными массивами является проблемой, но php-сообщество ее не замечает.
Да, писать код с ассоциативными массивами вместо классов, вероятно, быстрее. И в этом даже нет ничего плохого, если вы пишите короткий скрипт или код предназначенный только для вас. Но если ваш код придется кому то читать (а код все же чаще читают чем пишут), то вы просто перекладываете проблемы на чужие плечи.
Смысл очень простой — ассоциативные контейнеры предназначены не для замены ООП, а для совсем других целей. Кроме того, использование ассоциативных массивов вместо классов лишает ваш код тех и без того не больших возможностей статической типизации, которые дает php.
Примерно так. На первый взгляд кажется, что кода стало больше, но на самом деле (если не вырывать кусок кода из контекста), читаемость от такого подхода улучшится.
А еще лучше было бы вообще не использовать публичные поля, а использовать гетеры и сетеры.
На мой взгляд, описанные проблемы надуманы.
Комментариями код не испортишь. Они без проблем игнорируются при беглом осмотре за счет подсветки синтаксиса в редакторе кода. О причине предпочтения классов функциям сказано выше.
Вот о чем, на мой взгляд следовало бы сказать — это повальное увлечение PHP-сообщества ассоциативными массивами. В 9-ти случаях из 10-ти использование массивов не уместно.
Причем люди пришедшие в php из других ООП языков, таких как C++ или Java, обычно замечают эту странность.
Поясню. Например, в C++ тоже есть ассоциативные контейнеры, такие как std::map и std::unordered_map. Но никому не придет в голову использовать эти контейнеры там, где уместно было бы определить тип данных. Т.е. создать класс.
Эта тенденция является продолжением стиля программирования порождаемого отсутствием статической типизации. Но в данном конкретном случае средства языка явно позволяют писать более аккуратный и читаемый код. Поскольку классы в php все же определят пользовательский тип данных, но программисты все равно продолжают использовать ассоциативные массивы вместо классов.
Кстати, нет никаких причин не помещать мелкие классы порождаемые от одного и того же интерфейса в один файл.
Я присоединяюсь к этому комментарию и очень прошу не заставлять меня каждый раз нажимать на ссылку «Полная версия». На 10" планшете с ретиной мобильные версии сайтов вообще не нужны.
Особенно это неудобно когда читаешь Хабр через Твиттер.
Что бы прочитать статью теперь мне нужно промотать ее вниз (это на устройстве без скролла и кнопки «end» ) перейти к полной версии, затем уж начинать чтение. И так на каждом заинтересовавшем меня посте.
Я думаю что авторы таким названием заложили перспективы роста. Кроме того CppFramework точно воспринималось бы неоднозначно т.к. никаких ассоциаций с веб'ом не вы вызает. Чего не скажешь о названии CppCMS.
Последняя версия (1.1) действительно стабильна, в отличии от 1.0 и ей можно пользоваться в продакшене. Насколько мне известно, в прродакшене ее используют в компании автора библиотеки.
В любом случае после компиляции нужно запускать тесты. Я сам, к сожалению, так и не установил ее у себя на серверах из-за старого дебиана (старый gcc без c++11) — все руки никак не дойдут обновить. Как только обновлю буду использовать без сомнений.
Автор, вы про PHP-CPP слышали? Попробуйте на нем переписать.
Расширения написаные Зендовскими макросами категорически невозможно читать. Особенно, когда код без комментариев.
К тому же писать расширение на PHP-CPP для обертки C++ библиотек — тривиальная задача.
Автор, интересно было бы узнать какие вообще сейчас решают задачи на ваших суперкомпьютерах. Конкретно, начали ли их использовать для решения прикладных задач или только учебные? Какие компиляторы используются? По вашей ссылке я вижу, что сейчас есть возможность компилировать C++. Раньше был только С. Сами на чем писали? Какой стандарт C++ поддерживается?
Так и не понял зачем для полиморфизма динамическое определение типа? Видимо это как то связано с реализацией.
Идея написать язык на препроцессорных директивах весьма экстравагантна. Хотя сама идея иметь ООП язык конвертируемый в С вполне может быть оправдана.
Я бы для этой задачи использовал лексер.
Каково ваше впечатление от использования? Какие-нибудь глюки ловили? В последнее время я часто вижу ее в топе Гитхаба в разделе C++. Может быть ее уже допилили и там действительно все хорошо.
src/description-pakу меня как раз для checkinstall и лежит. Просто по идее сборка может проходить на любом Линукс дистрибутиве. Поэтому я не стал про это здесь писать. Тем более на Хабре уже много раз про checkinstall писали, поэтому мне показалось что не обязательно еще раз напоминать. Кстати для удаления я не забыл добавит командуmake uninstall. Так что в данном конкретном случаеmake installвполне безопасен.По поводу слива кармы и минусования адекватных топиков. Сам такое видел не раз.
Исправить ситуацию могло бы обязательное коментирование кнопки «минус» у топика что бы отдельные граждане с синдромом вахтера не минусовали просто потому что им кажется, что автор не прав. Но лишь в том случае, когда четко могут объяснить в чем именно не прав.
Да, писать код с ассоциативными массивами вместо классов, вероятно, быстрее. И в этом даже нет ничего плохого, если вы пишите короткий скрипт или код предназначенный только для вас. Но если ваш код придется кому то читать (а код все же чаще читают чем пишут), то вы просто перекладываете проблемы на чужие плечи.
Смысл очень простой — ассоциативные контейнеры предназначены не для замены ООП, а для совсем других целей. Кроме того, использование ассоциативных массивов вместо классов лишает ваш код тех и без того не больших возможностей статической типизации, которые дает php.
А еще лучше было бы вообще не использовать публичные поля, а использовать гетеры и сетеры.
Комментариями код не испортишь. Они без проблем игнорируются при беглом осмотре за счет подсветки синтаксиса в редакторе кода. О причине предпочтения классов функциям сказано выше.
Вот о чем, на мой взгляд следовало бы сказать — это повальное увлечение PHP-сообщества ассоциативными массивами. В 9-ти случаях из 10-ти использование массивов не уместно.
Причем люди пришедшие в php из других ООП языков, таких как C++ или Java, обычно замечают эту странность.
Поясню. Например, в C++ тоже есть ассоциативные контейнеры, такие как std::map и std::unordered_map. Но никому не придет в голову использовать эти контейнеры там, где уместно было бы определить тип данных. Т.е. создать класс.
Эта тенденция является продолжением стиля программирования порождаемого отсутствием статической типизации. Но в данном конкретном случае средства языка явно позволяют писать более аккуратный и читаемый код. Поскольку классы в php все же определят пользовательский тип данных, но программисты все равно продолжают использовать ассоциативные массивы вместо классов.
Кстати, нет никаких причин не помещать мелкие классы порождаемые от одного и того же интерфейса в один файл.
Особенно это неудобно когда читаешь Хабр через Твиттер.
Что бы прочитать статью теперь мне нужно промотать ее вниз (это на устройстве без скролла и кнопки «end» ) перейти к полной версии, затем уж начинать чтение. И так на каждом заинтересовавшем меня посте.
В любом случае после компиляции нужно запускать тесты. Я сам, к сожалению, так и не установил ее у себя на серверах из-за старого дебиана (старый gcc без c++11) — все руки никак не дойдут обновить. Как только обновлю буду использовать без сомнений.
Расширения написаные Зендовскими макросами категорически невозможно читать. Особенно, когда код без комментариев.
К тому же писать расширение на PHP-CPP для обертки C++ библиотек — тривиальная задача.