Если Вы пишете статью для новичков — пожалуйста, упомянтье о майкросотвовских стандартах для сигнатур и именовании методов, кидающих события и самих событий и приведите код в примерах к этим стандартам.
Он используется например в Dictionary. То есть для любого кастомного типа ключей, если встроенный хэш не устраивает можно написать свой, более эффективный.
Ну и с другой стороны, если реализуется своя имплементация того же Dictionary или чего-то еще, где нужен хэш, то удобно знать, что его поддерживают все объекты.
Мне бы тоже не хотелось, особенно если это нельзя сделать заранее и компания не Гугл.
Мне встречался вариант, когда hr-ы сказали «у нас есть свой формат анекты. Те поля, которые мы смогли выцепить из Вашего резюме мы заполнили — пожалуйста заполните оставшиеся». Вот этот подход вызывает уважение и сразу плюс в карму компании.
Если быть совсем уж справедливыми, то стоит отметить, что из-за оверхеда связанного с о сборщиком мусора и другими особенностями виртуальной машины лично у меня никогда не получалось достичь лучших относительно нативного кода производительности.
Во-первых, компиляция на ходу приводит к ощутимым задержкам, поэтому не во всех случаях удобна.
В случае автора все фильтры генерируются заранее. Здесь тоже можно сделать во время инициализации программы или ленивым образом, так что это операция которая выполняется один раз.
Во-вторых, построение кода на Expression'ах — это тоже нехилые простыни, которые в подходе write-only составят достойную конкуренцию коду на шаблонах из соседнего топика.
По поводу простыней не знаю, как по мне подход несколько более логичный, по крайней мере это использование инструмента по назначению. Все-таки шаблоны изначально задумывались несколько с другими целями.
Я бы трижды подумал, прежде чем внедрять в реальный проект такое шаманство.
Это вещь которая применяется в разовых случаях, это понятно. Равно как и подобные извращения с шаблонами.
К слову, эта оптимизация не применима в Java и C#, т.к. в generics невозможно использовать параметром значение, а не тип.
Ради справедливости стоит отметить, что в том же C# можно довольно легко средствами фреймфорка сгенерировать код фильтра во время исполнения и запускать вариант с нужным набором проверок.
Мне кажется, что на значительные расстояния (десятки км) было бы логичнее использовать ДВС, а не электромотор, или я не прав?
Не надо мучаться с заменой аккумулятора — дозаправка намного проще, к тому же запаса топлива, как мне кажется, должно хватить на большее расстояние.
Я никогда графикой не занимался, поэтому прошу прощения, если вопрос тривиальный.
Откуда Вы получили карту высот? Сгенерировали автоматически из текстур? Сделали руками «на глаз»? Или она была получена при генерировании текстуры?
Почему же в «нехороших»? По идее так система и должна работать. Если кто-то живет явно не по средствам — то в странах, на которые у нас принято равняться добрые соседи не преминут сообщить налоговой, да и сама она поинтересоваться, если совсем уж человек вызывающе богато живет при малых задекларированных доходах.
Это только у нас кристально честный гаишник спокойно скромно живет в двухэтажном особняке, записанном на мать-пенсионерку, и ездит на джипе за 50 тыс долларов по доверенности, которым владеет двоюродный 17-ти летний племянник.
Проблема у вас интересная и хорошая, но в некоторых местах категоричность суждений, уж извините, зашкаливает.
Первая проблема — они написаны под Linux. Хороша новость, то что они написаны на Си. Вообще, смотря код писанный под Linux я никак не могу побороть у себя впечатление, что возвращаюсь в доисторическую эпоху. Говорить о совместимости с Windows (т.е. якобы многоплатформенности) — совершенно не приходится (а я как минимум 3 больших проекта «смотрел»).
Если отбросить фразы про качество кода под Линукс (которое бывает очень разным), то для тестового запуска можно поднять виртуалку под линукс, написать на любом удобном языке демона, который будет обрабатывать запросы по сети от вашего програмного обеспечения и по сети же отсылает результат. Если время работы функций превышает издержки на удаленный вызов — то как минимум будет возможность проверить гипотезу и узнать стоит ли заниматься портированием.
Попробовал я партировать Phaistos в Windows… невозможно. Он использует библиотеку boost, где я после пару дней мучений пришел к однозначному выводу, библиотека сама по себе дрянь (использование шаблонов, в таком количестве, что код получается ужасным), и она не компилируется под Windows на MS Visual Studio
Boost — отличная библиотека, а использование шаблонов порой единственный вариант чтобы исправить недостатки С++ и получить оптимальную производительность. К тому же она вполне себе компилируется под Visual Studio, если брать свежие версии, то под них есть утилиты, которые автоматически собирают либы под х32 и х64 для студии.
Да, стоимость разработчиков и время разработки на Ruby, PHP или Perl будет меньше. Но если нужна высокая производительность — то придется платить хорошему С++ программисту, который пишет код без утечек памяти и проверяет продукт утилитами, следящими за валидностью доступа к памяти. Дать этому программисту больше времени, ибо на С++ кода придется написать больше.
Вопрос простой — что дешевле докупить оборудования (если продукт легко масштабируется, что бывает не всегда) или заплатить больше за разработку.
Если нужно не всеми функциями библиотеки, то можно ее использовать из-под C++ CLI сборки, методы управляемых классов которой без проблем вызываются из .Net сборок.
Ну и с другой стороны, если реализуется своя имплементация того же Dictionary или чего-то еще, где нужен хэш, то удобно знать, что его поддерживают все объекты.
Мне встречался вариант, когда hr-ы сказали «у нас есть свой формат анекты. Те поля, которые мы смогли выцепить из Вашего резюме мы заполнили — пожалуйста заполните оставшиеся». Вот этот подход вызывает уважение и сразу плюс в карму компании.
Разве что только когда на первую работу устравился, это какое-то неуважение к себе — столько ждать.
В случае автора все фильтры генерируются заранее. Здесь тоже можно сделать во время инициализации программы или ленивым образом, так что это операция которая выполняется один раз.
По поводу простыней не знаю, как по мне подход несколько более логичный, по крайней мере это использование инструмента по назначению. Все-таки шаблоны изначально задумывались несколько с другими целями.
Это вещь которая применяется в разовых случаях, это понятно. Равно как и подобные извращения с шаблонами.
Ради справедливости стоит отметить, что в том же C# можно довольно легко средствами фреймфорка сгенерировать код фильтра во время исполнения и запускать вариант с нужным набором проверок.
Не надо мучаться с заменой аккумулятора — дозаправка намного проще, к тому же запаса топлива, как мне кажется, должно хватить на большее расстояние.
Откуда Вы получили карту высот? Сгенерировали автоматически из текстур? Сделали руками «на глаз»? Или она была получена при генерировании текстуры?
На мой взгляд вполне нормальное слово, но есть еще «реализация»
>И разве по-русски нет выражения «генерические классы»?
Такого вообще никогда не слышал :) Или «дженерики» или «обобщения»
— P.S. Я буду обновлять страницу перед отсылкой комментария
Это только у нас кристально честный гаишник спокойно скромно живет в двухэтажном особняке, записанном на мать-пенсионерку, и ездит на джипе за 50 тыс долларов по доверенности, которым владеет двоюродный 17-ти летний племянник.
Если отбросить фразы про качество кода под Линукс (которое бывает очень разным), то для тестового запуска можно поднять виртуалку под линукс, написать на любом удобном языке демона, который будет обрабатывать запросы по сети от вашего програмного обеспечения и по сети же отсылает результат. Если время работы функций превышает издержки на удаленный вызов — то как минимум будет возможность проверить гипотезу и узнать стоит ли заниматься портированием.
Boost — отличная библиотека, а использование шаблонов порой единственный вариант чтобы исправить недостатки С++ и получить оптимальную производительность. К тому же она вполне себе компилируется под Visual Studio, если брать свежие версии, то под них есть утилиты, которые автоматически собирают либы под х32 и х64 для студии.
Вопрос простой — что дешевле докупить оборудования (если продукт легко масштабируется, что бывает не всегда) или заплатить больше за разработку.