Просто фраза «Но почти все реализации, виденные мной на просторах интернетиков, предлагают использовать один std::thread для одной очереди. С моей точки зрения это не есть хорошо. » — она предполагает что были исследованы основные реализации.
А на деле оказывается что самая распространенная, Boost.Asio, являющаяся практически стандартом дефакто, вообще не рассмотрена. Не удивлюсь если окажется что вообще ничего из мейнстримных библиотек не было исследовано, и та фраза — просто фигура речи.
Если абстрагироваться от велосипедов и вернуться к реальной разработке, то с помощью Boost.Asio вы можете делать именно то что вы в этом примере привели (почти буквально). Только вместо слова async будет слово post, а вместо queue будет io_service.
Но рассмотрим подробнее, откуда взялось предположение, что приведенный код должен приводить к вызову конструктора Renderable::Renderable(bool visible) вместо Renderable::Renderable().
Ну кто его знает. Может __declspec(dllimport/dllexport) для класса предотвращает встраивание методов.
Во-вторых, по никакого обязательного будет нет.
Компилятор может встроить метод, а может вызвать его. Во втором случае символ метода будет прилинкован согласно типу связывания (в MSVC он задается атрибутом dllimport), т.е. будет скорее всего использован правильный метод из другой ДЛЛ.
А задавал я вопрос потому что не уверен что приведенное решение гарантирует что-либо.
(Ну а насчет того работает ли оно вообще — поверил автору)
А что будет если default_delete<MyClass>::operator() заинлайнится компилятором, и соответственно его тело вызовется не из того модуля где объект создан, а из вызывающего?
Таких задач намного больше, чем тех, в которых нужно знание математики
Хорошо, что вы это осознаете.
Но сомневаюсь, что есть люди, которые бы хотели всю жизнь решать именно такие задачи.
Это смотря какие задачи. Есть очень много интересных.
И например, если брать этот ваш аргумент про интерес, то я бы не хотел всю жизнь решать задачи подобные вашим задачам 1-3.
Как вы думаете, что важнее для вас — сердце или печень?
Неуместная аналогия. Бывают программисты не умеющие либо то либо то, но не бывает людей без печени либо сердца.
А можно в качестве подтверждения пользы математики привести какие-то более близкие к жизни задачи?
Например, та же задача 1, но при этом охранник может работать не более 2 суток подряд, и всего 5 охранников, каждый из которых работает не пересекаясь с другими. Сгененерировать равномерный график для всех охранников.
Что про эту задачу говорит математика?
Или например, можете привести соотношение задач, которые рассмотрены в математике, к тем которые не рассматриваются ею?
Как думаете, что важнее для программиста — изучить математику или научиться читать чужой код и отлаживать программы?
И последнее: что вы понимаете под математикой (для программиста)? Математику в целом или например только дискретную математику?
Суть вопроса была такова — практически невозможно представить себе ситуацию, когда строка потеряет рефы одновременно из двух нитей, а стало быть атомарная операция в данном случае избыточна.
В принципе предпосылка интересная, но…
Что же тут интересного? Полностью ложная предпосылка.
Все равно что сказать что невозможно представить что Земля крутится вокруг Солнца. Т.е. сказать такое конечно кто-то может, имея девственно чистый мозг, но вместо того чтобы доказывать ему обратное, надо отправить его изучать основы.
Это именно что вброс.
Потому что если рассматривать данный опус серьезно, то из него следует, что автор — дурак.
Он откуда-то высосал утверждение, что полиморфизм умееет решать любые задачи, и потом его опроверг (по его мнению).
При этом сама задача вполне успешно решается с помощью хеш-таблицы.
Создается словарь ИмяКласса-Флаг. И при проверке просто по имени класса извлекается этот флаг.
Никаких IF/case не надо.
А учитывая что именно перебор вариантов через IF/case является проблемой, против которой направлен полиморфизм, то никакой нужды в полиморфизме на уровне языка для данной задачи нет, т.к. этой проблемы в данном случае нет.
Т.е. автор не сумел даже подобрать задачу которая бы нам продемонстрировала неспособность полиморфизма ее решить.
Ну и ненависть автора к С++, выражаемая несколько раз по ходу статьи, в которой к тому же С++ вообще не рассматривается, тоже не говорит о большом уме.
Исключения позволяют писать на порядки более простой (а значит и надежный) код за счет отделения прикладного кода от обработки ошибок.
Это окупает любые недостатки присущие исключениям.
(Под более простым кодом я понимаю например линейный код, вместо кода с ветвлениями, каждую ветку которых надо отлаживать или покрывать юниттестами, что возможно только для простейших случаев)
Хотя приведенный здесь аргумент, что любая функция может вызвать исключение, и можно забыть его обработать, — не годится.
1) У кодов возврата такая же проблема. Каждая функция может возвращать код возврата и его можно забыть обработать.
2) Суть исключений в том что их надо не ловить на каждый чих, а обработать для какого-то крупного логически завершенного блока из нескольких вычислений. В правильно построенной программе вообще очень мало мест где надо ловить исключения.
Во-первых, это всего 2 простых теста, а не вся функциональность которая требуется.
Во-вторых, для генерации тела метода там нужно слишком много телодвижений делать.
В-третьих, Eclipse люто тормозит, особенно на больших проектах.
Думаю, что JetBrain'овская IDE тоже будет тормозить.
Признаю, Eclipse — достаточно мощный.
Но пользоваться им комфортно нельзя.
Возможно и лучше.
Но «лучше» это понятие субъективное.
У меня есть два простых теста, которые должна пройти IDE чтобы я ее вообще начал рассматривать как С++ IDE.
1)
boost::shared_ptr<S> s;
s->
После ввода "->" должны быть предложены для автозаполнения поля и методы класса S.
2)
// S.hpp
namespace N
{
class S
{
void method1();
void method2();
};
}
// S.cpp
#include "S.hpp"
namespace N
{
void S::method1() // но не N::S::method1
{
}
// место для вставки method2
}
Должна быть возможность не более чем в два клика сгенерировать заготовку тела метода из объявления метода в классе.
При этом тело метода должно вставиться в тот же .cpp где уже находятся другие методы класса, либо в алфавитном либо в порядке объявления. А также если тело вставляется в неймспейс, то не должно быть избыточного квалифицирования этого неймспейса в упоминаниях типов описанных в нем.
Я так понимаю у вас новый KDevelop установлен. Можете проверить, умеет он это? Спасибо
Скажите это Стивену Хокингу.
А на деле оказывается что самая распространенная, Boost.Asio, являющаяся практически стандартом дефакто, вообще не рассмотрена. Не удивлюсь если окажется что вообще ничего из мейнстримных библиотек не было исследовано, и та фраза — просто фигура речи.
Если абстрагироваться от велосипедов и вернуться к реальной разработке, то с помощью Boost.Asio вы можете делать именно то что вы в этом примере привели (почти буквально). Только вместо слова async будет слово post, а вместо queue будет io_service.
От незнания языка С++? :)
Во-вторых, по никакого обязательного будет нет.
Компилятор может встроить метод, а может вызвать его. Во втором случае символ метода будет прилинкован согласно типу связывания (в MSVC он задается атрибутом dllimport), т.е. будет скорее всего использован правильный метод из другой ДЛЛ.
А задавал я вопрос потому что не уверен что приведенное решение гарантирует что-либо.
(Ну а насчет того работает ли оно вообще — поверил автору)
default_delete<MyClass>::operator()заинлайнится компилятором, и соответственно его тело вызовется не из того модуля где объект создан, а из вызывающего?Хорошо, что вы это осознаете.
Это смотря какие задачи. Есть очень много интересных.
И например, если брать этот ваш аргумент про интерес, то я бы не хотел всю жизнь решать задачи подобные вашим задачам 1-3.
Неуместная аналогия. Бывают программисты не умеющие либо то либо то, но не бывает людей без печени либо сердца.
Например, та же задача 1, но при этом охранник может работать не более 2 суток подряд, и всего 5 охранников, каждый из которых работает не пересекаясь с другими. Сгененерировать равномерный график для всех охранников.
Что про эту задачу говорит математика?
Или например, можете привести соотношение задач, которые рассмотрены в математике, к тем которые не рассматриваются ею?
Как думаете, что важнее для программиста — изучить математику или научиться читать чужой код и отлаживать программы?
И последнее: что вы понимаете под математикой (для программиста)? Математику в целом или например только дискретную математику?
инопланетянлюдей, которым удобно, даже когда трей и таскбар вообще не видны.А вы тут про цвет :)
Что же тут интересного? Полностью ложная предпосылка.
Все равно что сказать что невозможно представить что Земля крутится вокруг Солнца. Т.е. сказать такое конечно кто-то может, имея девственно чистый мозг, но вместо того чтобы доказывать ему обратное, надо отправить его изучать основы.
Потому что если рассматривать данный опус серьезно, то из него следует, что автор — дурак.
Он откуда-то высосал утверждение, что полиморфизм умееет решать любые задачи, и потом его опроверг (по его мнению).
При этом сама задача вполне успешно решается с помощью хеш-таблицы.
Создается словарь ИмяКласса-Флаг. И при проверке просто по имени класса извлекается этот флаг.
Никаких IF/case не надо.
А учитывая что именно перебор вариантов через IF/case является проблемой, против которой направлен полиморфизм, то никакой нужды в полиморфизме на уровне языка для данной задачи нет, т.к. этой проблемы в данном случае нет.
Т.е. автор не сумел даже подобрать задачу которая бы нам продемонстрировала неспособность полиморфизма ее решить.
Ну и ненависть автора к С++, выражаемая несколько раз по ходу статьи, в которой к тому же С++ вообще не рассматривается, тоже не говорит о большом уме.
Но я бы не стал из этого никаких выводов делать :)
Это окупает любые недостатки присущие исключениям.
(Под более простым кодом я понимаю например линейный код, вместо кода с ветвлениями, каждую ветку которых надо отлаживать или покрывать юниттестами, что возможно только для простейших случаев)
Хотя приведенный здесь аргумент, что любая функция может вызвать исключение, и можно забыть его обработать, — не годится.
1) У кодов возврата такая же проблема. Каждая функция может возвращать код возврата и его можно забыть обработать.
2) Суть исключений в том что их надо не ловить на каждый чих, а обработать для какого-то крупного логически завершенного блока из нескольких вычислений. В правильно построенной программе вообще очень мало мест где надо ловить исключения.
Во-вторых, для генерации тела метода там нужно слишком много телодвижений делать.
В-третьих, Eclipse люто тормозит, особенно на больших проектах.
Думаю, что JetBrain'овская IDE тоже будет тормозить.
Признаю, Eclipse — достаточно мощный.
Но пользоваться им комфортно нельзя.
Но «лучше» это понятие субъективное.
У меня есть два простых теста, которые должна пройти IDE чтобы я ее вообще начал рассматривать как С++ IDE.
1)
После ввода "->" должны быть предложены для автозаполнения поля и методы класса S.
2)
Должна быть возможность не более чем в два клика сгенерировать заготовку тела метода из объявления метода в классе.
При этом тело метода должно вставиться в тот же .cpp где уже находятся другие методы класса, либо в алфавитном либо в порядке объявления. А также если тело вставляется в неймспейс, то не должно быть избыточного квалифицирования этого неймспейса в упоминаниях типов описанных в нем.
Я так понимаю у вас новый KDevelop установлен. Можете проверить, умеет он это? Спасибо
А под Линуксом QtCreator — единственный полноценный вариант.
Остальные умеют только зачатки С++.