На что только ни пойдут разрабы, лишь бы названия нормальные не придумывать. Компилятор-то можно настроить как угодно. Но языки программирования ведь придуманы прежде всего для людей, чтобы они понимали, что происходит. И сами же дают такие названия из разряда value для переменной
А обязательно вот так сложно говорить на собеседовании, например, "инверсия зависимостей"?
Для меня SOLID это просто набор рекомендаций, которые помогают держать код в порядке. Это даже не что-то конкретное, что можно описать словами. Это такое состояние ума, к которому рано или поздно приходишь сам, набивая шишки, либо тебя этому учат коллеги на код-ревью.
То есть рекомендаций/лайфхаков, как делать код гибким/понятным такое огромное множество, что любое перечисление принципов SOLID, KISS и прочих - это маленькая капля в море личного опыта.
Конкретные правила - это скорее решения лида, которых должна придерживаться вся команда. И правила эти могут идти вразрез и с SOLID, и с кодстайлом. Особенно это касается лямбд, ломающих сокрытие данных, либо каких-нибудь паттернов, делающих то же самое.
Было бы неплохо, если бы все программисты на личном опыте понимали, зачем придуман SOLID. Но есть ли способ при приеме на работу не парить мозг зубрежкой терминов из конкретных книг/статей?
Та же "инверсия зависимостей" странный термин. Зависимостей в идеале быть вообще не должно. Если один кусок кода лезет в другой, это просто невозможно тестировать
Преимущество LINQ больше не в читаемости, а в том, что там есть оптимизации. Например, из всех команд выборок он формирует один запрос к БД
В С++ скорее всего будет просто цикл с наивным перебором элементов по условию. Так же можно и на шарпе написать. Но если очень хочется имено LINQ синтаксиса, можно использовать CLINQ. Или что-то свое сделать, уж лямбды-то в плюсах имеются
Но сейчас мне не нравится то, куда идет современный С++ - туда пытаются втащить все на свете
Мне кажется, это должен решать каждый программист сам. Например, пользоваться только модерн C++, запретив себе использовать старые парадигмы после перехода на новый стандарт. Тогда код будет написан в одном стиле, понятен и легок в масштабировании. Получится фактически тот самый новый прекрасный язык с небольшим количеством нужных инструментов. И новый язык изобретать будет уже не нужно только для того, чтобы новички не "стреляли себе в ногу", просто потому что им в руки попалось ружьë. То есть искусственно ограничивать набор инструментов путем создания нового языка
В моем случае это были ресурсы OpenGL, к которому из других потоков обращаться запрещено драйвером. А объекты могут удаляться и создаваться в разных потоках. Пришлось писать отдельную очередь, которая собирает графические ресурсы, а потом основной поток, владеющий контекстом OpenGL, все это обрабатывает, когда до него добирается
Очень актуально для игрового движка. При отрисовке каждого кадра приходится создавать и чистить большое количество данных (треугольники, иерархии игровых сущностей). Быстрее всего сразу "застолбить" побольше памяти, а потом с помощью собственного аллокатора брать оттуда кусочки под расчеты. Поскольку игра должна работать быстро и плавно, обращаться в ОС за памятью не эффективно, а данных перекладывать с места на место надо очень много
Действительно, после такого опыта многопоток кажется не сложным. Это и "один пишет, другие читают", и "как танцевать девушку". При этом мютексы ставились только на очень узкие места (в основном взятие или добавление объектов в контейнеры).
Но поскольку у нас игра, объекты может создавать и игрок, и поток подгрузки. Возникают очень хаотичные взаимодействия потоков в самых разных комбинациях. Каким-то образом всë это получилось разрулить и заставить работать быстро и без вылетов.
В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.
Статья слишком сильно манипулирует выводами на основе субъективных ощущений автора
Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.
Спасибо за статью. Очень ëмко и просто навела на некоторые мысли.
Я не мог начать пользоваться Rust пять лет назад из-за того, что просто не представлял, как со всеми этими ограничениями можно что-то сделать. То есть нужно действительно начать мыслить по-другому.
Сейчас у меня есть опыт параллельного программирования в С++, в этом очень сильно помогли умные указатели, которые следят за владением объекта и чисткой памяти. Они гарантируют отсутствие битых указателей, т.к. пока какой-то поток "одолжил" указатель, память в нем не чистится. Как недостаток, нельзя сказать точно, когда в рантайме объект освободится и в какой момент запустится деструктор, а главное из какого потока (например, к OpenGL можно обращаться только из главного потока, поэтому просто так из деструктора объекта, хранящиеся в shared_ptr, данные OpenGL не удалишь).
Тем не менее умные указатели и ссылки в плюсах - очень крутые средства, спасающие от выстрела в ногу. Мне кажется, заставив себя на них перекатиться, я постепенно дойду и до понимания Rust.
А теперь вопрос (он наверняка гуглится, но если всë гуглить, то о чем писать в комментах?). Rust многие вещи делает в компиляторе. Это ведь и по эффективности получается лучше, чем ООП в плюсах со всякими контейнерами и умными указателями? В плюсах это наверняка сплошной рантайм и достаточно тяжелый.
Приведу пример, как можно сделать делегат с параметрами без создания обертки, так это обычно и используют:
public class Health {
public delegate void DamageTaken(float damage);
public event DamageTaken OnDamageTaken; // will be triggered on damage
public delegate void PlayerDead(); // will be triggered when dead.
public event PlayerDead OnDead;
private float health = 100;
// call this to do damage
public void TakeDamage(float damage) {
if (health <= 0) return;
health -= 20;
if (OnDamageTaken != null) // null check is required because if there is no subscribers it produces error when invoking
{
OnDamageTaken.Invoke(damage);
}
if (health <= 0) {
if (OnDead != null) {
OnDead.Invoke();
}
}
}
}
С переменными идея понятна, т.к. хочется, чтобы можно было подписываться на изменение переменной. Но всё равно делать их публичными - очень плохое архитектурное решение. Если нужно подписаться на изменение здоровья извне, надо создать соответствующий ивент или делегат. Иногда можно нарушать правила, но в подобных статьях я не делал бы этого. Новичков и так постоянно учат плохому.
Насчет ссылок и указателей плохо понял. В С# любая переменная, содержащая объект, это аналог shared_ptr из C++ со всеми вытекающими проблемами. Есть кстати в C# и обычные C указатели, ими можно пользоваться в unsafe коде. Узнал недавно и удивился :)
P.S.: в этом примере делается проверка на null, но есть более короткая форма OnDamageTaken?.Invoke(damage);
По этой статье совершенно непонятно, зачем нужна обертка вокруг делегата, которая делает в точности то же самое, что и он? Также странное решение делать публичные переменные, обернутые в обертки. Какой-то ужасно приторный синтаксический сахар просто чтобы показать, что автор умеет писать шаблонные методы. Все это можно накодить в 3 строчки кода, если просто правильно пользоваться знанием среды и языка, не изобретая велосипед. Возможно, я неправ.
Подход делить логики и использовать делегаты сам по себе неплох. Но это тоже подходит не для всего. В некоторых случаях просто необходимо забить логику гвоздями просто чтобы никто ее не сломал неправильной настройкой компонентов. А делегаты - это больше чтобы звуки и партиклы на персонажа вешать
Автор сам себя дискредитировал тем, что пошел кодить критичную к производительности задачу совершенно не подходящим для этого способом. Там не только switch и c-стайл, но и ассемблер будет не лишним.
А чистый код это больше высокоуровневая архитектура и вот это вот все. Какие-нибудь сервисы, общающиеся с 1000 других сервисов. И это происходит в вэбе, в котором такие задержки, что выигрыш в паре тактов процессора вообще не принесет пользы.
Ну тут видимо изучалось одно конкретное явление. Вообще у ЧД уйма замудрённых свойств таких как специфические магнитные поля, виртуальные фотоны, смещение спектра (упомянутого в сообщении выше). В результате вращения ЧД ореол диска немного искажается и сбоку становится видно небольшой "пузырёк" (тоже линзирование, можно найти картинки с ним). Не представляю как вообще возможно было бы всё это симулировать :) Ну а в данном конкретном видео очевидно — сферическая черная дыра в вакууме.
На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого
На что только ни пойдут разрабы, лишь бы названия нормальные не придумывать. Компилятор-то можно настроить как угодно. Но языки программирования ведь придуманы прежде всего для людей, чтобы они понимали, что происходит. И сами же дают такие названия из разряда value для переменной
А обязательно вот так сложно говорить на собеседовании, например, "инверсия зависимостей"?
Для меня SOLID это просто набор рекомендаций, которые помогают держать код в порядке. Это даже не что-то конкретное, что можно описать словами. Это такое состояние ума, к которому рано или поздно приходишь сам, набивая шишки, либо тебя этому учат коллеги на код-ревью.
То есть рекомендаций/лайфхаков, как делать код гибким/понятным такое огромное множество, что любое перечисление принципов SOLID, KISS и прочих - это маленькая капля в море личного опыта.
Конкретные правила - это скорее решения лида, которых должна придерживаться вся команда. И правила эти могут идти вразрез и с SOLID, и с кодстайлом. Особенно это касается лямбд, ломающих сокрытие данных, либо каких-нибудь паттернов, делающих то же самое.
Было бы неплохо, если бы все программисты на личном опыте понимали, зачем придуман SOLID. Но есть ли способ при приеме на работу не парить мозг зубрежкой терминов из конкретных книг/статей?
Та же "инверсия зависимостей" странный термин. Зависимостей в идеале быть вообще не должно. Если один кусок кода лезет в другой, это просто невозможно тестировать
Преимущество LINQ больше не в читаемости, а в том, что там есть оптимизации. Например, из всех команд выборок он формирует один запрос к БД
В С++ скорее всего будет просто цикл с наивным перебором элементов по условию. Так же можно и на шарпе написать. Но если очень хочется имено LINQ синтаксиса, можно использовать CLINQ. Или что-то свое сделать, уж лямбды-то в плюсах имеются
Мне кажется, это должен решать каждый программист сам. Например, пользоваться только модерн C++, запретив себе использовать старые парадигмы после перехода на новый стандарт. Тогда код будет написан в одном стиле, понятен и легок в масштабировании. Получится фактически тот самый новый прекрасный язык с небольшим количеством нужных инструментов. И новый язык изобретать будет уже не нужно только для того, чтобы новички не "стреляли себе в ногу", просто потому что им в руки попалось ружьë. То есть искусственно ограничивать набор инструментов путем создания нового языка
В моем случае это были ресурсы OpenGL, к которому из других потоков обращаться запрещено драйвером. А объекты могут удаляться и создаваться в разных потоках. Пришлось писать отдельную очередь, которая собирает графические ресурсы, а потом основной поток, владеющий контекстом OpenGL, все это обрабатывает, когда до него добирается
Очень актуально для игрового движка. При отрисовке каждого кадра приходится создавать и чистить большое количество данных (треугольники, иерархии игровых сущностей). Быстрее всего сразу "застолбить" побольше памяти, а потом с помощью собственного аллокатора брать оттуда кусочки под расчеты. Поскольку игра должна работать быстро и плавно, обращаться в ОС за памятью не эффективно, а данных перекладывать с места на место надо очень много
Действительно, после такого опыта многопоток кажется не сложным. Это и "один пишет, другие читают", и "как танцевать девушку". При этом мютексы ставились только на очень узкие места (в основном взятие или добавление объектов в контейнеры).
Но поскольку у нас игра, объекты может создавать и игрок, и поток подгрузки. Возникают очень хаотичные взаимодействия потоков в самых разных комбинациях. Каким-то образом всë это получилось разрулить и заставить работать быстро и без вылетов.
В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.
Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.
Спасибо за статью. Очень ëмко и просто навела на некоторые мысли.
Я не мог начать пользоваться Rust пять лет назад из-за того, что просто не представлял, как со всеми этими ограничениями можно что-то сделать. То есть нужно действительно начать мыслить по-другому.
Сейчас у меня есть опыт параллельного программирования в С++, в этом очень сильно помогли умные указатели, которые следят за владением объекта и чисткой памяти. Они гарантируют отсутствие битых указателей, т.к. пока какой-то поток "одолжил" указатель, память в нем не чистится. Как недостаток, нельзя сказать точно, когда в рантайме объект освободится и в какой момент запустится деструктор, а главное из какого потока (например, к OpenGL можно обращаться только из главного потока, поэтому просто так из деструктора объекта, хранящиеся в shared_ptr, данные OpenGL не удалишь).
Тем не менее умные указатели и ссылки в плюсах - очень крутые средства, спасающие от выстрела в ногу. Мне кажется, заставив себя на них перекатиться, я постепенно дойду и до понимания Rust.
А теперь вопрос (он наверняка гуглится, но если всë гуглить, то о чем писать в комментах?). Rust многие вещи делает в компиляторе. Это ведь и по эффективности получается лучше, чем ООП в плюсах со всякими контейнерами и умными указателями? В плюсах это наверняка сплошной рантайм и достаточно тяжелый.
С этим соглашусь
Приведу пример, как можно сделать делегат с параметрами без создания обертки, так это обычно и используют:
С переменными идея понятна, т.к. хочется, чтобы можно было подписываться на изменение переменной. Но всё равно делать их публичными - очень плохое архитектурное решение. Если нужно подписаться на изменение здоровья извне, надо создать соответствующий ивент или делегат. Иногда можно нарушать правила, но в подобных статьях я не делал бы этого. Новичков и так постоянно учат плохому.
Насчет ссылок и указателей плохо понял. В С# любая переменная, содержащая объект, это аналог shared_ptr из C++ со всеми вытекающими проблемами. Есть кстати в C# и обычные C указатели, ими можно пользоваться в unsafe коде. Узнал недавно и удивился :)
P.S.: в этом примере делается проверка на null, но есть более короткая форма OnDamageTaken?.Invoke(damage);
По этой статье совершенно непонятно, зачем нужна обертка вокруг делегата, которая делает в точности то же самое, что и он? Также странное решение делать публичные переменные, обернутые в обертки. Какой-то ужасно приторный синтаксический сахар просто чтобы показать, что автор умеет писать шаблонные методы. Все это можно накодить в 3 строчки кода, если просто правильно пользоваться знанием среды и языка, не изобретая велосипед. Возможно, я неправ.
Подход делить логики и использовать делегаты сам по себе неплох. Но это тоже подходит не для всего. В некоторых случаях просто необходимо забить логику гвоздями просто чтобы никто ее не сломал неправильной настройкой компонентов. А делегаты - это больше чтобы звуки и партиклы на персонажа вешать
Автор сам себя дискредитировал тем, что пошел кодить критичную к производительности задачу совершенно не подходящим для этого способом. Там не только switch и c-стайл, но и ассемблер будет не лишним.
А чистый код это больше высокоуровневая архитектура и вот это вот все. Какие-нибудь сервисы, общающиеся с 1000 других сервисов. И это происходит в вэбе, в котором такие задержки, что выигрыш в паре тактов процессора вообще не принесет пользы.
Ну тут видимо изучалось одно конкретное явление. Вообще у ЧД уйма замудрённых свойств таких как специфические магнитные поля, виртуальные фотоны, смещение спектра (упомянутого в сообщении выше). В результате вращения ЧД ореол диска немного искажается и сбоку становится видно небольшой "пузырёк" (тоже линзирование, можно найти картинки с ним). Не представляю как вообще возможно было бы всё это симулировать :) Ну а в данном конкретном видео очевидно — сферическая черная дыра в вакууме.
В какой-то мере потемнение справа на симуляции НАСА можно отнести к этому эффекту.
Возможно, на симуляции не видимый спектр, а диапазон радиоизлучения (как на снимке, сделанном в этом году).
На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
( ;-p )
Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого